Подозрительные IP-пакеты на порту 53

Я обнаружил странную проблему, и я надеюсь, что кто-то может помочь мне исправить ее. Если я собираю ip-пакеты на сетевом интерфейсе em1 через порт 53 с помощью команды "tcpdump -i em1 -vvv -s 0 -l -n port 53", я получаю странный результат (ниже приведен фрагмент из них), непрерывно приходят пакеты с неизвестных IP-адресов (4-5 IP-адресов неоднократно). На сервере работает centos7 и DNS-сервер Bind9. Если я выключу названную службу или сетевой сервис, пакеты все еще будут приходить. Я изменил частный IP-адрес сервера с 10.10.10.100 на 10.10.10.xxx, и проблема все еще жива, ip-пакеты непрерывно приходят к исходному IP-адресу 10.10.10.100. Я перезагружал сервер несколько раз, безрезультатно.

Мой вопрос в том, могу ли я это игнорировать? Это ddos ​​как атака? Исходя из того, что при отключенном сетевом сервисе проблема все еще сохраняется, я думаю, что это может быть ошибка или вирус. Это?

09:13:28.941958 IP (tos 0x20, ttl 105, id 12674, offset 0, flags [DF], proto TCP (6), length 52)
    107.167.18.163.32902 > 10.10.10.100.domain: Flags [S], cksum 0x9538 (correct), seq 2019438094, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
09:13:28.942006 IP (tos 0x20, ttl 64, id 41456, offset 0, flags [DF], proto TCP (6), length 40)
    10.10.10.100.domain > 107.167.18.163.32902: Flags [.], cksum 0x328e (correct), seq 0, ack 1, win 14600, length 0
09:13:29.128215 IP (tos 0x20, ttl 103, id 54720, offset 0, flags [DF], proto TCP (6), length 52)
    107.167.18.163.32902 > 10.10.10.100.domain: Flags [S], cksum 0x35d2 (correct), seq 2106165321, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0

Сервер находится за маршрутизатором Cisco, а на маршрутизаторе есть правило NAT (86.34.156.51 <-> 10.10.10.100). На DNS-сервере BIND мне пришлось настроить локальный частный IP-адрес, в противном случае, если привязка была настроена с общедоступным IP-адресом, пакеты DNS никогда не поступали на хост, который сделал запрос (возможно, маршрутизатор интерпретировал, что маршрутизатор 86.34.156.51 должен маршрутизировать обратно к хозяину (10.10.10.100)). Другая проблема, связанная с этим, заключается в том, что значение TTL пакета DNS всегда равно 0 при поступлении на хост назначения.

Вот результат с флагом -A"tcpdump -i em1 -A -vvv -s 0 -l -n port 53"

11:16:22.681589 IP (tos 0x20, ttl 77, id 55139, offset 0, flags [DF], proto TCP (6), length 52)
    107.167.22.93.59026 > 10.10.10.100.domain: Flags [S], cksum 0x47a6 (correct), seq 1337080454, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
E .4.c@.M...k..]


d...5O.:....... .G...............
11:16:22.681638 IP (tos 0x20, ttl 64, id 28261, offset 0, flags [DF], proto TCP (6), length 40)
    10.10.10.100.domain > 107.167.22.93.59026: Flags [.], cksum 0xd525 (correct), seq 0, ack 1, win 14600, length 0
E .(ne@.@.5.


dk..].5..kT na.7|P.9..%..
Источник

1 ответ

Решение

Вы заметили, что пакеты поступают извне вашей организации через правило NAT в вашем маршрутизаторе, которое переводит 86.34.156.51 <-> 10.10.10.100, Я разрешаю этот адрес и получаю ns1.style2take.ro., Понятно, что эта машина рекламируется миру как сервер имен. Отключение службы BIND на этом хосте не остановит запросы; это должно изменить то, что вы отправляете обратно (т.е. какая-то ошибка сброса / недоступности, когда служба не работает), но вы не говорите, tcpdumpОни работали, когда служба была включена или выключена, поэтому трудно комментировать дальше.

Не безумно, что серверы имен получают запросы поиска DNS. Часто люди ищут открытые средства распознавания, поскольку они полезны как для законных (разрешение имен), так и для неправильных (усиление DDoS).

Если вы хотите, чтобы этот компьютер был опубликованным сервером имен, убедитесь, что вы правильно настроили BIND (только для ответов на запросы в его авторитетных доменах, а не для рекурсивного разрешения для Интернета в целом), следите за ваши патчи BIND, и не беспокойтесь об этом трафике. Другими словами, пусть приложение выполняет фильтрацию на уровне приложения; правильно сконфигурированный BIND лучше справится с решением, какие запросы будут отвечать, а какие игнорировать, чем любое фильтрующее устройство, которое вы можете поставить перед ним.

Если вы не хотите, чтобы этот компьютер был опубликованным сервером имен, то избавьтесь от этого правила NAT и убедитесь, что адрес и имя не отображаются ни в одной записи клея или в файлах зоны.

Что касается просмотра содержимого полезной нагрузки, любая современная версия tcpdump без каких-либо дополнительных флагов следует искать внутри DNS-пакетов. Вот пример вывода с моего сервера имен, ns.teaparty.net:

[me@lory mail]$ sudo tcpdump port 53
[...]
09:37:23.613422 IP nrdns08.fibertel.com.ar.57799 > ns.teaparty.net.domain: 62409 MX? enjura.com. (28)
[ and many, many more ]
Источник
Другие вопросы по тегам