KVM / iptables

  • Einen wunderschönen guten Tag,


    ich habe aktuell einen Root-Server auf KVM Basis (sind ja alle) und eine zweite ipv4 Adresse erhalten:



    In der /etc/Network/Interfaces ist es wie folgt definiert:



    Wenn ich jetzt beide IP-Adressen mit NMAP scanne, dann ist bei der ursprünglich zugewiesenen IP-Adresse (eth0) alles dicht, bei der zusätzlichen IP-Adresse (eth0:1) zeigt er mir mehrere offenen Ports an.
    Hier einmal meine iptables Konfiguration:



    Ich komme leider aktuell nicht mehr weiter, stehe Gedanklich ein wenig auf der Leitung. Warum zeigt mit nmap 37.120.183.x mit offenen Ports und 188.68.49.x nur mit den freigegebenen Ports an? Wenn ich das richtig verstanden habe, ist eth0:1 nur eine virtuelle Netzwerkkarte. Muss ich diesbezüglich in iptables anders rangehen?


    Grüße

  • Welche offenen Porst?
    Leider ist das ganze extrem schlechte zu lesen.
    Werfe mal die Ausgabe von
    iptables -L -n -v --line-numbers hier rein :)
    PS: Das state Modul ist schon etwas angestaubt, aktueller ist conntrack.

  • Mit nmap 7.0 (nmap -p 1-65535 -T4 -A -v 37.120.183.x) unter Windows 10 erhalte ich folgende Ausgabe:


    Code
    [...]Scanning 37.120.183.x [65535 ports]
    Discovered open port 80/tcp on 37.120.183.x
    Discovered open port 21/tcp on 37.120.183.x
    Discovered open port 443/tcp on 37.120.183.x
    Discovered open port 8080/tcp on 37.120.183.x[...]


    Allerdings mit nmap 6.40 von einem vServer erhalte ich ein ganz anderes Bild, welches auch viel detaillierter ist und auch dem entspricht was ich in den iptables definiert habe:



    Jetzt bin ich wirklich überfragt. Liegt es vielleicht daran, dass ich mit Windows über WLAN den nmap Scan starte?

  • Was man jetzt schön sieht, ist das du das connection tracking egal ob mit der alten oder neuen Version nicht durchgängig durchziehst.
    Wenn dann sollte man es überall durchziehen.
    z.B. so:

  • Das prüfe ich doch allerdings direkt am Anfang:


    Code
    2 2617  283K ACCEPT all  --  eth0   *   0.0.0.0/0    	0.0.0.0/0    	state RELATED,ESTABLISHED
    3	144 DROP   tcp  --  eth0   *   0.0.0.0/0    	0.0.0.0/0    	tcp flags:!0x17/0x02 state NEW
    4   26  1196 MYDROP all  --  eth0   *   0.0.0.0/0    	0.0.0.0/0    	state INVALID
    5	0 0 ACCEPT all  --  eth0:1 *   0.0.0.0/0    	0.0.0.0/0    	state RELATED,ESTABLISHED
    6	0 0 DROP   tcp  --  eth0:1 *   0.0.0.0/0    	0.0.0.0/0    	tcp flags:!0x17/0x02 state NEW
    7	0 0 MYDROP all  --  eth0:1 *   0.0.0.0/0    	0.0.0.0/0    	state INVALID
    8	0 0 MYDROP all  --  *  *   0.0.0.0/0    	0.0.0.0/0    	state INVALID


    Eigentlich sollte doch hier erst einmal jede Verbindung durch müssen, damit nachfolgende Regeln greifen.


    Wie sieht den der iptables Befehl für Dein Beispiel aus?

  • state RELATED,ESTABLISHED wird aber nur ausgewertet wenn die ganze Verbindung über das connection trakinng gemacht wird.
    Sprich an der Stelle wo du die neue Verbindung zuläßgt muss auch das "CT" davon erfahren-
    bzsp:
    -A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport PORT ... -j ACCEPT
    sonst nutzt dir das ganze :
    -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
    nix

  • Ich habe mir das ganze nochmal angeschaut und bitte verbessert mich wenn ich falsch liege. Jetzt einmal abgesehen von state oder conntrack, der Aufbau ist der gleiche, steht bei mir die Stateful Inspection oben. D.h. eine Verbindung wird nur zugelassen wenn diese Established oder Related ist, also keine New.


    Wenn ich also, z.B. ssh Aufbaue und keine aktive Verbindung habe, dann trifft diese Regel nicht zu und es wird an zur ssh Rule gesprungen, die dann ja nur den Status New haben kann, andernfalls würde ja Established/Related zum tragen kommen. Daher muss ich hier gar nicht mit state/conntrack arbeiten, da es nichts anderes, wie bereits erwähnt, sein kann als New. Folglich kann ich bei jeden neuen Rule mit dem Status arbeiten muss es aber nicht?


    Grüße

  • Lass dich bloß nicht verwirren. Ob du state/--state oder conntrack/--ctstate verwendest, ist hier unerheblich. Das Connection-Tracking kannst du in INPUT auch nicht beeinflussen, denn die Pakete durchlaufen bereits vor der INPUT-Kette der Standardtabelle filter das Connection-Tracking (https://upload.wikimedia.org/w…Netfilter-packet-flow.svg); das Connection-Tracking lässt sich nur in der Tabelle raw mit "-j NOTRACK" oder "-j CT --notrack" abschalten.


    Also im Moment sehe ich keinen Fehler in deinen Filterregeln, der einen Zugriff auf Port 21 oder 8080 erlauben würde. In deiner 15. INPUT-Regel steht sogar, dass 8 an Port 21 gerichtete Pakete verworfen wurden!


    Ich würde in INPUT alle ACCEPT-Ziele durch MYACCEPT und DROP durch MYDROP ersetzen und mir nach dem Nmap-Scan syslog ansehen.



    Was mir aufgefallen ist:
    1.) RELATED kann Nebenwirkungen haben. Deshalb steht bei mir

    Code
    iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
    iptables -A INPUT -p icmp -m icmp --icmp-type 0 -m conntrack --ctstate RELATED -j ACCEPT
    iptables -A INPUT -p icmp -m icmp --icmp-type 3 -m conntrack --ctstate RELATED -j ACCEPT
    iptables -A INPUT -p icmp -m icmp --icmp-type 11 -m conntrack --ctstate RELATED -j ACCEPT
    iptables -A INPUT -p icmp -m icmp --icmp-type 12 -m conntrack --ctstate RELATED -j ACCEPT


    2.) Damit "#Antispoofing" nicht das Connection-Tracking belastet, entsorge ich die Pakete mit zu offensichtlich gefälschtem Absender in der Kette PREROUTING der Tabelle raw.

    Code
    iptables -t raw -A PREROUTING -i lo -j ACCEPT
    iptables -t raw -A PREROUTING -s 127.0.0.0/8 -j DROP
    iptables -t raw -A PREROUTING -s 0.0.0.0/8 -j DROP
    iptables -t raw -A PREROUTING -s 10.0.0.0/8 -j DROP
    iptables -t raw -A PREROUTING -s 172.16.0.0/12 -j DROP
    iptables -t raw -A PREROUTING -s 192.168.0.0/16 -j DROP
    iptables -t raw -A PREROUTING -s 224.0.0.0/3 -j DROP


    PREROUTING ist ein geeigneter Ort für die Entsorgung von unerwünschten Paketen. Die Hashtabelle des Connection-Trackings wird entlastet, wodurch die Wahrscheinlichkeit für "table full, dropping packet" sinkt. Vorschlag:

    Code
    iptables -t raw -A PREROUTING -p tcp -d 188.68.49.x --dport 8443 -j ACCEPT
    iptables -t raw -A PREROUTING -p tcp -d 188.68.49.x --dport 8447 -j ACCEPT
    iptables -t raw -A PREROUTING -p tcp -d 188.68.49.x --dport 22 -j ACCEPT
    iptables -t raw -A PREROUTING -p tcp -d 37.120.183.x --dport 80 -j ACCEPT
    iptables -t raw -A PREROUTING -p tcp -d 37.120.183.x --dport 443 -j ACCEPT
    iptables -t raw -A PREROUTING -p tcp --tcp-flags SYN,ACK,FIN,RST SYN -j DROP


    3.) "eth0:1" ist ein Alias für "eth0". Die drei "-i eth0:1"-Regeln in INPUT sind überflüssig.