LINUX.ORG.RU
Форум — Admin  

Bind9 notify port

 


0

1

Доброго времени суток. Пытаюсь подобрать оптимальную конфигурацию iptables для bind. Заметил, что notify отправляются на разные порты из определенного диапазона. В also-notify можно указать порт, на который отправляется notify, но в моем случае не сработало. 194.135.107.238 - мастер, 194.135.107.234, 194.135.107.231 - слэйвы.

часть named.conf.options на мастере: 

zone "test.lala" {
        type master;
        file "test.lala";
        allow-transfer {194.135.107.234; 194.135.107.231;};
        notify YES;
        also-notify port 40001 { 194.135.107.234; 194.135.107.231; };
};

Порт пытался указывать и таким образом: 

also-notify { 194.135.107.234 port 40001; 194.135.107.231 port 40001; };

Но в syslog на мастере все также указаны рандомные порты: 

..................
Mar 11 10:28:27 bind9master named[14488]: using default UDP/IPv4 port range: [1024, 65535]
Mar 11 10:28:27 bind9master named[14488]: using default UDP/IPv6 port range: [1024, 65535]
.......................
Mar 11 10:28:27 bind9master named[14488]: zone test.lala/IN: loaded serial 2015031102
Mar 11 10:28:27 bind9master named[14488]: zone test.lala/IN: sending notifies (serial 2015031102)
Mar 11 10:28:27 bind9master named[14488]: client 194.135.107.231#33137: transfer of 'test.lala/IN': AXFR-style IXFR started
Mar 11 10:28:27 bind9master named[14488]: client 194.135.107.231#33137: transfer of 'test.lala/IN': AXFR-style IXFR ended
Mar 11 10:28:27 bind9master named[14488]: client 194.135.107.234#57501: transfer of 'test.lala/IN': AXFR-style IXFR started
Mar 11 10:28:27 bind9master named[14488]: client 194.135.107.234#57501: transfer of 'test.lala/IN': AXFR-style IXFR ended

При этом на слэйвах указано, что notify они получили на 22203 и 60885 соответственно. Если я правильно понял, то отправлены notify были с портов 33137 и 57501, а получены на 22203 и 60885. Нигде не фигурирует 40001, явно указанный в named.conf.local.

P.S. на слэйвах есть такая строка: 

transfer of 'test.lala/IN' from 194.135.107.238#53: Transfer completed: 1 messages, 17 records, 431 bytes, 0.001 secs (431000 bytes/sec)

Если оставить как есть, то придется держать открытыми порты в диапазоне 1024-65535.

← Туннель между двумя системами за серыми IP
iptables →

Заметил, что notify отправляются на разные порты из определенного диапазона.

Ты ничего не перепутал? С разных портов ( из указанного диапазона портов). Отсылка нотифая на порт отличный от 53 - это нестандартная ситуация.

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

Спасибо за ответ. Хм, не знаю на сколько она нестандартная, но и уходят нотифаи с рандомных портов и приходят на рандомные порты, а трансфер идет через 53. Вот, например, кусок syslog с одного из слэйвов: 

Mar 11 10:55:48 bind9slave1 named[16188]: client 194.135.107.238#55670: received notify for zone 'test.lala'
Mar 11 10:55:48 bind9slave1 named[16188]: zone test.lala/IN: Transfer started.
Mar 11 10:55:48 bind9slave1 named[16188]: transfer of 'test.lala/IN' from 194.135.107.238#53: connected using 194.135.107.234#58245
Mar 11 10:55:48 bind9slave1 named[16188]: zone test.lala/IN: transferred serial 2015031105
Mar 11 10:55:48 bind9slave1 named[16188]: transfer of 'test.lala/IN' from 194.135.107.238#53: Transfer completed: 1 messages, 16 records, 412 bytes, 0.001 secs (412000 bytes/sec)
Mar 11 10:55:48 bind9slave1 named[16188]: zone test.lala/IN: sending notifies (serial 2015031105)
Mar 11 10:55:49 bind9slave1 named[16188]: client 194.135.107.231#4573: received notify for zone 'test.lala'
Mar 11 10:55:49 bind9slave1 named[16188]: zone test.lala/IN: refused notify from non-master: 194.135.107.231#4573
здесь видно что нотифай получен на 55670, трансфер идет на 53, а какой-то коннект для трансфера вообще с 58245. То, что касается 194.135.107.231 здесь можно проигнорировать, это второй слэйв.

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

пофиг на syslog, tcpdump-ом посмотри.

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

здесь видно что нотифай получен на 55670

Не видно. Видно, что клиент пришёл с 194.135.107.238#55670.

а какой-то коннект для трансфера вообще с 58245

Не коннект, а коннектед. Пришедший с 194.135.107.234#58245.

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

Спасибо за ответы. Я воспользовался вашем советом и попробовал посмотреть tcpdump`ом, но к сожалению затрудняюсь интерпретировать вывод. Напомню что имею: 194.135.107.228 - мастер, 194.135.107.229 - слэйв (не обращайте внимание на адресное пространство - это закрытая лаборатория).
На мастере вот такие правила: 

#трафик с lo на lo
iptables -t filter --append INPUT --in-interface lo -j ACCEPT                          
iptables -t filter --append OUTPUT --out-interface lo -j ACCEPT				
#разрешим ICMP для всех интерфейсов, типы 0 и 8 на вход, любой на выход
iptables -t filter --append INPUT --protocol icmp --icmp-type 0 -j ACCEPT
iptables -t filter --append INPUT --protocol icmp --icmp-type 8 -j ACCEPT
iptables -t filter --append OUTPUT --protocol icmp -j ACCEPT
#правила для принятия запросов dns и трансфера зоны (tcp при больших зонах тоже нужно, на сколько я знаю)
iptables -t filter --append INPUT --in-interface eth0 --protocol tcp --dport 53 --sport 1024:65535 --source 194.135.107.0/24 -j ACCEPT
iptables -t filter --append INPUT --in-interface eth0 --protocol udp --dport 53 --sport 1024:65535 --source 194.135.107.0/24 -j ACCEPT
iptables -t filter --append OUTPUT --out-interface eth0 --protocol tcp --sport 53 --destination 194.135.107.0/24 -j ACCEPT
iptables -t filter --append OUTPUT --out-interface eth0 --protocol udp --sport 53 --destination 194.135.107.0/24 -j ACCEPT
#и правило для разрешения отправки notify:
iptables -t filter --append OUTPUT --out-interface eth0 --destination 194.135.107.229 --protocol tcp --sport 1024:65535 -j ACCEPT
iptables -t filter --append OUTPUT --out-interface eth0 --destination 194.135.107.229 --protocol udp --sport 1024:65535 -j ACCEPT
Но после после проведения rndc reload, notify на слэйв все равно не приходит (там netfilter не настроен, политики ACCEPT). Пока не добавил на мастер строку: 
iptables -t filter --append INPUT --in-interface eth0 --source 194.135.107.229
нотифаи не приходили. Теперь приходят, трансфер проходит.
Вот что показывает tcpdump на мастере: 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:13:02.320562 IP master.51904 > 194.135.107.229.domain: 9209 notify [b2&3=0x2400] [1a] SOA? test.lala. (81)
11:13:02.321456 IP 194.135.107.229.domain > master.51904: 9209 notify*- 0/0/0 (32)
11:13:02.321914 IP 194.135.107.229.42599 > master.domain: 23273 [1au] SOA? test.lala. (43)
11:13:02.322138 IP master.domain > 194.135.107.229.42599: 23273*- 1/3/4 SOA (196)
11:13:02.322752 IP 194.135.107.229.47455 > master.domain: Flags [S], seq 1246719041, win 14600, options [mss 1460,sackOK,TS val 685813597 ecr 0,nop,wscale 4], length 0
11:13:02.322771 IP master.domain > 194.135.107.229.47455: Flags [S.], seq 48719929, ack 1246719042, win 14480, options [mss 1460,sackOK,TS val 686132797 ecr 685813597,nop,wscale 4], length 0
11:13:02.323139 IP 194.135.107.229.47455 > master.domain: Flags [.], ack 1, win 913, options [nop,nop,TS val 685813597 ecr 686132797], length 0
11:13:02.323159 IP 194.135.107.229.47455 > master.domain: Flags [P.], seq 1:3, ack 1, win 913, options [nop,nop,TS val 685813597 ecr 686132797], length 2
11:13:02.323167 IP master.domain > 194.135.107.229.47455: Flags [.], ack 3, win 905, options [nop,nop,TS val 686132797 ecr 685813597], length 0
11:13:02.323281 IP 194.135.107.229.47455 > master.domain: Flags [P.], seq 3:84, ack 1, win 913, options [nop,nop,TS val 685813597 ecr 686132797], length 810 [b2&3=0x1] [1a] [0q] [2919au] (79)
11:13:02.323294 IP master.domain > 194.135.107.229.47455: Flags [.], ack 84, win 905, options [nop,nop,TS val 686132797 ecr 685813597], length 0
11:13:02.323804 IP master.domain > 194.135.107.229.47455: Flags [P.], seq 1:302, ack 84, win 905, options [nop,nop,TS val 686132797 ecr 685813597], length 30120515*- 12/0/0 SOA, NS master.test.lala., NS slave1.test.lala., NS slave2.test.lala., CNAME tolya.test.lala., CNAME tolya.test.lala., A 194.135.107.228, A 194.135.107.229, A 194.135.107.230, CNAME tolya.test.lala., A 83.246.211.45, SOA (299)
11:13:02.323914 IP 194.135.107.229.47455 > master.domain: Flags [.], ack 302, win 980, options [nop,nop,TS val 685813598 ecr 686132797], length 0
11:13:02.324487 IP 194.135.107.229.47455 > master.domain: Flags [F.], seq 84, ack 302, win 980, options [nop,nop,TS val 685813598 ecr 686132797], length 0
11:13:02.324554 IP master.domain > 194.135.107.229.47455: Flags [F.], seq 302, ack 85, win 905, options [nop,nop,TS val 686132797 ecr 685813598], length 0
11:13:02.324624 IP 194.135.107.229.47455 > master.domain: Flags [.], ack 303, win 980, options [nop,nop,TS val 685813598 ecr 686132797], length 0
11:13:02.822585 ARP, Request who-has 194.135.107.230 tell 194.135.107.229, length 46
Я не могу понять, какие порты еще должны быть открыты на мастере для входа с 194.135.107.229, чтобы заменить правило 
iptables -t filter --append INPUT --in-interface eth0 --source 194.135.107.229
на более «секьюрное». Заранее благодарен тем, кто осилит эту стену текста.

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

Как мне показалось, после отправки notify с мастера на слэйв, со слэйва также приходит какое-то сообщение (подключение) на мастер на любой порт в диапазоне 1024-65535, т.е. правило 

iptables -t filter --append INPUT --in-interface eth0 --source 194.135.107.229
можно будет заменить только на 
iptables -t filter --append INPUT --in-interface eth0 -m state --state ESTABLISHED,RELATED --source 194.135.107.229
Если я не прав, прошу просветите меня.

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

Для начала, зачем, вообще, закрывать, что ни попадя ? К примеру, какой сакральный смысл в фильтрации OUTPUT ?

Следующий вопрос: что значит "--state ESTABLISHED,RELATED" по отношению к udp ?

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

Вы считаете что не нужно фильтровать OUTPUT вообще?
Больше неясностей для меня оставляет вопрос, какие правила должны быть для INPUT для нормальной работы notify, разрешения только для 53 недостаточно. Из вывода tcpdump я не могу этого понять.

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

Вы считаете что не нужно фильтровать OUTPUT вообще ?

От себя же фильтровать ? Транзит (forward) - это если шлюз. Вход (input) - да, защита. А output - вот по логике, для чего ? Это значит, что у тебя там стоит неопознанная фигня, которая шлёт что-то куда-то ? А зачем она делает это ? Если же она опознанная, её надо настроить, чтобы слала что надо и куда надо. output бывает нужен, но совсем не в общих случаях.

какие правила должны быть для INPUT для нормальной работы notify, разрешения только для 53 недостаточно.

Учитывая, что куча разных приложений использует для собственных нужд порты от 1024 и выше, они все должны быть открыты (и udp, и tcp), за исключением тех, на которых, лично у тебя, висит то, что должно быть закрыто (посмотри на вывод netstat, кто где висит).

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

Спасибо за вашу помощь и терпение. В итоге решил делать трансфер и нотифай через gre туннель в локальной сети без фильтрации на gre интерфейсах, голова перестала болеть.

nokogerra ★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Туннель между двумя системами за серыми IP
Admin
iptables →