Инструменты TCPDUMP С помощью параметра

Инструменты
TCPDUMP
С помощью параметра -i можно указать сетевой интерфейс, с которого следует
принимать данные:
tcpdump -i eth2
можно указывать порт
tcpdump -v -i eth0 dst port 80
порт можно менять
Запись в лог
tcpdump -v -n -w attack.log dst port 80 -c 250
-v самый простой уровень логирования, без изысканности.
-n преобразуем имена хостов в IP адреса
-w записываем анализ трафика в файл
-c количество захваченных пакетов
Просмотр лога
tcpdump -nr attack.log |awk '{print $3}' |grep -oE '[0-9]{1,}\.[0-9]{1,}\.[09]{1,}\.[0-9]{1,}' |sort |uniq -c |sort -rn
Если список очень длинный можно ограничить его указав нужное количество
выводимых строк
tcpdump -nr attack.log |awk '{print $3}' |grep -oE '[0-9]{1,}\.[0-9]{1,}\.[09]{1,}\.[0-9]{1,}' |sort |uniq -c |sort -rn | head -20
Что бы получить только IP адреса, без первого столбца, нужно убрать ключ -c
после uniq
NETSTAT
netstat -ntu | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -n
Просматриваем сетевые соединения, формируем
список из двух колонок, первая — количество соединений,
вторая — IP-адрес, чем больше соединений на 1 IP-адрес,
тем больше вероятности, что нас атакуют.
netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n
1 established)
1 Foreign
12 CLOSE_WAIT
15 LISTEN
64 LAST_ACK
201 FIN_WAIT2
334 CLOSING
605 ESTABLISHED
816 SYN_RECV
981 FIN_WAIT1
26830 TIME_WAIT
Виды DoS-атак
Флуд (англ. flood) — атака, связанная с большим количеством обычно бессмысленных или
сформированных в неправильном формате запросов к компьютерной системе или сетевому
оборудованию, имеющая своей целью или приведшая к отказу в работе системы из-за
исчерпания ресурсов системы — процессора, памяти либо каналов связи.
Атака второго рода — атака, которая стремится вызвать ложное срабатывание системы
защиты и таким образом привести к недоступности ресурса.
Если атака (обычно флуд) производится одновременно с большого количества IP-адресов, то
в этом случае она называется распределённой атакой на отказ в обслуживании (DDoS).
Наиболее частой проблемой игровых серверов является флуд
Флуд канала связи и TCP-подсистемы
Обнаружение DoS-атак
Существует мнение, что специальные средства для обнаружения DoS-атак не требуются,
поскольку факт DoS-атаки невозможно не заметить. Во многих случаях это действительно
так. Однако достаточно часто отмечались успешные атаки, которые были замечены жертвами
лишь через 2-3 суток. Бывало, что негативные последствия атаки (типа флуд) заключались в
излишних расходах по оплате трафика, что выяснялось лишь при получении счёта. Кроме
того, многие методы обнаружения атак неэффективны вблизи цели атаки, но эффективны на
магистральной сети. В таком случае целесообразно ставить системы обнаружения именно
там, а не дожидаться, пока пользователь, подвергшийся атаке, сам её заметит и обратится за
помощью. К тому же, для эффективного противодействия необходимо знать тип, характер и
другие показатели DoS-атаки, а оперативно получить эти сведения как раз и позволяют
системы обнаружения.
Методы обнаружения можно разделить на несколько больших групп:
сигнатурные — основанные на качественном анализе трафика;
статистические — основанные на количественном анализе трафика;
гибридные — сочетающие в себе достоинства двух предыдущих методов
SYN-флуд — одна из разновидностей сетевых атак типа отказ от обслуживания, которая
заключается в отправке большого количества SYN-запросов (запросов на подключение по
протоколу TCP) в достаточно короткий срок (RFC 4987).
Согласно процессу «трёхкратного рукопожатия» TCP, клиент посылает пакет с
установленным флагом SYN (synchronize). В ответ на него сервер должен ответить
комбинацией флагов SYN+ACK (acknowledges). После этого клиент должен ответить пакетом
с флагом ACK, после чего соединение считается установленным.
Принцип атаки заключается в том, что злоумышленник, посылая SYN-запросы, переполняет
на сервере (цели атаки) очередь на подключения. При этом он игнорирует SYN+ACK пакеты
цели, не высылая ответные пакеты, либо подделывает заголовок пакета таким образом, что
ответный SYN+ACK отправляется на несуществующий адрес. В очереди подключений
появляются так называемые полуоткрытые соединения (англ. half-open connection),
ожидающие подтверждения от клиента. По истечении определенного тайм-аута эти
подключения отбрасываются. Задача злоумышленника заключается в том, чтобы
поддерживать очередь заполненной таким образом, чтобы не допустить новых подключений.
Из-за этого легитимные клиенты не могут установить связь, либо устанавливают её с
существенными задержками.
Атака основывается на уязвимости ограничения ресурсов операционной системы для
полуоткрытых соединений, описанной в 1996 году группой CERT[1], согласно которой
очередь для таких подключений была очень короткой (например, в Solaris допускалось не
более восьми подключений), а тайм-аут подключений — достаточно продолжительным (по
RFC 1122 — 3 минуты).
ICMP-флуд - ping-флуд (от англ. ping-flood, дословно: наводнение (пакетами) ping) — тип
атаки на сетевое оборудование, ставящий своей целью отказ в обслуживании. Ключевой
особенностью (по сравнению с остальными видами флуд-атак) является возможность
осуществления атаки «бытовыми средствами» (программами и утилитами, входящими в
состав домашних/офисных версий операционных систем).
Суть атаки
ICMP-сообщение (эхо-запрос) обрабатывается сетевым оборудованием третьего (и выше)
уровня. В большинстве случаев это оборудование использует программные средства
маршрутизации и обработки пакетов. При этом эхо-запрос требует от устройства принятия
пакета, его обработки и формирования/отправки пакета с ответом на запрос. Объём
выполняемых действий при этом многократно превышает объём работы по маршрутизации
обычного пакета. Размер ICMP-запроса обычно небольшой (около 64 байт, при
максимальном размере пакета IP 64 кбайт). В результате, при формальном сохранении
небольшого трафика, возникает перегрузка по количеству пакетов, и устройство начинает
пропускать остальные пакеты (по другим интерфейсам или протоколам), что и является
целью атаки.
UDP-флуд — этот тип флуда атакует не компьютер-цель, а его канал связи. Провайдеры
резонно предполагают, что UDP более приоритетен, чем TCP. Большим количеством UDPпакетов разного размера вызывается перегрузка канала связи, и сервер, работающий по
протоколу TCP, перестаёт отвечать.
Распределённая атака
При распределённой атаке (с нескольких тысяч узлов), ICMP-запросы поступают с обычной
скоростью тестирования (около 1 пакета в секунду с узла), но одновременно с нескольких
тысяч компьютеров. В этом случае итоговая нагрузка на устройство, являющееся целью
атаки, может достигать пропускной способности канала (и заведомо превосходить скорость
обработки пакетов устройством).
В апреле 2007 года сайты правительства Эстонии подверглись распределённой ICMP-атаке (в
связи с событиями вокруг бронзового солдата). В качестве «орудия» атаки использовалась
диагностическая утилита ping, отправляющая пакет объёмом 20000 байт на сайт www.riik.ee.
По сообщениям СМИ атака была успешной
Противодействие атаке
Для противодействия атаке (помимо блокирования трафика с отдельных узлов и сетей)
возможны следующие меры:
отключение ответов на ICMP-запросы (отключение соответствующих служб или
предотвращение отклика на определенный тип сообщения) на целевой системе;
Понижение приоритета обработки ICMP-сообщений (при этом весь остальной трафик
обрабатывается в обычном порядке, а ICMP-запросы обрабатываются по остаточному
принципу, в случае перегрузки ICMP-сообщениями часть из них игнорируется).
отбрасывание или фильтрация ICMP-трафика средствами межсетевого экрана.
увеличение очереди обрабатываемых подключений
Флуд прикладного уровня
HTTP-флуд.
Один из самых распространенных на сегодняшний день способов флуда. Основан на
бесконечной посылке HTTP-сообщений GET на 80-ый порт с целью загрузить web-сервер
настолько, чтобы он оказался не в состоянии обрабатывать все остальные запросы. Часто
целью флуда становится не корень web-сервера, а один из скриптов, выполняющих
ресурсоемкие задачи или работающий с базой данных. В любом случае, индикатором
начавшейся атаки будет служить аномально быстрый рост логов web-сервера.
Многие службы устроены так, что небольшим запросом можно вызвать большой расход
вычислительных мощностей на сервере. В таком случае атакуется не канал связи или TCPподсистема, а непосредственно служба — флудом подобных «больных» запросов. Например,
веб-серверы подвержены HTTP-флуду: для выведения сервера из строя может применяться
как простейшее GET /, так и сложный запрос в базу данных наподобие GET
/index.php?search=<случайная строка>.
КАК ОБНАРУЖИТЬ И БОРОТЬСЯ
Определение наличия DDoS
Как выяснилось позже, наличие DDoS проще всего определить,
установив скорость поступающих по внешнему интерфейсу пакетов,
в linux это проще всего сделать чтением из /proc/net/dev:
root@laylah ~ #cat /proc/net/dev
Inter-| Receive
| Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls
carrier compressed
lo:59286813 278952 0 0 0 0
0
0 59286813 278952 0 0 0 0
0
0
eth0:38433436 575324 0 0 0 0
0
0 64005875 101279 0 0 0 0
0
0
eth1:
0
0 0 0 0 0
0
0
0
0 0 0 0 0
0
0
eth2:
0
0 0 0 0 0
0
0
0
0 0 0 0 0
0
0
eth3:
0
0 0 0 0 0
0
0
0
0 0 0 0 0
0
0
eth4:160842629303 1968355293 0 9282641 689519 0
0
0 175815679927
464227952 0 0 0 0
0
0
На основании поля "Receive packets" можно рассчитать
скорость поступающих на интерфейсов пакетов, для моего
сервера в нормальных условиях эта цифра колеблется
от 100 до 1000 пакетов в секунду.
Во время же DDoS цифра за несколько десятков секунд
достигает значений в десятки тысяч пакетов в секунду
и продолжает держаться, пока продолжается атака.
1.ICMP-флуд.
Почти безболезненный способ абсолютной защиты основан на отключении ответов на
запросы ICMP ECHO:
# sysctl net.ipv4.icmp_echo_ignore_all=1
Или с помощью брандмауэра:
# iptables -A INPUT -p icmp -j DROP --icmp-type 8
2. SYN-флуд.
Наличие SYN-флуда устанавливается легко – через подсчет числа «полуоткрытых» TCPсоединений:
# netstat -na | grep ":80\ " | grep SYN_RCVD
В обычной ситуации их не должно быть совсем (или очень небольшое количество: максимум
1-3). Если это не так – ты атакован, срочно переходи к дропанью атакующих.
Борьба какУвеличение очереди «полуоткрытых» TCP-соединений:
# sysctl -w net.ipv4.tcp_max_syn_backlog=1024
Уменьшение времени удержания «полуоткрытых» соединений:
# sysctl -w net.ipv4.tcp_synack_retries=1
Включение механизма TCP syncookies:
# sysctl -w net.ipv4.tcp_syncookies=1
Ограничение максимального числа «полуоткрытых» соединений с одного IP к конкретному
порту:
# iptables -I INPUT -p tcp --syn --dport 80 -m iplimit --iplimit-above 10 -j DROP
3. UDP-флуд.
Типичный метод захламления полосы пропускания. Основан на бесконечной посылке UDPпакетов на порты различных UDP-сервисов. Легко устраняется за счет отрезания таких
сервисов от внешнего мира и установки лимита на количество соединений в единицу
времени к DNS-серверу на стороне шлюза:
# iptables -I INPUT -p udp –dport 53 -j DROP -m iplimit –iplimit-above 1
4. HTTP-флуд.
HTTP-флуд обнаружить несколько сложнее.
Для начала нужно подсчитать количество процессов Apache и количество коннектов на 80-ый
порт (HTTP-флуд):
# ps aux | grep httpd | wc -l
# netstat -na | grep ":80\ " | wc -l
Значения, в несколько раз превышающие среднестатистические, дают основания задуматься.
Далее следует просмотреть список IP-адресов, с которых идут запросы на подключение:
# netstat -na | grep ":80\ " | sort | uniq -c | sort -nr | less
Однозначно идентифицировать DoS-атаку нельзя, можно лишь подтвердить свои догадки о
наличии таковой, если один адрес повторяется в списке слишком много раз (да и то, это
может говорить о посетителях, сидящих за NAT’ом). Дополнительным подтверждением
будет анализ пакетов с помощью tcpdump:
# tcpdump -n -i eth0 -s 0 -w output.txt dst port 80 and host IP-сервера
Показателем служит большой поток однообразных (и не содержащих полезной информации)
пакетов от разных IP, направленных на один порт/сервис (например, корень web-сервера или
определенный cgi-скрипт).
Окончательно определившись, начинаем дропать неугодных по IP-адресам (будет гораздо
больше эффекта, если ты сделаешь это на маршрутизаторе):
# iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port http -j DROP
Или сразу по подсетям:
# iptables -A INPUT -s xxx.xxx.0.0/16 -p tcp --destination-port http -j DROP
Методы борьбы с HTTP-флудом включают в себя тюнинг web-сервера и базы данных с
целью снизить эффект от атаки, а также отсеивание DoS-ботов с помощью различных
приемов. Во-первых, следует увеличить максимальное число коннектов к базе данных
одновременно. Во-вторых, установить перед web-сервером Apache легкий и
производительный nginx – он будет кэшировать запросы и отдавать статику. Это решение из
списка «must have», которое не только снизит эффект DoS-атак, но и позволит серверу
выдержать огромные нагрузки.
В случае необходимости можно задействовать nginx-модуль ngx_http_limit_req_module,
ограничивающий количество одновременных подключений с одного адреса
(http://sysoev.ru/nginx/docs/http/ngx_http_limit_req_module.html). Ресурсоемкие скрипты
можно защитить от ботов с помощью задержек, кнопок «Нажми меня», выставления кукисов
и других приемов, направленных на проверку «человечности».
Определение типа атаки с помощью утилиты tcpdump
Формат выходной информации tcpdump
В начале каждой строки листинга tcpdump ставится отметка времени, которая является
текущим временем часов в формате: hh:mm:ss.frac, где frac - это доли секунд. За отметкой
времени может указываться интерфейс, на который происходит прием пакетов, например
eth0, eth1, lo и т. п. Запись eth0< означает, что идет прием пакетов на интерфейс eth0.
Соответственно запись eth0> означает, что идет отправка пакетов в сеть с интерфейса eth0.
Дальнейшие сведения зависят от типа принимаемого пакета (ARP/RARP, TCP, UDP, NBP,
ATP, ...). Далее показаны форматы для некоторых основных типов пакетов.
TCP Packets
Src.port > dst.port: flags data-seqno ack window urgent options
Src.port и dst.port - это IP-адрес и порт, соответственно источника и приемника пакетов.
Flags - это флаги, установленные в заголовке TCP-пакета. Могут принимать комбинации из
символов S (SYN), F (FIN), P (PUSH), R (RST), также в этом поле может стоять одна точка ".",
которая означает отсутствие установленных флагов.
Data-seqno - описывает данные, содержащиеся в пакете, в таком формате: first:last(nbytes), где
first и last - номер последовательности первого и последнего байта пакета, nbytes - количество
байт данных. Если параметр nbytes равен нулю, то first и last совпадают.
Ack - следующий номер последовательности (ISN + 1).
Window - размер окна.
Urgent - указывает на наличие срочных данных в пакете (флаг URG).
Options - здесь могут указываться дополнительные сведения, например (максимальный
размер сегмента).
UDP Packets
Src.port > dst.port: udp nbytes
Udp - метка, указывающая на то, что идет анализ UDP-пакетов.
Nbytes - число байтов данных, которые содержит UDP-пакет.
ICMP Packets
Src > dst: icmp: type
Icmp - метка, идентифицирующая ICMP-пакет.
Type - тип ICMP-сообщения, например echo request или echo reply.
Примеры флуда в логе tcpdump
Учимся обнаруживать атаку в листингах tcpdump
Некоторые системы обнаружения атак (NIDS) используют журналы протоколирования
созданные утилитой tcpdump, но мы сейчас научимся самостоятельно определять основные
типы атак в листингах tcpdump.
Рис.1. DoS-атака SYN Flood
На рисунке 1 показан листинг tcpdump в котором зафиксировала DoS-атака SYN Flood
против узла 172.23.115.22. Об этом говорит множество SYN-запросов на один порт (80) за
очень короткий промежуток времени (десятки запросов за одно и то же время:
13:15:11.580126).
Рис.2. Распределенная DoS-атака (DDoS) ICMP flooding
На рисунке 2 зафиксирована распределенная DoS-атака (DDoS) ICMP flooding (flood ping).
На первый взгляд можно подумать, что это обычный ping хоста, поскольку просто
принимаются ICMP-сообщения ECHO-REQUEST, а в ответ посылаются сообщения ICMP
ECHO-REPLY. Если бы не слишком большое число запросов за столь короткий промежуток
времени, к тому же все они приходят с разных IP-адресов.
Рис.3. Атака Land
На рисунке 3 видно, что IP-адреса, а также порт источника и приемника совпадают - это
явный признак атаки Land. Шторм Land-запросов приводит к зацикливанию и может
полностью вывести узел из строя. Долгое время считалась, что эта атака окончательно ушла
в историю, вместе с устаревшими системами, однако багтраки всего мира не так давно
сообщили, что обнаружена возможность осуществления Land против систем Windows Server
2003 и Windows XP SP2. Стоит отметить, что существует несколько модификаций этой атаки,
например Latierra - когда посылаются пакеты на несколько портов одновременно.
Рис.4. TCP-сканирование узла 172.23.115.22
На рисунке 4 ты видишь множество попыток установить TCP-соединение на различные
порты узла 172.23.115.22. Большинство записей имеют следующий вид:
12:00:17.899408 eth0 < 192.168.10.35.2878 > 172.23.115.22.340: S 3477705342:3477705342 (0)
win 64240 (DF)
12:00:17.899408 eth0 > 172.23.115.22.340 > 192.168.10.35.2878: R 0:0 (0) ack 3477705343 win 0
(DF)
В первой строке передается TCP SYN-запрос, а во второй отсылаются в ответ пакеты TCP
RST - что говорит о том, что подключение к данному порту невозможно. В листинге
встречается также такая цепочка записей:
12:00:17.899408 eth0 < 192.168.10.35.2879 > 172.23.115.22.ssh: S 3477765723:3477765723 (0)
win 64240 (DF)
12:00:17.899408 eth0 > 172.23.115.22.ssh > 192.168.10.35.2879: S 3567248280:3567248280 (0)
ack 3477765724 win 5840 (DF)
12:00:17.899408 eth0 < 192.168.10.35.2879 > 172.23.115.22.ssh: . 1:1(0) ack 1 win 64240 (DF)
12:00:17.899408 eth0 < 192.168.10.35.2879 > 172.23.115.22.ssh: R 3477765724:3477765724(0)
win 0 (DF)
Здесь аналогично, в первой строке передается SYN-запрос на ssh-порт (порт 22) узла
172.23.115.22. Затем в следующей строке показано, что узел 172.23.115.22 посылает ответ с
установленными флагами SYN и ACK, при этом значение ACK увеличено на единицу
(3477765723+1). В третьей строке узел 192.168.10.35 подтверждает получение ответа. И в
последней строчке соединение закрывается узлом 192.168.255.20 посылкой RST. Это было
осуществлено трехэтапное рукопожатие TCP (TCP three-way handshake), следовательно, на
рисунке 4 зафиксировано TCP-сканирование узла 172.23.115.22.
Можно предположить с большой вероятностью, что работает сканер nmap (с установленным
флагом -sT), т. к. номера портов, на которые приходят запросы, увеличиваются не
последовательно на единицу, как в случае большинства других сканеров, а совершенно
случайным образом (хотя так поступает не только один nmap).
Рис.5. Скрытое (stealth) TCP SYN сканирование
На рисунке 5 листинг похож на предыдущий. На узел 172.20.100.100 поступают SYNзапросы, и в случае закрытого порта в ответ отсылаются пакеты с флагом RST. Однако
реакция на открытые порты отличается по сравнению с предыдущим листингом:
12:44:17.899408 eth0 < 192.168.99.200.2879 > 172.20.100.100.http: S 1045782751:1045782751
(0) win 4096
12:00:17.899408 eth0 > 172.20.100.100.http > 192.168.99.200.2879: S 2341745720:2341745720
(0) ack 1045782752 win 5840 (DF)
12:00:17.899408 eth0 < 192.168.99.200.2879 > 172.20.100.100.http: R 1045782752:1045782752
(0) win 0
Заметно, что в ответ на SYN-запрос возвращается пакет с установленными флагами SYN и
ACK, после чего соединение обрывается посылкой флага RST. Значит, трехэтапное
рукопожатие не было выполнено полностью - это говорит о том, что порты узла
172.20.100.100 сканируются методом незавершенного открытого сеанса (half-open scanning)
или как его еще называют - скрытое (stealth) TCP SYN сканирование (флаг -sS в сканере
nmap).
Рис.6. UDP-сканирование
В листинге на рисунке 6 на различные порты поступают UDP-дейтаграммы, содержащие 0
байт данных. Это явный признак того, что осуществляется UDP-сканирование. Если порт
закрыт, узел отсылает ICMP-сообщение port unreachable. Если такое сообщение не
посылается, значит, порт открыт. Отмечу, что 0 байт данных при UDP-сканировании
посылает сканер nmap (с установленным флагом -sU), другие сканеры могут посылать
большее число байт данных, например, Xspider посылает 3 байта в каждом пакете.
Если же в листинге будет множество запросов, в которых не установлено ни одного флага
(стоит точка в поле Flags), например:
02:12:59.899408 eth0 < 10.15.100.6.41343 > 192.168.2.4.30310: . 971654054:971654054(0) win
2048
02:12:59.899408 eth0 > 192.168.2.4.30310 > 10.15.100.6.41343: R 0:0(0) ack 971654054 win 0
(DF)
02:12:59.899408 eth0 < 10.15.100.6.41343 > 192.168.2.4.275: . 971654054:971654054(0) win
3072
То это ненормальное состояние, которое явно свидетельствует о том, что выполняется Nullсканирование (флаг -sN в сканере nmap).
FIN-сканирование (флаг -sF в сканере nmap) легко вычислить по множеству поступающих
пакетов с установленным флагом FIN:
04:17:40.580653 eth0 < 192.168.10.35.46598 > 172.23.115.22.ftp: F 1918335677: 1918335677(0)
win 2048
04:17:40.580653 eth0 < 192.168.10.35.46599 > 172.23.115.22.ftp: F 1918337777: 1918337777(0)
win 3072
Сканирование по методу "рождественской елки" (TCP Xmas Tree scan) (флаг -sX в nmap)
определяется по множеству запросов с установленными флагами FIN, URG и PUSH.
Закрытые порты в ответ посылают пакет с флагом RST:
03:22:46.960653 eth0 < 192.168.10.35.55133 > 172.23.115.22.19150: FP
1308848741:1308848741(0) win 2048 urg 0
03:22:46.960653 eth0 > 172.23.115.22.19150 > 192.168.10.35.55133: R 0:0(0) ack 1308848741
win 0 (DF)
03:22:46.960653 eth0 < 192.168.10.35.55133 > 172.23.115.22.smtp: FP
1308848741:1308848741(0) win 3072 urg 0
Существует еще сканирование с помощью ACK-пакетов (флаг -sA в nmap). Этот метод
используется для определения правил, используемых брандмауэром. На порты сканируемого
узла отправляются пакеты с установленным флагом ACK. Если в ответ приходят пакеты с
флагом RST, то порты классифицируются как нефильтруемые (unfiltered) брандмауэром. Если
никакого ответа не приходит порт считается фильтруемым (filtered), для подтверждения
сканер делает запрос дважды, листинг tcpdump будет выглядеть примерно так:
13:44:46.361688 eth0 < 192.168.91.130.56528 > 172.18.10.23.30310: .
1114201130:1114201130(0) ack 0 win 2048
13:44:46.361688 eth0 > 172.18.10.23.30310 > 192.168.91.130.56528: R 0:0(0) win 0 (DF)
13:44:46.361688 eth0 < 192.168.91.130.56528 > 172.18.10.23.275: . 1114201130:1114201130(0)
ack 0 win 3072
13:44:46.361688 eth0 >172.18.10.23.275 > 192.168.91.130.56528: R 0:0(0) win 0 (DF)
13:44:46.361688 eth0 < 192.168.91.130.56528 > 172.18.10.23.nntp: . 1114201130:1114201130(0)
ack 0 win 2048
Рис.7. Атака Smurf
На рисунке 7 показана атака Smurf. Хакер посылает широковещательный ICMP-запрос (echo
request) в сеть 172.23.115.0 от имени жертвы (192.168.10.1). Каждый компьютер сети (в
листинге показан только узел 172.23.115.1), получивший широковещательный запрос
генерирует ответ (echo reply) на адрес жертвы, вызывая ее "отказ в обслуживании".
Периодическое повторение запроса позволяет поддерживать проведение атаки против хоста
192.168.10.1. Утилита tcpdump после имени интерфейса (eth0) предупреждает опцией B, что
идет прием широковещательного запроса. Есть разновидность атаки Smurf под названием
Fraggle (осколочная граната), в ней используется не ICMP-протокол, а UDP:
08:34:18.899408 eth0 B 192.168.10.22.34904 > 172.23.115.255.echo: udp 64
08:34:18.899408 eth0 > 172.23.115.255.echo > 192.168.10.22.34904: udp 64
08:34:18.520602 eth0 B 192.168.10.22.34904 > 172.23.115.255.echo: udp 64
Атакующий посылает обманные UDР-пакеты на широковещательной адрес усиливающей
сети (обычно на порт 7 (echo)). Каждая система сети, в которой разрешен ответ на эхопакеты, возвратит пакеты системе-жертве, в результате чего будет сгенерирован большой
объем трафика.
Иногда в поступающих пакетах могут быть установлены нестандартные сочетания флагов,
например, взаимоисключающие флаги SF (SYN+FIN), где SYN - устанавливает соединение,
FIN - завершает. Также могут быть указаны резервные флаги [ECN-Echo,CWR] и идущие
подряд флаги FIN без предшествующих SYN, например:
11:16:22:899931 eth0 < 192.168.10.35.2879 > 172.23.115.22.491: SF 3477765723:3477765723
(0) win 1024
11:16:22:899931 eth0 < 192.168.10.35.2880 > 172.23.115.22.1351: S [ECN-Echo,CWR]
3477800253:3477800253 (0) win 4096
11:16:22:899931 eth0 < 192.168.10.35.2881 > 172.23.115.22.2880: SFR 3477835208:3477835208
(0) win 4096
Такие запросы злоумышленник может использовать в двух целях. Во-первых, нестандартные
комбинации флагов могут вывести узел из строя или способствовать обходу систем
обнаружения атак и межсетевых экранов. А, во-вторых, нестандартные флаги используются
для идентификации ОС узла. Разные оси реагируют по-разному на пакеты
несоответствующие стандартам RFC - эту возможность практикуют утилиты nmap, queso и
пр.
DNS Amplification DDoS: Анатомия атаки и защиты.
Сегодня у нас первая часть большой статьи про устройство ныне печально известной DDoS-
атаки через отражение (DNS Amplification). Конечная цель статьи — показать, как можно
эффективно бороться с паразитным DNS-трафиком, для чего сначала рассмотрим основы в
первой части статьи, где исследуем механизмы и глубинное устройство этой атаки.
Когда-то давным-давно, в те далекие времена, когда все в Интернете доверяли друг другу,
когда было нормальным отвечать на любой сторонний запрос по сети — «нет проблем,
пожалуйста, можешь пользоваться моим сервисом, если тебе это нужно», — была задумана и
спроектирована замечательная интернет-служба — DNS. Она позволяет приводить в
соответствие человеко-понятные доменные адреса в их компьютерно-числовую форму и
наоборот.
В отличие от других интернет-сервисов, DNS является своего рода связующим хребтом для
всего Интернета: мало кто задумывается, что сервис разрешения имен косвенно используется
фактически во всех других службах и протоколах.
Сегодня же реальность такова, что DNS нашёл своё применение и в других, в том числе и
криминальных целях. Поэтому предлагаю рассмотреть теорию правильной настройки этой
службы на практическом примере противодействия генерированию паразитного трафика для
распространенной атаки — DNS Amplification DDoS (DAD).
Вызовы сегодняшнего дня
В феврале месяце 2012 года известная хакерская группа Anonymous объявила миру о
готовящейся сетевой акции под названием Global Blackout. Она была запланирована на 31
марта, именно в этот день хакеры планировали вывести из строя все 13 корневых DNSсерверов Интернета.
Для осуществления этой атаки на базе инструмента AntiSec DHN ими была написана
специальная программа «Reflective DNS Amplification», которая, как ожидается, будет
запущена сочувствующими в указанный «час X» на десятках тысячах компьютеров по всему
миру.
Технический смысл сего действия — проведение мощнейшей DDoS-атаки по уже обкатанной
схеме, получившей устоявшееся название — «DNS Amplification».
С одной стороны можно вспомнить множество масштабных атак уже вошедших в историю, в
том числе выполненных против корневых DNS-серверы с помощью именно этой техники.
Несмотря даже на выход из строя нескольких корневых серверов в тех отдельных случаях,
ещё никогда не удавалось достичь прекращения работы сразу всех root-серверов.
С другой стороны DAD — это именно тот тип атаки, который прочно удерживает
неоспоримое лидерство среди наиболее мощных DDoS-атак, проведенных в истории
Интернета.
Каждый новый год, атаки этой разновидности берут всё новые, ранее казавшиеся
фантастическими высоты по мощности генерируемой ими «волны» трафика.
Что же это за дьявольский механизм, который поднимает в виртуальном пространстве
цунами такой мощности и разрушительности?
Общая схема работы DNS
Чтобы следовать дальше, давайте предварительно в справочных целях рассмотрим общий
алгоритм работы DNS (смотрите план-схему ниже).
Пользователь запрашивает IP-адрес требуемого ему домена webserver.com у DNS (как
правило, предоставляемого провайдером интернет-услуг), обозначим его далее как User
Primary DNS Server;
Если данный DNS-сервер не авторитативный для запрашиваемого домена, не содержит этот
адрес в своём временном кэше, а также работает в рекурсивном режиме (а это справедливо
для большей части серверов такого рода) — этот запрос задаётся уже от имени User Primary
DNS Server одному из корневых DNS-серверов (Root DNS Server);
Если Root Server не обладает данным соответствием, он возвращает для User Primary DNS
Server подсказку — адрес другого DNS-сервера, который является управляющим (TLD) для
указанной зоны (в нашем случае .com);
User Primary DNS Server дождавшись его ответа, итеративно повторяет свой запрос уже к
указанному в ответе DNS-серверу .com-зоны;
DNS-сервер .com-зоны также может не знать соответствия, и тогда он возвращает в ответ
адрес авторитативного для этого домена DNS-сервера — назовем его Domain Primary DNS
Server;
User Primary DNS Server получив в очередной раз ответ-подсказку, повторяет запрос в
указанный адрес — на этот раз уже напрямик к Domain Primary DNS Server;
И, наконец, Domain Primary DNS Server возвращает искомое соответствие IP-адреса для
указанного домена;
После вышеописанной серии итеративных опросов, User Primary DNS Server, наконец-то,
успешно возвращает значение IP-адреса для домена webserver.com своему клиенту, завершив
обслуживание рекурсивного запроса.
Конечно, это лишь примерная схема работы DNS (в данном случае её стандартный
рекурсивный вариант), в реальной жизни всё может работать с некоторыми отличиями в
зависимости от особенностей настройки каждого конкретного сервера.
Внимательно изучив эту стандартную последовательность, мы готовы перейти к
рассмотрению уязвимостей и некоторых слабых мест этой схемы на примере сегодняшней
DDoS-атаки.
Динамика работы DNS Amplification
Интересной особенностью именно DAD является то, что здесь, в общем случае, даже не
нужно наличие ботнета. Для успешной атаки достаточно самому «сидеть» на относительно
быстром канале, после чего использовать эффект «усиления атаки» через описанную ниже
DNS-схему.
Ситуация драматически меняется, если совместную игру начинают «организованные
преступные группировки» из десятков тысяч (или как в описанном выше случае —
миллионов) зомбированных компьютеров со всего мира.
Давайте рассмотрим схему того, как это работает (см. графический алгоритм чуть выше):
1. Атакующий посылает сигнал скомпрометированным компьютерам (ботнет) на начало
цикла запросов к DNS;
2. Все зомби-компьютеры начинают выполнять запросы каждый к своему User Primary DNS
Server с подделанным обратным IP-адресом (spoofed ip), который указывает на компьютер
жертвы;
3. Описание шагов 3-8опускаем — это серия стандартных итеративных запросов,
выполняемая рекурсивным сервером User Primary DNS Server, полностью аналогичных той
схеме, которая была описана выше (см. пункты2-7);
9. Итак, в результате, пакет с IP-адресом для webserver.com должен быть доставлен клиенту
User Primary DNS, но реально его “усиленный” вариант будет отправлен на ранее
подделанный IP-адрес жертвы.
Чтобы в многообразии деталей этой многоступенчатой схемы не потерять суть атаки,
предлагаю отдельно выделить три ключевых момента, которые делают принципиально
возможной реализацию данного сверхэффективного варианта DDoS:
Эффект отражения: использование спуфинга обратного IP-адреса даёт перенаправление всех
результирующих пакетов-ответов на заранее заданную жертву.
Коэффициент усиления атаки (amplification factor): этот фактор может достигать при самых
благоприятных условиях 73 (в большинстве случаев колеблется между30-60). Это значит, что
на каждый посланный условный 1 байт-запроса — вышеупомянутая схема из неверно
настроенных DNS-серверов вернет30-60 байтов-ответа, что и обеспечивает кратное
нарастание DDoS-эффекта при отражении.
Проблема «open resolver»: в большинстве случаев это устаревшая версия DNS-сервера или
просто неверно настроенный его экземпляр. Он позволяет не только получать запросы из
чужих сетей, выполняя рекурсивные запросы для них, но и посылать ответы без
необходимых предварительных проверок. В нашем примере подобным уязвимым сервером
выступает User Primary DNS Server.
DNS: спецсвязь для ботнета
Ботнет — это большая распределенная система, где на первый план всё чаще выходит
надежный механизм обратной связи, который позволил бы держать постоянную связь с
управляющей головой ботнета (говоря на сленге ботостроителей — с «папой»).
Времена использования для отправки управляющих команд классического IRC-канала—
ушли в прошлое. Для донесения кодированных посланий теперь чаще всего применяются
сервисы типа Twitter (см. рис.3) или p2p-сети.
Недостаток такого подхода в том, что современные «ортодоксальные» администраторы часто
сосредоточены на фильтрации этих традиционных протоколов (главным образом http), но в
большинстве случаев совершенно упускают из вида нестандартные подходы. Например,
возможность тунелирования TCP/IP-трафика через стандартные DNS-запросы в целях
внешнего управления ботами или троянами сидящими внутри корпоративных сетей.
Именно поэтому это направление получило всплеск такой популярности в последнее время.
Для этого существуют удобные шелл-коды, которые по этому же принципу пробрасывают
внутрь подобной «защищенной» локальной сети свою консоль управления, чаще всего
используя для этого DNS-запросы типа TXT.
В этой связи стоит также напомнить о dnscat (эта известная утилита часто упоминается как
самостоятельный инструмент, но это лишь часть пакета DNS-утилит nbtools ), созданная
специально для этих целей, а также о не менеe известном в узких кругах протоколе NSTX (IP
over DNS — NameServer Transfer Protocol). В случае с NSTX решение получается достаточно
надежное, максимальный размеры пакетов которые здесь можно передать —512 байт по UDP,
которые затем «глубоко в тылу» собираются в полноценные IP-пакеты.
Более новый, но аналогичный по идее инструмент — Heyoka, — кроме тунелинга TCP/IP
трафика также выполняет спуфинг адресов-источников запросов для самомаскировки.
OpenSource-природа этих решений приводит к тому, что принципиальные кодовые части
упомянутых программ для тунелирования сегодня обнаруживаются в «личинках» самых
разных ботнетов.
В частности популярный для Windows пакет Iodine, который в наших условиях часто
используется для незаконного «добывания интернета» абонентом, ранее отключенным
провайдером за неуплату (DNS, как правило, при этом остаётся рабочим), применяется в коде
одной из разновидностей ботнета Gheg.
Другая подобная система OzymanDNS — популярна у «специалистов» для надежного
проброса своего SSH через служебный DNS-трафик перед самым носом даже у самых
строгих сисадминов.
Более подробно про DNS-тунелинг можно почитать вот здесь.
В такой схеме единственный минус (который именно для случая ботов не так существенен):
DNS-клиент (зомби) может связываться с «папой» только сам и в одностороннем порядке.
Статистика собранная при наблюдении подобных «пчелиных улеев» показывает, что
«пробив» у подобной схемы чрезвычайно высок, — чаще всего зомби с обратной связью на
основе DNS-тунелинга надежно управляются даже из самых глубоких недр тщательно
«зафильтрованной» корпоративной сети.
Во второй части этой статьи мы рассмотрим уже практическую часть борьбы с такого рода
интернет-угрозами.
Продолжение большого разговора про особенно сильную разновидность DDoS-атаки через
«DNS-отражение и усиление пакетов» (DNS Amplification DDoS, ещё её иногда называют
DNS reflect attack).
Рекомендую сначала обязательно проштудировать первую часть этой статьи, чтобы
добросовестно понять устройство самой атаки, в противном случае многие советыобъяснения по борьбе с ней ниже рискуют остаться не правильно понятыми.
Итак, после порции необходимой теории в первой части — переходим к практической части
по борьбе с паразитным транзитным DNS-трафиком, который и даёт возможность
генерировать «усиливающий эффект» данного вида весьма опасного DDoS, в котором
каждый из нас невольно может стать соучастником.
DNS на профилактике
В этом месте есть смысл немного остановиться, чтобы осмыслить всё сказанное выше на
голых цифрах. Так, согласно исследованиям компании Nominum, в сети было обнаружено как
минимум 10 миллионов DNS-серверов настроенных в режиме «open resolver».
Из них около 2 миллионов позволяют выполнять рекурсивные запросы через себя вообще
любому желающему. В среднем, 71% всех дистанционно исследованных этой компанией
публичных DNS-серверов имеют те или иные ошибки в настройках, при этом нужно учесть,
что автоматически проверялись лишь наиболее базовые и распространенные проблемы
такого рода. Глядя на эту статистику становится очевидным то, что сейчас в сети труднее
найти правильно настроенный DNS, нежели чем уязвимый.
Осознав всю серьёзность ситуации, давайте для начала попробуем перечислить типичные
симптомы в работе DNS, которые сигнализируют о его негласном использовании в качестве
одного из ретрансляторов паразитного трафика в рамках атаки по схеме DAD:
- резкое преобладание у DNS-сервера UDP-трафика перед обычным TCP-трафиком.
- большое количество запросов к NS-серверу вида «.» (зона «точка»), как вариант иногда
встречаются однобуквенные домены (чем короче имя домена, тем короче сам запрос и выше
ответный коэффициент усиления). При этом такие оптимизированные пакеты-запросы будут
заметно меньшими, чем обычные.
-обратные IP-адреса источников запросов, которые лежат за пределами вашей локальной сети
(как правило, это всегда один и тот же IP-адрес жертвы).
- огромный исходящий трафик от вашего DNS-сервера, при этом все пакеты-ответы в
большинстве случаев — одинакового размера, что очень хорошо видно в лог-файле.
- десятки (для кого-то даже и сотни) тысяч запросов от одного клиента (подсети) в течение
часа.
В последнее время начинают получать распространение так называемые «ленивые ботнеты»,
состоящие, как правило, из большого количества особей (от ста тысяч до миллиона голов),
которые монотонно «долбят» с очень низкой интенсивностью (например, один пакет в 3
минуты).
Учитывая их чудовищное количество, жертва всё равно задыхается от тяжести суммарной
нагрузки, тогда как сам «зомби» при такой стратегии не только никак не выдаёт себя на
зараженном хосте, но и существенно затрудняет своё детектирование на атакуемой стороне.
Именно поэтому администратору лучше не полагаться лишь на какие-то внешние симптомы
паразитной активности, а сосредоточиться на изначально правильной настройке DNSсервера
Поскольку объективно бороться с возможностью ретрансляции (или усиления) атаки типа
DNS Amplification через ваш сервер имен не всегда просто (некоторые распространенные
решения и патчи почти всегда обладают нежелательными побочными эффектами), я приведу
здесь вариант наиболее сбалансированной настройки от авторитетной организации CCIRC на
примере BIND:
1. В файл /etc/hosts.conf добавляем новую строку, с целью противодействия спуфингу:
nospoof on
2. Дальше открываем файл /etc/named.conf для отключения рекурсии на сервере:
Options {
…
recursion no;
…}
Теперь будут приниматься только итеративные запросы. При необходимости в качестве более
гибкого решения можно воспользоваться опцией allow-recursion , которая определяет список
заведомо доверенных хостов, запросы от которых разрешено обрабатывать рекурсивно.
Кроме того, через настройки параметра views можно избирательно разрешать рекурсию для
внутренних и внешних адресов.
3. Помещаем в этот же файл следующие строчки:
additional-from-auth no;
additional-from-cache no;
4. Далее, ещё больше усиливаем противодействие спуфингу:
use-id-pool yes;
Эта опция включает режим, в котором идентификаторы DNS-запросов выбираются
случайным образом.
5. Отключаем fetch-glue :
fetch-glue no;
Этим мы запрещаем дополнительный поиск IP-адресов DNS-серверов.
6. Запретите динамические обновления зон следующим способом:
zone «example.com»
{
type master;
file «db.example.com»;
allow-update {
localhost;
key allowed-updater.;
};
};
В качестве компромисса можно разрешить обновления только с жестко заданных IP-адресов
или защищенных списком валидных TSIG-ключей.
7. Кроме того здесь же убедитесь в том, что вы отключили уведомления и перенос доменных
зон на ваш сервер для всех желающих, перечислив в блоке ACL список доверенных серверов,
этим вы обезопасите себя от некоторых потенциальных махинаций:
acl «trusted» {
11.22.33.44;
55.66.77.99;
};
allow-notify { trusted; };
allow-transfer { trusted; };
8. По возможности в настройках лучше всегда использовать новые, более мощные
механизмы — например расширение DNSSEC для обеспечения большей безопасности и
возможностей DNS-сервера.
В качестве варианта для прошлого примера (трансфер зоны) можно использовать TSIG, вот
пример подобной конфигурации:
key tsig-signing. {
algorithm hmac-md5;
secret “ff3d7REQwDAE8Aedae56345==”;
};
zone “example.com” {
type master;
file “db.example.com”;
allow-transfer { key tsig-signing; };
};
9. Обязательно выполняйте предварительную фильтрацию DNS-трафика, для этого в таблице
ниже собраны все типовые случаи. Обратите внимание на номера портов —
распространенное заблуждение гласит, что запросы DNS передаются через 53/UDP, а
трансфер зон — через 53/TCP. Это лишь «полуправда»: 53/TCP может также применяться и
для «длинных запросов», а в версиях BIND 8/9 активно используются порты выше 1023 для
операций с запросами.
Опять же, по возможности старайтесь использовать последние и самые мощные средства для
контроля трафика в BIND, например новый «брандмауэр для DNS» — DNSRPZ (DNS
Response Policy Zone), а также DLZ-драйверы — отличный способ упорядочивания
множества конфигов и настроек.
Инструменты для проверки и контроля DNS
В заключение остановимся и на специализированных инструментах для тестирования DNSсервисов, которые не только позволят проверить правильность всех вышеописанных
настроек, но и смогут наладить перманентный контроль над работой подведомственного вам
DNS-сервера.
1. Организация SANS предоставила простейший онлайн-тест для проверки любого DNS на
самую банальную его уязвимость, позволяющую получать тот самый «эффект усиления».
Кроме того, она же распространяет типовой шаблон конфигурации для безопасной настройки
BIND и Microsoft DNS.
2. Для самостоятельного проведения расширенного пентеста своей DNS-системы можно
рекомендовать написанную на Java утилиту — DNSpenTest (аналог).
3. fierce.pl — это похожий хакерский скрипт, который позволяет выуживать дополнительную
информацию о чужих сетях непосредственно из DNS их обслуживающих. В этом плане
бывает очень полезно посмотреть на свою сеть со стороны (желательно сделать это перед
тем, как это сделают злоумышленники). В качестве примера работы скрипта, по этому адресу
сгенерирована вся топология субдоменов для mail.ru.
4. dnswalk — это хорошо известный отладчик для тонкой настройки DNS. Как и предыдущий
скрипт, он также написан на Perl, для его работы нужны дополнительно два модуля:
Net::DNS и Perl IO . Следует подчеркнуть, что README из поставки самой программы
несколько устарел и в некоторых пунктах вводит в заблуждение (например, dnswalk в
последней версии не использует dig, как это утверждается в упомянутом документе). С одной
стороны этот сервисный скрипт позволяет удобно получать практически любую техническую
информацию о DNS, с другой — для работы с ним требуется глубокое понимание устройства
DNS. Кроме того, имеется написанный на его основе DNSSEC Walker, который
дополнительно поддерживает работу с DNSSEC.
5. Другой удобный инструмент для отладки из этой же серии — ldns, — он написан на
чистом C и поддерживает все самые последние стандарты (IP4/IP6/TSIG/DNSSEC). Отдельно
обращаю внимание на замечательную утилиту drill из состава этого пакета, которая является
расширенным аналогом dig, но с поддержкой DNSSEC. Всего в пакете ldns поставляется
около 15 DNS-утилит что называется «на все случаи жизни».
6. dns-grind — Perl-скрипт предназначенный для стресс-тестирования DNS-серверов.
Дополнительно используется для обнаружения скрытых субдоменов методом перебора,
поиска требуемых хостов в неких диапазонах IP-адресов и так далее. Выше в рекомендациях
по правильной настройке уже озвучивалась необходимость ограничения количества DNSзапросов от внешних хостов в единицу времени (в разумных пределах) — dns-grind может
использоваться для проверки этих и подобных ограничений. Для своей работы требует
следующие модули: Net::DNS, Socket, IO::Handle, IO::Select, Getopt::Std .
7. Для контроля структуры и содержания DNS-трафика весьма удобна утилита dnstop,
которая является аналогом tcpdump для DNS. Она генерирует статистические таблицы по
типам запросов, адресам источников и назначения пакетов, кодами ответов и запросов,
списки доменов, которые запрашиваются через DNS-сервис. Из технических моментов стоит
лишь отметить, что она поддерживает IPv4/IPv6 и использует библиотеку libpcap.
8. Очень полезный демон dnswall поддерживается компанией Google. Он динамически
фильтрует весь проходящий трафик, защищая подопечный DNS-сервер от попыток rebindатак (DNS rebinding attack), выполняемых с помощью популярного в хакерской среде
инструмента Rebind. Это позволяет безопасно эксплуатировать DNS-сервер в его штатном
рекурсивном режиме.
9. Более общая утилита — DNS Flood Detector. Она предназначена для мониторинга и
контроля за паразитным трафиком проходящим через ваш DNS, при этом может работать в
двух режимах: как демон (все сервисные сообщения отправляются через syslog), так и в роли
«обвязки», когда все статистические данные в режиме реального времени доступны через
командную строку. Для работы требуется библиотека libpcap .
Краткое резюме
В рамках этой обзорной статьи из двух частей мы рассмотрели лишь только некоторые,
отдельные варианты и последствия некорректных настроек DNS-серверов на примере
широко распространенного вида DDoS-атак (в рамках которой вы можете стать как жертвой,
так и невольным соучастников её проведения). Также подчеркивается опасность
бесконтрольного обмена DNS-трафиком с внешним миром на примере возможностей
инкапсулирующих протоколов типа «IP через DNS».
Я постарался не только обратить внимание на эти не самые популярные у администраторов
темы, но и также предложить базовые рекомендации и инструменты для устранения этих
распространенных в реальной жизни проблем.