iptables

[Apollo013]

hallo, kann mir jemand bei iptables helfen?
Ich habe alle Ports geblockt, danach habe ich bestimmte Ports freigeschaltet.
So schaut die iptables -L -v aus.

❯ sudo iptables -L -v
Chain INPUT (policy DROP 3925 packets, 236K bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:imap2
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:smtp
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:https
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http-alt
1388 83591 LOG all -- any any anywhere anywhere LOG level debug prefix "iptables:INPUT-DROP "

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy DROP 1517 packets, 116K bytes)
pkts bytes target prot opt in out source destination
146 8760 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http
2425 146K ACCEPT tcp -- any any anywhere anywhere tcp dpt:https
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:imap2
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:smtp
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http-alt
516 36217 LOG all -- any any anywhere anywhere LOG level debug prefix "iptables:OUTPUT-DROP "

sudo journalctl -k | grep "iptables"

Mai 05 12:54:15 debian kernel: iptables:OUTPUT-DROP IN= OUT=wlxf0a7314ab340 SRC=192.168.129.5 DST=212.227.17.170 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48659 DF PROTO=TCP SPT=42328 DPT=993 WINDOW=64240 RES=0x00 SYN URGP=0
Mai 05 12:54:15 debian kernel: iptables:OUTPUT-DROP IN= OUT=wlxf0a7314ab340 SRC=192.168.129.5 DST=212.227.17.170 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=24128 DF PROTO=TCP SPT=42318 DPT=993 WINDOW=64240 RES=0x00 SYN URGP=0
Mai 05 12:54:21 debian kernel: iptables:INPUT-DROP IN=wlxf0a7314ab340 OUT= MAC=f0:a7:31:4a:b3:40:42:65:5a:09:14:9f:08:00 SRC=44.196.22.110 DST=192.168.129.5 LEN=60 TOS=0x00 PREC=0x00 TTL=243 ID=0 DF PROTO=TCP SPT=443 DPT=49112 WINDOW=26847 RES=0x00 ACK SYN URGP=0
Mai 05 12:54:21 debian kernel: iptables:INPUT-DROP IN=wlxf0a7314ab340 OUT= MAC=f0:a7:31:4a:b3:40:42:65:5a:09:14:9f:08:00 SRC=44.196.22.110 DST=192.168.129.5 LEN=60 TOS=0x00 PREC=0x00 TTL=243 ID=0 DF PROTO=TCP SPT=443 DPT=49144 WINDOW=26847 RES=0x00 ACK SYN URGP=0
Mai 05 12:54:21 debian kernel: iptables:INPUT-DROP IN=wlxf0a7314ab340 OUT= MAC=f0:a7:31:4a:b3:40:42:65:5a:09:14:9f:08:00 SRC=44.196.22.110 DST=192.168.129.5 LEN=60 TOS=0x00 PREC=0x00 TTL=241 ID=0 DF PROTO=TCP SPT=443 DPT=49106 WINDOW=26847 RES=0x00 ACK SYN URGP=0
Mai 05 12:54:21 debian kernel: iptables:INPUT-DROP IN=wlxf0a7314ab340 OUT= MAC=f0:a7:31:4a:b3:40:42:65:5a:09:14:9f:08:00 SRC=44.196.22.110 DST=192.168.129.5 LEN=60 TOS=0x00 PREC=0x00 TTL=243 ID=0 DF PROTO=TCP SPT=443 DPT=49160 WINDOW=26847 RES=0x00 ACK SYN URGP=0
Mai 05 12:54:21 debian kernel: iptables:INPUT-DROP IN=wlxf0a7314ab340 OUT= MAC=f0:a7:31:4a:b3:40:42:65:5a:09:14:9f:08:00 SRC=44.196.22.110 DST=192.168.129.5 LEN=60 TOS=0x00 PREC=0x00 TTL=243 ID=0 DF PROTO=TCP SPT=443 DPT=49124 WINDOW=26847 RES=0x00 ACK SYN URGP=0
Mai 05 12:54:21 debian kernel: iptables:INPUT-DROP IN=wlxf0a7314ab340 OUT= MAC=f0:a7:31:4a:b3:40:42:65:5a:09:14:9f:08:00 SRC=44.196.22.110 DST=192.168.129.5 LEN=60 TOS=0x00 PREC=0x00 TTL=243 ID=0 DF PROTO=TCP SPT=443 DPT=49128 WINDOW=26847 RES=0x00 ACK SYN URGP=0

Problem ist da alle Webseiten werden nicht aufgerufen, außer zb. wie Google oder Amazon.

LG

[Livingston]

Zu den beiden Drops in der OUTPUT-Chain: Hier wird DPT=993 ausgefiltert. Das entspricht dem IMAP/TLS-Protokoll (imaps, verschlüsseltes Mail-Protokoll). Diesen Port hast Du aber nirgendwo erlaubt.
Zu den INPUT-Drops: In allen Fällen entsprechen die DPT's nicht den freigegebenen Ports. Dafür gibt es einen einfachen Grund: Wenn Du z.B. einen Browser startest, der über https quatscht, dann erlaubst Du zwar im Ausgang den Destination-Port 443 (=https) auf dem Server, aber die Rückantwort vom Server zu Deinem Rechner geht an einen zufällig gewählten Port, den Dein Browser ausgewürfelt hat, z.B. hier:

SRC=44.196.22.110 DST=192.168.129.5 LEN=60 TOS=0x00 PREC=0x00 TTL=243 ID=0 DF PROTO=TCP SPT=443 DPT=49112 WINDOW=26847 RES=0x00 ACK SYN URGP=0

Der Server spricht vom Port 443 aus, also https, aber Dein Destination-Port ist 49112. Den hast Du nicht freigegeben, daher wird das Paket gedropt.

NACHTRAG:
Lass Dir mal die iptables-Angaben mit der Option -n ausgeben, dann siehst Du die Portnummern, statt der Protokoll/Service-Angaben:

Code: Alles auswählen

$ iptables -L -v -n

[Apollo013]

Danke vielmals für die Erklärung, das bedeutet ich kann nicht alle Ports schließen und ein paar offen lassen, weil der Browser spielt mit würfeln.
Meine Idee war, dass ich mehr Sicherheit in mein System bringe.

Mit dem IMAP Port habe ich mich noch nicht beschäftigt, darum wollte ich zuerst wissen, warum die Seiten nicht gehen.
Danke für den zweiten Tipp.

Gibt es eine andere Möglichkeit alles dicht machen und nur offen lassen, was man braucht.

LG

[Livingston]

Wenn ich mal raten soll, willst Du einfach einen Desktop-Rechner abdichten
Dann wäre die Frage, was überhaupt offen ist. Bei einer Standardinstallation brauchst Du Dir darüber normalerweise keine Gedanken zu machen, da Du keinen Service anbietest, der von außen zugänglich ist. Wenn, dann rufst Du Daten ab, und Du bekommst eine Antwort, die sich auf Deine Anfrage bezieht. Dein Browser bspw. nimmt nur etwas an, wonach er gefragt hat. Von außen lässt der sich nicht triggern.
Kann bei einem Handy natürlich anders aussehen, falls Du da irgendwelche Spezialitäten installiert hast.

Um sicherzugehen, dass Du wirklich keine offenen Ports hast, rufst Du am Besten mal als root

Code: Alles auswählen

# ss -tulpn

und

Code: Alles auswählen

# ss -tulp

auf.

Das gibt Dir die zu tcp und udp gehörigen offenen (=listen) Verbindungen und zugehörigen prozesse an, einmal mit Portnummern (-n), das andere mal ohne Nummern stattdessen mit Namen des dazugehörigen Services.
Sollte etwas offen sein, dann wahrscheinlich DHCP (in der ss-Auflistung Port 68 bzw. bootpc). Den willst Du bestimmt nicht dichtmachen, sonst wirst Du nicht mehr von Deinem Router mit einer IP-Adresse versorgt. Ebenso Services, die nur auf localhost hören (Local Address 127.xxx.xxx.xxx bzw. ::0). Die können nix von außen annehmen, also brauchst Du auch dafür keine iptables-Regel.
Apropos Router/Modem: Handelsübliche Geräte, die Dich mit dem großen, weiten Internet verknoten, arbeiten normalerweise als natürliche Firewall und lassen ungefragt keine neuen Verbindungen von außen zu.

Beispiel von meinem Arbeitslaptop:

Code: Alles auswählen

# ss -tulp
Netid        State          Recv-Q         Send-Q                 Local Address:Port                   Peer Address:Port        Process                                   
udp          UNCONN         0              0                            0.0.0.0:bootpc                      0.0.0.0:*            users:(("dhclient",pid=601,fd=7))        
tcp          LISTEN         0              128                        127.0.0.1:ipp                         0.0.0.0:*            users:(("cupsd",pid=3162,fd=7))          
tcp          LISTEN         0              128                            [::1]:ipp                            [::]:*            users:(("cupsd",pid=3162,fd=6))

Die oberste Verbindung ist DHCP, die beiden anderen warten auf der Localhost-Adresse auf Druckanfragen. In der letzten Spalte sieht man dann auch die Prozesse, die dafür die Verantwortung übernehmen. Bis auf das theoretische Problem, dass mir jemand zuhause im internen LAN einen bösartigen DHCP-Server unterjubelt, kann hier niemand auf den Laptop von außen zugreifen. DHCP dichtmachen ist keine Option. Wenn ich da iptables drauf loslasse, bekomme ich keine IP-Adresse mehr zugewiesen. Bliebe also nur die Paranoia-Lösung: Die IP manuell zuweisen und dhclient entfernen.

[wanne]

Gibt es eine andere Möglichkeit alles dicht machen und nur offen lassen, was man braucht.

Zuerst mal sind ja Sachen nur offen, wenn du explizit eine Anwendung gestartete hast. Ich denke mir wie Livingston, dass ich Anwendungen von denen ich nicht will, dass sie nicht mit dem Internet kommunizieren gar nicht erst starte.


Aber es gibt schon noch ein paar alternativen:
1. Gewürfelt wird nicht über alle Ports: die in /proc/sys/net/ipv4/ip_local_port_range stehen.
Du kannst also die freigeben:

Code: Alles auswählen

-A OUTPUT -p tcp -m tcp --dport 443 --sport 32768:60999 -j ACCEPT
-A INPUT -p tcp -m tcp --sport 443 --dport 32768:60999 -j ACCEPT

2. Das erste Paket einer Verbinung kommt mit syn ohne Ack. Du kannst also lediglich auf solche Pakete Filtern und alle anderen Durch lassen.

Code: Alles auswählen

-A OUTPUT -p tcp -m tcp --dport 443 --syn -j ACCEPT
-P INPUT ACCEPT

Die nächste Variante wäre mit conntrack Rückpackete wiederzuerkennen.

Wichtig anzumerken: Du willst auf jeden Fall noch DNS durch lassen.

Daneben: Debian übersetzt im Hintergrund eh seit langem nach nftables. Das ist schneller und kann auf Ethernet IPv4 und IPv6 gleichzeitig filtern, was im besten Fall aus drei Regeln eine macht. Daneben ist die Syntax IMHO deutlich angenehmer.
Volles regelset mit SSH https, DNS und dynamischen Ports:

Code: Alles auswählen

flush ruleset
table inet firewall {
  chain OUTPUT {
    type filter hook output priority 0; policy accept;
    tcp sport 32768-60999 dport { ssh, https } accept
    udp dport 53 accept
    icmp accept
    counter reject
  }
  chain INPUT {
    type filter hook input priority 0; policy drop;
    tcp dport 32768-60999 sport { ssh, https } accept
    udp sport 53 accept
    icmp accept
    counter reject
  }
}

Stattdessen mit SYN

Code: Alles auswählen

flush ruleset
table inet firewall {
  chain OUTPUT {
    type filter hook output priority 0; policy accept;
    tcp dport { ssh, https } flags syn / fin,syn,rst,ack accept
    tcp flags syn / fin,syn,rst,ack reject
  }
  chain INPUT {
    type filter hook input priority 0; policy accept;
    flags syn / fin,syn,rst,ack reject
  }
}

[Apollo013]

Danke für die Hilfe wanne,

also es ist besser nft zu benutzen statt iptables?

Wie ich schon oben erwähnt habe, wollte ich gezielt die Ports filtern, egal ob die geschlossen sind oder nicht und auf diesen offenen Ports ein Tcpdump laufen lassen.

Ja, das ist paranoid, aber aufgrund, dass ein Mord ausgeübt wurde gegen meine Person, ist es so
und es ist gutes Lernmaterial für mich.

LG

[mat6937]

Debian übersetzt im Hintergrund eh seit langem nach nftables.

BTW: Schön wärs. Mit z. B.:

Code: Alles auswählen

IPMasquerade=yes

in einer *.network-Datei (für systemd-networkd) generiert systemd, leider nur eine iptables-legacy-Regel.

Code: Alles auswählen

:~# iptables-legacy -nvx -L -t nat      

Chain POSTROUTING (policy ACCEPT 15371 packets, 1559532 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
  441651 37098612 MASQUERADE  all  --  *      *       192.168.111.0/24      0.0.0.0/

xtables-legacy — iptables using old getsockopt/setsockopt-based kernel api

It is also important to note that while iptables-nft can supplant iptables-legacy, you should never use them simultaneously.

Quelle: https://developers.redhat.com/blog/2020 ... h-nftables#

[cosinus]

Gibt es eine andere Möglichkeit alles dicht machen und nur offen lassen, was man braucht.

Nur eingehend, also "versehentlich" offene Serverdienste abschotten bzw, nur von bestimmten Adressen erreichbar machen? Wenn ja, schau dir mal dieses Beispiel/Grundgerüst an, welches ich für iptables-persistent nutze. Mit Beispielen wie man Ports öffnet; bitte IPv6 dann nicht vergessen!

IPv4 in /etc/iptables/rules.v4

Code: Alles auswählen

*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT ACCEPT
-A INPUT -j ACCEPT -i lo
-A INPUT -j ACCEPT -p icmp
-A INPUT -j ACCEPT -m conntrack --ctstate RELATED,ESTABLISHED
### TCP-Ports 80 und 443 für alle öffnen
-A INPUT -j ACCEPT -p tcp -m multiport --dports 22,80,443
### TCP-Ports 110, 135, 445 für ein bestimmtes Subnetz öffnen
-A INPUT -j ACCEPT -s 192.168.1.0/24 -p tcp -m multiport --dports 110,135,445
COMMIT

IPv6 in /etc/iptables/rules.v6

Code: Alles auswählen

*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT ACCEPT
-A INPUT -j ACCEPT -i lo
-A INPUT -j ACCEPT -p ipv6-icmp
-A INPUT -j ACCEPT -m conntrack --ctstate RELATED,ESTABLISHED
### TCP-Ports 80 und 443 für alle öffnen
-A INPUT -j ACCEPT -p tcp -m multiport --dports 22,80,443
### TCP-Ports 110, 135, 445 für ein bestimmtes Subnetz öffnen
-A INPUT -j ACCEPT -s 2003::/19 -p tcp -m multiport --dports 110,135,445
COMMIT

[Livingston]

also es ist besser nft zu benutzen statt iptables?

Praktisch betrachtet: Wenn Du das Ganze neu lernst, würde ich keinen alten Gaul reiten, sondern gleich mir das neue Konzept anfüttern.
Das gute, alte iptables tut's natürlich noch immer. Selbst die nft-Entwickler sagen, dass es immer noch ein grundsolides Paket ist, das aber inzwischen bei komplexen Konfigurationen manches zu wünschen übrig lässt.

Ich habe immer noch nicht verstanden, was Du grundsätzlich lösen möchtest. Wenn Du Zugänge mit ACCEPT-Regeln erlaubst, die Du ohnehin geöffnet hast, erreichst Du nichts neues, und wenn Du Dinge sperrst, die gar nicht als Dienst laufen, passiert effektiv auch nix.

Filterregeln machen eigentlich nur dann einen Sinn, wenn Du Zugänge einschränken oder explizit erlauben willst. Wenn Du z.B. eine Liste mit IP-Adressen hast, die Deinen Server mit permanenten Anfragen nerven und Du gezielt diese IPs blocken möchtest - oder Du willst verschiedene lokale Netze trennen, oder...
Kurz und gut: Nur in den seltensten Fällen erteilt man pauschal ein ACCEPT (oder DROP) sondern definiert Regeln, was einzelne Rechner, Subnetze, externe Adressen dürfen oder nicht dürfen.

[Apollo013]

Also ich habe das Script angepasst, dass er mir auch die IP-Adresse abfragt und herein schreibt.
Ist nur vorläufig, bis ich herausfinde, welche Ports ich nicht brauche.

#!/bin/bash

# Überprüfen, ob das Skript mit Root-Rechten ausgeführt wird
if [ "$EUID" -ne 0 ]; then
echo "Bitte führen Sie dieses Skript als Root aus."
exit 1
fi

# IP-Adresse des iPads ermitteln
ip_addr=$(ip addr show | grep inet | grep -v 127.0.0.1 | awk ' NR==2 {print $2}')

# Neue Regel erstellen
new_rule="*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT ACCEPT
-A INPUT -j ACCEPT -i lo
-A INPUT -j ACCEPT -p icmp
-A INPUT -j ACCEPT -m conntrack --ctstate RELATED,ESTABLISHED
### TCP-Ports 80 und 443 für alle öffnen
-A INPUT -j ACCEPT -p tcp -m multiport --dports 22,80,443
### TCP-Ports 110, 135, 445 für ein bestimmtes Subnetz öffnen
-A INPUT -j ACCEPT -s $ip_addr -p tcp -m multiport --dports 110,135,445
COMMIT"

# Die neue Regel in die Datei schreiben
echo "$new_rule" > /etc/iptables/rules.v4

# Berechtigungen für die Datei setzen
chmod 600 /etc/iptables/rules.v4

echo "Die Firewall-Regeln wurden erfolgreich aktualisiert."

Jetzt muss ich nur hinbekommen, dass der Script nach der Anmeldung startet.

Danke für die Tipps!

LG

[cosinus]

Filterregeln machen eigentlich nur dann einen Sinn, wenn Du Zugänge einschränken oder explizit erlauben willst.

Hm, wäre für sowas nicht fail2ban besser? Das wertet doch fehlgeschlagene Logins aus und macht dann bei zu vielen Fehlversuchen automatisch die Regeln für iptables.

[Livingston]

Filterregeln machen eigentlich nur dann einen Sinn, wenn Du Zugänge einschränken oder explizit erlauben willst.

Hm, wäre für sowas nicht fail2ban besser? Das wertet doch fehlgeschlagene Logins aus und macht dann bei zu vielen Fehlversuchen automatisch die Regeln für iptables.

Ja, ein schönes Tool, benutze ich auch gerne. Und nicht vergessen: Eine Firewall ist letztlich immer ein Konzept und kein einzelnes Werkzeug.

Um sich Übersicht zu verschaffen kann man iptables übrigens auch zählen und loggen lassen oder die Zugriffe pro Zeiteinheit von einer/mehreren IPs beschränken lassen. Führt hier jetzt wohl zu weit, aber wir haben hier 'ne Menge Threads zu diesen Themen. Einfach mal die Forensuche anschmeißen.

[cosinus]

Und nicht vergessen: Eine Firewall ist letztlich immer ein Konzept und kein einzelnes Werkzeug.

Ja, ich hab iptables auch nicht als "Firewall" bezeichnet. Ich weiß ja, dass das nur ein Paketfilter ist.
Laien können damit aber rel. wenig anfangen, für die ist "Firewall" gleichbedeutend mit "Paketfilter". Und ein Hacker ist eine böse Person, obwohl in IT-Kreisen jeder weiß: hacker = whitehat = gut und cracker = blackhat = böse

[Apollo013]

Ist für nicht Neuland, bis jetzt weigerte ich mich ein Blick auf Iptables zu werfen.
Aber macht Spaß und ist sehr umfangreich. Muss mich noch mit der Materie mehr auseinandersetzten.

Fail2Ban hatte ich auf meinen Server, sehr nützliches Werkzeug.

Ist ja auch für mich eine Beschäftigungstherapie


LG

[Livingston]

Ist ja auch für mich eine Beschäftigungstherapie

Da sagst Du was... Je mehr man ins Detail geht, umso spannender wird's. Es ist sehr hilfreich, wenn man sich mal die verschiedenen Schichten des TCP/IP-Schemas zu Gemüte führt. Man kann dadurch viel genauer eingrenzen, was überhaupt eine Bedrohung sein kann und was nicht.
Umgekehrt ist es eine Herausforderung, vermeintlich ungefährliche Dinge als Störenfriede zu erkennen, z.B. IoT -> Internet of Things: Irgendwelche "Dinge" (Toaster, Waschmaschine) scannen im Auftrag der Hersteller Dein heimisches LAN und telefonieren munter nach Hause. (Sowas klärt man übrigens nicht (nur) durch Verschlüsselung des internen Verkehrs und softwaremäßiges Blocken sondern vor allem dadurch, dass man "Dingen" ein eigenes physisches Subnetz/Verkabelung verpasst.)

Viel Spaß beim Forschen

[wanne]

also es ist besser nft zu benutzen statt iptables?

Ich würde sagen ja. Wie gesagt. Wenn man nicht explizit iptables-legacy nutzt, konvertiert Debian sowieso automatisch nach nftables. Direkt nutzen spart da ein potentielles Komplikationslayer[/quote]

[Apollo013]

Ich habe in die Iptables Logs eingebunden,

-A INPUT -j LOG --log-level 1 --log-prefix "Incoming-traffic: "
-A OUTPUT -j LOG --log-level 1 --log-prefix "Outgoing-traffic: "

Die Ausgabe zeigt, dass Input keine Logs aufzeichnet.

0 0 LOG 0 -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 1 prefix "Incoming-traffic: "
363 50892 LOG 0 -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 1 prefix "Outgoing-traffic: "

Ich frage mich, warum?

LG

[Livingston]

Hast Du die INPUT-Log-Regel vielleicht hinter die anderen INPUT-Regeln gereiht, so dass die LOG-Regel gar nicht mehr erreicht wird?

[Apollo013]

Danke

Habe geglaubt das es nicht funktioniert, aber muss ich zugeben das nach einiger Zeit habe ich ein Traffic.
Vielleicht habe ich was umgestellt.

Zurzeit schaut es so aus

18 898 LOG 0 -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 1 prefix "Incoming-traffic: "
229 39706 LOG 0 -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 1 prefix "Outgoing-traffic: "

Ebenfalls wundert mich auch das so ein großer Unterschied ist.

LG