Вирусная атака с одного ip
Порядок действий при обнаружении сетевых атак.
1. Классификация сетевых атак
1.1. Снифферы пакетов
Сниффер пакетов представляет собой прикладную программу, которая использует сетевую карту, работающую в режиме promiscuous mode (в этом режиме все пакеты, полученные по физическим каналам, сетевой адаптер отправляет приложению для обработки). При этом сниффер перехватывает все сетевые пакеты, которые передаются через определенный домен.
IP-спуфинг происходит, когда хакер, находящийся внутри системы или вне ее выдает себя за санкционированного пользователя. Это можно сделать двумя способами. Во-первых, хакер может воспользоваться IP-адресом, находящимся в пределах диапазона санкционированных IP-адресов, или авторизованным внешним адресом, которому разрешается доступ к определенным сетевым ресурсам. Атаки IP-спуфинга часто являются отправной точкой для прочих атак. Классический пример — атака DoS, которая начинается с чужого адреса, скрывающего истинную личность хакера.
Обычно IP-спуфинг ограничивается вставкой ложной информации или вредоносных команд в обычный поток данных, передаваемых между клиентским и серверным приложением или по каналу связи между одноранговыми устройствами. Для двусторонней связи хакер должен изменить все таблицы маршрутизации, чтобы направить трафик на ложный IP-адрес. Некоторые хакеры, однако, даже не пытаются получить ответ от приложений. Если главная задача состоит в получении от системы важного файла, ответы приложений не имеют значения.
Если же хакеру удается поменять таблицы маршрутизации и направить трафик на ложный IP-адрес, хакер получит все пакеты и сможет отвечать на них так, будто он является санкционированным пользователем.
1.3. Отказ в обслуживании (Denial of Service — DoS)
DoS является наиболее известной формой хакерских атак. Против атак такого типа труднее всего создать стопроцентную защиту.
Наиболее известные разновидности DoS:
- TCP SYN Flood Ping of Death Tribe Flood Network (TFN);
- Tribe Flood Network 2000 (TFN2K);
- Trinco;
- Stacheldracht;
- Trinity.
Атаки DoS отличаются от атак других типов. Они не нацелены на получение доступа к сети или на получение из этой сети какой-либо информации. Атака DoS делает сеть недоступной для обычного использования за счет превышения допустимых пределов функционирования сети, операционной системы или приложения.
В случае использования некоторых серверных приложений (таких как Web-сервер или FTP-сервер) атаки DoS могут заключаться в том, чтобы занять все соединения, доступные для этих приложений и держать их в занятом состоянии, не допуская обслуживания обычных пользователей. В ходе атак DoS могут использоваться обычные Интернет-протоколы, такие как TCP и ICMP (Internet Control Message Protocol). Большинство атак DoS опирается не на программные ошибки или бреши в системе безопасности, а на общие слабости системной архитектуры. Некоторые атаки сводят к нулю производительность сети, переполняя ее нежелательными и ненужными пакетами или сообщая ложную информацию о текущем состоянии сетевых ресурсов. Этот тип атак трудно предотвратить, так как для этого требуется координация действий с провайдером. Если трафик, предназначенный для переполнения вашей сети, не остановить у провайдера, то на входе в сеть вы это сделать уже невозможно, потому что вся полоса пропускания будет занята. Когда атака этого типа проводится одновременно через множество устройств, атака является распределенной DoS (DDoS — distributed DoS).
1.4. Парольные атаки
Еще одна проблема возникает, когда пользователи применяют один и тот же (пусть даже очень хороший) пароль для доступа ко многим системам: корпоративной, персональной и системам Интернет. Поскольку устойчивость пароля равна устойчивости самого слабого хоста, хакер, узнавший пароль через этот хост, получает доступ ко всем остальным системам, где используется тот же пароль.
1.5. Атаки типа Man-in-the-Middle
Для атаки типа Man-in-the-Middle хакеру нужен доступ к пакетам, передаваемым по сети. Такой доступ ко всем пакетам, передаваемым от провайдера в любую другую сеть, может, к примеру, получить сотрудник этого провайдера. Для атак этого типа часто используются снифферы пакетов, транспортные протоколы и протоколы маршрутизации. Атаки проводятся с целью кражи информации, перехвата текущей сессии и получения доступа к частным сетевым ресурсам, для анализа трафика и получения информации о сети и ее пользователях, для проведения атак типа DoS, искажения передаваемых данных и ввода несанкционированной информации в сетевые сессии.
1.6. Атаки на уровне приложений
Атаки на уровне приложений могут проводиться несколькими способами. Самый распространенный из них состоит в использовании слабостей серверного программного обеспечения (sendmail, HTTP, FTP). Используя эти слабости, хакеры могут получить доступ к компьютеру от имени пользователя, работающего с приложением (обычно это бывает не простой пользователь, а привилегированный администратор с правами системного доступа). Сведения об атаках на уровне приложений широко публикуются, чтобы дать возможность администраторам исправить проблему с помощью коррекционных модулей (патчей). Главная проблема с атаками на уровне приложений состоит в том, что они часто пользуются портами, которым разрешен проход через межсетевой экран. К примеру, хакер, эксплуатирующий известную слабость Web-сервера, часто использует в ходе атаки ТСР порт 80. Поскольку Web-сервер предоставляет пользователям Web-страницы, межсетевой экран должен предоставлять доступ к этому порту. С точки зрения межсетевого экрана, атака рассматривается как стандартный трафик для порта 80.
1.7. Сетевая разведка
Сетевой разведкой называется сбор информации о сети с помощью общедоступных данных и приложений. При подготовке атаки против какой-либо сети хакер, как правило, пытается получить о ней как можно больше информации. Сетевая разведка проводится в форме запросов DNS, эхо-тестирования (ping sweep) и сканирования портов. Запросы DNS помогают понять, кто владеет тем или иным доменом и какие адреса этому домену присвоены. Эхо-тестирование (ping sweep) адресов, раскрытых с помощью DNS, позволяет увидеть, какие хосты реально работают в данной среде. Получив список хостов, хакер использует средства сканирования портов, чтобы составить полный список услуг, поддерживаемых этими хостами. И, наконец, хакер анализирует характеристики приложений, работающих на хостах. В результате добывается информация, которую можно использовать для взлома.
1.8. Злоупотребление доверием
1.9. Переадресация портов
Переадресация портов представляет собой разновидность злоупотребления доверием, когда взломанный хост используется для передачи через межсетевой экран трафика, который в противном случае был бы обязательно отбракован. Примером приложения, которое может предоставить такой доступ, является netcat.
1.10. Несанкционированный доступ
2. Методы противодействия сетевым атакам
2.1. Смягчить угрозу сниффинга пакетов можно с помощью следующих средств:
2.1.2. Коммутируемая инфраструктура - Еще одним способом борьбы со сниффингом пакетов в сетевой среде является создание коммутируемой инфраструктуры, при этом хакеры могут получить доступ только к трафику, поступающему на тот порт, к которому они подключены. Коммутируемая инфраструктуры не ликвидирует угрозу сниффинга, но заметно снижает ее остроту.
2.1.4. Криптография - Самый эффективный способ борьбы со сниффингом пакетов не предотвращает перехвата и не распознает работу снифферов, но делает эту работу бесполезной. Если канал связи является криптографически защищенным, это значит, что хакер перехватывает не сообщение, а зашифрованный текст (то есть непонятную последовательность битов).
2.2. Угрозу спуфинга можно ослабить (но не устранить) с помощью следующих мер:
2.2.1. Контроль доступа - Самый простой способ предотвращения IP-спуфинга состоит в правильной настройке управления доступом. Чтобы снизить эффективность IP-спуфигна, контроль доступа настраивается на отсечение любого трафика, поступающего из внешней сети с исходным адресом, который должен располагаться внутри вашей сети. Это помогает бороться с IP-спуфингом, когда санкционированными являются только внутренние адреса. Если санкционированными являются и некоторые адреса внешней сети, данный метод становится неэффективным.
2.2.3. Наиболее эффективный метод борьбы с IP-спуфингом тот же, что и в случае со сниффингом пакетов: необходимо сделать атаку абсолютно неэффективной. IP-спуфинг может функционировать только при условии, что аутентификация происходит на базе IP-адресов. Поэтому внедрение дополнительных методов аутентификации делает этот вид атак бесполезными. Лучшим видом дополнительной аутентификации является криптографическая. Если она невозможна, хорошие результаты может дать двухфакторная аутентификация с использованием одноразовых паролей.
2.3. Угроза атак типа DoS может снижаться следующими способами:
2.3.1. Функции анти-спуфинга - правильная конфигурация функций анти-спуфинга на ваших маршрутизаторах и межсетевых экранах поможет снизить риск DoS. Эти функции, как минимум, должны включать фильтрацию RFC 2827. Если хакер не сможет замаскировать свою истинную личность, он вряд ли решится провести атаку.
2.3.2. Функции анти-DoS - правильная конфигурация функций анти-DoS на маршрутизаторах и межсетевых экранах может ограничить эффективность атак. Эти функции ограничивают число полуоткрытых каналов в любой момент времени.
2.3.3. Ограничение объема трафика (traffic rate limiting) – договор с провайдером (ISP) об ограничении объем трафика. Этот тип фильтрации позволяет ограничить объем некритического трафика, проходящего сети. Обычным примером является ограничение объемов трафика ICMP, который используется только для диагностических целей. Атаки (D) DoS часто используют ICMP.
2.3.4. Блокирование IP адресов – после анализа DoS атаки и выявления диапазона IP адресов, с которых осуществляется атака, обратиться к провайдеру для их блокировки.
2.4. Парольных атак можно избежать, если не пользоваться паролями в текстовой форме. Одноразовые пароли и/или криптографическая аутентификация могут практически свести на нет угрозу таких атак. Не все приложения, хосты и устройства поддерживают указанные выше методы аутентификации.
При использовании обычных паролей, необходимо придумать такой пароль, который было бы трудно подобрать. Минимальная длина пароля должна быть не менее восьми символов. Пароль должен включать символы верхнего регистра, цифры и специальные символы (#, %, $ и т.д.). Лучшие пароли трудно подобрать и трудно запомнить, что вынуждает пользователей записывать пароли на бумаге.
2.5. Эффективно бороться с атаками типа Man-in-the-Middle можно только с помощью криптографии. Если хакер перехватит данные зашифрованной сессии, у него на экране появится не перехваченное сообщение, а бессмысленный набор символов. Заметим, что, если хакер получит информацию о криптографической сессии (например, ключ сессии), это может сделать возможной атаку Man-in-the-Middle даже в зашифрованной среде.
2.6. Полностью исключить атаки на уровне приложений невозможно. Хакеры постоянно открывают и публикуют в Интернете все новые уязвимые места прикладных программ. Самое главное — хорошее системное администрирование.
Меры, которые можно предпринять, чтобы снизить уязвимость для атак этого типа:
- чтение и/или анализ лог-файлов операционных систем и сетевые лог-файлов с помощью специальных аналитических приложений;
- своевременное обновление версий операционных систем и приложений и установка последних коррекционных модулей (патчей);
- использование систем распознавания атак (IDS).
2.7. Полностью избавиться от сетевой разведки невозможно. Если отключить эхо ICMP и эхо-ответ на периферийных маршрутизаторах, вы избавитесь от эхо-тестирования, но потеряете данные, необходимые для диагностики сетевых сбоев. Кроме того, сканировать порты можно и без предварительного эхо-тестирования. Просто этой займет больше времени, так как сканировать придется и несуществующие IP-адреса. Системы IDS на уровне сети и хостов обычно хорошо справляются с задачей уведомления администратора о ведущейся сетевой разведке, что позволяет лучше подготовиться к предстоящей атаке и оповестить провайдера (ISP), в сети которого установлена система, проявляющая чрезмерное любопытство.
2.8. Риск злоупотребления доверием можно снизить за счет более жесткого контроля уровней доверия в пределах своей сети. Системы, расположенные с внешней стороны межсетевого экрана, никогда не должны пользоваться абсолютным доверием со стороны защищенных экраном систем. Отношения доверия должны ограничиваться определенными протоколами и, по возможности, аутентифицироваться не только по IP-адресам, но и по другим параметрам.
2.9. Основным способом борьбы с переадресацией портов является использование надежных моделей доверия (см. п. 2.8). Кроме того, помешать хакеру установить на хосте свои программные средства может хост-система IDS (HIDS).
2.10. Способы борьбы с несанкционированным доступом достаточно просты. Главным здесь является сокращение или полная ликвидация возможностей хакера по получению доступа к системе с помощью несанкционированного протокола. В качестве примера можно рассмотреть недопущение хакерского доступа к порту telnet на сервере, который предоставляет Web-услуги внешним пользователям. Не имея доступа к этому порту, хакер не сможет его атаковать. Что же касается межсетевого экрана, то его основной задачей является предотвращение самых простых попыток несанкционированного доступа.
3. Алгоритм действий при обнаружении сетевых атак
3.1. Большая часть сетевых атак блокируется автоматически установленными средствами защиты информации (межсетевые экраны, средства доверенной загрузки, сетевые маршрутизаторы, антивирусные средства и т.п.).
3.2. К атакам, требующим вмешательства персонала для их блокировки или снижения тяжести последствий относятся атаки типа DoS.
3.2.2. В случае выявления атаки системный администратор выполняет следующие действия:
- осуществляет ручное переключение маршрутизатора на резервный канал и обратно с целью выявления менее загруженного канала (канала с более широкой пропускной способностью);
- выявляет диапазон IP – адресов, с которых осуществляется атака;
- отправляет провайдеру заявку на блокировку IP адресов из указанного диапазона.
3.3. DoS атака, как правило, используется для маскировки успешно проведенной атаки на ресурсы клиента с целью затруднить ее обнаружение. Поэтому при выявлении DoS атаки необходимо провести анализ последних транзакций с целью выявления необычных операций, осуществить (при возможности) их блокировку, связаться с клиентами по альтернативному каналу для подтверждения проведенных транзакций.
3.4. В случае получения от клиента информации о несанкционированных действиях осуществляется фиксация всех имеющихся доказательств, проводится внутреннее расследование и подается заявление в правоохранительные органы.
Скачать ZIP файл (24151)
Вирусная активность, подозрительный трафик, атака с моего айпи
Добрый день,
Пришло письмо от провайдера
Относительно попытки несанкционированого вмешательства в роботу вычислительных систем. с моего айпи.
здравствуйте,
согласно письма вероятные сервера для атаки:
It is most likely the attack traffic is directed at one of the following
endpoints:
These endpoints on our network are resolved by Geo DNS, so the IP
addresses they resolve to will depend on the originating IP address.
The destination port will be TCP 443.
поиск проводился по 23.59.112.0/20, вероятно активность осталась:
0.061588 62.80.161.130 -> 23.59.118.77 SSL Client Hello
0.076070 23.59.118.77 -> 62.80.161.130 TCP 443 > 50614 [ACK] Seq=1
Ack=136 Win=30272 Len=0
0.078650 23.59.118.77 -> 62.80.161.130 TLSv1 Server Hello,
0.078678 23.59.118.77 -> 62.80.161.130 TCP [TCP segment of a
reassembled PDU]
0.078729 23.59.118.77 -> 62.80.161.130 TLSv1 Certificate, Server Key
Exchange, Server Hello Done
0.085319 62.80.161.130 -> 23.59.118.77 TCP 50614 > 443 [ACK] Seq=136
Ack=2921 Win=65700 Len=0
0.090241 62.80.161.130 -> 23.59.118.77 TLSv1 Client Key Exchange,
Change Cipher Spec, Encrypted Handshake Message
0.105443 23.59.118.77 -> 62.80.161.130 TLSv1 Change Cipher Spec,
Encrypted Handshake Message
0.109965 62.80.161.130 -> 23.59.118.77 TLSv1 Application Data,
Application Data
0.125786 23.59.118.77 -> 62.80.161.130 TLSv1 Application Data
0.230295 62.80.161.130 -> 23.59.118.77 TCP 50614 > 443 [FIN, ACK]
Seq=520 Ack=4175 Win=64444 Len=0
0.244769 23.59.118.77 -> 62.80.161.130 TLSv1 Encrypted Alert
0.244803 23.59.118.77 -> 62.80.161.130 TCP 443 > 50614 [FIN, ACK]
Seq=4212 Ack=521 Win=32416 Len=0
0.247956 62.80.161.130 -> 23.59.118.77 TCP 50614 > 443 [ACK] Seq=521
Ack=4213 Win=64408 Len=0
----
а это письмо приходило за 2 недели до этого
Здравствуйте.
согласно жалобы основное, вероятное направление атак на сервера:
к этим адресам активности нет, но есть к другим хостам в одной AS с
этими ip:
0.000000 62.80.161.130 -> 23.0.47.122 TCP 50086 > 443 [SYN] Seq=0
Win=65535 Len=0 MSS=1460 WS=5 TSV=535348208 TSER=0
0.027445 23.0.47.122 -> 62.80.161.130 TCP 443 > 50086 [SYN, ACK]
Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 TSV=3128298856 TSER=535348208 WS=5
0.035923 62.80.161.130 -> 23.0.47.122 TCP 50086 > 443 [ACK] Seq=1
Ack=1 Win=131744 Len=0 TSV=535348241 TSER=3128298856
0.044585 62.80.161.130 -> 23.0.47.122 SSL Client Hello
0.071945 23.0.47.122 -> 62.80.161.130 TCP 443 > 50086 [ACK] Seq=1
Ack=211 Win=30048 Len=0 TSV=3128298900 TSER=535348243
0.072928 23.0.47.122 -> 62.80.161.130 TLSv1.2 Server Hello,
0.072942 23.0.47.122 -> 62.80.161.130 TCP [TCP segment of a
reassembled PDU]
0.073048 23.0.47.122 -> 62.80.161.130 TLSv1.2 Certificate, Server
Key Exchange, Server Hello Done
0.079970 62.80.161.130 -> 23.0.47.122 TCP 50086 > 443 [ACK] Seq=211
Ack=2897 Win=129600 Len=0 TSV=535348285 TSER=3128298901
0.079980 62.80.161.130 -> 23.0.47.122 TCP 50086 > 443 [ACK] Seq=211
Ack=3781 Win=128736 Len=0 TSV=535348285 TSER=3128298901
0.155743 62.80.161.130 -> 23.0.47.122 TLSv1.2 Client Key Exchange
0.155753 62.80.161.130 -> 23.0.47.122 TLSv1.2 Change Cipher Spec
0.155764 62.80.161.130 -> 23.0.47.122 TLSv1.2 Encrypted Handshake
Message
0.183403 23.0.47.122 -> 62.80.161.130 TCP 443 > 50086 [ACK] Seq=3781
Ack=337 Win=30048 Len=0 TSV=3128299012 TSER=535348359
0.183413 23.0.47.122 -> 62.80.161.130 TLSv1.2 Change Cipher Spec,
Encrypted Handshake Message
0.191649 62.80.161.130 -> 23.0.47.122 TCP 50086 > 443 [ACK] Seq=337
Ack=3832 Win=131008 Len=0 TSV=535348394
Некоторое время назад я написал подробную статью про установку и настройку web сервера на базе nginx и php-fpm последних версий. Там я упомянул, что это первая статья из цикла заметок о веб сервере. Сегодня я расскажу как простыми и подручными средствами защититься от простых ddos атак.
Введение
Сразу сделаю оговорку по поводу слова ddos, которое тут не совсем уместно, но я не придумал, как еще популярно объяснить о чем идет речь. От полноценной ddos атаки вы не сможете защититься в рамках настройки веб сервера. У вас просто будет забит весь канал и сервер перестанет отвечать. Если мощности сервера не достаточно для обработки и фильтрации входящих запросов, то он ляжет, чтобы вы там не делали. Для полноценной защиты от ddos нужны полноценные средства, которые стоят ощутимых финансовых затрат. Более подробно с теорией по защите от ddos читайте в отдельной статье.
Нужно понимать, что защита от ddos должна быть адекватна значимости ресурса. Если у вас персональный блог, который не приносит существенной прибыли, то платить за защиту от ddos бессмысленно. Достаточно просто полежать какое-то время или сделать защиту своими силами. В общем, всегда нужно соизмерять стоимость простоя со стоимостью защиты и на основе этого принимать решение о целесообразности того или иного метода.
Я приведу советы по защите от простых атак ботов или каких-то мелких вредителей и пакостников, которые без должных действий с вашей стороны могут положить ваш сайт или сервер без особых проблем. Вот простой пример. Есть не очень слабый виртуальный сервер от ihor, на борту которого 2 ярда, 8 гигов оперативы и ssd диск.
Сервер настроен по моей предыдущей статье, ссылку на которую привел в начале. На сервере развернут wordpress сайт с некоторым содержимым. И есть у нас вредитель, который на своем сервере запускает простой тест от apache на производительность веб сервера:
Всего лишь 50 параллельных потоков. Что мы видим на своем веб сервере:
Не очень приятная картина. Сервер загружен на 100%. И хотя он нормально обрабатывает запросы и в целом корректно работает. Даже не очень тормозит, но все равно это плохо. А если будет 3 сервера и по 100 потоков на каждом? Нет никаких проблем даже на тест взять у разных хостеров по виртуальной машине и запускать на них подобные штуки, имитируя ддос атаку.
Защита от ddos с помощью iptables
Для защиты от простейшей атаки мы будем использовать firewall — iptables, модуль ядра ipset для хранения больших списков ip и самописные скрипты. По фаерволу смотрите мою статью — настройка iptables. Здесь я не буду на этом останавливаться.
Вопрос настройки ipset я подробно рассматривал в своей статье по блокировке ботов по странам. Советую посмотреть материал, так как он напрямую связан с этой статьей и дополняет ее.
Итак, приступим к созданию нашей простой защиты от dos атаки с большим количеством подключений с одного ip адреса. Для начала проверим команду, которая покажет нам количество подключений с каждого ip адреса:
У меня получается примерно так. Много единичных подключений. Идет штатная работа веб сервера, никто на него не ломится десятками подключений. Теперь нагрузим наш сервер множественными паразитными запросами и еще раз посмотрим вывод команды.
Вот он, нарушитель нашего спокойствия, пытающийся организовать дос атаку на наш сервер. Теперь нарисуем скрипт, который будет блокировать всех кто устанавливает более 50-ти одновременных соединений с сайтом.
В принципе, комментировать тут особо нечего. Берем список подключений, который только что вывели, в нем сравниваем первую колонку, если она больше 50, то результат второй колонки, где записан ip адрес, передаем в файл.
Далее читаем этот файл и добавляем все ip адреса из него в ipset список под названием much_conn. Предварительно его надо создать. Подробно об этом я рассказывал в статье, на которую привел ссылку выше, но повторю еще раз здесь:
Посмотреть содержимое списка можно командой:
Теперь нужно добавить в iptables правило, по которому будут блокироваться все подключения из указанного списка ipset.
Все, мы заблокировали всех, кто создает массовый спам подключений к серверу. Ограничение в 50 подключений можете исправлять по месту, возможно его нужно будет уменьшить, если кто-то будет открывать меньше подключений с одного ip.
Единственный момент, о котором хочу сказать. Сам я не проверял, сколько подключений открывают поисковые боты, когда приходят на сайт. Я подозреваю, что явно не 50 и даже не 30, но наверняка я не проверял. В общем, будьте аккуратны, когда используете это средство.
Данный скрипт можно засунуть в крон и запускать каждую минуту. Но лично я бы так не стал делать. Я рекомендую мониторить ресурсы сервера и запускать подобные средства, только если сервер работает на пределе своих возможностей и вы вручную зашли и убедились, что вас кто-то спамит подключениями. После этого врубайте на какое-то время данный скрипт по крону. Когда ddos прекратится, отключайте.
Было бы неплохо как-то автоматически очищать список забаненных, удаляя оттуда тех, кто уже сутки к вам не подключается, но это сильно усложняет задачу. Нужно как минимум вести лог по блокирующему списку, сохранять время последнего обращения. Обрабатывать все это, высчитывать. В общем, задача хоть и не сильно сложная, но уже не тривиальная. Мне не захотелось этим заниматься.
Есть хоть и не очень изящное, но простое решение этой проблемы. Создать список ipset с заданным временем жизни записи с помощью timeout. Например вот так:
В данном случае запись с забаненным ip в списке ipset будет храниться в течении 3600 секунд или 60 минут.
Нужно понимать, что в данном примере с 1 ip адресом использовать ipset нет никакого смысла, можно сразу банить средствами самого iptables. Ipset нужен только тогда, когда этот список хотя бы в сотни строк. Если там несколько десяткой адресов, хватит и одного iptables.
Анализ лог файла web сервера для защиты от ddos
Рассмотрим еще один простой, но все же более сложный тип ддос атаки, когда идут типовые запросы с разных IP. То есть простой ботнет, может быть даже собранный руками из нескольких дешевых vds серверов. Одновременных подключений будет не много, но если у вас тяжелый сайт и злоумышленник найдет его слабое место (например поиск), то этого может быть достаточно, чтобы положить сайт.
Банить будем тоже через iptables, а список адресов для бана будем извлекать из логов веб сервера. Для этого у вас должно быть включено логирование запросов к веб серверу. Например, в nginx за это отвечает такая настройка виртуального хоста:
Результатом этой команды будет примерно такой список.
В данном случае я использовал немного другое условие и просто вывел список всех тех, кто стучался на главную страницу. Но уже тут видно нарушителя, которого можно забанить.
Рисуем похожий на предыдущий скрипт для автоматической блокировки тех, кто отправляет слишком много запросов на наш сайт и создает проблемы с производительностью. Повторюсь еще раз, если проблем с производительностью нет, я не рекомендую делать лишних движений.
Здесь делаем то же самое, что и раньше. Те, кто сделали более 50-ти одинаковых запросов по нашей маске на последние 1000 строк в лог файле, отправляются в бан.
Не забудьте создать отдельный список в ipset и добавить отдельное правило в ipables. Можно использовать уже существующий список и добавленное правило из предыдущего примера, но я рекомендую все разделять. Так удобнее для последующего анализа.
Во время ddos атаки добавляете это правило в cron и выполняете каждую минуту. После завершения атаки скрипт можно отключить. В принципе, можно и на постоянку оставлять, но тут нужно хорошенько подумать и прикинуть, как оно должно выглядеть. Главный принцип — не навредить.
Баним ботов с неправильным referer
После этого проверьте конфигурацию nginx и перечитайте ее.
Если вас достает какой-то бот с конкретным referer, можно забанить именно его. Для этого можно дополнить условие, или изменить. Например, вот так:
Защита от ддос с помощью модулей nginx — limit_conn и limit_req
Поделюсь еще одним простым способом снизить нагрузку на сервер и частично защититься от ддос с помощью модулей nginx — limit_conn и limit_req. Настроить их не сложно, частично результат работы первого модуля будет пересекаться с первыми двумя способами ddos защиты, описанными в начале. Он более простой для настройки, так что если не справились с теми способами, можно попробовать этот.
Смысл данных модулей в том, что один может ограничить одновременное количество разрешенных соединений с сайтом, а другой количество соединений в единицу времени.
Я ограничу в своем примере количество одновременных подключений к сайту с одного ip числом 50, а количество одновременных запросов к динамическому контенту не более 2-х в секунду. При этом будет разрешен всплеск (burst) запросов до 5-ти. Объясню, как понимать этот всплеск, так как сам не сразу понял, что конкретно он означает.
Если у нас идет превышение количества установленных запросов в секунду, то их выполнение задерживается, и они выстраиваются в очередь на исполнение с указанной скоростью. Размер этой очереди и равен значению всплеска. Все запросы, которым не хватит места в очереди, будут завершены с ошибкой. То есть, если запросов будет 4 в секунду, то 2 выполнятся сразу и еще 2 встанут в очередь. А если будет 10, то 2 выполнятся сразу, 5 встанут в очередь на выполнение по 2 штуки в секунду, а остальные будут завершены с ошибкой.
Вот пример конфига nginx для реализации установленных ограничений с целью защиты от ддос атак.
После этого перезапустите nginx и проверьте как работают лимиты. Ограничение на количество выполняемых динамических запросов можно увидеть, просто нажимая очень быстро F5 в браузере. Если будете достаточно ловки, то скоро увидите картинку
и запись в логе с ошибками:
Лимит на количество подключений можете проверить той же утилитой ab, о которой я рассказал во введении.
Только не забывайте, что тест нужно запускать не на конкретную страницу, тогда вы попадете на ограничение выполнения динамического контента, а на что-то другое. Например, как в моем примере, на картинку.
Заключение
Я рассмотрел наиболее простые способы для защиты web сервера от не менее простых ddos атак, которые больше похожи на баловство. Серьезная атака, которая просто зальет весь входящий канал сервера, даже не заметит наших защит. Но тем не менее, мне приходилось убеждаться в эффективности этих способов в отражении некоторых атак.
Существует до сих пор огромное количество веб серверов, которые вообще никак не защищены даже от утилиты ab :) Я знаю о чем говорю, так как мне попадаются в работу такие серверы. И есть так же много всяких ботов и простых программ, которые можно найти на просторах интернета и побаловаться, заваливая сайты, которые не готовы к нагрузкам вообще.
Есть еще один способ, такой же простой, как я описал, и эффективный от ботов, которые не понимают редиректов и кукисов. Не стал его описывать, так как не на чем проверить, да и просто устал писать статью, она получилась очень большая. Писал и редактировал ее долго, собирая скрипты и настройки по разным серверам и вспоминая, что я когда-то делал. Потом проверял все это отдельно.
Суть защиты в том, что с помощью nginx выдаем пользователю определенную cookies, а потом редиректим на запрашиваемую страницу. Если бот не понимает кукисов или редиректов, то он отваливается. Нормальные пользователи ничего не замечают. Возможно позже я отдельно расскажу про этот способ и дополню статью. А пока все. Буду рад замечаниям по существу в статьях.
Читайте также: