☰

Что не так с этим исходящим брандмауэром iptables?

tag-icon • tag-icon firewall iptables tcpip
Что не так с этим исходящим брандмауэром iptables?

У меня есть почтовый сервер, который я хотел бы защитить, разрешив только ИСХОДЯЩИЕ соединения на различных портах, которые он использует. Правила для входящих соединений работают нормально — они обрабатываются хостом виртуальной машины.

Мне не удалось узнать многого об этом, и хотя приведенный ниже скрипт почти работает, он теряет пакеты, например, здесь для порта 993:

Mar 25 16:08:11 lorina kernel: [200590.714226] IPTables-Dropped: IN= OUT=ens18 SRC=[local IP here] DST=[remote IP here] LEN=148 TOS=0x00 PREC=0x00 TTL=64 ID=37253 DF PROTO=TCP SPT=993 DPT=14826 WINDOW=243 RES=0x00 ACK PSH FIN URGP=0

Вот скрипт. Обратите внимание, что ens19 — это интерфейс LAN (который я хотел бы оставить открытым), а ens18 — это WAN.

iptables -A OUTPUT -o lo -p all -j ACCEPT
iptables -A OUTPUT -o ens19 -p all -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp -m owner --uid-owner systemd-timesync -j ACCEPT

ip6tables -A OUTPUT -o lo -p all -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 -j ACCEPT
ip6tables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A OUTPUT -p tcp --dport 53 -j ACCEPT
ip6tables -A OUTPUT -p udp --dport 53 -j ACCEPT
ip6tables -A OUTPUT -p udp -m owner --uid-owner systemd-timesync -j ACCEPT

while read h; do
        ip6tables -A OUTPUT -m conntrack --ctstate NEW -d $h -j ACCEPT &> /dev/null
        iptables -A OUTPUT -m conntrack --ctstate NEW -d $h -j ACCEPT
done < /usr/local/etc/hosts-to-allow.list

while read p; do
        ip6tables -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport $p -j ACCEPT
        iptables -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport $p -j ACCEPT
done < /usr/local/etc/ports-to-allow.list

ip6tables -A OUTPUT -o ens18 -j LOGGING
ip6tables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A OUTPUT -o ens18 -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4

iptables -A OUTPUT -o ens18 -j REJECT
ip6tables -A OUTPUT -o ens18 -j REJECT

Интересная сноска

Отброшенные пакеты из этих правил могут быть нормальными, и я все еще иногда их вижу. Объяснение этому дал пользователь Doug S на форумах поддержки Ubuntu:

Ваш пример строки журнала относится к пакету, который не является "NEW". Это можно определить по флагам TCP в конце строки.

Я предполагаю, что это задержавшийся пакет из уже закрытого и забытого сеанса TCP, в противном случае он прошел бы по пути RELATED,ESTABLISHED.

Это часто случается с iptables, в зависимости от вашего маршрутизатора и/или других вещей в пакетах, которые перемещаются. Почему? Потому что для TCP-соединений Linux имеет тенденцию использовать "полудуплексную" последовательность закрытия, где любая сторона сеанса может инициировать завершение соединения с помощью одного двухстороннего рукопожатия FIN-ACK (которое переводит соединение в состояние CLOSE_WAIT), вместо полного четырехстороннего рукопожатия FIN-ACK.

Всегда следите за флагами, чтобы точно знать, что происходит. Я думаю, что вы в порядке.

На данный момент в сегодняшнем файле /var/log/syslog у меня 115 записей, которые заканчиваются на «RES=0x00 ACK FIN URGP=0», и 93 из них из моей локальной сети.

решение1

Я предполагаю, что ваш ports-to-allow.list содержит порт 993, поэтому вы не ожидали записи в журнале, которую вы цитировали. Обратите внимание, однако, что вы, похоже, используете список портов для белого спискаместо назначенияпорт, тогда как ваш журнал показывает 993 какисточникпорт заблокированного пакета.

Связанный контент