Loading IP address geographic location...
Offsore Cloud Services

DDoS-атака или нет?

uk ru

Когда не удается попасть на сайт, веб-приложение или сервер можно предположить, что причиной является DDoS-атака (распределенная атака типа "отказ в обслуживании", целью которой является недоступность сервера или сети). Порой это так и есть, но иногда нет.

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

1. Базовые действия

Чтобы быстро выявить причину недоступности сервера когда вы столкнулись с проблемой доступа или получили оповещение от системы мониторинга, можно предпринять следующие действия:

  1. проверьте email:

    письма от хостера или датацентра, касающиеся проблемы

  2. посетите сайт хостера и личный кабинет:

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

  3. проверьте доступность сайта/сервера:

    с серверов в других странах, а также через VPN/Tor/прокси (сделайте запросы по HTTP(s), к TCP-портам, чтобы проверить сталкиваетесь ли только вы с недоступностью, изучите таймауты, время ответа, SSL-сертификат)

  4. пинг сервера:

    через терминал или другой компьютер или сервис проверки пинга для того, чтобы увидеть отвечает ли сервер и нет ли потери сетевых пакетов (бывает также, что сервер работает, но не отвечает на ICMP-запросы или они заблокированы); пропингуйте соседние IP-адреса и адрес шлюза, возможно они тоже недоступны (например ping 1.2.3.5 и 1.2.3.1 если IP-адрес сервера 1.2.3.4)

  5. подключитесь по ssh (или VNC, RDP, KVM-over-IP) и проанализируйте систему:

    проверьте нагрузку через uptime, top/htop, netstat, iostat, посмотрите вывод dmesg, проверьте файл системных логов /var/log/syslog, проверьте работу резолвинга имен, а также возможность исходящих соединений...

  6. проанализируйте логи веб-сервера и приложения:

    на предмет каких-либо аномальных запросов

  7. проверьте домен и настройки DNS:

    дату истечения домена, записи DNS и т.д.

В процессе этого быстрого исследования вы можете обнаружить, что сервер недоступен только для вас, существует частичная потеря сетевых пакетов или какие-либо другие проблемы.

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

2. Расширенные действия

2.1 Хостер и датацентр

  1. технические работы: проверьте почту на наличие каких-либо писем от хостера о проведении работ по обслуживанию и недоступности сервера
  2. статус сервера: проверьте статус сервера в панели управления у хостера, статус может быть "Приостановлен" или "Остановлен" (попробуйте "Запустить"), проверьте лимиты по трафику, проверьте раздел "Счета", попробуйте подключиться к серверу через VNC или KVM-over-IP и т.п.
  3. твиттер: посмотрите аккаунт хостинговой компании и датацентра где размещен сервер, а также аккаунт CDN для поиска возможных новостей о потцениальном инциденте (пример: статус аккаунт Linode)
  4. страница состояния и инцидентов: посетите данные страницы у хостинговой компании (пример: страница состояния у OVH), датацентра и CDN (пример: страница состояния у Cloudflare), если CDN используется

2.2 Домен

  1. истекший домен: получите whois данные по домену и проверьте дату истечения ("Updated Date", "Creation Date"...), домен может оказаться не продлен, возможны какие-то подозрительные изменения или смена EPP статуса на serverHold и т.п.
  2. name-серверы (NS): name-серверы возвращают не тот IP-адрес или вообще не отвечают, используйте команды dig или nslookup для диагностики: 
    dig @nameserver yourdomain.com
nslookup yourdomain.com nameserver
  3. угон домена или изъятие правоохранительными органами: домен не истёк, но name-серверы изменены, или name-серверы возвращают некорректные данные, не удается попасть в панель управления к доменному регистратору, SSL-сертификат новый или недействительный/самоподписанный, статус домена clientDeleteProhibited

2.3 DNS

Возможны подобные проблемы с DNS:

  • Неверная A-запись
  • Неверная AAAA-запись
  • A и AAAA указывают на разные серверы
  • AAAA существует, но сервер недоступен по IPv6, а только по IPv4
  • A существует, но сервер недоступен по IPv4, а только по IPv6

Используйте такие программы как host, dig, nslookup для анализа.

2.4 Сеть

  1. сделайте проверку HTTP(S) и TCP-порт(ов) из разных стран, проанализируйте время ответа, таймауты, ошибки веб-сервера и т.п., возможно проблема у вашего интернет-провайдера или цензурные ограничения со стороны правительства (в этом случае рекомендуем поиск на OONI Explorer)
  2. пинг (отправка ICMP-запросов):
    • пинг сервера (со своей машины, с другой машины, через VPN, через check-host.net или альтернативы) для выявление потери сетевых пакетов
    • пинг соседних IP-адресов сервера и пинг шлюза
    • определите где именно происходит потеря, используя команды traceroute или mtr

    ICMP-запросы могут блокироваться (по умолчанию или как новое правило для защиты сети)

  3. подключитесь через VNC/KVM-over-IP, используя панель управления у хостера и проверьте возможно исходящих запросов по TCP и UDP (для резолвинга имён) как минимум

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

  • DDoS-атака направленная на переполнение канала
  • временные сетевые проблемы в датацентре или где-то на пути между вами и сервером
  • строгие настройки файервола (брандмауэра) или пакетного фильтра

При отсутствии ICMP-ответов и невозможности подключения к любому порту это может быть:

  • сетевая проблема у хостера или датацентра
  • сервер выключен (kernel panic, аппаратная проблема или достаточно послать сигнал включения для сервера...)
  • IP-адрес добавлен в нулевой маршрут (null route или black hole route) датацентром по причине слишком интенсивной DDoS-атаки или из-за отсутствия DDoS-защиты у хостера (правило нулевого маршрута может быть снято автоматически через несколько часов или сутки, а может быть снято только вручную по запросу)
  • сервер изъят полицией (в этом случае служба поддержки обычно перестает отвечать на тикеты) или уничтожен взломщиками

2.5 Аппаратная проблема

Для выделенных серверов возможны такие проблемы:

  • с памятью (RAM): используйте memtester или memtest86+
  • с жетским диском (HDD): smartctl, ioping, проверьте dmesg на I/O ошибки, проанализируйте /var/log/syslog
  • с RAID: cat /proc/mdstat
  • с сетевой картой (NIC): ip link show для проверки статуса карты
  • с процессором (CPU)
  • с питанием, кабелем, шлейфом и т.п.

Иногда есть возможно перезагрузиться в систему восстановления (rescue system / rescue mode).

При каких-либо подозрениях на проблему в аппаратной части следует написать в службу поддержки.

2.6 Программная проблема

В случае возможности удаленного подключения к сереру потенциальная DDoS-атака является не настолько мощной, имеет временный характер или причина проблемы в другом.

Какие следующие направления могут быть проверены?

Система:

  1. Разрешение доменных имен (изучите /etc/resolv.conf, воспользуйтесь host, nslookup и dig) - исходящие UDP-пакеты могут блокироваться или же name-серверы недоступны
  2. Системные лимиты: используйте ulimit, sysctl, lsof, /etc/security/limits.conf
  3. Системные логи: /var/log/syslog, /var/log/messages, dmesg, uptime, history, last (для получения данных последних входов на сервер), проанализируйте файлы /etc/shadow, ~/.ssh/authorized_keys, ~/.bash_history и т.п. для подтверждения того, что сервер не был взломан и не используется как часть ботнета, тем самым влияя на стабильность работы сервера
    примеры ошибок в выводе dmesg:
    TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters.
    nf_conntrack: nf_conntrack: table full, dropping packet
    Out of memory: Kill process 28725 (postgres) score 216 or sacrifice child Killed process 28725 (postgres) total-vm:36365660kB,anon-rss:32344260kB, file-rss:0kB, shmem-rss:0kB
  4. Файловая система (проверьте на ошибки с помощью fsck)
  5. Ресурсные лимиты: загрузка CPU (uptime), место на диске (df -h), память и своп (top/htop), процессы (ps aux), скорость и задержка при вводе-выводе (iostat, ioping)
  6. Последние обновления программного обеспечения: обновления или устаревшее программное обеспечение может быть причиной проблемы (проверьте последние строки history на предмет каких-либо подобных действий), или возможно требуется обновление какого-либо ПО

Сеть:

  1. TCP-порты 80 или 443 (или другие используемые порты сервера)
  2. Сетевые соединения и трафик (netstat -ant | wc -l, bmon, lsof, nload, iftop, ifstat, iptraf-ng, vnstat)
  3. Правила файервола/пакетного фильтра/fail2ban/...
  4. Графики и оповещения системы мониторинга (zabbix, prometeus и др.)
  5. Анализ сетевых пакетов с помощью tcpdump/wireshark, включение логирования у пакетного фильтра

Приложение:

  1. Состояние контейнеров (docker ps)
  2. SSL-сертификат (он может быть истекшим, неправильно сконфигурирован)
  3. База данных (работающий сервис, использование памяти, логи)
  4. Работающие процессы веб-сервера и веб-приложения
  5. Правила блокировки у веб-сервера
  6. Логи веб-сервера (в онлайн-режиме через tail -f, поиск 500-503 ошибок, анализ логов по времени недоступности)
    пример ошибок nginx:
    accept4() failed (24: Too many open files) socket() failed (24: Too many open files)
  7. Логи веб-приложения
  8. Детальный анализ приложений через strace

3. Заключение

В первую очередь вам необходимо сначала определить источник проблемы:
хостинг/датацентр, домен, DNS, сеть, программное обеспечение, "железо" или реальная DDoS-атака

Под DDoS-атакой:

  • сохраняйте спокойствие
  • не платите атакующим
  • определить тип атаки (проанализируйте логи и сетевую активность, получите информацию о типе аномального трафика от службы подержки хостера или датацентра):
    • сетевой уровень (L3) - Gbps
    • транспортный уровень (L4) - SYN/SYN-ACK/UDP флуд, NTP/DNS-амплификация, IP-фрагментация
    • прикладной уровень (L7)

DDoS-атака не такая мощная (или периодическая) и к серверу есть удаленный доступ напрямую или через дополнительный IP-адрес:

  • тюнинг системы с помощью sysctl, ulimit и т.д. (для защиты от атаки на ресурсы системы, SYN-флуда...)
  • настройка пакетного фильтра (iptables, nftables, pf, ipfw) или файервола на стороне хостера
  • лимиты соединений на стороне веб-сервера и веб-приложения, правила для WAF (Web Application Firewall), кэширование
  • улучшения веб-приложения, оптимизация, кэширование
  • защита веб-приложения на стороне фронтенда: через JavaScript и cookie, CAPTCHA (свое решение или используя CDN)
  • анализ логов веб-сервера и блокировка IP-адресов по паттернам веб-запросов
  • автоматическая отправка жалоб провайдерам на IP-адреса участвующие в атаке

DDoS-атака мощная, постоянная и пропускной способности канала недостаточно:

  • свяжитесь со службой поддержки хостера для помощи или рекомендаций
  • получите доступ к серверу через дополнительный IP-адрес, смените главный IP-адрес (если это как-то может помочь временно или для тестирования) для имени вашего веб-сайта или веб-приложения
  • подключите DDoS-защиту от вашего провайдера хостинговых услуг или смените хостера на другого, у которого есть защита от DDoS-атак (попробуйте JVPS.hosting c защитой от атак)
  • переключитесь на CDN (например на CloudFlare) и смените IP-адрес у сервера, разрешите доступ к серверу только с IP-диапазонов принадлежащих CDN
  • воспользуйтесь балансировщиками нагрузки
  • переключитесь на сервис полноценной защиты от DDoS-атак

DDoS-атаки не бесконечны, атака стоит атакущему определенных ресурсов. Но не стоит ожидать конца атаки, необходимо действовать как можно скорее (в зависимости от последствий для вашего бизнеса).

В большинстве случаев DDoS-атак может быть отражена без использования платных услуг третьих сторон, это зависит от уровня квалификации и опыта как в системном и сетевом администрировании, так и в защите от подобных атак.

2023.12.08 © Check-Host.net