Изпечатай

[wfw]

Някой навътре в нещата може ли да сподели идеята и интелигентен начин за предпазване от този тип атаки?

Говорим за атаките, които напълват лога с тези съобщения:

Код:

Feb 18 06:25:07 rocket named[2198]: client 62.109.4.89#3336: query (cache) './NS/IN' denied
Feb 18 06:25:08 rocket named[2198]: client 62.109.4.89#39712: query (cache) './NS/IN' denied
Feb 18 06:25:11 rocket named[2198]: client 62.109.4.89#48380: query (cache) './NS/IN' denied
Feb 18 06:25:11 rocket named[2198]: client 62.109.4.89#50051: query (cache) './NS/IN' denied
Feb 18 06:25:13 rocket named[2198]: client 62.109.4.89#61766: query (cache) './NS/IN' denied
Feb 18 06:25:14 rocket named[2198]: client 62.109.4.89#57687: query (cache) './NS/IN' denied
Feb 18 06:25:17 rocket named[2198]: client 62.109.4.89#20923: query (cache) './NS/IN' denied

и така с милиони редове.

Код:

$IPTABLES -A INPUT -s 62.109.4.0/24 -j DROP

това не е решение, няма смисъл да вардя всяко ИП, което отправя такъв тип заявки към днс-ите.

[wfw]

В rfc5358 се говори по въпроса, но самата защита от този тип атака не изглежда никак сложна, просто забрана за рекурсивни заявки към ДНС сървъра. Според ИЕТФ проблема се състои в това, че по подразбиране ДНС сървърите са настроени да отговарят на рекурсивните заявки.

Замисъла на атаката е, както явно на повечето ДОС атаки да се изпрати малък пакет, който да накара демона да върне по-голям. В случая не съм сигурен каква е големината на заявката и каква е големината на отговора на моя ДНС сървър при условие, че рекурсивните заявки са забранени.

п.с. Последните ми наблюдения сочат, че

Someone on the Internet with access to a bot-net configures the bots to perform DNS queries from a spoofed ip to a large number of DNS servers. The DNS servers that receive the queries answer to the spoofed ip address. Usually the number of DNS servers is quite large and the number of spoofed ip addresses is quite small. This results in a very small traffic load for each DNS server and a huge traffic load for the unfortunate owner of the spoofed ip address.

т.е. моя проблем е много по-малък от онзи с ИП 62.109.4.89

[gat3way]

Обикновено такива traffic amplification атаки се правят с PTR или TXT заявки, а не с A или NS. Просто има много повече смисъл - за 4-те байта IP адрес+хедърите+заявката се връща PTR отговор, който съдържа примерно ip-1.2.3.4.pool.isp.com което е 24 байта, оттам грубо 6 пъти amplification (всъщност е по-малко, щото има и IP/UDP хедъри, които са към 30-40 байта).

С рекурсивни запитвания за NS записи просто не се постига достатъчно добър amplification ефект.

Иначе според мен това в твоя лог е следствие на това, че някой се опитва да те ползва като resolver (защо не знам), а не защото иска да те DoS-ва.

[wfw]

интересното е, че точно това IP присъства в други подобни размишления, но в един англоезичен блог, а лога е систематичен, само от 2 ИП-та, от няколко дни и генерира заявка на 1-2 сек. Също така забелязах едното от ИП-тата да пробва и ДНС-а ми вкъщи, там също имам сложени няколко домейна.

Любопитно ми е дали някой друг не забелязва подобна активност по неговите ДНС сървъри.

[laskov]

В тази тема за сендмейл, VladSun ми посочи решение, при което можеш да забраниш заявки от дадено IP за определено време след първата заявка, но линкът е счупен. Не го ползвам вече, но мога да го издиря. Става дума за iptables

[gat3way]

Няма нужда, просто му се забраняват рекурсивни заявки. Като гледам обаче те са си забранени.

Ха, тва не го знаех, интересно
http://isc.sans.org/diary.html?storyid=5713

Значи имало и случаи при които и NS заявките водят дотам..

[laskov]

# The next two lines will stop every second SMTP connection from the same IP within 120 sec interval
iptables -A INPUT -p tcp --syn --dport 25 -m recent --name bad_smtp --update --seconds 120 -j DROP
iptables -A INPUT -p tcp --syn --dport 25 -m recent --name bad_smtp --set -j ACCEPT

[gat3way]

DNS заявките са UDP-базирани, там няма SYN

[Just4Nick]

Преди около месец започнаха да се наблюдават тези неща, явно са сменили IP-тата. Ето малко линкове и от мен:
http://www.merit.edu/mail.archives/nanog/msg14429.html
https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful