Обнаружение клиентских атак на шлюзе провайдера

Какие признаки позволяют провайдеру понять, что клиент участвует в атаке?

Предлагаю обмениваться в данной теме списком возможных критериев.

 

В частности:

1) количество syn-обращений на 25 порт больше X за Y секунд - это сделано в http://sources.homelink.ru/spamblock/

2) исходящий трафик больше входящего в X раз (например, X >= 30?)

3) количество разных узлов, к которым были syn-обращения на 22 или 443 порт, больше X за Y секунд (например, для Y=2: X>2, Y=5: X>3, ...)

4) количество исходящих ICMP-пакетов больше X за Y секунд (например, для Y=1: X>3)

5) суммарный размер исходящих ICMP-пакетов больше X за Y секунд (например, для Y=1: X>500)

 

UPD:

6) количество DNS-запросов (проверка не столько для шлюза, сколько на внутреннем DNS-сервере). Интерактивный инструмент - dnstop.

7) количество DNS-ответов NXDOMAIN

 

What's more? :-\

Изменено пользователем Ilya Evseev

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяюсь к вопросу! Очень актуальная тема для меня сейчас. По каким критериям смотреть более-менее представляю, а пороговые значения не знаю. Ещё интересует вопрос обнаружения http-атак.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я занимался тоже этим вопросом, и тоже с удовольствием приму участие в обсуждении.

Вот моя маленькая заметка Выявление угроз посредством DNS протокола. Мои наработки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можно к примеру слушать трафик tcpdump`om и потом в результате найти все повторения и их количество и относительно этого выносить приговор. А вообще нужно IDS использовать. Если кто-то этим занимался, делитесь информацией, мыслями. Только дельной информацией!

Изменено пользователем hub00

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

К примеру, этой командой можно найти локального ддосера (указываем конечно свою подсеть и свой ифейс).

 

tcpdump -i eth1 -n |grep "IP 172." |cut -d' ' -f3 | cut -d. -f1,2,3,4,5 |head -5000 | awk '{ print $1 }' | sort | uniq -c | sort -n

 

Можно модернизировать эту команду для определения нужных повторений и тем самым выявлять разных правонарушителей.

Ну или по крайней мере покажет на кого стоит обратить внимание.

Изменено пользователем hub00

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можно так написать комплексный скрипт который будет выводить нужную инфу о трафике.

Поделиться сообщением


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

Вот моя маленькая заметка Выявление угроз посредством DNS протокола. Мои наработки.

Спасибо, статья интересная. Провели анализ, видим вот такое:

Queries: 611 new, 528300 total Fri Feb 5 13:02:48 2010

 

Source Query Name Count %

--------------- -------------------- --------- ------

91.149.187.221 0.10.in-addr.arpa 19710 3.7

93.125.8.63 168.192.in-addr.arpa 8909 1.7

93.125.3.156 168.192.in-addr.arpa 6148 1.2

87.252.254.154 10.10.in-addr.arpa 4547 0.9

93.125.84.67 168.192.in-addr.arpa 4440 0.8

217.21.60.46 168.192.in-addr.arpa 4353 0.8

93.125.6.50 168.192.in-addr.arpa 4295 0.8

213.184.249.190 168.192.in-addr.arpa 3780 0.7

217.21.60.35 168.192.in-addr.arpa 3774 0.7

213.184.249.19 168.192.in-addr.arpa 3758 0.7

91.149.134.136 168.192.in-addr.arpa 3705 0.7

217.21.54.201 168.192.in-addr.arpa 3416 0.6

212.98.187.229 168.192.in-addr.arpa 3359 0.6

91.149.187.83 168.192.in-addr.arpa 3345 0.6

91.149.191.199 168.192.in-addr.arpa 3278 0.6

91.149.187.134 168.192.in-addr.arpa 2970 0.6

217.21.54.201 186.194.in-addr.arpa 2831 0.5

93.125.10.105 168.192.in-addr.arpa 2808 0.5

91.149.186.243 168.192.in-addr.arpa 2696 0.5

93.125.100.121 168.192.in-addr.arpa 2620 0.5

93.125.84.120 155.10.in-addr.arpa 2260 0.4

213.184.251.176 168.192.in-addr.arpa 2157 0.4

213.184.249.190 186.194.in-addr.arpa 2132 0.4

93.125.3.112 168.192.in-addr.arpa 2128 0.4

213.184.224.233 168.192.in-addr.arpa 1891 0.4

213.184.255.103 168.192.in-addr.arpa 1798 0.3

 

 

Т.е. клиенты запрашивают свои реверсные зоны и получают denied от бинда. Есть ли идеи как сделать (кроме звонков клиентам ибо дело долгое и муторное, да и много их) что бы не запрашивали?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если я понял правильно и у тебя бинд, то allow-query { any; }; any - конечно шикарно, но ... лучше свое поставь. Хотя я может что-то не то понял.

Изменено пользователем hub00

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Если я понял правильно и у тебя бинд, то allow-query { any; }; any - конечно шикарно, но ... лучше свое поставь. Хотя я может что-то не то понял.

Не так. Это действительно наши клиенты, им работать с ДНС сервером можно. Но они запрашивают всякую свою локальную муть. Т.е. хочется как-то сделать что бы не запрашивали, что бы нагрузку на днс снизить mailgraph_day.png.

Ибо за полчаса такого сбора имеем:

Source Query Name Count %

--------------- -------------------- --------- ------

91.149.187.221 0.10.in-addr.arpa 40204 2.2

93.125.8.63 168.192.in-addr.arpa 36549 2.0

93.125.3.156 168.192.in-addr.arpa 20046 1.1

93.125.10.105 168.192.in-addr.arpa 16705 0.9

93.125.84.67 168.192.in-addr.arpa 16536 0.9

213.184.249.190 168.192.in-addr.arpa 14131 0.8

87.252.254.154 10.10.in-addr.arpa 13895 0.7

213.184.255.103 168.192.in-addr.arpa 13885 0.7

213.184.249.19 168.192.in-addr.arpa 13704 0.7

212.98.187.229 168.192.in-addr.arpa 12862 0.7

217.21.60.35 168.192.in-addr.arpa 12667 0.7

91.149.187.134 168.192.in-addr.arpa 12071 0.7

91.149.134.136 168.192.in-addr.arpa 12001 0.6

91.149.186.243 168.192.in-addr.arpa 11938 0.6

213.184.225.212 ms.akamai.net 11743 0.6

91.149.191.199 168.192.in-addr.arpa 11067 0.6

93.125.6.50 168.192.in-addr.arpa 10668 0.6

217.21.60.46 168.192.in-addr.arpa 10246 0.6

 

Пока единственное что придумалось - запуск dnstop раз в сутки на час - генерацию списка Top 50 и автоматизированныя рассылка им на емылы - поправьте настройки/проверьтесь на вирусы.

 

 

Изменено пользователем Oleg Gawriloff

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А настроить обратную зону - не судьба? Всё-равно же придётся, - вон для тех же торрентов с BEP-22

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А настроить обратную зону - не судьба? Всё-равно же придётся, - вон для тех же торрентов с BEP-22

Почему ж не судьба то. Есть обратная зона. С RFC1918 адресами. Но проблема как я понимаю не в ее наличии а в количестве запросов то от клиентов. Счет то на тысячи измеряется.

Причем часть зон клиент не должен видеть (к примеру технологическую), в результате в логах имеем вот что (за одну секунду от одного клиента):

Feb 8 21:21:56 eagle-cl1 named[27366]: client 213.184.245.158#1848: view external: RFC 1918 response from Internet for 110.9.16.172.in-addr.arpa

Feb 8 21:21:56 eagle-cl1 named[27366]: client 213.184.245.158#1848: view external: RFC 1918 response from Internet for 110.9.16.172.in-addr.arpa

Feb 8 21:21:56 eagle-cl1 named[27366]: client 213.184.245.158#1848: view external: RFC 1918 response from Internet for 110.9.16.172.in-addr.arpa

Feb 8 21:21:56 eagle-cl1 named[27366]: client 213.184.245.158#1848: view external: RFC 1918 response from Internet for 110.9.16.172.in-addr.arpa

Feb 8 21:21:56 eagle-cl1 named[27366]: client 213.184.245.158#1848: view external: RFC 1918 response from Internet for 110.9.16.172.in-addr.arpa

 

Или имеется в виду отдавать им всем в 1918 фейковые адреса левые, абы не запрашивали?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Левые конечно давайте, пусть спрашивают :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Наверное было бы праильнее разнести IP для ресолвера и для доступных с наружи NSов. Ресолвер для запросов снаружи закрыть вообще.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ок, идеи понятны, попробуем, результаты сообщу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Левые конечно давайте, пусть спрашивают :)
Как выяснилось было настроено в соотв. с https://www.isc.org/node/315. Сделал что бы отдавало левые адреса (с надеждой что клиенты ответы закешируют). Однако по графику ничего не изменилось:( Посмотрим еще сутки.

Проанализировав тцпдампом трафик - явно завирусованные клиенты. Значит только обратным отзвоном.

 

Идея насчет разнесения резолвера конечно правильная, но это вызовет либо смену ип адреса днсов у клиентов (которые этого не переживут), либо смену ип-адресов nsов для нашего хостинга днс, что терпимо в принципе, но не охота лезть. Работает то в принципе нормально.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А ведь можно отдавать левый адрес своего вебсервера, и выдавать всем завирусованым клиентам ошибку ВИРУС и много инструкций+теелфон поддержки. Тогда не надо будет отзванивать, сами позвонят.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати, что он получали в ответ на PTR 1.1.16.172.in-addr.arpa ? Часом ли не 500 байтный набор рутовых серверов + все их A записи ? Как вариант может оказаться развитием атаки с многократным увеличением трафика: Запросы идут из другого места, SRC идут для провайдера, на которого флудят, и Вы уже туда отвечаете. запрос на полста байт, ответы на 500. А то многие взялись фильтровать запрос NS .

 

Хотя не похоже конечно, больше таки похоже на то, что ресолвер стоит Ваш, а клиент уже не Ваш.

 

А запросы то от них, кроме PTR есть ? тогда что они получают на A www.microsoft.com ? Если не A запись, , то как они пользуются интернетом ? А если www.microsoft.com уже есть в кеше то что ? если запретить allow recursion но не allow query то из кеша ответы они получат, при большом кеше даже интернет будет интернетить более - менее сносно.

 

И вообще правильнее было бы вообще не отвечать. Даже ошибкой. На любой запрос снаружи, кроме запроса явно прописанных зон, для которых мы NS.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А ведь можно отдавать левый адрес своего вебсервера, и выдавать всем завирусованым клиентам ошибку ВИРУС и много инструкций+теелфон поддержки. Тогда не надо будет отзванивать, сами позвонят.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Кстати, что он получали в ответ на PTR 1.1.16.172.in-addr.arpa ? Часом ли не 500 байтный набор рутовых серверов + все их A записи ? Как вариант может оказаться развитием атаки с многократным увеличением трафика: Запросы идут из другого места, SRC идут для провайдера, на которого флудят, и Вы уже туда отвечаете. запрос на полста байт, ответы на 500. А то многие взялись фильтровать запрос NS .

 

Хотя не похоже конечно, больше таки похоже на то, что ресолвер стоит Ваш, а клиент уже не Ваш.

 

А запросы то от них, кроме PTR есть ? тогда что они получают на A www.microsoft.com ? Если не A запись, , то как они пользуются интернетом ? А если www.microsoft.com уже есть в кеше то что ? если запретить allow recursion но не allow query то из кеша ответы они получат, при большом кеше даже интернет будет интернетить более - менее сносно.

 

И вообще правильнее было бы вообще не отвечать. Даже ошибкой. На любой запрос снаружи, кроме запроса явно прописанных зон, для которых мы NS.

Раньше получила отлуп (NX NOT FOUND), теперь получают if-you-see-this-then-your-resolver-is-bad. тцдумп показал что это не атака, а вполне нормальные клиентские запросы на резолв реверса своих внутренних адресов. Просто их количество наводит на мысли что у них в сети явно что-то не так. Ладно, в принципе дальше понятно что делать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А ведь можно отдавать левый адрес своего вебсервера, и выдавать всем завирусованым клиентам ошибку ВИРУС и много инструкций+теелфон поддержки. Тогда не надо будет отзванивать, сами позвонят.

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

Ну, отдаете ип адрес вебсервера, а он на любые запросы выдает старничку такую.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Кто-нить ставил ?

 

http://software.klolik.org/smtp-gated/

Это почтовый прокси, он заведомо медленнее, чем spamblock, а эффективность вряд ли намного выше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

_Тестовый_(!!!) вариант утилиты для обнаружения вирусов, сканирующих 443, 22 порт (по умолчанию 443):

http://sources.homelink.ru/spamblock/portcheck.txt

 

Запускать на шлюзе (убрав расширение ".txt" и сделав chmod +x ;-).

Требования: perl, tcpdump.

 

Синтаксис и пример работы:

http://sources.homelink.ru/spamblock/portcheck-sample.txt

 

Пояснение: ratio означает порог для удельной доли обращений отдельного клиента от общего числа.

Если доля меньше - клиент не попадает в отчёт.

То есть.

Если сеть большая или хочется большой отчёт, включая неочевидные случаи - уменьшайте ratio.

Если сеть маленькая или хочется короткий отчёт по наиболее злостным - увеличивайте ratio.

При значениях по умолчанию у меня отчёт состоит примерно из 15 ip-адресов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти
Подписчики 0