Я работал над созданием набора правил для обнаружения и блокировки атаки с усилением DNS.
Я застрял и надеюсь найти здесь помощь.
Я опубликую здесь то, что у меня есть (скрипты bash, части, касающиеся DNS):
IPTABLES='/sbin/iptables -v'
SERVERIP=a.b.c.d
echo '################ Previously initiated and accepted exchanges bypass rule checking #'
$IPTABLES --append INPUT -m state --state ESTABLISHED,RELATED --jump ACCEPT
echo '################################################ Allow unlimited outbound traffic #'
$IPTABLES --append OUTPUT -m state --state NEW,ESTABLISHED,RELATED --jump ACCEPT
echo '################################################################## Rules for DNS #'
# DIG ANY ISC.ORG attack preventer.
# QUESTION1: this one does not work, why!?!?
$IPTABLES --append INPUT --proto udp --dport 53 -m string --string "isc.org" --algo bm --to 65535 --jump LOG --log-prefix "iptables: UDP ISC0 "
$IPTABLES --append INPUT --proto udp --dport 53 -m string --hex-string "|03697363036f726700|" --algo bm --to 65535 --jump LOG --log-prefix "iptables: UDP ISC "
$IPTABLES --append INPUT --proto udp --dport 53 -m string --hex-string "|03697363036f726700|" --algo bm --to 65535 --jump DROP
# DNS DNSIPSOK list
$IPTABLES --new DNSFLOODRULES
$IPTABLES --append DNSFLOODRULES --source 127.0.0.1 --jump RETURN
$IPTABLES --append DNSFLOODRULES --source $SERVERIP --jump RETURN
$IPTABLES --append DNSFLOODRULES --jump LOG --log-prefix "iptables: UDP BLOCK "
$IPTABLES --append DNSFLOODRULES --jump ACCEPT
#$IPTABLES --append DNSFLOODRULES --jump DROP
# I have it turned off right now, because
echo '# S & D port rules'
# DNS limit rule for standard acceptance
# QUESTION2: can't get the connbytes to work properly :(
$IPTABLES --append INPUT --proto udp --source 0/0 --dport 53 \
-m state --state NEW \
-m connbytes --connbytes 75 --connbytes-dir reply --connbytes-mode bytes
-m limit --limit 1/s --limit-burst 10 --jump ACCEPT
# DNS log / drop the abusers EXEPT the whitelisted IP numbers
$IPTABLES --append INPUT --proto udp --source 0/0 --dport 53 -m state --state NEW --jump DNSFLOODRULES
$IPTABLES --append INPUT --proto udp --source 0/0 --sport 53 -m state --state NEW --jump DNSFLOODRULES
# DNS allow the whitelisted IP numbers
$IPTABLES --append INPUT --proto udp --source 0/0 --dport 53 -m state --state NEW --jump ACCEPT
$IPTABLES --append INPUT --proto udp --source 0/0 --sport 53 -m state --state NEW --jump ACCEPT
ВОПРОС 1: Почему это должна быть шестнадцатеричная строка, простую было бы легче поддерживать, но эта не будет байтовой, вы можете сказать почему?
ВОПРОС 2: С помощью TCPdump я вижу, что большинство ответов довольно маленькие, поэтому их нужно добавить в белый список. Также localhost (и несколько моих собственных серверов я часто запрашиваю сервер имен (DNSFLOODRULES). Атака с усилением DNS - это непрерывный всплеск «больших» ответов, которые я хочу ограничить. Проблема в том, что я не могу получить ' connbytes, чтобы работать. Я немного возился с этим, также подумал, что это должно быть искусство ВЫХОДА, поскольку это касается размера ответа, а не вопроса. Я также экспериментировал с 'Разрешить неограниченный исходящий часть трафика, но это пошло ужасно неправильно.
Мы очень ценим ваши мысли и помощь.
Вопрос 1:
Строка не совпадает из-за символа "." в пакет не входит. Пакет DNS содержит не «имя хоста» как таковое, а «метки». В пакете каждая часть доменного имени представляет собой метку с префиксом количества байтов для метки.
Итак, "isc.org" переводится как:
isc: 03 69 73 63
org: 03 6f 72 67
Или в пакете:
03697363036f7267
Каждая метка ограничена 63 байтами, полное имя ограничено 255 байтами.
Это объясняется в DNS RFC:
http://tools.ietf.org/html/rfc1035#section-2.3.4
http://tools.ietf.org/html/rfc1035#section-4.1.2
Вопрос 2:
Вам необходимо включить флаг net.netfilter.nf_conntrack_acct, чтобы использовать параметр conntrack (см. iptables
справочная страница). Но я не думаю, что это разумно так использовать. Всегда будут правильные ответы - большие пакеты.
Возможно, вам лучше использовать расширение hashlimit. Уже упоминалось:
https://lists.dns-oarc.net/pipermail/dns-operations/2012-October/009321.html