Ich habe ein Problem auf einem neu eingerichteten Server in der Hetzner-Cloud, auf dem Ubuntu 18.04 LTS läuft.
Nach der Installation von Iptables(-persistent) und der Konfiguration des folgenden Regelsatzes:
root@inetsec:/home/linus# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere 1.2.3.4 tcp dpt:272
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Ich kann immer noch einen erfolgreichen TCP-Handshake mit Telnet durchführen, indem ich mehrere andere Ports (110, 143, 25, 993) verwende.
Trotzdem werden die für diese Ports verantwortlichen Anwendungen (Dovecot und Postfix) nicht einmal ausgeführt und es netstat -tulpenwird Folgendes angezeigt:
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 112 20485 1198/mysqld
tcp 0 0 1.2.3.4:272 0.0.0.0:* LISTEN 0 18773 1047/sshd
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 19746 1113/systemd-resolv
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 111 19076 1004/named
udp 0 0 127.0.0.53:53 0.0.0.0:* 101 19745 1113/systemd-resolv
udp 0 0 127.0.0.1:53 0.0.0.0:* 111 19075 1004/named
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 18955 1173/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 15042 816/dhclient
, bekomme ich bei Verwendung von Telnet auf den genannten Ports immer noch einen TCP-Handshake, statt des erwarteten Timeouts (aufgrund der INPUT DROP-Policy) oder zumindest einer ICMP-Destination Unreachable (3)Meldung für die geschlossenen Ports.
Ein Problem, das ich gefunden habe, ist, dass, wenn ich den Server mit gespeichertem iptable-Regelsatz () neu starte, iptables-save > /etc/iptables/rules.v4der Server etwa 5 Minuten im Zustand hängt
....
iscsi: registered transport (tcp)
iscsi: registered transport (user)
bevor Sie die Anmeldung aktivieren.
Außerdem dauert es dann etwa 15 Sekunden, um den Befehl auszuführeniptables -L