Вчера одного из заказчиков сильно ддосили. Решил поделиться опытом и написать заметку на этот счет. А опыт тут очень простой. Сами вы ничего не сделаете, поэтому лучше не терять время, а сразу заказывать услугу по защите.
Атака развивалась стандартно. Нашли тяжелые урлы на сайте и начали туда лить трафик. Сначала немного, так что сайт начал тормозить и иногда пятисотые ошибки выдавать. Потом усилили так, что он прилег. Сайт за reverse proxy был, так что пошел на него и попытался что-то сделать.
Как только я каким-то образом автоматизировал бан ip и сайт оживал, атака менялась, запросы добавлялись, ip адресов было все больше и больше. В какой-то момент все легко. Провайдер просто отправил наш ip в blackhole. Написал об этом сообщение. Прислал подробности атаки, количество и тип запросов и т.д. И сказал, что атака влияет на его инфраструктуру, так что он вынужден нас отключить.
Предложил подключить ddos защиту, что и было сделано. Пока не понятно, насколько это будет эффективно. Защит существует огромное количество на любой бюджет. От слабых атак иногда помогает бесплатный тариф cloudflare, был такой опыт. Но если атака серьезная, то что-то дешевое за 3-5 т.р. в месяц вас вряд ли спасет.
Если вам важен и дорог аптайм, планируйте защиту от ddos заранее и не своими силами. Вас практически любой провайдер быстро отключит, как только на его ip адреса пойдет атака. Потом включит через несколько часов. Если атака не прекратится, быстро отключит снова.
Если все плохо и атаки будут продолжаться, то готовьтесь серьезно к настройке сервера, сайта, почты и т.д. Вам нужно будет прятать свои реальные ip и закрываться защищенными, которые предоставит сервис защиты от ddos.
Кстати, сервер был на тех. поддержке у одного аутсорсера, который обещал реакцию в течении 15 минут круглые сутки в случае проблем с сайтом. У него был свой мониторинг, бэкапы и т.д. Как вы понимаете, они ничего не сделали и не предложили, так что пришлось подключить меня.
#ddos
Атака развивалась стандартно. Нашли тяжелые урлы на сайте и начали туда лить трафик. Сначала немного, так что сайт начал тормозить и иногда пятисотые ошибки выдавать. Потом усилили так, что он прилег. Сайт за reverse proxy был, так что пошел на него и попытался что-то сделать.
Как только я каким-то образом автоматизировал бан ip и сайт оживал, атака менялась, запросы добавлялись, ip адресов было все больше и больше. В какой-то момент все легко. Провайдер просто отправил наш ip в blackhole. Написал об этом сообщение. Прислал подробности атаки, количество и тип запросов и т.д. И сказал, что атака влияет на его инфраструктуру, так что он вынужден нас отключить.
Предложил подключить ddos защиту, что и было сделано. Пока не понятно, насколько это будет эффективно. Защит существует огромное количество на любой бюджет. От слабых атак иногда помогает бесплатный тариф cloudflare, был такой опыт. Но если атака серьезная, то что-то дешевое за 3-5 т.р. в месяц вас вряд ли спасет.
Если вам важен и дорог аптайм, планируйте защиту от ddos заранее и не своими силами. Вас практически любой провайдер быстро отключит, как только на его ip адреса пойдет атака. Потом включит через несколько часов. Если атака не прекратится, быстро отключит снова.
Если все плохо и атаки будут продолжаться, то готовьтесь серьезно к настройке сервера, сайта, почты и т.д. Вам нужно будет прятать свои реальные ip и закрываться защищенными, которые предоставит сервис защиты от ddos.
Кстати, сервер был на тех. поддержке у одного аутсорсера, который обещал реакцию в течении 15 минут круглые сутки в случае проблем с сайтом. У него был свой мониторинг, бэкапы и т.д. Как вы понимаете, они ничего не сделали и не предложили, так что пришлось подключить меня.
#ddos
Продолжая тему ddos, расскажу, что делал я на самом сервере для защиты. Напомню, что это не сам web сервер, а reverse proxy с iptables. Первым делом сразу же настроил с помощью netstat вывод всех ip адресов, у которых больше 10-ти подключений к серверу. Обработал этот вывод, получив чистый список ip.
netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//' | awk '{if ($1 > 10 ) print$2}';
Дальше не стал его отправлять в iptables, так как фаервол начнет тормозить, когда список будет из десятков тысяч адресов и более. Уже проходил это. Так что сразу настроил ipset и поставил правило с блокировкой адресов из этого списка в самый верх:
iptables -A INPUT -m set --match-set blacklist src -j DROP
Важно сделать список ipset не с дефолтными параметрами, а поставить побольше hashsize и maxelem, на случай, если списки будут очень большими. Потом начал его заполнять простым bash скриптом, в цикле перебирая все адреса, полученные из команды выше.
Далее пошел в nginx и настроил там лимит подключений для одного ip. Все, кто его превышают, отмечаются в error логе. Настроил его парсинг и добавление адресов в ipset.
Потом стал смотреть, по каким урлам идут запросы. Это были запросы к поиску и сортировке каталога. Добавил отдельные location и deny правила для этих урлов и так же начал банить ip адреса, которые обращаются к этим урлам, забирая их из error лога nginx.
Скрипты по парсингу и бану запускал каждые 5 секунд. Важно парсить не весь error.log, а только его хвост из нескольких сот строк. Иначе можно повесить сервер, так как лог быстро разрастается до гигабайтов и просто так грепнуть его не получится. Поэтому в таких случаях не поможет fail2ban. Он очень тормозной, начнет вешать сервер своим анализом логов.
В целом, этого хватало, чтобы оперативно банить все фейковые запросы от ботов. На сайт и сервера можно было нормально заходить и настраивать что-то. Но когда все это заработало эффективно, атакующие просто увеличили масштаб атаки и нас заблокировал хостер за превышение какого-то его внутреннего лимита по запросам на ip адрес.
С теми, у кого нет масштабного ботнета, так вполне успешно можно справляться. Так же можно легко закрыться, если весь трафик ботов идет не из вашего региона и вы его можете забанить по спискам стран. Например, отсечь все, что не из РФ. Я так делал и это нормально работает. Но тут ботнет из России был.
А у вас какой опыт отражения ddos атак? Пытались что-то своими силами делать или сразу подключали услугу?
#ddos
netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//' | awk '{if ($1 > 10 ) print$2}';
Дальше не стал его отправлять в iptables, так как фаервол начнет тормозить, когда список будет из десятков тысяч адресов и более. Уже проходил это. Так что сразу настроил ipset и поставил правило с блокировкой адресов из этого списка в самый верх:
iptables -A INPUT -m set --match-set blacklist src -j DROP
Важно сделать список ipset не с дефолтными параметрами, а поставить побольше hashsize и maxelem, на случай, если списки будут очень большими. Потом начал его заполнять простым bash скриптом, в цикле перебирая все адреса, полученные из команды выше.
Далее пошел в nginx и настроил там лимит подключений для одного ip. Все, кто его превышают, отмечаются в error логе. Настроил его парсинг и добавление адресов в ipset.
Потом стал смотреть, по каким урлам идут запросы. Это были запросы к поиску и сортировке каталога. Добавил отдельные location и deny правила для этих урлов и так же начал банить ip адреса, которые обращаются к этим урлам, забирая их из error лога nginx.
Скрипты по парсингу и бану запускал каждые 5 секунд. Важно парсить не весь error.log, а только его хвост из нескольких сот строк. Иначе можно повесить сервер, так как лог быстро разрастается до гигабайтов и просто так грепнуть его не получится. Поэтому в таких случаях не поможет fail2ban. Он очень тормозной, начнет вешать сервер своим анализом логов.
В целом, этого хватало, чтобы оперативно банить все фейковые запросы от ботов. На сайт и сервера можно было нормально заходить и настраивать что-то. Но когда все это заработало эффективно, атакующие просто увеличили масштаб атаки и нас заблокировал хостер за превышение какого-то его внутреннего лимита по запросам на ip адрес.
С теми, у кого нет масштабного ботнета, так вполне успешно можно справляться. Так же можно легко закрыться, если весь трафик ботов идет не из вашего региона и вы его можете забанить по спискам стран. Например, отсечь все, что не из РФ. Я так делал и это нормально работает. Но тут ботнет из России был.
А у вас какой опыт отражения ddos атак? Пытались что-то своими силами делать или сразу подключали услугу?
#ddos
🛡 Последнее время приходилось настраивать anti ddos защиту, так что решил сделать небольшую заметку по теме для тех, кто не знает, как на практике защищаются от ddos. Расскажу немного об этом.
Если у вас не стояло никакой защиты и вас начали ддосить, то скорее всего первым делом вам придется сменить внешний ip адрес и не светить новый, пока не включите защиту. Зная ваш старый адрес, вас без проблем выключат, что бы вы ни делали. Отключит вас сам провайдер, так как ддос доставляет ему лишние хлопоты, которые забесплатно он решать не будет.
В общем, сайт у вас лежит, так как вас отключил хостер. Сами вы ничего тут не сделаете. Дальше выбираете защиту. Выбор огромен. Разброс цен приличный, от 1000 р. в месяц и до бесконечности. Если есть деньги и желание максимально надежно защититься, заказывайте сразу защиту у qrator. Если денег немного, то начинайте с самых дешевых тарифов бюджетных защит. Либо попробуйте бесплатный план от cloudflare. Часто этого бывает достаточно.
Сервис защиты вам даст новый внешний ip адрес из своего диапазона. Весь ваш трафик он теперь будет принимать на себя. Этот адрес вы указываете в dns для вашего домена. А в самом сервисе защиты прописываете ваш новый ip адрес непосредственно веб сервера для редиректа очищенного трафика на него.
Дальше очень важно нигде не спалить ваш новый внешний ip веб сервера, чтобы вам не налили туда трафика в обход защиты, так как хостер снова отключит вас. Лучше всего запретить на уровне фаервола вообще все соединения, кроме ssh по белому списку ip адресов и разрешить 80, 443 порты для доступа с ip адресов защиты. И все. На пинги лучше тоже не отвечать на всякий случай.
Сразу же нужно проработать момент с отправкой почты. Очень часто веб сервера сами ее рассылают и палят свои ip адреса. Почту нужно отправлять через внешние сервисы или свои сервера. При этом обязательно проверить, чтобы в заголовках нигде не отсвечивал ваш реальный адрес веб сервера.
Перед тем, как прописывать на dns ip адреса защиты, рекомендую перед этим внимательно самому посмотреть на сайт, сервер, заголовки и все остальное. Нужно убедиться, что реальный ip адрес веб сервера нигде не отсвечивает. Вы должны везде видеть ip адрес защиты, который они вам дали. Просто если свой ip не спрятать, то придется снова менять. Иногда это бывает не очень просто сделать.
После того, как убедитесь, что все ОК, настраиваете dns записи, указываете там защищенные ip адреса и дальше от вас практически ничего не зависит. Все будет делать сам сервис anti ddos. А вы получите очищенный трафик.
https://youtu.be/QdU8B0KAbZ8
#ddos
Если у вас не стояло никакой защиты и вас начали ддосить, то скорее всего первым делом вам придется сменить внешний ip адрес и не светить новый, пока не включите защиту. Зная ваш старый адрес, вас без проблем выключат, что бы вы ни делали. Отключит вас сам провайдер, так как ддос доставляет ему лишние хлопоты, которые забесплатно он решать не будет.
В общем, сайт у вас лежит, так как вас отключил хостер. Сами вы ничего тут не сделаете. Дальше выбираете защиту. Выбор огромен. Разброс цен приличный, от 1000 р. в месяц и до бесконечности. Если есть деньги и желание максимально надежно защититься, заказывайте сразу защиту у qrator. Если денег немного, то начинайте с самых дешевых тарифов бюджетных защит. Либо попробуйте бесплатный план от cloudflare. Часто этого бывает достаточно.
Сервис защиты вам даст новый внешний ip адрес из своего диапазона. Весь ваш трафик он теперь будет принимать на себя. Этот адрес вы указываете в dns для вашего домена. А в самом сервисе защиты прописываете ваш новый ip адрес непосредственно веб сервера для редиректа очищенного трафика на него.
Дальше очень важно нигде не спалить ваш новый внешний ip веб сервера, чтобы вам не налили туда трафика в обход защиты, так как хостер снова отключит вас. Лучше всего запретить на уровне фаервола вообще все соединения, кроме ssh по белому списку ip адресов и разрешить 80, 443 порты для доступа с ip адресов защиты. И все. На пинги лучше тоже не отвечать на всякий случай.
Сразу же нужно проработать момент с отправкой почты. Очень часто веб сервера сами ее рассылают и палят свои ip адреса. Почту нужно отправлять через внешние сервисы или свои сервера. При этом обязательно проверить, чтобы в заголовках нигде не отсвечивал ваш реальный адрес веб сервера.
Перед тем, как прописывать на dns ip адреса защиты, рекомендую перед этим внимательно самому посмотреть на сайт, сервер, заголовки и все остальное. Нужно убедиться, что реальный ip адрес веб сервера нигде не отсвечивает. Вы должны везде видеть ip адрес защиты, который они вам дали. Просто если свой ip не спрятать, то придется снова менять. Иногда это бывает не очень просто сделать.
После того, как убедитесь, что все ОК, настраиваете dns записи, указываете там защищенные ip адреса и дальше от вас практически ничего не зависит. Все будет делать сам сервис anti ddos. А вы получите очищенный трафик.
https://youtu.be/QdU8B0KAbZ8
#ddos
YouTube
ddos attack
У меня тут сайт на днях ддоснули. Не знаю, специально или нет. Длилось недолго, минут 10-15. Никакой защиты у меня не стоит, так как нет смысла. С меня не убудет, если сайт полежит какое-то время. Защита стоит дороже, чем доход с сайта.
Как-только сайт начал лагать и пришли алерты от мониторинга о том, что на прокси сервере CPU в потолок ушел, сразу же пошел смотреть дашборд в ELK. Картина из него во вложении. Увидел количество запросов и разных IP, сразу расслабился. Я тут сделать ничего не могу. Канал в 1 гиг сразу забили весь. При этом инфра достойно держалась, хотя всё крутится на дешманском сервере chipcore с двумя обычными ssd.
Пользователям отдаётся чистая статика из кэша напрямую через nginx. Так что 500-е полезли из-за того, что на proxy-nginx было всего 2 CPU и они были загружены полностью. Может быть вообще переварили бы весь этот траф. Другое дело, что меня бы провайдер отрубил, если бы атака продлилась чуть дольше.
Важно иметь мониторинг и логи где-то во вне от наблюдаемого объекта. Если бы они висели на том же ip и канале, то посмотреть бы ничего не смог. Пришлось бы разбираться. А так я сразу же всё понял и оценил обстановку. Так как был вечер, приготовился лечь спать 😎
#ddos #elk
Как-только сайт начал лагать и пришли алерты от мониторинга о том, что на прокси сервере CPU в потолок ушел, сразу же пошел смотреть дашборд в ELK. Картина из него во вложении. Увидел количество запросов и разных IP, сразу расслабился. Я тут сделать ничего не могу. Канал в 1 гиг сразу забили весь. При этом инфра достойно держалась, хотя всё крутится на дешманском сервере chipcore с двумя обычными ssd.
Пользователям отдаётся чистая статика из кэша напрямую через nginx. Так что 500-е полезли из-за того, что на proxy-nginx было всего 2 CPU и они были загружены полностью. Может быть вообще переварили бы весь этот траф. Другое дело, что меня бы провайдер отрубил, если бы атака продлилась чуть дольше.
Важно иметь мониторинг и логи где-то во вне от наблюдаемого объекта. Если бы они висели на том же ip и канале, то посмотреть бы ничего не смог. Пришлось бы разбираться. А так я сразу же всё понял и оценил обстановку. Так как был вечер, приготовился лечь спать 😎
#ddos #elk
Ещё один пример того, чем пользуются юные "хакеры". Известный скрипт на Python для DDoS атак - MHDDoS. Для того, чтобы научиться защищаться от подобных инструментов, имеет смысл самому их изучить.
Я время от времени сталкиваюсь с атаками чем-то подобным. Последний раз мой сайт зачем-то пытались ддосить в конце февраля. Особо не парился с защитой, но одного fail2ban оказалось недостаточно. Очень много запросов было, логи разрастались молниеносно и fail2ban сам его вешал. Пришлось скрипт быстро набросать, чтобы в бан сразу улетали те, кто открывали с сервером больше 50 соединений. А сами логи отключил.
Хоть заметку и не об этом хотел сделать, но сразу покажу скрипт, так как наверняка будете спрашивать в комментариях.
Для этого лучше использовать ipset. Заранее добавить правило блокировки в iptables, а потом просто обновлять список. Но мне не захотелось заморачиваться и что-то перенастраивать. Просто напрямую в fail2ban стал отдавать ip адреса. Их было не много, поэтому решение нормально сработало, плюс писались логи самого fail2ban. Их можно было анализировать.
Возвращаемся к MHDDoS. Установить его просто, нужен только Python и Git:
Сразу можно запускать атаку. Для атаки L7 требуется список прокси. Если его нет, то скрипт автоматом скачает списки прокси от публичных сервисов, которые их предоставляют, проверит работоспособность и начнёт использовать. Проверка длится очень долго, так что пользоваться в таком виде не очень удобно. Лучше заранее обзавестись готовым списком. Их продают за 3-5$.
Атакуем сайт site.com атакой типа L7 методом GET с использованием всех доступных прокси (параметр 0), в 50 потоков, используя по 10 подключений к каждому прокси-серверу, в течении 30 секунд.
Для атаки уровня L4 прокси не нужны. Всё гораздо проще:
Атакуем dns сервер udp флудом по 53 порту в 1 поток в течении 30 секунд.
Всё довольно просто. Можете подолбить свои сервера и проверить защиту на них. От одного ip адреса злоумышленника отбиться не сложно. Я бы даже сказал очень просто, если есть хоть какая-то защита. Вы можете очень удивиться, но на практике есть куча сайтов, интернет магазинов, игровых серверов, которые ложатся от подобных атак даже с одного IP адреса. Не спрашивайте, откуда я это знаю 🤫
В сети можно найти различные вариации готовых инструментов на базе MHDDoS, которые и сразу списки прокси дают, и устанавливаются автоматически, и списки жертв могут автоматом откуда-то подтягивать. У меня нет цели учить кого-то ддосить, да я и сам не умею. Просто рассказываю, как это на практике может выглядеть.
❗️Как обычно предупреждаю, не надо запускать подобные штуки на своих рабочих машинах или серверах. Используйте какие-нибудь арендованные виртуалки.
Документация - https://github.com/MatrixTM/MHDDoS/wiki/Usage-of-script
#security #ddos
Я время от времени сталкиваюсь с атаками чем-то подобным. Последний раз мой сайт зачем-то пытались ддосить в конце февраля. Особо не парился с защитой, но одного fail2ban оказалось недостаточно. Очень много запросов было, логи разрастались молниеносно и fail2ban сам его вешал. Пришлось скрипт быстро набросать, чтобы в бан сразу улетали те, кто открывали с сервером больше 50 соединений. А сами логи отключил.
Хоть заметку и не об этом хотел сделать, но сразу покажу скрипт, так как наверняка будете спрашивать в комментариях.
#!/bin/baships=`netstat -ntu | grep -vE "(Address|servers|127.0.0.1)" \| awk '{print $5}' | cut -d ':' -f 1 | sort -n | uniq -c \| sort -n | awk '{if ($1 > 50 ) print $2}'`if [[ -z $ips ]]; then exit 0else for i in $ips do fail2ban-client -vvv set nginx-limit-conn banip $i donefiДля этого лучше использовать ipset. Заранее добавить правило блокировки в iptables, а потом просто обновлять список. Но мне не захотелось заморачиваться и что-то перенастраивать. Просто напрямую в fail2ban стал отдавать ip адреса. Их было не много, поэтому решение нормально сработало, плюс писались логи самого fail2ban. Их можно было анализировать.
Возвращаемся к MHDDoS. Установить его просто, нужен только Python и Git:
# git clone https://github.com/MatrixTM/MHDDoS.git# cd MHDDoS# pip install -r requirements.txtСразу можно запускать атаку. Для атаки L7 требуется список прокси. Если его нет, то скрипт автоматом скачает списки прокси от публичных сервисов, которые их предоставляют, проверит работоспособность и начнёт использовать. Проверка длится очень долго, так что пользоваться в таком виде не очень удобно. Лучше заранее обзавестись готовым списком. Их продают за 3-5$.
# python3 start.py GET https://site.com 0 50 proxy.txt 10 30Атакуем сайт site.com атакой типа L7 методом GET с использованием всех доступных прокси (параметр 0), в 50 потоков, используя по 10 подключений к каждому прокси-серверу, в течении 30 секунд.
Для атаки уровня L4 прокси не нужны. Всё гораздо проще:
# python3 start.py udp 1.1.1.1:53 1 30Атакуем dns сервер udp флудом по 53 порту в 1 поток в течении 30 секунд.
Всё довольно просто. Можете подолбить свои сервера и проверить защиту на них. От одного ip адреса злоумышленника отбиться не сложно. Я бы даже сказал очень просто, если есть хоть какая-то защита. Вы можете очень удивиться, но на практике есть куча сайтов, интернет магазинов, игровых серверов, которые ложатся от подобных атак даже с одного IP адреса. Не спрашивайте, откуда я это знаю 🤫
В сети можно найти различные вариации готовых инструментов на базе MHDDoS, которые и сразу списки прокси дают, и устанавливаются автоматически, и списки жертв могут автоматом откуда-то подтягивать. У меня нет цели учить кого-то ддосить, да я и сам не умею. Просто рассказываю, как это на практике может выглядеть.
❗️Как обычно предупреждаю, не надо запускать подобные штуки на своих рабочих машинах или серверах. Используйте какие-нибудь арендованные виртуалки.
Документация - https://github.com/MatrixTM/MHDDoS/wiki/Usage-of-script
#security #ddos
К вчерашней заметке про CF как здесь, так и в VK, возникло обсуждение скрытия/раскрытия настоящего IP адреса веб сервера. Насколько я знаю, через нормальную защиту от ddos узнать IP адрес веб сервера нереально. Поясню на пальцах, как работает защита от ddos.
Если вас начали серьёзно ддосить и вы решили спрятаться за защиту, то действовать вы должны следующим образом:
1️⃣ Закрываете все входящие запросы к серверу с помощью файрвола. Разрешаете только HTTP запросы от сети защиты. Они вам предоставят свои адреса. У CF список доступен публично.
2️⃣ Меняете внешний IP адрес веб сервера. Обычно у всех хостеров есть такая услуга. Старый IP адрес отключаете.
3️⃣ Обновляете DNS записи для вашего сайта, указывая в качестве А записи IP адреса защиты. А в самой защите прописываете проксирование на ваш новый веб сервер.
Если вы всё сделали правильно, то реальный IP адрес вашего сайта вычислить не получится. Сервис защиты следит за этим, так как это важная часть его работы.
Все известные мне способы определить реальный IP адрес сайта, чтобы ддоснуть его в обход защиты следующие:
▪ Смотрится история DNS записей домена. Если вы не изменили внешний IP адрес, то вас всё равно могут отключить, даже если вы на своём файрволе заблокировали все соединения. Если поток запросов напрямую, мимо защиты будет слишком большой, вас отключит провайдер, чтобы не нагружать чрезмерно свою инфраструктуру.
▪ По спискам проверяются поддомены. Часто люди запускают их временно без защиты, прописывают реальные IP адреса веб сервера, которые остаются в истории навсегда. Даже если вы давно отключили этот поддомен, IP адрес засвечен. Так что реальный IP адрес прода светить нигде нельзя.
▪ Часто почта отправляется напрямую веб сервером. И даже если используется сторонний SMTP сервер, по заголовкам писем всё равно можно обнаружить IP адрес веб сервера. Почистить заголовки не всегда тривиальная задача и этим надо заниматься отдельно. На этом очень легко погореть.
▪ Теоретически какие-то данные можно засветить в HTTP заголовках, но я на практике не припоминаю, чтобы это происходило. Точно не знаю, кто может выдать там реальный IP веб сервера.
Если всё сделать правильно, то вы будете надёжно защищены сервисом от ддоса и все вопросы защиты будут касаться только сервиса. Сами вы ничего не сможете и не должны будете делать, кроме корректной настройки своего сайта через проксирование, а часто и кэширование. С этим могут быть проблемы и наверняка будут.
☝ Если запускаете новый проект и сразу планируете поместить его под защиту, проследите, чтобы нигде не засветился его IP адрес. Особенно это касается DNS записей.
#ddos
Если вас начали серьёзно ддосить и вы решили спрятаться за защиту, то действовать вы должны следующим образом:
1️⃣ Закрываете все входящие запросы к серверу с помощью файрвола. Разрешаете только HTTP запросы от сети защиты. Они вам предоставят свои адреса. У CF список доступен публично.
2️⃣ Меняете внешний IP адрес веб сервера. Обычно у всех хостеров есть такая услуга. Старый IP адрес отключаете.
3️⃣ Обновляете DNS записи для вашего сайта, указывая в качестве А записи IP адреса защиты. А в самой защите прописываете проксирование на ваш новый веб сервер.
Если вы всё сделали правильно, то реальный IP адрес вашего сайта вычислить не получится. Сервис защиты следит за этим, так как это важная часть его работы.
Все известные мне способы определить реальный IP адрес сайта, чтобы ддоснуть его в обход защиты следующие:
▪ Смотрится история DNS записей домена. Если вы не изменили внешний IP адрес, то вас всё равно могут отключить, даже если вы на своём файрволе заблокировали все соединения. Если поток запросов напрямую, мимо защиты будет слишком большой, вас отключит провайдер, чтобы не нагружать чрезмерно свою инфраструктуру.
▪ По спискам проверяются поддомены. Часто люди запускают их временно без защиты, прописывают реальные IP адреса веб сервера, которые остаются в истории навсегда. Даже если вы давно отключили этот поддомен, IP адрес засвечен. Так что реальный IP адрес прода светить нигде нельзя.
▪ Часто почта отправляется напрямую веб сервером. И даже если используется сторонний SMTP сервер, по заголовкам писем всё равно можно обнаружить IP адрес веб сервера. Почистить заголовки не всегда тривиальная задача и этим надо заниматься отдельно. На этом очень легко погореть.
▪ Теоретически какие-то данные можно засветить в HTTP заголовках, но я на практике не припоминаю, чтобы это происходило. Точно не знаю, кто может выдать там реальный IP веб сервера.
Если всё сделать правильно, то вы будете надёжно защищены сервисом от ддоса и все вопросы защиты будут касаться только сервиса. Сами вы ничего не сможете и не должны будете делать, кроме корректной настройки своего сайта через проксирование, а часто и кэширование. С этим могут быть проблемы и наверняка будут.
☝ Если запускаете новый проект и сразу планируете поместить его под защиту, проследите, чтобы нигде не засветился его IP адрес. Особенно это касается DNS записей.
#ddos
На днях случился необычный для меня инцидент. Расскажу, как его преодолел. Сразу скажу, что это будет не инструкция, как надо делать, а то, как поступил я в конкретной ситуации. У меня есть в управлении одиночный сервер, где одна из виртуальных машин выполняет роль Nginx Proxy для других сервисов. Кто-то эту прокси решил ддоснуть. Немного растерялся от ситуации, так как сталкиваешься с ней нечасто и выверенного алгоритма действий нет.
Я не знаю, кем и для чего это делалось. Виртуалка проксировала доступ на неприметный публичный сайт, который давно не обновлялся и работал для галочки. Также проксировались соединения на мониторинг, 1С и некоторые другие внутренние сервисы для доступа к ним извне. На виртуалке внутри не было никакой защиты от ddos, внешняя, соответственно, тоже подключена не была. В этом не было необходимости. Ничего критичного там не стояло.
От мониторинга прилетел алерт на недоступность некоторых ресурсов, и на высокий LA виртуалки. По SSH хоть и небыстро, но подключился к ней. Заодно сразу зашёл на гипервизор. Он нормально переваривал нагрузку. Увидел, что на виртуалке CPU на четырёх ядрах в потолке. И все ядра нагрузил Nginx. Голым Nginx нагрузить практически пустыми соединениями на 100% 4 CPU не так просто. Я думал, что сейчас провайдер просто отрубит сервак и на этом всё закончится. Но нет, он переваривал, так что я стал разбираться на сервере локально.
Глянул лог Nginx и увидел массовые обращения на один конкретный URL публичного сайта с разных IP адресов. Вообще не понял, причём тут этот URL и почему в него долбят. Первое, что сделал, вообще отключил этот сайт. Nginx стал отдавать 502 ошибку, но серверу это слабо помогло.
Потом добавил параметр
в nginx.conf и
в настройки виртуального хоста. Хотел собирать айпишники тех, кто открывает более 50 соединений к сайту, чтобы потом их банить. Но там особо не собиралось, плюс лог ошибок рос с огромной скоростью, трудно было из него что-то выбирать. Виртуалка и так сильно тормозила. IP постоянно менялись, одновременных запросов, которые бы ловились Nginx, не было.
Решил мимо Nginx напрямую с iptables работать. У меня есть в закладках команда, которая сортирует и считает соединения с каждого IP адреса:
Тут уже было хорошо видно адреса, которые открыли много соединений. Немного изменил скрипт, чтобы выводить чистые списки IP адресов, открывших более 50-ти соединений и сохранять их в файл:
Дальше создал список ipset для использования списка IP адресов в правилах iptables. Напрямую большие списки в iptables направлять не надо, он их может не переварить.
Закинул туда список пойманных ранее IP адресов:
И сделал правило в iptables для блокировки из этого списка:
Блокировка заработала, счётчики правила пошли вверх, но помогло это слабо. Адреса постоянно менялись. Собрал всё это в скрипт и запускал по крону раз в минуту, тоже не помогло.
Решил забанить всех, кто обращается к урлу, который ддосят. Забирал IP ардеса, чтобы сильно не грузить сервак, так:
Собрал их в ipset, добавил правило блокировки:
Продолжение в следующей заметке 👇👇👇👇
#ddos #nginx #iptables
Я не знаю, кем и для чего это делалось. Виртуалка проксировала доступ на неприметный публичный сайт, который давно не обновлялся и работал для галочки. Также проксировались соединения на мониторинг, 1С и некоторые другие внутренние сервисы для доступа к ним извне. На виртуалке внутри не было никакой защиты от ddos, внешняя, соответственно, тоже подключена не была. В этом не было необходимости. Ничего критичного там не стояло.
От мониторинга прилетел алерт на недоступность некоторых ресурсов, и на высокий LA виртуалки. По SSH хоть и небыстро, но подключился к ней. Заодно сразу зашёл на гипервизор. Он нормально переваривал нагрузку. Увидел, что на виртуалке CPU на четырёх ядрах в потолке. И все ядра нагрузил Nginx. Голым Nginx нагрузить практически пустыми соединениями на 100% 4 CPU не так просто. Я думал, что сейчас провайдер просто отрубит сервак и на этом всё закончится. Но нет, он переваривал, так что я стал разбираться на сервере локально.
Глянул лог Nginx и увидел массовые обращения на один конкретный URL публичного сайта с разных IP адресов. Вообще не понял, причём тут этот URL и почему в него долбят. Первое, что сделал, вообще отключил этот сайт. Nginx стал отдавать 502 ошибку, но серверу это слабо помогло.
Потом добавил параметр
limit_conn_zone $binary_remote_addr zone=perip:10m;в nginx.conf и
limit_conn perip 50;в настройки виртуального хоста. Хотел собирать айпишники тех, кто открывает более 50 соединений к сайту, чтобы потом их банить. Но там особо не собиралось, плюс лог ошибок рос с огромной скоростью, трудно было из него что-то выбирать. Виртуалка и так сильно тормозила. IP постоянно менялись, одновременных запросов, которые бы ловились Nginx, не было.
Решил мимо Nginx напрямую с iptables работать. У меня есть в закладках команда, которая сортирует и считает соединения с каждого IP адреса:
# netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//'Тут уже было хорошо видно адреса, которые открыли много соединений. Немного изменил скрипт, чтобы выводить чистые списки IP адресов, открывших более 50-ти соединений и сохранять их в файл:
# netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//' | awk '{if ($1 > 50 ) print$2}' > ~/top_connect.txtДальше создал список ipset для использования списка IP адресов в правилах iptables. Напрямую большие списки в iptables направлять не надо, он их может не переварить.
# ipset -N top_connect nethashЗакинул туда список пойманных ранее IP адресов:
# cat ~/top_connect.txt | xargs -n1 ipset -A top_connectИ сделал правило в iptables для блокировки из этого списка:
# iptables -I INPUT 1 -m set --match-set top_connect src -j DROPБлокировка заработала, счётчики правила пошли вверх, но помогло это слабо. Адреса постоянно менялись. Собрал всё это в скрипт и запускал по крону раз в минуту, тоже не помогло.
Решил забанить всех, кто обращается к урлу, который ддосят. Забирал IP ардеса, чтобы сильно не грузить сервак, так:
# tail -1000 /var/log/nginx/access.log | egrep "GET /url-for-ddos/" | awk '{print $1}' | sort -n | uniq -c | sort -n | tail -n100 | awk '{if ($1 > 2 ) print $2}' > ~/top_get.txtСобрал их в ipset, добавил правило блокировки:
# ipset -N top_get nethash
# iptables -I INPUT 1 -m set --match-set top_get src -j DROPПродолжение в следующей заметке 👇👇👇👇
#ddos #nginx #iptables
После прошлой истории с ddos захотелось проработать какое-то готовое универсальное решение, чтобы можно было его быстро применить, а не придумывать разные способы. В комментариях люди писали, что надо было установить fail2ban, какой-нибудь WAF или что-то в этом роде. Это всё слабо поможет, если идёт большая нагрузка. Fail2ban сразу мимо, забываем про него. А WAF или какой-то фильтрующий сервер надо настраивать заранее, а не когда у вас единственную машину ддосят.
Я взял наиболее простой и быстрый с точки зрения производительности вариант: ipset + iptables. Если ваш канал и сервер в целом вывозят нагрузку и вас не блокирует провайдер, указанная связка будет наиболее лёгкой и эффективной с точки зрения потребления ресурсов.
Сначала хотел что-то простое набросать, но потом всё расширял и расширял возможности. В итоге родился довольно большой bash скрипт с некоторыми проверками и логированием. Рассказываю, что он делает:
1️⃣ Проверяет установку ipset, создаёт списки.
2️⃣ Проверяет установку rsyslog, чтобы логировать заблокированные подключения. Это нужно на момент отладки и в обычное время, когда нет ддоса. Если начали ддосить, логирование надо отключить.
3️⃣ Создаёт конфигурацию rsyslog для хранения логов в отдельных файлах. Настраивает ротацию через logrotate.
4️⃣ Дальше идут переменные, касающиеся правил iptables: имя и ip адрес WAN интерфейса, белый список IP, с которых разрешено всё, разрешённые TCP и UDP порты, на которые мы принимаем соединения. Всё остальное блокируем.
5️⃣ Дальше идут наборы правил:
- очистка всех правил
- запрет всего, что не разрешено явно
- разрешаем установленные соединения
- разрешаем localhost и icmp
- разрешаем исходящие соединения сервера
- разрешаем все соединения от белого списка
- блокируем неопознанные и нулевые пакеты
- блокируем новые соединения без статуса NEW
- блокируем списки ipset, которые формируются ниже
- добавляем в список тех, кто открывает более 10-ти соединений с сервером в течении секунды, логируем таких товарищей
- разрешаем доступ к открытым портам, в данном примере это порты 80, 443 TCP и 443 UDP
- тех, кто обращается к другим портам, добавляем в список ipset
- сохраняю все правила в файл
Сразу скажу, что я не занимался плотной отладкой этого набора правил в реальной ситуации. Набросал правила на основе своего опыта и протестировал в ручном режиме. Под реальной нагрузкой и спамом запросов не проверял.
Для проверки работы надо установить на сервере iptables, ipset, rsyslog:
Скопировать и заполнить переменные в bash скрипте. Особое внимание уделить переменным WAN, WAN_IP, WLIST, WPORT_TCP, WPORT_UDP. На основе них будут сформированы правила iptables. Отдельного правила для SSH я не делал. Подразумевается, что подключаться куда-либо кроме открытых 80 и 443 портов можно только из списка WLIST. Туда можно добавлять IP адреса или подсети через запятую.
После выполнения скрипта, смотрим правила iptables:
Проверял работу так. Установил веб сервер. Попробовал с другой машины подключиться к серверу через telnet на любой отличный от HTTP порт:
Получил бан с занесением в список BANPORT. Смотреть этот список так:
Далее установил ab и попробовал спам запросов в 50 потоков к веб серверу:
Получил бан с занесением в список BANDDOS. Оба бана были отражены в лог файлах
⚡️На работающем сервере запускать такие скрипты не рекомендую, особенно если нет доступа к консоли. Сначала проверьте и отладьте на тестовой виртуалке. Убедитесь, что не отрубаете себе доступ. В целом, тут небольшой и относительно простой набор правил.
⇨ Забрать скрипт iptables.sh
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#iptables #ipset #ddos
Я взял наиболее простой и быстрый с точки зрения производительности вариант: ipset + iptables. Если ваш канал и сервер в целом вывозят нагрузку и вас не блокирует провайдер, указанная связка будет наиболее лёгкой и эффективной с точки зрения потребления ресурсов.
Сначала хотел что-то простое набросать, но потом всё расширял и расширял возможности. В итоге родился довольно большой bash скрипт с некоторыми проверками и логированием. Рассказываю, что он делает:
- очистка всех правил
- запрет всего, что не разрешено явно
- разрешаем установленные соединения
- разрешаем localhost и icmp
- разрешаем исходящие соединения сервера
- разрешаем все соединения от белого списка
- блокируем неопознанные и нулевые пакеты
- блокируем новые соединения без статуса NEW
- блокируем списки ipset, которые формируются ниже
- добавляем в список тех, кто открывает более 10-ти соединений с сервером в течении секунды, логируем таких товарищей
- разрешаем доступ к открытым портам, в данном примере это порты 80, 443 TCP и 443 UDP
- тех, кто обращается к другим портам, добавляем в список ipset
- сохраняю все правила в файл
Сразу скажу, что я не занимался плотной отладкой этого набора правил в реальной ситуации. Набросал правила на основе своего опыта и протестировал в ручном режиме. Под реальной нагрузкой и спамом запросов не проверял.
Для проверки работы надо установить на сервере iptables, ipset, rsyslog:
# apt install iptables ipset rsyslogСкопировать и заполнить переменные в bash скрипте. Особое внимание уделить переменным WAN, WAN_IP, WLIST, WPORT_TCP, WPORT_UDP. На основе них будут сформированы правила iptables. Отдельного правила для SSH я не делал. Подразумевается, что подключаться куда-либо кроме открытых 80 и 443 портов можно только из списка WLIST. Туда можно добавлять IP адреса или подсети через запятую.
После выполнения скрипта, смотрим правила iptables:
# iptables -L -v -nПроверял работу так. Установил веб сервер. Попробовал с другой машины подключиться к серверу через telnet на любой отличный от HTTP порт:
# telnet 85.143.173.182 23Получил бан с занесением в список BANPORT. Смотреть этот список так:
# ipset -L BANPORTДалее установил ab и попробовал спам запросов в 50 потоков к веб серверу:
# ab -c 50 -n 30000 "http://85.143.173.182/"Получил бан с занесением в список BANDDOS. Оба бана были отражены в лог файлах
ipset_portscan.log и ipset_ddos.log. При этом если ничего из описанного выше не делать, а просто ходить на веб сайт, доступ открыт, всё работает нормально.⚡️На работающем сервере запускать такие скрипты не рекомендую, особенно если нет доступа к консоли. Сначала проверьте и отладьте на тестовой виртуалке. Убедитесь, что не отрубаете себе доступ. В целом, тут небольшой и относительно простой набор правил.
⇨ Забрать скрипт iptables.sh
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#iptables #ipset #ddos
Please open Telegram to view this post
VIEW IN TELEGRAM