LINUX.ORG.RU
ФорумAdmin

Bind 9.11 + iptables не отвечает на запросы

 ,


0

2

Доброго дня коллеги.
Нужна ваша помощь. Bind упорно молчит на запросы от клиентов. В iptables политика по умолчанию DROP, правила у меня такие:

iptables -P INPUT DROP;
iptables -P OUTPUT DROP;
iptables -P FORWARD DROP;

#INPUT
iptables -A INPUT -i $WAN_IF -p tcp -m tcp --source 0/0 --sport $UNPRIV_PORTS --destination $WAN_IP --dport 53 -m conntrack --ctstate NEW -j ACCEPT;
iptables -A INPUT -i $WAN_IF -p udp -m udp --source 0/0 --sport $UNPRIV_PORTS --destination $WAN_IP --dport 53 -m conntrack --ctstate NEW -j ACCEPT;
iptables -A INPUT -i $WAN_IF -p tcp -m tcp --source 0/0 --sport 53 --destination $WAN_IP --dport $UNPRIV_PORTS -m conntrack --ctstate NEW -j ACCEPT;
iptables -A INPUT -i $WAN_IF -p udp -m udp --source 0/0 --sport 53 --destination $WAN_IP --dport $UNPRIV_PORTS -m conntrack --ctstate NEW -j ACCEPT;
iptables -A INPUT -i $WAN_IF -p all -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

#OUTPUT
iptables -A OUTPUT -o $WAN_IF -p tcp --source $WAN_IP --sport 53 --destination 0/0 --dport $UNPRIV_PORTS -m conntrack --ctstate NEW -j ACCEPT;
iptables -A OUTPUT -o $WAN_IF -p udp --source $WAN_IP --sport 53 --destination 0/0 --dport $UNPRIV_PORTS -m conntrack --ctstate NEW -j ACCEPT;
iptables -A OUTPUT -o $WAN_IF -p tcp --source $WAN_IP --sport $UNPRIV_PORTS --destination 0/0 --dport 53 -m conntrack --ctstate NEW -j ACCEPT;
iptables -A OUTPUT -o $WAN_IF -p udp --source $WAN_IP --sport $UNPRIV_PORTS --destination 0/0 --dport 53 -m conntrack --ctstate NEW -j ACCEPT;
iptables -A OUTPUT -o $WAN_IF -p all -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT;

Вроде ничего не упустил, но не работает. Если сбросить все правила , и поставить политику по умолчанию ACCEPT, то bind прекрасно отвечает на запросы. Значит проблема таки в iptables.

dig с клиентской машины отвечает вот так:

dig @xx.xx.xx.xx +noall +comments +cmd +bufsize=1 query
; <<>> DiG 9.10.3-P4-Debian <<>> @xx.xx.xx.xx +noall +comments +cmd +bufsize=1 query
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Подскажите в какую сторону копнуть.
Спасибо заранее.

★★

Последнее исправление: Vint (всего исправлений: 2)

В iptables не силён, но для начала я бы попытался определить проблема в INPUT, OUTPUT или в обеих цепочках.

bind 127.0.0.1 прослушивает? Если с самого сервера сделать запрос?

Объединил бы похожие правила, например, зачем каждый протокол указывать явно?

Deleted
()
Ответ на: комментарий от Deleted

Как определить в какой цепочке проблема? Методику подскажите пожалуйста.

На 127.0.0.1 и на интерфейсе смотрящем в локалку висит dnsmasq, он обслуживает внутреннюю зону и DHCP. Bind висит только на внешнем интерфейсе как первичный сервер зоны реального домена. Машина работает роутером. При чём вторичным серверам он зону отдаёт без проблем. Только на прямой запрос от клиента не отвечает.

Указал протоколы явно потому как -p all будет включать в себя ещё и icmp/sctp/.... Зачем, если можно ограничить всё по максимуму?

Vint ★★
() автор топика
Последнее исправление: Vint (всего исправлений: 1)
Ответ на: комментарий от Vint

Как определить в какой цепочке проблема? Методику подскажите пожалуйста.

Сначала сделать iptables -P INPUT ACCEPT и посмотреть, если не поможет, то откатить конфиг и настроить iptables -P OUTPUT ACCEPT

Указал протоколы явно потому как -p all будет включать в себя ещё и icmp/sctp/.... Зачем, если можно ограничить всё по максимуму?

ИМХО, упростить чтение конфигурации. Для icmp --sport 53 всё равно смысла не имеет, зато число подобных строк вдвое сократится. Идея, конечно хорошая, разрешить только то что нужно, а остальное заблокировать. Только зачем такие строгие правила? ИМХО, полезнее было ограничить количество запросов в секунду, чтобы хоть немного защититься от DDOS.

Также, как вариант, настроить логирование. Тут в помощь man и гугл. Настроить логирование, чтобы убедиться, что правила работают и настроить логирование событие, которые не вписываются в твои требования.

Deleted
()

А клиент то у тебя в какой сети находится? Похоже, что у тебя он только на WAN интерфейсе и отвечает.

turtle_bazon ★★★★★
()
Ответ на: комментарий от turtle_bazon

Естессно если сервер смотрин только наружу, то и проверяю я клиентом снаружи. Уж это совсем элементарно.

Vint ★★
() автор топика
Ответ на: комментарий от Deleted

От DDOS у бинда есть свои rate-limit, и они у меня настроены. Их думаю достаточно.

Про логирование из правила я как то забыл, щас попробую. Спасибо

Vint ★★
() автор топика
Ответ на: комментарий от Vint

Мало ли. :) Раз такие вопросы с иптаблесами возникают. :) Я ещё посмотрел, у тебя INPUT на dport 53 не разрешает. А когда коннектятся к тебе, то это как раз dport и есть. То есть dst address и dst port.

turtle_bazon ★★★★★
()

Вообще, source port у тебя рандомный для тебя будет на клиенте выбираться, а вот destination port как раз 53. Грубо говоря, у тебя там наоборот. И да, правила какие-то слишком замудрёные, можно постараться упростить.

turtle_bazon ★★★★★
()

1. Возможно какие-то еще правила iptables, покажите iptables-save
2. Возможно проблема в переменных $WAN_IF, $UNPRIV_PORTS, $WAN_IP - опять-таки смотрите iptables-save
3. запрос прилетает не на $WAN_IF && $WAN_IP - смотрите tcpdump

anc ★★★★★
()
Ответ на: комментарий от turtle_bazon

почему на разрешено на 53 INPUT:
iptables -A INPUT -i $WAN_IF -p tcp -m tcp --source 0/0 --sport $UNPRIV_PORTS --destination $WAN_IP --dport 53 -m conntrack --ctstate NEW -j ACCEPT;
iptables -A INPUT -i $WAN_IF -p udp -m udp --source 0/0 --sport $UNPRIV_PORTS --destination $WAN_IP --dport 53 -m conntrack --ctstate NEW -j ACCEPT;

тут же явно --destination $WAN_IP --dport 53 на обоих протоколах

или я вас неправильно понял?

Vint ★★
() автор топика
Ответ на: комментарий от anc

С переменными всё в порядке, остальные правила с этими же переменными работают.

Упростил до безобразия:

INPUT
iptables -A INPUT -i $RED -p tcp -d $WAN_IP --dport 53 -j ACCEPT;
iptables -A INPUT -i $RED -p udp -d $WAN_IP --dport 53 -j ACCEPT;

OUTPUT
iptables -A OUTPUT -o $RED -p all -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT;

И всё равно не работает.

Vint ★★
() автор топика
Ответ на: комментарий от Vint
:INPUT DROP [2:112]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -p tcp -m multiport --dports 0:65535 -m set --match-set f2b-recidive src -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m multiport --dports 25,465,587,443,993,110,995 -m set --match-set f2b-postfix-bad-helo src -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m multiport --dports 80,443 -m set --match-set f2b-nginx-botsearch src -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m conntrack --ctstate INVALID -m comment --comment "Drop invalid packets" -j DROP
-A INPUT -p tcp -m conntrack --ctstate INVALID,NEW -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m comment --comment "Prevent SYN-Flood atack" -j REJECT --reject-with tcp-reset
-A INPUT -s 127.0.0.0/8 -i lo -m comment --comment "Grant all access for loppback input traffic" -j ACCEPT
-A INPUT -s 192.168.77.0/24 -i eth1 -m comment --comment "Grant all access for intranet input traffic" -j ACCEPT
-A INPUT -i eth1 -p udp -m multiport --dports 53,67,68 -m conntrack --ctstate NEW -m comment --comment "Accept DNS/DHCP UDP traffic for intranet" -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW -m comment --comment "Accept DNS TCP traffic for intranet" -j ACCEPT
-A INPUT -i eth0 -f -m comment --comment "Drop all fragmented packets" -j DROP
-A INPUT -i eth0 -m geoip --source-country CN,VN,TW,UA  -m comment --comment "Deny all traffic from restricted countries" -j DROP
-A INPUT -i eth0 -m psd --psd-weight-threshold 21 --psd-delay-threshold 300 --psd-lo-ports-weight 3 --psd-hi-ports-weight 1  -m comment --comment "Prevent port-scaning by legal method" -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,ACK FIN -m comment --comment "FIN-scan protection" -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -m comment --comment "X-scan protect" -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -m comment --comment "N-scan protect" -j DROP
-A INPUT -i eth0 -p tcp -m osf --genre NMAP -m comment --comment "NMAP OS detection protection" -j DROP
-A INPUT -s 10.0.0.0/8 -i eth0 -m comment --comment "Antispoofing Class A from internet" -j DROP
-A INPUT -s 172.16.0.0/12 -i eth0 -m comment --comment "Antispoffing Class B from internet" -j DROP
-A INPUT -s 192.168.0.0/16 -i eth0 -m comment --comment "Antispoofing Class C from internet" -j DROP
-A INPUT -s 224.0.0.0/8 -i eth0 -m comment --comment "Antispoffing Class D(multicast) from internet" -j DROP
-A INPUT -s 240.0.0.0/5 -i eth0 -m comment --comment "Antispoofing Class E from internet" -j DROP
-A INPUT -s 127.0.0.0/8 -i eth0 -m comment --comment "Antispoofing Loopback from internet" -j DROP
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 0 -m limit --limit 2/sec -m comment --comment "ICMP \'echo reply\' with some restricts" -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec -m comment --comment "ICMP \'echo request\' with some restricts" -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 3 -m comment --comment "ICMP \'Destination unreachable\'" -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 12 -m comment --comment "ICMP \'IP Header bad\'" -j ACCEPT
-A INPUT -d 192.168.77.254/32 -i eth0 -p tcp -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --update --seconds 120 --hitcount 4 --name ssh_brutforce --mask 255.255.255.255 --rsource -m comment --comment "SSH brutforce prevent in gate.lan" -j DELUDE
-A INPUT -d 192.168.77.254/32 -i eth0 -p tcp -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource -m comment --comment "SSH accept normal connect to gate.lan" -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m multiport --dports 80,443 -m connlimit --connlimit-above 20 --connlimit-mask 32 --connlimit-saddr -m comment --comment "Restric connects to WEB ports for 20 counts per one IP" -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m multiport --dports 80,443 -m connlimit --connlimit-above 150 --connlimit-mask 0 --connlimit-saddr -m comment --comment "Restrict all connects to WEB ports for 150 counts" -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m multiport --dports 25,465,587,993 -m connlimit --connlimit-above 5 --connlimit-mask 32 --connlimit-saddr -m comment --comment "Restric connects to MAIL ports for 5 per one IP" -j DROP
-A INPUT -i eth0 -p udp -m udp --dport 53 -m string --hex-string "|0000ff0001|" --algo bm --to 65535 -m comment --comment "Restrict ANY request to our DNS" -j DROP
-A INPUT -i eth0 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -m recent --update --seconds 180 --hitcount 3 --name dns_any --mask 255.255.255.255 --rsource -m comment --comment "Restrict ANY request to our DNS" -j DROP
-A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "Accept all established connection from WAN to router" -j ACCEPT
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m multiport --dports 25,53,80,443,465,587,993 -m comment --comment "Accept allowed WAN TCP ports" -j ACCEPT
-A INPUT -i eth0 -p udp -m conntrack --ctstate NEW -m multiport --dports 53 -m comment --comment "Accept allowed WAN UDP ports" -j ACCEPT

-A OUTPUT -m conntrack --ctstate INVALID -j DROP
-A OUTPUT -p tcp -m conntrack --ctstate INVALID,NEW -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with tcp-reset
-A OUTPUT -d 127.0.0.0/8 -o lo -j ACCEPT
-A OUTPUT -d 192.168.77.0/24 -o eth1 -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 0 -m limit --limit 2/sec -m comment --comment "ICMP \'echo reply\' with some restricts" -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec -m comment --comment "ICMP \'echo request\' with some restricts" -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 3 -m comment --comment "ICMP \'destination unreachable\'" -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 4 -m comment --comment "ICMP \'source quench\'" -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 11 -m comment --comment "ICMP \'time-to-live exceeded\'" -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 12 -m comment --comment "ICMP \'IP header bad\'" -j ACCEPT
-A OUTPUT -o eth0 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT



Всё не влезло, убрал цепочку FORWARD/PREROUTING и NAT. Eth0 это внешний, Eth1 внутренний

Vint ★★
() автор топика
Последнее исправление: Vint (всего исправлений: 2)
Ответ на: комментарий от shell-script

Так а с -P INPUT/OUTPUT ACCEPT работает или нет?

Да, как ни странно

Vint ★★
() автор топика
Ответ на: комментарий от Vint

Вот это не оно?

-A INPUT -i eth0 -p udp -m udp --dport 53 -m string --hex-string "|0000ff0001|" --algo bm --to 65535 -m comment --comment "Restrict ANY request to our DNS" -j DROP
-A INPUT -i eth0 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -m recent --update --seconds 180 --hitcount 3 --name dns_any --mask 255.255.255.255 --rsource -m comment --comment "Restrict ANY request to our DNS" -j DROP

Вообще для наглядности тестировать лучше не так. Обнули счётчики iptables, потом попробуй сделать несколько проблемных запросов и потом посмотреть iptables -nvL --line-numbers

P.S. Запутанные у тебя настройки. Я бы порекомендовал или аккуратно всё разнести по цепочкам или, если лень вникать, взять хотя бы тот же самый ferm.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Запутанные у тебя настройки.

У меня всё по порядку, даже комментарии есть. Это вывод iptables-save. В скрипте всё более понятно и упорядочено. Два правила что вы указали откидывают запросы типа ANY. К нормальному клиентскому запросу это не относится. Для проверки я их даже отключал.

Вообще для наглядности тестировать лучше не так. Обнули счётчики iptables, потом попробуй сделать несколько проблемных запросов и потом посмотреть iptables -nvL --line-numbers

Уже делал так, ни один из счётчиков на правилах не меняется.

Vint ★★
() автор топика
Ответ на: комментарий от Vint

У меня всё по порядку, даже комментарии есть. Это вывод iptables-save.

iptables-save показывает правила в том порядке, в котором они у тебя в данный момент реально работают. Таким образом разрешающее правило для 53 udp у тебя в самом конце и под него пакет попадёт только в том случае, если не попал ни под одно вышестоящее.

Уже делал так, ни один из счётчиков на правилах не меняется.

Счётчики не растут вообще ни на каких правилах? Что будет, если эксперимента ради добавить -I INPUT -p udp -m udp --dport 53 -j ACCEPT руками на живую?

shell-script ★★★★★
()
Последнее исправление: shell-script (всего исправлений: 1)
Ответ на: комментарий от shell-script

iptables-save показывает правила в том порядке, в котором они у тебя в данный момент реально работают. Таким образом разрешающее правило для 53 udp у тебя в самом конце и под него пакет попадёт только в том случае, если не попал ни под одно вышестоящее.

В курсе. Исходя из нужного мне порядка всё и стоит. Запрещающее правило жёстко описывает пакет содержащий HEX-последовательность, которой по определению быть не может в стандартном запросе. Исходя из этого пакеты нормального запроса доберутся до разрешающего правила. К тому же я у же написал вам, что ради эксперимента я уже отключал эти два правила. Бестолку.

Что будет, если эксперимента ради добавить

Щас попробую. Не помогло

Vint ★★
() автор топика
Последнее исправление: Vint (всего исправлений: 1)
Ответ на: комментарий от Vint

Да я не конкретно про эти два правила. Я довольно бегло просмотрел остальные правила, думал, может что там.

Но вообще странно, раз при политике ACCEPT работает, а при явном первом разрешающем правиле - нет. Очень странно.

Была ещё идея, может что-то в таблице nat в PREROUTING'е мешает, но тогда бы оно при любых правилах filter не работало. У меня идеи кончились.

shell-script ★★★★★
()
Ответ на: комментарий от Vint

Выше я ответил: с политикой по умолчанию ACCEPT, всё нормально работает.

Логика подсказывает, что ни под одно запрещающее правило нормальный запрос к DNS не попадает. И он пролетает только по дефолтной политике. Значит просто ему не хватает какого то разрешающего правила при политике DROP. Логично же? Так вот какого правила то не хватает? Я уже всю башку сломал.

Vint ★★
() автор топика
Последнее исправление: Vint (всего исправлений: 1)
Ответ на: комментарий от shell-script

У меня идеи кончились

Вот по этому я здесь и спросил, потому как у меня тоже идеи кончились

Vint ★★
() автор топика
Ответ на: комментарий от Vint

Да. Именно по этому я и предложил попробовать поставить в начало максимально простое разрешающее правило. И вот это-то и странно, что на него ничего не попало.

shell-script ★★★★★
()

В порядке предположения: UDP это стейтлесс протокол, а у тебя в цепочке output разрешаются только ответы с стейтами new, related, estab, возможно это мешает. Вполне вероятно, что я вру и с твоей стороны было бы проще поставить conntrack-tools и посмотреть на стейты «соедиенений».

Да и вообще — фильтровать OUTPUT это как-то некомильфо с моей точки зрения.

BOOBLIK ★★★
()
Ответ на: комментарий от BOOBLIK

Если бы проблема была в OUTPUT при экспериментах росли бы счётчики INPUT.

shell-script ★★★★★
()
Ответ на: комментарий от Vint

Ну так, по идее, должен работать, наверное. Что логи говорят?

turtle_bazon ★★★★★
()
Ответ на: комментарий от Vint

Оставь только то, что DNS касается и играйся. Тут куча правил, надо понять проблема в них или в чём-то другом.

turtle_bazon ★★★★★
()
Ответ на: комментарий от Vint

И все-таки если как написали выше в правиле -I INPUT -p udp -m udp --dport 53 -j ACCEPT не растут счетчики при запросе, то остается либо mangle у INPUT либо PREROUTING

anc ★★★★★
()
Ответ на: комментарий от anc

В прероутинге (только у таблицы NAT) у меня только редирект на SSH и FTP снаружи на локальные сервера. В других таблицах prerouting пустой. Mangle вобще не трогал, девственно чиста по дефолту, тем более что в скрипте перед назначением политик по умолчанию я все таблицы сбрасываю, в том числе и mangle. Использую только таблицы filter и nat.

Вот мой PREROUTING(NAT)
iptables -t nat -A PREROUTING -i eth0 --dst $WAN_IP -p tcp -m tcp --dport $SSH_PORT -j DNAT --to-destination $LAN_IP:22 -m comment --comment «SSH redirect to lan»;
iptables -t nat -A PREROUTING -i eth0 --dst $WAN_IP -p tcp -m tcp --dport $SSH_PORT_S1 -j DNAT --to-destination $LOCAL_S1:22 -m comment --comment «SSH redirect to lan»;
iptables -t nat -A PREROUTING -i eth0 --dst $WAN_IP -p tcp -m tcp --dport $SSH_PORT_S2 -j DNAT --to-destination $LOCAL_S2:22 -m comment --comment «SSH redirect to lan»;

iptables -t nat -A PREROUTING -i eth0 --dst $WAN_IP -p tcp -m multiport --dports $FTP_PORTS -j DNAT --to-destination $LOCAL_S1 -m comment --comment «FTP redirect to lan»;

iptables -t nat -A PREROUTING -i eth0 --dst $WAN_IP -p tcp -m multiport --dport $PLEX_PORT -j DNAT --to-destination $LOCAL_S1 -m comment --comment «PLEX redirect to lan»;

Vint ★★
() автор топика
Последнее исправление: Vint (всего исправлений: 2)
Ответ на: комментарий от turtle_bazon

Может, показалось. Когда смотрел, было по другому.

:-) Ну так я ж написал выше, что изменил/упростил правила. Так что не показалось.

Vint ★★
() автор топика
Ответ на: комментарий от Vint

Поставил действие LOG на строки правил NDS:

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j LOG
iptables -A INPUT -i eth0 -p udp -m udp --dport 53 -j LOG

iptables -A INPUT -i eth0 -p tcp -m tcp --sport 1024:65535 -j LOG
iptables -A INPUT -i eth0 -p udp -m udp --sport 1024:65535 -j LOG

Поставил их самыми первыми в таблице. В логе ТИШИНА. То есть получается запросы просто тупо не приходят на 53 порт! WHY!? Я понимаю провайдер может в своей подсети рубить весь трафик по udp на 53 порт. Но проваливаются без результата даже локальные запросы на внешний интерфейс.

Я в ступоре

P.S. Обнаружил на втором сервере ровно ту же ситуацию. Системы разные, на одной Debian 9 на второй Ubuntu 18. Это точно проблема iptables. Правила файервола на обеих машинах очень похожи.

Vint ★★
() автор топика
Последнее исправление: Vint (всего исправлений: 1)
Ответ на: комментарий от Vint

Если поставить политику ACCEPT и на INPUT и на OUTPUT, то в логе вот что:

запрос
IN=enp5s2 OUT= SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=86 TOS=0x00 PREC=0x00 TTL=54 ID=19485 PROTO=UDP SPT=48516 DPT=53 LEN=66

ответ
IN= OUT=enp5s2 SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=63583 DF PROTO=UDP SPT=13245 DPT=53 LEN=47

и запрос пролетает, и bind отвечает. Если выставить политику DROP то в логах вобще тихо.

С портами в правилах всё правильно, судя по тому какие в логе запрашиваются. Единственное что насторожило, это поле IN=. Оно пустое.

P.P.S.Понял строка лога от правила INPUT содержит пустое поле OUT. Строка лога от правила OUTPUT содержит пустое поле IN. Так что всё в порядке.

Vint ★★
() автор топика
Последнее исправление: Vint (всего исправлений: 1)
Ответ на: комментарий от anc

Немного не понимаю вашей краткости, но если вы имеете ввиду что все правила (описанные выше) содержат другое имя интерфейса, то спешу вас разочаровать. Я ж написал чуть выше что нашёл ту же проблему на другом сервере (debian), так вот там эти новомодные имена интерфейсов и есть, ну и соответственно правила тоже на них настроены (пакеты же ходят судя по логам). Я просто лог привёл с другой машины

Vint ★★
() автор топика
Ответ на: комментарий от Vint

Я просто лог привёл с другой машины

Замечательно. Давайте все-таки разбираться с той про которую уже что-то написали. Начнем сначала
iptables -I INPUT -i eth0 -p udp -m udp --dport 53 -j LOG Именно -I а не -A.
При политике INPUT DROP Ничего не пишет в лог? А при политеке INPUT ACCEPT пишет? Покажите плиз выхлоп.

anc ★★★★★
()
Ответ на: комментарий от anc

политика ACCEPT, правила:

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j LOG;
iptables -A INPUT -i eth0 -p udp -m udp --dport 53 -j LOG;

в логах:
Jan 24 14:13:26 gate kernel: [252765.943564] IN=eth0 OUT= MAC=00:80:48:c1:f5:98:00:22:56:ba:47:3f:08:00 SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=60 ID=35195 DF PROTO=TCP SPT=55427 DPT=53 WINDOW=260 RES=0x00 ACK URGP=0
Jan 24 14:13:58 gate kernel: [252797.849700] IN= OUT=eth0 SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=68 TOS=0x00 PREC=0x00 TTL=64 ID=3315 DF PROTO=UDP SPT=8207 DPT=53 LEN=48

странно но tcpdump никак не реагирует на посланный запрос, только разный левак, и ни строчки по моему запросу. Bind на запрос отвечает.

При политике DROP в логах тишина и tcpdump ведёт себя так же, ответа от binda нет.

Vint ★★
() автор топика
Ответ на: комментарий от Vint

Вру, tcpdump показывает запрос и ответ при политике ACCEPT. ПРи политике DROP ничего относительно моего запроса нет. Не хочу вываливать сюда выхлоп tcpdump, там основная инфа это адреса, кои светить нет желания.

Vint ★★
() автор топика

если мне не изменяет память, то вот это:

iptables -P INPUT DROP;
iptables -P OUTPUT DROP;
iptables -P FORWARD DROP;

ставь в конце, а не в начале.

shashilx ★★
()
Ответ на: комментарий от shashilx

Разницы никакой, хоть в середине. Это не цепочки. Зачем это делают (прописывают в конце) к данной проблеме не имеет никакого отношения.

anc ★★★★★
()
Ответ на: комментарий от anc

Не -A а -I выполнить при уже загруженных ваших правилах

Выше уже советовали и я делал. Без разницы, что в самом начале правила что в том месте где я их определил.

Вся петрушка в том, что все остальные сервисы (для которых есть правила в файерволе) работают нормально, smtp, urd, submission, imaps, ssh, ftp. Проблема точно не сети и маршрутизации. Тут похоже что бинду чего то не хватает. Причём именно в клиентском соединении, потому как слейвам он зону нормально передаёт, только что проверил.

Vint ★★
() автор топика
Последнее исправление: Vint (всего исправлений: 2)
Ответ на: комментарий от Vint

Если все так как вы написали, то у меня мыслей нет.

Тут похоже что бинду чего то не хватает

Бинд тут не причем, у вас может вообще ничего не слушать порт, пакет все равно прилетит в INPUT т.е. при первом правиле в цепочке INPUT -i eth0 -p tcp -m tcp --dport 53 -j LOG в логе должна появиться запись.

anc ★★★★★
()
Ответ на: комментарий от vodz

Если бы дело было в conntrack то изменение полиси DROP->ACCEPT не влияло на не-работоспособность->работоспособность.

anc ★★★★★
()
Ответ на: комментарий от anc

Если бы дело было в conntrack то изменение полиси DROP->ACCEPT не влияло на не-работоспособность->работоспособность.

Я до сих пор не понял в этом топике, был ли вообще от ТСа ответ на первые коменты: какие из input/output или только когда оба влияет на.

vodz ★★★★★
()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от vodz

Ну исходя из того как пишет TC, если прописываем первыми правилами

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j LOG;
iptables -A INPUT -i eth0 -p udp -m udp --dport 53 -j LOG;

при полиси DROP в лог ничего не попадает
при изменении на ACCEPT в лог пишется

Jan 24 14:13:26 gate kernel: [252765.943564] IN=eth0 OUT= MAC=00:80:48:c1:f5:98:00:22:56:ba:47:3f:08:00 SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=60 ID=35195 DF PROTO=TCP SPT=55427 DPT=53 WINDOW=260 RES=0x00 ACK URGP=0
Jan 24 14:13:58 gate kernel: [252797.849700] IN= OUT=eth0 SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=68 TOS=0x00 PREC=0x00 TTL=64 ID=3315 DF PROTO=UDP SPT=8207 DPT=53 LEN=48

anc ★★★★★
()
Ответ на: комментарий от vodz

Я до сих пор не понял в этом топике, был ли вообще от ТСа ответ на первые коменты: какие из input/output или только когда оба влияет на.

Я ответил - только когда и INPUT и OUTPUT в ACCEPT. Если по одному то не работает.

Сейчас отметил закономерность. С внешнего хоста (географически далеко, терминалом) запрос от dig не получает ответа. Локально на серваке запрос dig на внешний IP сервера тоже остаётся без ответа. А вот если запустить dig с хоста из локалки (в той же подсети что и сервер) и тоже указать внешний IP сервера, то опа, получаю ответ.
Чёт я запутался. Ну допустим снаружи не достучаться до 53 порта можно по вине провайдера, который возможно бессовестно рубит UDP53 трафик на своих маршрутизаторах. Но почему локально запрос не прокатывает? Может я чего не знаю?

Vint ★★
() автор топика
Ответ на: комментарий от Vint

Я ответил - только когда и INPUT и OUTPUT в ACCEPT. Если по одному то не работает.

Когда всего две политики, то логика то простая — откройте вторую политику и чините пока первую.

Чёт я запутался. Ну допустим снаружи не достучаться до 53 порта

Но как это у ваших провайдеров по пути можно поменять вашей политикой? Тяжело вам что-то советовать, когда весь топик какая-то каша. Ну уберите в файрволе ВСЁ, добавляйте по двум строкам, одна с логированием, вторая с правилом и ищите где оно ломается. Я тут дал доку, где вполне разумные и законченные правила для DNS от авторов bind-а приведены. Они вполне достаточны.

vodz ★★★★★
()
Ответ на: комментарий от vodz

Спасибо за доку. Попробую рекомендации

Vint ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.