Веб-сервер, которым я управляю, показывает странные отклонения iptables от адресов IPv4 на порту назначения 443, несмотря на явное разрешение трафика HTTPS. Порт 80 также разрешен в том же правиле, но сайт поддерживает только HTTPS, а 80 сразу перенаправляется на 443 nginx.
Дело в том, что просмотр сайта работает. Вы можете загрузить все страницы, все ресурсы будут в порядке и т. Д. Но что-то здесь явно не так, и это может снизить производительность загрузки страницы.
Вот несколько примеров ошибок при входе в систему /var/log/iptables_deny.log для порта 443 и 80 соответственно. Они могут приходить по отдельности или пачками, судя по моим tail -f в файле журнала. Подавляющее большинство - для порта 443:
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x08 PREC=0x00 TTL=53 ID=61266 DF PROTO=TCP SPT=49264 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=11186 DF PROTO=TCP SPT=58445 DPT=443 WINDOW=254 RES=0x00 ACK FIN URGP=0
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=16941 DF PROTO=TCP SPT=16278 DPT=80 WINDOW=255 RES=0x00 ACK FIN URGP=0
Быстрый поиск показывает, что типы пакетов в отказах могут быть как минимум ACK, ACK FIN, ACK RST, ACK PSH и RST. Возможно, другие, но они мне не попались.
Ниже вывод iptables -nvL. Базовый шаблон (сначала разрешить все связанные и установленные, а затем разрешить весь новый трафик на 80 и 443) должен быть твердым на основе всего, что я прочитал. Правила LOG & DROP - последние в цепочке INPUT, как и должно быть.
Chain INPUT (policy ACCEPT 1 packets, 391 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
8893 770K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22
0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22
0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22
0 0 ACCEPT tcp -- * * (redacted IP) 0.0.0.0/0 ctstate NEW tcp dpt:22
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
63 3840 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW multiport dports 80,443
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:137
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:138
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:139
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:445
1 40 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 15/min burst 5 LOG flags 0 level 7 prefix "iptables denied: "
1 40 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 1 packets, 65 bytes)
pkts bytes target prot opt in out source destination
7311 19M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Фактические соответствующие правила, если они пригодятся после этого вывода:
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m multiport --dports 80,443 -j ACCEPT
Ясно одно: это по большому счету не вредоносный трафик. Я просматривал сайт с нескольких разных IP-адресов, и хотя сайт загружался, казалось бы, нормально, мой IP-адрес также появился в журнале отказов без какого-либо шаблона, который я мог различить, и без каких-либо видимых пользователем ошибок в браузере.
Есть идеи, что может быть за этим?
Пакеты RST и ACK, FIN являются частью самого конца TCP-соединения.
Насколько я понимаю, iptablesМеханизм отслеживания соединений использует довольно надежный подход к удалению записей таблицы состояний по соображениям безопасности: как только он видит, что один конец соединения пытается его закрыть, тогда (зная, что такой запрос сигнализирует об окончании соединения, поскольку один его конец теперь считает, что соединение не работает), он удаляет записи таблицы состояний, которые разрешали трафик этого соединения.
Возможно, было бы небезопасно ждать дольше, чтобы сделать это, в случае, если некоторые Другой аналогичный брандмауэр также был на пути, блокируя остальные пакеты очистки, указанные в RFC; отсрочка получения записи таблицы состояний до тех пор, пока они не будут обнаружены, может привести к риску оставить недействительные записи в таблице на некоторый период времени, и это может создать потенциальную уязвимость.
Но в RFC указывается, что нужно сделать еще кое-что, и именно те пакеты, которые вы видите, отклоняются. Да, это означает, что конечные точки в соединении будут использовать больше памяти, ожидая, пока соединения истекут, вместо того, чтобы видеть полное закрытие и иметь возможность освобождать память соединения намного быстрее; но для повышения безопасности часто требуются ресурсы, и это один из таких компромиссов.
Нет ничего плохого в том, что эти пакеты никогда не проходят, поэтому вы можете спокойно игнорировать записи журнала.
редактировать: если вы не хотите видеть их в журналах, разберитесь с ними до своей строки журнала, например
iptables -I INPUT 13 -p tcp -m conntrack --ctstate INVALID --tcp-flags ACK,FIN ACK,FIN -j DROP