Comments 18
Это метафорическое переосмысление инструмента BGP с точки зрения игровой классики.
Честно говоря, увидев такой подзаголовок, удивился и приготовился прочесть про «магию +1 уровня», а это оказалась шутка, и текст просто про BGP.
Замечание про сканирование портов в поисках сертификатов SSL, PTR или ответов по HTTP:
все уже просканировано до нас и лежит на scans.io и на commoncrawl.org вместе с историей изменений за много лет.
А вот с UDP весело — при виртуалке 100mbit, FastVPS отрубал сеть при входящем потоке в 50mbit, и отказывались что бы то ни было делать на своей стороне. Уехал на OVH, которые срезали атаку самостоятельно без малейших телодвижений с моей стороны.
Думал даже CloudFlare убрать с фронта, но решил не рисковать.
Если кто хочет пентеста — могу рекомендовать esagelab.com
TARPIT наше всё.
LaBrea-подобные? или чего другое?
А то как-то видел тисипишный флуд на те же 10G, где тарпит-ом даже четверть не срезало.
Не говоря уже про веб-серверные типа limit-req и ко.
Про UDP флуд не совсем понял — провайдеру жеж легче его срубить, почти все современные железки то умеют, и автоматом (иногда по звонку провайдеру) меняют "UDP flood threshold" и иже с ним (и все идут лесом). "Нормальный" то трафик в основном через TCP бегает, а его так рубить уже нельзя...
iptables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK
iptables -A INPUT -p tcp --dport 80 -j qTARPIT
и в qTARPIT суём правила вида
iptables -A qTARPIT -s botnethost -j TARPIT
botnethost'ы собирал из access.log'а.
этот тарпит ставит TCP окно нулевое, что означает «заткнись и помолчи». удалённые хосты это и делали — плюс такого соединения в том, что со стороны сервера затрат — один пакет, со стороны клиента — висящее соединение (занятый порт). то есть через несколько тысяч попыток соедениться, TCP коннекты полностью становились заняты, и открыть новые нельзя => ботнет хост переставал выполнять какие-либо атаки.
через 20 минут набралось 200 записей, на которых атака похудела до 2 сотен мегабит, через еще 20 минут было около 300 записей, и траффик упал до обычных 40 мегабит.
держал скрипт около трёх суток, суммарный улов был всего 5 тысяч хостов.
первое время пытался удалять старые, но они через час опять появлялись живыми (похоже, они затыкались и их ребутили...)
а вот про UDP да, это я и просил сделать — меня послали в пешее эротическое вида «мы ничего не делаем, разбирайтесь сами». а что я с UDP со своей стороны сделать могу? канал уже засран… только линять на другого провайдера, который может фильтровать на своей стороне или стороне его аплинка.
Я там тоже так пытался, но видимо ботнет ширше был, ибо SYN/ACK-ми все завалено было, а результат так себе.
botnethost'ы собирал из access.log'а.
Мне даже делать ничего не нужно было, все собиралось fail2ban-ом автоматически из отдельного лога от псевдо-location с limit-req (с отдельным логом, т.е. значит одни "нарушители") плюс те что в протоколе от iptables отметились (порт сканы, режекты, залимичиные и т.д.)… и отправлялось в тарпит-action почти тем же макаром через iptables (только с ipset, на одном iptables таблицу бы сильно раздуло).
Но…
Видать шибко "широкий" бот-нет был… Т.е. 10G, но много-много маленьких пакетов (подозреваю что "бабушек" просто черезчур много было).
Совсем стихло только через сутки где-то.
Я статистику с логов собирал тогда, но сильно много было (слимши в базу sqlite под 20-гиг было) и анализировать не стал — руки не дошли (где-то валяется еще вроде).
Вероятно, арендовали что-то маленькое, потому как срезалось легко.
Но если 10G на syn'ах — то тут так же как с UDP, только аплинком можно отбиваться.
На текущий момент, 1G хост кладут старым добрым SYNFLOOD'ом на ура, причем плевать что хост сам флуд переживает — канал просто забит, зараза.
Куратор, клаудфлёр, и прочие заградительные решения — ничего другого тут не сделаешь.
Но если 10G на syn'ах ...
Та не… Вроде нормальные three-way handshake, оно то моими SYN/ACK-ответами все завалено было, и их ACK-ответы как положено "игнорились" и т.д.
Просто видно правда сильно жирно было. Ну или действительно часть SYN/ACK-пакетов в пустую уходили (на поддельные адреса), так сказать в качестве "защиты" атакующей сети от возможного тарпит'а со стороны обороняющегося (т.е. комби-атака).
Ну а я попался.
$ host -t ns habrahabr.ru
habrahabr.ru name server ns3.habradns.net.
habrahabr.ru name server ns2.habradns.net.
habrahabr.ru name server ns1.habradns.net.
$ host ns3.habradns.net.
ns3.habradns.net has address 88.198.175.104
$ host ns1.habradns.net.
ns1.habradns.net has address 88.198.175.104
ns1.habradns.net has IPv6 address 2a01:4f8:d16:4d4a::2
$ host ns2.habradns.net.
ns2.habradns.net has address 188.226.201.107
Хетцнер и ДО. Куратора нет, кучи виртуалок тоже не видно.
В итоге primary мы просто скрываем. То есть мы их нигде не анонсируем. Они у нас есть, но они далеко. Он не один, и их IP-адреса и доменные имена вообще нигде не указывается.
Эм тогда зачем он? и можно поподробней как такое сделать? Просто не могу представить как без master обойтись, ведь он должен быть обязательно в каждом домене.
Для внешнего наблюдателя все NS, которые ассоциированы с доменом (прописаны у регистратора и в зоне домена) равнозначны. По идее, первичный NS прописывается в зоне в SOA-записи, но для стороннего наблюдателя он опять же, не особо важен. Поэтому стороннему наблюдателю запросто можно подсунуть в списке NS только вторичные сервера.
Понятие "первичный" и "вторичные" — они больше для внутренней кухни, так как вторичные NS забирают AXFR-запросом изменения с первичного, а первичный рассылает NOTIFY вторичным в случае обновления зоны. Так как мы в принципе AXFR не используем, у нас механика "первичный-вторичный NS" переехала в плоскость "MySQL Master-Slave".
Золотые слова, Юрий Венедиктович (С)
Лет 5 назад, когда я это говорил начальству — все смотрели на меня, как на идиота. Сейчас это уже доходит до более широкого круга лиц…
DDoS в обход Куратора: простые действия для спокойной жизни