Совет по оптимальной конфигурации межсетевого экрана (Iptables)

Это моя конфигурация Iptables:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:port-scan - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m multiport --sports 80,443 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags ACK,URG URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags PSH,ACK PSH -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -j LOG
-A FORWARD -j DROP
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j DROP
-A OUTPUT -j DROP
-A port-scan -m limit --limit 1/sec --limit-burst 4 -j RETURN

Есть предложения по улучшению или удалению бесполезных правил?

Когда ваша политика базовой цепи – сброс (:INPUT DROP [0:0]), нет смысла добавлять правила сброса в базовую цепь, если только вам не нужно «вычесть» часть правила принятия.

Например, если вы хотите принять весь входящий трафик ICMP кроме тех, что «типа 8» (что бы это ни значило):

-A INPUT -p icmp -m icmp --icmp-type 8 -j DROP
-A INPUT -p icmp -j ACCEPT

Обратите внимание, что правила отклонения, такие как те, что с -j REJECT --reject-with icmp-port-unreachable, не то же самое, что и правила сброса. Я не собираюсь углубляться в детали того, когда вам может понадобиться отклонить трафик вместо того, чтобы просто сбрасывать его, или что означает отклонение, скорее моя точка зрения заключается в том, если вы хотите отклонить определенный трафик вместо его сброса, вам понадобится правило, даже когда политика цепи – сброс.

Поскольку у вас нет никаких значимых правил принятия добавленных (после) этих правил:

-A INPUT -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags ACK,URG URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags PSH,ACK PSH -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP

ни одно из них не имеет значения.

Я не знаю, могут ли какие-либо из этих правил проверки TCP-флагов иметь смысл при любых обстоятельствах, но если вы действительно хотите применить их, например, к трафику -p tcp -m multiport --sports 80,443, правильный способ сделать это – добавить эти правила сброса в новую цепь (вместо базовой цепи), например, названную TCP_FC, а затем заменить -j ACCEPT на -g TCP_FC (-j TCP_FC в данном случае подходит), с резервным -j ACCEPT добавленным в конце TCP_FC:

-N TCP_FC
-A TCP_FC -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
...
-A TCP_FC -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP
-A TCP_FC -j ACCEPT
-A INPUT -p tcp -m multiport --sports 80,443 -g ACCEPT_FC

Обратите внимание, что когда у вас есть:

-m state --state RELATED,ESTABLISHED -j ACCEPT

в цепи, такой как INPUT, любое правило, состоящее из того же совпадения, например,

-A INPUT -p tcp -m multiport --sports 80,443 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

бесполезно (-m state --state RELATED,ESTABLISHED является более короткой версией -m conntrack --ctstate RELATED,ESTABLISHED), потому что «принять любой A» «покрывает» «принять любой A И B».

Другими словами, если вы действительно просто хотите принять часть трафика RELATED,ESTABLISHED, то не следует иметь правило, которое принимает их всех. И если вы все же хотите «оптимизировать» что-то вроде:

-A INPUT -p tcp -m multiport --sports 80,443 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp --sports 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
...

вы можете сделать что-то вроде:

-N ACCEPT_RE
-A ACCEPT_RE -p tcp -m multiport --sports 80,443 -j ACCEPT
-A ACCEPT_RE -p udp --sports 53 -j ACCEPT
...
-A INPUT -m state --state RELATED,ESTABLISHED -g ACCEPT_RE

Обратите внимание на -g в последнем правиле, что означает, если какой-то трафик совпадает с этим правилом и, следовательно, «переходит» в указанную цепь (ACCEPT_RE), но он дальше не совпадает с никаким правилом в этой цепи, он не пройдет через последующие правила в цепи, содержащие правило с -g. (Когда есть только один дополнительный уровень цепи, как в данном примере, это означает, что судьба трафика будет определяться политикой цепи базовой цепи, а именно DROP в INPUT.)

Также вы можете в целом иметь что-то вроде этого вместо:

-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m state ! --state RELATED,ESTABLISHED -j DROP
-A INPUT -p tcp -m multiport --sports 80,443 -j ACCEPT

Обратите внимание, что правило принятия -i lo было «перемещено вверх», чтобы сохранить тот же эффект, который имеет в исходном наборе правил – любой трафик -i lo должен быть принят независимо от его состояния.

Правило отклонения для -p icmp -m icmp --icmp-type 8 также было поднято, чтобы такой трафик отклонялся вместо того, чтобы сбрасываться независимо от его состояния.

Отклоняя «ранний» любой трафик состояния, отличного от (обратите внимание на !) RELATED или ESTABLISHED, а именно с состоянием NEW или INVALID, вы можете иметь правила принятия после правила сброса, которые принимают, например, трафик -p tcp -m multiport --sports 80,443, не указывая ту же проверку состояния снова и снова, потому что только трафики, которые «пробрались» через правило сброса, смогут «достичь» правила(ов) принятия, которые следуют.

Проверка состояния (conntrack) в этом правиле бесполезна:

-A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT

потому что перед ним у вас есть:

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Технически наличие проверки состояния обеспечит, что INVALID исходящий трафик, направленный на любой из этих двух номеров порта, не будет принят (по этому правилу), но я сомневаюсь, что на самом деле это имеет какой-либо смысл (или что состояние вообще может быть INVALID). (В любом случае, только NEW необходимо.)

Также обратите внимание, что это правило не будет использовано вообще:

-A port-scan -m limit --limit 1/sec --limit-burst 4 -j RETURN

поскольку никакой трафик не будет проходить через цепь port-scan (т.е. ни -j port-scan, ни -g port-scan не используются ни в одном правилe). Кроме того, эффект RETURN в значительной степени зависит от «структуры» вашего набора правил.