none
Forefront TMG detected a possible SYN attack and will protect the network accordingly. RRS feed

  • Общие обсуждения

  • Здравствуйте.

     

    Начали испытывать следующую проблему.

     

    Несколько раз в неделю, после появления записи в логах - "Forefront TMG detected a possible SYN attack and will protect the network accordingly.", TMG блокирует весь трафик (со всех интерфейсах), до полявления в логах следующей записи - "Forefront TMG is no longer experiencing a SYN attack."

     

    Чем регулируется данная система защиты от SYN attack?

    В “Intrusion Prevention System” – “Configure Flood Mitigation Settings” есть следующая опция -> “Maximum half-open TCP connections”, которая не регулируется а явлется половиной от “Maximum concurrent TCP connections”.

    В описании данной опции сказано: TMG block requests from a specific IP address with more than the specified limit of concurrent half-open TCP connections. Тоесть TMG должен блокировать новые half-open TCP соединения с IP а не блокировать ВЕСЬ трафик.

     

     

    Установили “Maximum concurrent TCP connections” на 100 соединений, тоесть “Maximum half-open TCP connections” = 50

     

    Настроили уведомления с TMG. Небыло ни одного уведомления о том что TMG заблокировал с какого либо IP новые half-open TCP коннекты. Только о превышении лимита максимального количества одновременных соединений с IP адреса.

     

     

    На форумах вычитал следующую информацию:

     

    SYN Attack thresholds are configurable.

    Following are the default settings for SYN attack  – we have 2 settings here

     

    "SynAttackHalfOpenEnable" – default 1000 decimal

     

    "SynAttackHalfOpenDisable" – default 200 decimal

     

    These are reg key values under HKLM\System\CCS\Service\fweng\parameters

     

    So, as soon as global half opened connections goes over 1000 we are not going to start accepting any more connections until the number of half opened connections goes below 200. Existing connections will continue to function OK – it will just be new connections that are affected.

    http://social.technet.microsoft.com/Forums/en-US/Forefrontedgegeneral/thread/db60398b-c8f2-4d25-8f85-94ffb5aaeb7e/

     

     

    Тоесть из этой информации следует, что данная система защиты регулируется по средствам изменения реестра.

    Пробовал применить это на практике. В результате после перезагрузки сервера – TMG не пропускал трафик вообще (Записей в журнале о SYN attack не было). Использовал следующие значения:

     

    "SynAttackHalfOpenEnable" – 9000 decimal (dword (32-bit) Value)

    "SynAttackHalfOpenDisable" – 8000 decimal (dword (32-bit) Value)

     

    "SynAttackHalfOpenEnable" – 95000 decimal (dword (32-bit) Value)

    "SynAttackHalfOpenDisable" – 94000 decimal (dword (32-bit) Value)

     

    После каждых изменений перезагружал сервер. Не знаю возможно где-то допустил ошибку при добавлении ключей в реестр. Как говорил выше, с данными ключами в реестре TMG не пропускал трафик. После удаления ключей и перезагрузки сервера, все заработало.

     

     

     

    Возможно ли отключить данную защиту? Или возможно ли какими либо средствами предупредить ее срабатывание

    На данный момент в сети около 90+ workstations и 30+ серверов. Тоесть возможно что лимит half-open TCP connections превышается внутренними хостами. Вопрос – каков этот лимит (его значение). Как его можно регулировать?

     

    Если будут какие либо вопросы по конфигурации/другие – задавайте, все отвечу.

     

    PS: на многих форумах, был дан ответ в духе – надо лечить болезнь а не симптомы – это не вариант. Потому как нам необходимо предоставлять клиентским машинам довольно широкий доступ (и владелец рабочей машины является локальным администратором).

    И главное – получается что данная защита направленая от DDOS сама по себе является встроенным DDOSером, потому как с одного компьютера можно уложить TMG инициировав определенное количество SYN запросов на TMG.

     

    19 июля 2011 г. 11:57

Все ответы

  • Ну если лечить не хотите, то уберите галку Mitigate flood attacks... и спите спокойно.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    20 июля 2011 г. 8:24
    Модератор
  • Здравствуйте

     - Ну если лечить не хотите, то уберите галку Mitigate flood attacks... и спите спокойно.

    Убрал. Проспал неделю спокойно, после чего Forefront TMG detected a possible SYN attack and will protect the network accordingly повторилось.

    Снимал галку без особого интузиазма, потому как на ISA сервере была подобная проблема, и отключение всех "защитных" механизмов не приносило результата.

    Буду рад любому совету

     

    Спасибо

    29 июля 2011 г. 13:50
  • Дополнительно

     - PS: на многих форумах, был дан ответ в духе – надо лечить болезнь а не симптомы – это не вариант.

    Сейчас буду благодарен, если поможите выяснить корень сего зла...

    Воспользовавшись советом данным здесь - http://social.technet.microsoft.com/Forums/ru-RU/isaru/thread/1863df32-d3c7-427c-8687-650f24cbfd82/ , сделал БАТ файл который пишет в момент возможной "SYN Attack" в txt файл результат "netstat -n -a -b -p tcp > C:\tcp.txt" команды и отсылает уведомление на почту о возможной SYN attack.

    Результат netstat -n -a -b -p tcp ничего не дал, потому как в момент "атаки" в файле есть всего три записи - c SYN_RECEIVED:

     TCP    **.**.**.1:11272       **.**.**.85:53303      SYN_RECEIVED [wspsrv.exe]

      TCP    **.**.**.1:11482       **.**.**.85:53316      SYN_RECEIVED [wspsrv.exe]

      TCP    **.**.**.1:11850      **.**.**.56:49845     SYN_RECEIVED [wspsrv.exe]

    Или одну запись с SYN_RECEIVED надо вопринимать как возможную SYN attack?

     

    Заранее благодарен любой помощи

    29 июля 2011 г. 14:17
  • Источник SYN пакетов?
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    1 августа 2011 г. 2:21
    Модератор
  •  - Источник SYN пакетов?

      Proto  Local Address          Foreign Address        State

    ============================================================

              TMG server                 айпи из LAN

     TCP    **.**.**.1:11272       **.**.**.85:53303      SYN_RECEIVED [wspsrv.exe] -

      TCP    **.**.**.1:11482       **.**.**.85:53316      SYN_RECEIVED [wspsrv.exe]

    ============================================================

              TMG server                 айпи из LAN (из гостевой сети с ограниченным доступом)

      TCP    **.**.**.1:11850      **.**.**.56:49845     SYN_RECEIVED [wspsrv.exe]

    ============================================================

     

    Несколько часов спустя, произошло еще два случая с возможными SYN attack-ами.

    Записи в TXT файле не содержат ни одной строки с SYN_RECEIVED, но при этом TMG блокировал весь трафик.

    Должен сказать что после последней СИН атаки в txt файле есть порядка 100-120 записей:

    TCP  от куда: внешний айпи TMG server;  куда: 67.215.65.132:80 SYN_SENT

    Не знаю, является ли это проблемой

    Так же после выключения Mitigate flood attacks - случаи с SYN attack-ами начали заканчиваться BSODами.

     

    Результат анализа BSODов - Probably caused by : fwpkclnt.sys ( fwpkclnt!FwpsInjectNetworkReceiveAsync0+183 )

    Испытываем аналогичные проблемы с BSODами в других офисах. Майкрософтом было посоветованно установить следующий hotfix - http://support.microsoft.com/kb/2469100/en-us для устранения проблемы с BSODами в других офисах, буду пробовать и на текущем (но это уже другая история)


    • Изменено Igor Korytko 1 августа 2011 г. 6:35 исправления
    1 августа 2011 г. 6:34
  • И дополнительно: хотелось бы понять, как работает TMG, какие настройки регулируют поведение TMG при обнаружении SYN attack.

     

    На данный момент:

     - Mitigate flood attacks выключено

     - в Configure Detection Settings for Common Network Attacks - Enable intrusion detection включено - Ip half-scan выключено.

     

    Но при этом TMG продолжает блокировать трафик при появлении - "Forefront TMG detected a possible SYN attack and will protect the network accordingly"

     
    1 августа 2011 г. 6:46
  • проверьте порядок привязок адаптеров - внутренний адаптер должен быть первым и использовать внутренний днс-сервер, днс на внешнем адаптере не должен быть настроен

    отключите netbios, если он включен


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    2 августа 2011 г. 8:13
  • По порядку:

     - проверьте порядок привязок адаптеров

    не совсем понял, что значит порядок привязок адаптеров.

     -  внутренний адаптер должен быть первым и использовать внутренний днс-сервер

    что значит - должен быть первым. Есть 5 внутренних сет. интерфейсов и 1 смотрит в мир. Только один сетевой интерфейс (внутренний - CRM) ипользует DNS.

     - днс на внешнем адаптере не должен быть настроен

    не настроен

     - отключите netbios, если он включен

    отключен на всех интерфейсах

     

    PS: не знаю, поменяет ли что-то - используем VLANы. Сетевой адаптер Intel PRO/1000 GT Desktop Adapter. Intel pro set (дистрибутив от Intel) дает возможность настраивать/создавать VLANы. Так вот есть 5 виртуальных сетей (внутренних) и встроенный сетевой адаптер используется для External (на External включен только TCP/IP v4, и напомню - ДНС нет, НетБиос - нет)

    3 августа 2011 г. 8:53
  • VLAN могут вызывать проблемы

    распишите более подробно часть Internal-tmg - как у вас организованы интерфейсы-вланы


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    3 августа 2011 г. 9:22
  • Sorry for the delay.

     - распишите более подробно часть Internal-tmg - как у вас организованы интерфейсы-вланы

    Всего два сетевых адаптера. Встроенный Realteck как писал выше используется для External.

    Внешний PCI адаптер - Intel PRO/1000 GT Desktop Adapter. Установлен Intel Pro Set.

    Создано 5 виртуальных сетей (VLAN):

    LAN1; LAN2; LAN3; LAN4; Guest

    (LAN1/LAN2/etc... имеют разные назначения с разными наборами правил, в подробности вдаваться не буду, думаю речь не о том)

     

    Правила:

    Между LAN1-LAN2-LAN3-LAN4 правило Route

    LAN -> Guest  через NAT (для возможности управления WiFi в гостевой сети).

    Все 5 внутренних сетей натятся в мир.

    Может не совсем то инфо которое ожидалось. Что именно вас интересует? Настройки в TMG или виндовая часть, как созданны VLANы?

     

    PS: не совсем пойму как VLANs могут создавать проблемы с SYN атаками. Около 2-ух лет использовали ISA сервер (испытывали проблемы с SYN at. на ISA server так же.). Где-то пол года назад перешли на TMG. 3-4 месяца после перехода все было хорошо. Около месяца назад проблема вернулась

    4 августа 2011 г. 11:58
  • а сам tmg в каком vlan?

    кстати, посмотрите, mac-адреса виртуальных адаптеров не один и тот же?


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    4 августа 2011 г. 12:28
  •  - а сам tmg в каком vlan?

    если имеете в виду - TMG console - System - Свойства TMG сервера - Communication - Intra-array communication -> тогда тут выбран айпи из CRM сети (один из этих - LAN1; LAN2; LAN3; LAN4)

     

    - кстати, посмотрите, mac-адреса виртуальных адаптеров не один и тот же?

    одинаков, но проблемы как таковой не вижу. они в разных сетях, тоесть одинаковых мак адресов в одной сети нет (тоесть можно представить что эти сетевые интерфейсы воткнуты в разные свичи, которые никак не связанны между собой). Могу добавить что в другом офисе используем Broadcom адаптеры с VLANs - мак адерса одинаковы на виртуальных адаптерах, проблем с SYN атаками ни разу не возникало - тот офис работает порядка 2-ух лет.

     

    PS: могу показаться надоедливым, но все же, хотелось бы получить ответ на данный вопрос -

    И дополнительно: хотелось бы понять, как работает TMG, какие настройки регулируют поведение TMG при обнаружении SYN attack.

    Если этой настройкой - Mitigate flood attacks, тогда совсем не понятно, потому как в описании защиты от SYN attack написало что TMG должен блокировать новые соединения для IP который превысил лимит а не блокировать весь трафик:

    Mitigates SYN attacks by blocking requests from an IP address with which more than the specified number of half-open TCP connections exist.

    5 августа 2011 г. 8:58
  • - кстати, посмотрите, mac-адреса виртуальных адаптеров не один и тот же?

    одинаков, но проблемы как таковой не вижу. они в разных сетях, тоесть одинаковых мак адресов в одной сети нет (тоесть можно представить что эти сетевые интерфейсы воткнуты в разные свичи, которые никак не связанны между собой). Могу добавить что в другом офисе используем Broadcom адаптеры с VLANs - мак адерса одинаковы на виртуальных адаптерах, проблем с SYN атаками ни разу не возникало - тот офис работает порядка 2-ух лет.

    Здесь, я напротив считаю, что это потенциально может быть источником проблемы. То, что с адаптером другого производителя работает - не показательно, потому что не факт, что реализация VLAN и взаимодействия между ними в драйверах адаптеров одинакова у интел и броадком.

    Посмотрите в perfomace monitor tmg количество backlogged packets, какие у вас значения при нормальной работе и при блокировке

    проверьте состояние службы MS forefront tmg firewall при блокировке

    ну и посмотрите эту статью и рекомендации из нее http://blogs.technet.com/b/isablog/archive/2009/01/12/isa-server-2006-stops-answering-requests.aspx

     

     

     


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    5 августа 2011 г. 9:50
  • Уважаемый пользователь!
    В вашей теме отсутствует активность в течение последних 5 дней. При отсутствии каких-либо действий в течение 2 последующих дней, тема будет переведена в разряд обсуждений. Вы можете возобновить дискуссию, просто оставив сообщение в данной теме.
    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    15 августа 2011 г. 7:13
  • И снова здравствуйте.

     Всем спасибо за советы, будем изучать и искать возможное решение. Пока решение не найдено - продолжаем страдать от того же поведения TMG ->

     1. Forefront TMG detected a possible SYN attack and will protect the network accordingly

     2. TMG блокирует весь трафик.

    Ответ по теме пока небыл дан (кроме второго ответа - Ну если лечить не хотите, то уберите галку Mitigate flood attacks... и спите спокойно. , но это ничего не поменяло, поведение TMG осталось прежним).

    Буду благодарен за любую предоставленную информацию по теме.

     

    Спасибо!

    5 сентября 2011 г. 10:10
  • Есть одна идея.

    Собственно описано все тут http://blogs.technet.com/b/isablog/archive/2009/01/12/isa-server-2006-stops-answering-requests.aspx

    Краткий смысл - выновато может быть правило типа "разешить/запретить ВЕСЬ траффик на набор URL".

    Под это правило логично подходит весь траффик и TMG приходится на каждый пакет делать запрос к DNS для резольвинга адресов из списка, на все это время пакет висит в ожидании на TMG, и при наличии в сети  например пары-тройки торрент-клиентов и/или 2х-3х секундной проблеме с доступом к DNS серверам быстро приводит к переполнению очереди полуоткрытых соединений.

    В общем вероятное решение заключается в одном предложении - "Note that normally URLs only apply to HTTP and as such this rule should have been limited to HTTP protocol."

    10 октября 2011 г. 8:42
  • У нас та же проблема. Найти ничего не удалось, даже на защищенной части сайта expert-exchange. Появились какие-нибудь новые идеи? Может SP2 профиксил проблему? Хотим попробовать его установить.

    У нас многие пользуются торрентами и это не запрещено. Форвардинг DNS-запросов отключал скриптом, не помогло. Правил на кокретные URL нет вообще. И клиентов порядка 300-400. Днем обязательно начинает возникать SYN-атака и все новые коннекты блокируются. Пытался анализировать логи за минуту до атаки - по 1000 коннектов на 1 айпишник там нет, хотя ограничение на half open connection увеличено до такого.

    Что интересно. Есть еще одна проблема, о которой нигде в интернете вообще ничего нет. У нас 2 TMG сервера в кластере NLB. У каждого по 4 интерфеса. Внутренний, внеший, DMZ, интерконнект. По всем, кроме интерконнекта сделан NLB. Баг возникает обычно только на одной ноде. Причем после передергивания NLB он может возникнуть на второй, а на первой исчезнуть. После хитрых манипуляций с остановкой и запуком NLB из консоли TMG его можно вылечить (до следующего момента перезапуска кластера из-за SYN-атаки :)).

    А баг такой. Все о SecureNAT клиенте. С клиента идет запрос на установление сессии TCP - SYN-пакет, TMG клиенту отвечает SYN-ACK (хотя не должен по идее), затем клиент, отвечает на этот SYN-ACK своим ACK. И вот вроде бы можно начинать передавать данные. Но тут приходит еще один SYN-ACK, которые уже приходит не от TMG (лично), а от того хоста, с которым он начал сессию. Причем этот SYN-ACK нормально проходит через TMG. Все есть в виде дампов  wireshark на всех концах, где видно что лишний первый SYN-ACK приходит с внутреннего интерфейса TMG. А что дальше? Дальше клиент недоумевает, он уже хочет данные, а ему тут приходит пакет SYN-ACK. Он начинает отвечать на этот пакет DUP ACK. В результате до момента получения данных (например по 80 порту, хотя баг есть по любым портам) , браузеры начинают тормозить с отображеним страниц (3 сек таймаут). А если страница нагруженная, представляете сколько раз там по 3 сек? Причем все браузеры, кроме IE. IE почему-то на эту кривую ситуацию нормально реагирует. Если бы не было этого второго пакета (как работает правильная нода), то клиент дожидается SYN-ACK от хоста назначения, отвечает ему, и дальше все ок.

    Так вот предположим, что у нас работает 1 нода, на которой есть бага с этим лишним SYN-ACK пакетом. Все тормозит (но не у всех). И проблемы с SYN-атакой нет. Вообще нет никогда. Как только поднимаем вторую ноду (в разгаре рабочего дня), сразу возникает SYN-атака, и вообще все перестает работать, например, минуты на 2, потом 30 секунд работает и опять 2 минуты не работает. Причем эта SYN-атака возникает на той ноде, где все нормально, где нет этого лишнего пакета SYN-ACK.

    Ночью же, когда все юзеры отдыхают, SYN-атака не возникает. И трафик через одну ноду тормозит (из-за бага), а через вторую все летает.

    Что делать - не понятно. Уже месяц пытаемся с этим бороться. Причем, думали, что это железки или драйвера. Эта бага была и на ISA2006. Поменяли железки целиком. Поставили новые сервера TMG. Тоже самое. Перелопатили конфигурацию - никаких явных ошибок нет. Меняли multicast на unicast. Ничего. Меняли обмен между нодами через внутренний интерфейс. Убирали локалхост из всех правил (кроме системных). Результатов 0. Перечитали несколько раз бэст практики по натройке TMG, запускали даже сам анализатор - тоже ничего явно неправильного. У нас много подсетей, поэтому тестировали даже из подсети, которая прямо на внутреннем интерфейса TMG - тоже самое. Т.е. исключили возможность влияния на ситуацию коммутаторов 3-го уровня. Остался только 2 уровень, так как тот же баг даже из внутренней сети в DMZ.

    Может это by design так криво работает?

    • Изменено Dmitry_admin 8 декабря 2011 г. 16:13
    8 декабря 2011 г. 15:56
  • А у кого-нибудь из коллег вопрос, поднятый в обсуждении - решился ? 
    11 июля 2012 г. 10:04
  • Решился - увеличить все лимиты примерно в 10 раз. Оптимально делать это последовательно. Пример - при передаче файла по скайпу, скайп открывает лишние соединения по разным портам одновременно, но это не является аттакой, а особоенностью определенного ПО.

    30 июля 2012 г. 12:35
  • Можно сказать почти решился ) Поставили второй апдейт после sp2. Сделали настройки в реестре halfopenenable и disable сооответвенно на 1000 и 2000. Вернули на дефолт настройки flood mitigation settings. Баг с двойным синаком исчез (видимо после второго апдейта). Теперь обе ноды нормально работают в плане установке TCP сессий. И синатака теперь случается ни несколько раз в день, а 1 раз в месяц. Это при средней нагрузке на интернет канал в 60 мбит трафика. Еще настроили правила, которые перегружают ноду, на которой возникает синатака. В результате все более менее. Раз в месяц одна из нод сама грузится, бага нет, все хорошо, точнее почти хорошо :))))

    16 августа 2012 г. 12:14
  • Отлично, рад за вас.

    17 августа 2012 г. 4:51