[rz3dwy]

# limit NS floood

-A INPUT -i eth0 -p udp --dport 53 -m string --algo kmp --hex-string "|00 02 00 01|" --from 20 --to 50 -m recent --set --name NS-FLOOD --rsource

-A INPUT -i eth0 -p udp --dport 53 -m string --algo kmp --hex-string "|00 02 00 01|" --from 20 --to 50 -m recent --update --seconds 5 --hitcount 5 --name NS-FLOOD -j NS-DROP

 

# limit NULL flood

-A INPUT -i eth0 -p udp --dport 53 -m string --algo kmp --hex-string "|00 0a 00 01|" --from 20 --to 50 -m recent --set --name NULL-FLOOD --rsource

-A INPUT -i eth0 -p udp --dport 53 -m string --algo kmp --hex-string "|00 0a 00 01|" --from 20 --to 50 -m recent --update --seconds 5 --hitcount 5 --name NULL-FLOOD -j NULL-DROP

 

-A NS-DROP -j LOG --log-prefix "DNS-NS-FLOOD: "

-A NS-DROP -j DROP

-A NULL-DROP -j LOG --log-prefix "DNS-NULL-FLOOD: "

-A NULL-DROP -j DROP

 

 

лимиты, source address и содержимое пакетов поправьте под себя если требуется

[hsvt]

# limit NS floood

-A INPUT -i eth0 -p udp --dport 53 -m string --algo kmp --hex-string "|00 02 00 01|" --from 20 --to 50 -m recent --set --name NS-FLOOD --rsource

-A INPUT -i eth0 -p udp --dport 53 -m string --algo kmp --hex-string "|00 02 00 01|" --from 20 --to 50 -m recent --update --seconds 5 --hitcount 5 --name NS-FLOOD -j NS-DROP

 

# limit NULL flood

-A INPUT -i eth0 -p udp --dport 53 -m string --algo kmp --hex-string "|00 0a 00 01|" --from 20 --to 50 -m recent --set --name NULL-FLOOD --rsource

-A INPUT -i eth0 -p udp --dport 53 -m string --algo kmp --hex-string "|00 0a 00 01|" --from 20 --to 50 -m recent --update --seconds 5 --hitcount 5 --name NULL-FLOOD -j NULL-DROP

 

-A NS-DROP -j LOG --log-prefix "DNS-NS-FLOOD: "

-A NS-DROP -j DROP

-A NULL-DROP -j LOG --log-prefix "DNS-NULL-FLOOD: "

-A NULL-DROP -j DROP

 

 

лимиты, source address и содержимое пакетов поправьте под себя если требуется

 

Спасибо,но я впринципе знаю как бороться с этим на Linux, есть еще такое - http://dnsamplificationattacks.blogspot.ru/

Но у меня FreeBSD.

Изменено 3 мая, 2015 пользователем hsvt

[Ivan_83]

Матчить содержимое пакетов точно умеет ng_bpf.

Его можно подключить как к сетевушке так и к правилам ipfw.

[hsvt]

Матчить содержимое пакетов точно умеет ng_bpf.

Его можно подключить как к сетевушке так и к правилам ipfw.

 

Не работал с этим еще, спасибо попробуем.

 

sonewconn: pcb 0xfffffe0442c1fdc8: Listen queue overflow: 16 already in queue awaiting acceptance (5 occurrences)

 

Эти сообщения как я понимаю тоже из-за слишком частых запросов к named?

 

netstat -naA | grep fffffe0442

 

Не успеваю отследить...

[GrandPr1de]

Матчить содержимое пакетов точно умеет ng_bpf.

Его можно подключить как к сетевушке так и к правилам ipfw.

 

Не работал с этим еще, спасибо попробуем.

 

sonewconn: pcb 0xfffffe0442c1fdc8: Listen queue overflow: 16 already in queue awaiting acceptance (5 occurrences)

 

Эти сообщения как я понимаю тоже из-за слишком частых запросов к named?

 

netstat -naA | grep fffffe0442

 

Не успеваю отследить...

 

У меня такое только с апачем было.

Лечится добавлением в httpd.conf

ListenBackLog 1024

[alexpn]

может настроить фаервол на размер пакетов

или

убрать BIND в сторону PowerDNS например

[rdntw]

настроить фаервол на размер пакетов

аккуратней :)

[Ivan_83]

Эти сообщения как я понимаю тоже из-за слишком частых запросов к named?

Это относится к tcp, задаётся длинна очереди входящих подключений. Listen backlog, можно спокойно ставить 1024-4096.

[nu11]

У вас единственный вариант - отказаться от этого клиента.

 

С каналом в 1G вас (вашу сетку) могут положить вместе с ним в любой момент любыми пакетами с любых SRC_IP. Позвоните клиенту и поинтересуйтесь, что он такое хостит. Ткните в договор лицом, у провов обычно запрещено что-то хостить на домашнем канале. Клиента в любом случае от себя гнать, потому что атакующие уже знают, где физически сидит жертва и будут долбить по вашей сети даже полностью вслепую.

Пусть размещает свои дела в датацентрах и использует сервисы защиты от DDoS.

 

Listen backlog, можно спокойно ставить 1024-4096.

named раньше упадет, чем забьется бэклог.

Изменено 7 мая, 2015 пользователем nu11

[YuryD]

netstat -naA | grep fffffe0442

 

Не успеваю отследить...

 

Из портов dnstop. Увидите кто из клиентов. Далее разглядите траффик этого клиента, и с помощью ipfw попытайтесь урезать число коннектов по src-ip или dst-ip limit. По udp правда не очень помогает бордеру с такими правилами, но атака не может быть вечной.

[Ivan_83]

named раньше упадет, чем забьется бэклог.

Оно к named имеет не много отношения.

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

А к udp оно никакого отношения не имеет.

[hsvt]

У вас единственный вариант - отказаться от этого клиента.

 

С каналом в 1G вас (вашу сетку) могут положить вместе с ним в любой момент любыми пакетами с любых SRC_IP. Позвоните клиенту и поинтересуйтесь, что он такое хостит. Ткните в договор лицом, у провов обычно запрещено что-то хостить на домашнем канале. Клиента в любом случае от себя гнать, потому что атакующие уже знают, где физически сидит жертва и будут долбить по вашей сети даже полностью вслепую.

Пусть размещает свои дела в датацентрах и использует сервисы защиты от DDoS.

 

Откуда вы знаете что 1G ? :)

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

По договору юр. лицо, ну открывать свой днс сервер вроде нигде не указано, что запрещено.

 

Listen backlog относится к apache? apache здесь как обычно за nginx и к ним обращений не очень много, большинство из внутреней сети. Тогда смысл увеличивать длину очереди? Попробовать конечно можно.

 

sysctl kern.ipc.somaxconn
kern.ipc.somaxconn: 32768

 

netstat -naA | grep fffffe0442

 

Не успеваю отследить...

 

Из портов dnstop. Увидите кто из клиентов. Далее разглядите траффик этого клиента, и с помощью ipfw попытайтесь урезать число коннектов по src-ip или dst-ip limit. По udp правда не очень помогает бордеру с такими правилами, но атака не может быть вечной.

 

Ну вообще и так по логам named видно с какого клиента идут SERVFAIL или NX, просто когда пытаюсь найти по сокету, то уже не понятно какой это процесс, но скорей всего всё таки named. Попробую dnstop, спасибо за совет. Урезать думаю и с pf можно.

 

named раньше упадет, чем забьется бэклог.

Оно к named имеет не много отношения.

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

А к udp оно никакого отношения не имеет.

 

Обычно я тоже так считал, но есть много запрос и по TCP.

 

Количество tcp-clients не прописано.

 

Размеры UDP ответов и рейты прописаны так:

 

edns-udp-size          4096;
max-udp-size           8192;
rate-limit  { responses-per-second 30; window 5; ipv4-prefix-length 32; slip 0; };

 

23:30:37.484669 IP client.54761 > server.53: Flags [F.], seq 36, ack 805, win 255, length 0
23:30:37.484682 IP server.53 > client.54761: Flags [.], ack 37, win 517, length 0
23:30:37.484725 IP server.53 > client.54761: Flags [F.], seq 805, ack 37, win 517, length 0
23:30:37.485493 IP client.63325 > server.53: Flags [F.], seq 36, ack 805, win 255, length 0
23:30:37.485508 IP server.53 > client.63325: Flags [.], ack 37, win 517, length 0
23:30:37.485546 IP server.53 > client.63325: Flags [F.], seq 805, ack 37, win 517, length 0
23:30:37.486404 IP client.54761 > server.53: Flags [.], ack 806, win 255, length 0
23:30:37.487940 IP client.63325 > server.53: Flags [.], ack 806, win 255, length 0

 

На момент написания тут мало чего есть:

netstat -Lan
Current listen queue sizes (qlen/incqlen/maxqlen)
Proto Listen         Local Address
tcp4  0/0/128        ssh.22
tcp4  0/0/100        billing
tcp4  0/0/128        zabbix_aggent.10050
tcp4  0/0/128        127.0.0.1.953
tcp4  0/0/10         named.53
tcp4  0/0/50         mysql.3306
tcp4  0/0/128        billing_json.1502
tcp4  0/0/511        127.0.0.1.81
tcp4  0/0/32768      nginx.443
tcp4  0/0/32768      nginx.80
tcp4  0/0/32768      nginx.80
tcp4  0/0/32768      nginx.80
unix  0/0/50         /tmp/mysql.sock
unix  0/0/4          /var/run/devd.pipe

 

netstat -m
4100/12550/16650 mbufs in use (current/cache/total)
4096/6614/10710/1523306 mbuf clusters in use (current/cache/total/max)
4094/3714 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/761653 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/225675 9k jumbo clusters in use (current/cache/total/max)
0/0/0/126942 16k jumbo clusters in use (current/cache/total/max)
9217K/16365K/25582K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

 

Понаблюдаю за праздниками...

Изменено 7 мая, 2015 пользователем hsvt

[Ivan_83]

Listen backlog относится к apache? apache здесь как обычно за nginx и к ним обращений не очень много, большинство из внутреней сети. Тогда смысл увеличивать длину очереди? Попробовать конечно можно. sysctl kern.ipc.somaxconn kern.ipc.somaxconn: 32768

Он относится ко всем слушающим TCP сокетам в системе.

kern.ipc.somaxconn - это сколько максимум сокетов можно создать приложению.

[nu11]

Откуда вы знаете что 1G ? :)

Вы сами написали. Будьте внимательней :)

Не забывайте, что умный атакующий вполне может вас читать.

 

Если летят ответы DNS, смысла увеличивать бэклог для хттп нет никакого.

 

Уточните еще раз, что куда шлют. На айпи вашего клиента идут ответы DNS или DNS-сервер клиента юзают как множитель трафика? Досят клиента или с помощью клиента досят кого-то еще?

Если первое, только отказ от клиента. Если второе, рубите DNS пакеты с SRC_IP жертвы.

[hsvt]

Listen backlog относится к apache? apache здесь как обычно за nginx и к ним обращений не очень много, большинство из внутреней сети. Тогда смысл увеличивать длину очереди? Попробовать конечно можно. sysctl kern.ipc.somaxconn kern.ipc.somaxconn: 32768

Он относится ко всем слушающим TCP сокетам в системе.

kern.ipc.somaxconn - это сколько максимум сокетов можно создать приложению.

 

Да, с somaxconn я напутал, это похоже.

Так в каком тогда конкретно приложении стоит пробовать увеличивать? в nginx тоже есть backlog

 

Откуда вы знаете что 1G ? :)

Вы сами написали. Будьте внимательней :)

Не забывайте, что умный атакующий вполне может вас читать.

 

Если летят ответы DNS, смысла увеличивать бэклог для хттп нет никакого.

 

Уточните еще раз, что куда шлют. На айпи вашего клиента идут ответы DNS или DNS-сервер клиента юзают как множитель трафика? Досят клиента или с помощью клиента досят кого-то еще?

Если первое, только отказ от клиента. Если второе, рубите DNS пакеты с SRC_IP жертвы.

 

Про канал в 1 гиг писал не я, а топикстартер, никнеймы может похожие просто, но суть не меняет т.к. у нас тоже 1G. На данный момент каких то всплесков атак нет.

 

Уточняю, мы не знаем досят его или нет, по крайней мере от них жалоб нет. У него белый адрес и открытый DNS в мир, судя по nmap это cisco. DNS клиента отвечает рекурсивно на всё.

 

 

PORT     STATE SERVICE
22/tcp   open  ssh
23/tcp   open  telnet
53/tcp   open  domain
2222/tcp open  EtherNet/IP-1

 

 

Клиент подключен к нашей сети и соответственно использует наши DNS сервера как рекурсивно так и авторитативно имеет не сколько своих зон и записей у нас (A, MX), но не хоститься. В момент атаки я вижу в логах множество query-errors от клиента и rate limit drop SERVFAIL на какие то левые домены типа

 

 cn.www.appledaily.com.tw wt.www.bet16.com otqfurcropapgz.www.bet16.com

 

В этот же момент по sockstat видно как src_ip нашего днс сервера ломится на какой то конкретный dst_ip:53 адрес в большом количестве. Тоже самое видно и по tcpdump.

 

09:51:33.146646 IP 5.5.5.5.62746 > 198.41.222.12.53: 165% [1au] A? sjsvkjor.www.appledaily.com.tw. (59)
09:51:33.150144 IP 5.5.5.5.56943 > 198.41.222.12.53: 28393% [1au] A? opwfclwtcf.www.appledaily.com.tw. (61)

Изменено 12 мая, 2015 пользователем hsvt

[snvoronkov]

Уточняю, мы не знаем досят его или нет, по крайней мере от них жалоб нет. У него белый адрес и открытый DNS в мир, судя по nmap это cisco. DNS клиента отвечает рекурсивно на всё.

 

 

PORT     STATE SERVICE
22/tcp   open  ssh
23/tcp   open  telnet
53/tcp   open  domain
2222/tcp open  EtherNet/IP-1

 

 

Клиент подключен к нашей сети и соответственно использует наши DNS сервера как рекурсивно так и авторитативно имеет не сколько своих зон и записей у нас (A, MX), но не хоститься. В момент атаки я вижу в логах множество query-errors от клиента и rate limit drop SERVFAIL на какие то левые домены типа

 

 cn.www.appledaily.com.tw wt.www.bet16.com otqfurcropapgz.www.bet16.com

 

В этот же момент по sockstat видно как src_ip нашего днс сервера ломится на какой то конкретный dst_ip:53 адрес в большом количестве. Тоже самое видно и по tcpdump.

 

09:51:33.146646 IP 5.5.5.5.62746 > 198.41.222.12.53: 165% [1au] A? sjsvkjor.www.appledaily.com.tw. (59)
09:51:33.150144 IP 5.5.5.5.56943 > 198.41.222.12.53: 28393% [1au] A? opwfclwtcf.www.appledaily.com.tw. (61)

Закройте пакеты вида

protocol udp
destination-port 53
source-address !${my_dns_ip}
destination-address ${clnt_ip}

и будет вам щасье! :-)

 

Классическая атака на DNS-сервера хостера-конкурента через открытый резолвер. Ваша задача - сделать этот резолвер закрытым. Всё.

Изменено 13 мая, 2015 пользователем snvoronkov

[hsvt]

Уточняю, мы не знаем досят его или нет, по крайней мере от них жалоб нет. У него белый адрес и открытый DNS в мир, судя по nmap это cisco. DNS клиента отвечает рекурсивно на всё.

 

 

PORT     STATE SERVICE
22/tcp   open  ssh
23/tcp   open  telnet
53/tcp   open  domain
2222/tcp open  EtherNet/IP-1

 

 

Клиент подключен к нашей сети и соответственно использует наши DNS сервера как рекурсивно так и авторитативно имеет не сколько своих зон и записей у нас (A, MX), но не хоститься. В момент атаки я вижу в логах множество query-errors от клиента и rate limit drop SERVFAIL на какие то левые домены типа

 

 cn.www.appledaily.com.tw wt.www.bet16.com otqfurcropapgz.www.bet16.com

 

В этот же момент по sockstat видно как src_ip нашего днс сервера ломится на какой то конкретный dst_ip:53 адрес в большом количестве. Тоже самое видно и по tcpdump.

 

09:51:33.146646 IP 5.5.5.5.62746 > 198.41.222.12.53: 165% [1au] A? sjsvkjor.www.appledaily.com.tw. (59)
09:51:33.150144 IP 5.5.5.5.56943 > 198.41.222.12.53: 28393% [1au] A? opwfclwtcf.www.appledaily.com.tw. (61)

Закройте пакеты вида

protocol udp
destination-port 53
source-address !${my_dns_ip}
destination-address ${clnt_ip}

и будет вам щасье! :-)

 

Классическая атака на DNS-сервера хостера-конкурента через открытый резолвер. Ваша задача - сделать этот резолвер закрытым. Всё.

 

Лучше на шлюзе через который ходил клиент или на самой ns'ки?

[snvoronkov]

Лучше на шлюзе через который ходил клиент или на самой ns'ки?

На шлюзе, конечно. Нефиг ботам к нему запросы слать.

[hsvt]

Лучше на шлюзе через который ходил клиент или на самой ns'ки?

На шлюзе, конечно. Нефиг ботам к нему запросы слать.

 

На шлюзах уже Linux для NAT и iptables да и плодить лишние правила там не хочется, чтобы потом путаться... А если к нему из внешки валидные клиенты стучаться или у него свои зоны, всё заблочиться ведь. Ну в любом случае спасибо за правило, можно кстати такую ACL и на порту коммутатора прописать куда воткнут клиент?

 

Вот кстати dnstop.

 

Destinations       Count      %   cum%
-------------- --------- ------ ------
ns               246350   22.6   22.6
client1          44597    4.1   26.7
client2          44392    4.1   30.8
client3          26091    2.4   33.2
client4          25940    2.4   35.6
client5          20270    1.9   37.4

 

Rcode        Count      %   cum%
-------- --------- ------ ------
Noerror     741687   67.0   67.0
Servfail    195368   17.7   84.7
Nxdomain    143348   13.0   97.6
Refused      26310    2.4  100.0
Formerr          2    0.0  100.0

 

Source         Query Name           Count      %   cum%
-------------- ---------------- --------- ------ ------
ns   mgm86800.com         44796    3.1    3.1
ns   mgm86811.com         41692    2.8    5.9
ns   mgm003.com           39193    2.7    8.6
ns   mgm86822.com         36162    2.5   11.1
ns   mgm86844.com         35974    2.5   13.5
ns   mgm86833.com         35940    2.5   16.0
ns   mgm86866.com         26294    1.8   17.8
ns   mgm86877.com         25801    1.8   19.5
ns   mgm86855.com         25724    1.8   21.3
ns   vk.me                24373    1.7   23.0
client1  ironmen-style.ru 19501    1.3   24.3
ns   avast.com            13839    0.9   25.2
ns   akamai.net           10169    0.7   25.9
client1 mgm86800.com      8369    0.6   26.5
client2  mgm86800.com     8351    0.6   27.1
client3  mgm003.com       8331    0.6   27.6
client4 mgm003.com        8329    0.6   28.2
client5 mgm86811.com      8292    0.6   28.8
client6  mgm86811.com     8222    0.6   29.3
ns   mail.ru              7953    0.5   29.9

Изменено 14 мая, 2015 пользователем hsvt

[hsvt]

В общем вроде бы решил проблему так:

 

block quick log on $ext_if inet proto { udp, tcp } from $dns_ip to ! <dns_trust> port 53

 

Теперь нормальный dnstop

 

Queries: 395 new, 33480 total Thu May 14 15:21:41 2015

 

Rcode        Count      %   cum%
-------- --------- ------ ------
Noerror      33395   99.7   99.7
Servfail        55    0.2   99.9
Nxdomain        30    0.1  100.0

[snvoronkov]

Не понял куда вы это правило pf взгромоздили.

 

Ну и, велика ли таблица доверенных Днс и не ломаете-ли вы сим правилом pf states?

[hsvt]

Не понял куда вы это правило pf взгромоздили.

 

Ну и, велика ли таблица доверенных Днс и не ломаете-ли вы сим правилом pf states?

 

Правило на named-slave сервере. По крайней мере теперь IP сервера не ломится на разные адреса dst-53, а только обращается к табличным.

 

Ну и forwarders те же самые.

 

forwarders         { 8.8.8.8; 77.88.8.1; 8.8.4.4; };

 

table <dns_trust> const { ns1.host.ru, 8.8.8.8, 8.8.4.4, 77.88.8.1 }

 

Ну некоторый флуд от клиентов с открытым DNS всё равно конечно остался.

 

tcpdump | grep mgm
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vtnet0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:17:41.883383 IP client.45147 > ns1.host.ru.domain: 61002+ A? nbpdeftuvwkyz.www.mgm86811.com. (48)
21:17:41.883733 IP ns1.host.ru.56542 > google-public-dns-b.google.com.domain: 62229+% [1au] A? nbpdeftuvwkyz.www.mgm86811.com. (59)
21:17:41.889023 IP ns1.host.ru.63834 > google-public-dns-a.google.com.domain: 23660+% [1au] A? kxwcibztv.www.mgm86877.com. (55)
21:17:41.896529 IP ns1.host.ru.54988 > secondary.dns.yandex.ru.domain: 18099+ A? zlzwuaofo.www.mgm86844.com. (44)
21:17:41.901021 IP ns1.host.ru.58809 > secondary.dns.yandex.ru.domain: 53996+ A? yfjikukcp.www.mgm86844.com. (44)
21:17:41.904856 IP ns1.host.ru.60512 > secondary.dns.yandex.ru.domain: 58853+ A? nbpdeftuvwkyz.www.mgm86811.com. (48)
21:17:41.912575 IP ns1.host.ru.51521 > google-public-dns-a.google.com.domain: 60137+% [1au] A? stwlsrmnerqvsp.www.mgm86877.com. (60)
21:17:41.933987 IP client.40406 > ns1.host.ru.domain: 32433+ A? zpj.www.mgm86877.com. (38)
21:17:41.954143 IP client.54493 > ns1.host.ru.domain: 32599+ A? wxbwsyh.www.mgm86877.com. (42)
21:17:41.954443 IP ns1.host.ru.54673 > google-public-dns-b.google.com.domain: 27425+% [1au] A? wxbwsyh.www.mgm86877.com. (53)
21:17:41.954610 IP ns1.host.ru.65059 > secondary.dns.yandex.ru.domain: 9963+ A? voi.www.mgm86866.com. (38)
21:17:41.956094 IP client.37692 > ns1.host.ru.domain: 64603+ A? blyccpr.www.mgm86877.com. (42)
21:17:41.956396 IP ns1.host.ru.65028 > google-public-dns-b.google.com.domain: 36075+% [1au] A? blyccpr.www.mgm86877.com. (53)
21:17:41.961291 IP ns1.host.ru.63147 > google-public-dns-a.google.com.domain: 31540+% [1au] A? nbcdrsguiwxlz.www.mgm86855.com. (59)
21:17:41.961353 IP ns1.host.ru.63914 > google-public-dns-a.google.com.domain: 2469+% [1au] A? aopqrsthijklz.www.mgm86855.com. (59)
21:17:41.974128 IP ns1.host.ru.59755 > secondary.dns.yandex.ru.domain: 55479+ A? wxbwsyh.www.mgm86877.com. (42)
21:17:41.977184 IP ns1.host.ru.56360 > secondary.dns.yandex.ru.domain: 29549+ A? blyccpr.www.mgm86877.com. (42)
21:17:41.985323 IP ns1.host.ru.56933 > google-public-dns-a.google.com.domain: 65164+% [1au] A? yfbwrbi.www.mgm86866.com. (53)
21:17:42.000024 IP client.58744 > ns1.host.ru.domain: 62199+ A? llb.www.mgm86822.com. (38)

 

Queries: 227 new, 4739693 total                                                                                                                            Thu May 14 21:12:50 2015

Rcode        Count      %   cum%
-------- --------- ------ ------
Noerror    4735019   99.9   99.9
Nxdomain      4328    0.1  100.0
Servfail       316    0.0  100.0
Notauth         28    0.0  100.0
Refused          2    0.0  100.0

 

pfctl -si
No ALTQ support in kernel
ALTQ related functions disabled
Status: Enabled for 8 days 20:12:36           Debug: Urgent

State Table                          Total             Rate
 current entries                    11985
 searches                       341030269          446.4/s
 inserts                        119109057          155.9/s
 removals                       119147826          156.0/s
Counters
 match                          122666005          160.6/s
 bad-offset                             0            0.0/s
 fragment                               0            0.0/s
 short                                 12            0.0/s
 normalize                            164            0.0/s
 memory                                 0            0.0/s
 bad-timestamp                     109293            0.1/s
 congestion                             0            0.0/s
 ip-option                              0            0.0/s
 proto-cksum                            0            0.0/s
 state-mismatch                      3003            0.0/s
 state-insert                          19            0.0/s
 state-limit                         2183            0.0/s
 src-limit                         802555            1.1/s
 synproxy                               0            0.0/s

Изменено 14 мая, 2015 пользователем hsvt

[pavel.odintsov]

Это уже не похоже на усиление трафика. При усилении он летит с 53го порта, а тут порты высокие. Стало быть клиенты просто запрашивают эти урлы.

[st_re]

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

 

Жертва в примере выше скорее всего cloudflare.com (или они сами или какой либо домен лежащий на их NSах)

 

mgm86844.com. 86400 IN NS scott.ns.cloudflare.com.

mgm86844.com. 86400 IN NS lorna.ns.cloudflare.com.

 

(хотя www.mgm86844.com ими не отдается, может там еще есть (были) чьи то NSы для www). Чтобы не отрабатывал кеш на ресолвере первая часть запрашмваемого имени берется из /dev/random

 

Оригинальные запросы на открытый ресолвер (т.к. ответы в общем и не интересны) летят скорее всего вообще с левых IP из того же /dev/random

[hsvt]

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

 

Жертва в примере выше скорее всего cloudflare.com (или они сами или какой либо домен лежащий на их NSах)

 

mgm86844.com. 86400 IN NS scott.ns.cloudflare.com.

mgm86844.com. 86400 IN NS lorna.ns.cloudflare.com.

 

(хотя www.mgm86844.com ими не отдается, может там еще есть (были) чьи то NSы для www). Чтобы не отрабатывал кеш на ресолвере первая часть запрашмваемого имени берется из /dev/random

 

Оригинальные запросы на открытый ресолвер (т.к. ответы в общем и не интересны) летят скорее всего вообще с левых IP из того же /dev/random

 

Вот это подробно, спасибо.