Ich habe einen Mailserver, den ich absichern möchte, indem ich nur AUSGEHENDE Verbindungen über die verschiedenen von ihm verwendeten Ports zulasse. Die Regeln für eingehende Verbindungen funktionieren einwandfrei – sie werden vom VM-Host verwaltet.
Ich konnte nicht viel darüber herausfinden, und obwohl das folgende Skript fast funktioniert, verliert es Pakete, beispielsweise hier für Port 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
Hier ist das Skript. Beachten Sie, dass ens19 die LAN-Schnittstelle ist (die ich offen halten möchte) und ens18 das 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
Interessante Fußnote
Die von diesen Regeln verworfenen Pakete sind möglicherweise normal und ich sehe sie immer noch gelegentlich. Der Benutzer Doug S hat in den Ubuntu-Supportforen eine Erklärung dafür bereitgestellt:
Ihr Beispiel für die Protokollzeile ist für ein Paket, das nicht „NEU“ ist. Sie können es an den TCP-Flags am Ende der Zeile erkennen.
Ich vermute, dass es sich hierbei um ein übrig gebliebenes Paket aus einer bereits geschlossenen und vergessenen TCP-Sitzung handelt, da es sonst den Pfad RELATED, ESTABLISHED durchlaufen hätte.
Dies passiert häufig mit iptables, abhängig von Ihrem Router und/oder anderen Dingen, die die Pakete transportieren. Warum? Weil Linux für TCP-Verbindungen dazu neigt, eine „Halbduplex“-Schließsequenz zu verwenden, bei der jede Seite der Sitzung die Verbindungsbeendigung über einen einzelnen 2-Wege-FIN-ACK-Handshake einleiten kann (der die Verbindung in den Zustand CLOSE_WAIT versetzt), anstatt über einen vollständigen 4-Wege-FIN-ACK-Handshake.
Beobachten Sie immer die Flaggen, um sicher zu sein, was los ist. Ich denke, Sie sind in Ordnung
Bisher habe ich in der heutigen /var/log/syslog-Datei 115 Einträge, die mit „RES=0x00 ACK FIN URGP=0“ enden, und 93 davon stammen aus meinem LAN.
Antwort1
Ich vermute, dass Ihre ports-to-allow.list Port 993 enthält, weshalb Sie den von Ihnen zitierten Protokolleintrag nicht erwartet haben. Beachten Sie jedoch, dass Sie die Portliste anscheinend zum Whitelisting verwendenZielPort, während Ihr Protokoll 993 als denQuellePort des blockierten Pakets.