Firewall vor Root Servern?

  • Hallo Netcup Team,


    wir haben einen Root Server (RS 1000) den wir u.A. für Netzwerkprotokolltests einsetzen.

    Dabei haben wir beobachtet, dass uns diverse IPv6 Pakete nicht erreichen.


    Handelsübliche TCP/UDP/ICMP Kommunikation über IPv6 geht problemlos, darunter HTTP/HTTPS/SSH.
    SCTP über IPv6 kommt aber schon nicht bei unserem Server an.

    Wir haben dann mittels scapy ein Script geschrieben um das näher zu untersuchen.

    Das Script sendet wahlweise IPv4/IPv6 Pakete und geht dabei jeweils alle 256 Protokollheader durch.
    Der Inhalt der jeweiligen Pakete ist Schrott, klar!


    Wir haben von unterschiedlichen Systemen externe ISPs (UM, Telekom, DFN) Pakete geschickt und auf dem Server mit tcpdump mitgelesen.
    Unsere Beobachtung:

    • Über IPv4 kommt alles an, wie gewünscht.
    • Über IPv6 kommen nur valide ICMP/UDP/TCP Pakete an
    • ESP über IPv6 geht auch mit Schrott


    Daher unsere Frage:
    Wird seitens netcup irgendeine Layer-3 Paketfilterung durchgeführt?


    VG



  • Nein, der RS hat keine Firewall, bis auf ein gehärteter sshd läuft da kein Service drauf.

    Aber auch mit Firewall sollte das keine Hürde sein: tcpdump greift die Pakete - Sonderfälle mal ausgenommen - via libpcap vor der Firewall ab.


    Die sinnlosen Pakete kommen über IPv4 an, nur über IPv6 nicht.

    Das Standardverhalten für "schrottige" Pakete sollte eine ICMP Nachricht an den Sender sein.

    Aber eben vom Empfänger, außer es gibt eine Layer-3 Filterung auf dem Weg.


    Zum selbst probieren:

    Auf dem Server tcpdump laufen lassen und auf SCTP filtern: tcpdump -i vtnet0 sctp

    Von einem anderen Client (getestet mit Linux / FreeBSD) eine SCTP Verbindung aufbauen: ncat --sctp -4 example.com 80 bzw. für IPv6 ncat --sctp -6 example.com 80

    ncat wird mit dem nmap Paket mitgeliefert (getestet mit apt/Ubuntu und pkg/FreeBSD).


    Unsere Beobachtung:

    • Bei IPv4 erreicht den Server ein INIT
    • Bei IPv6 kommt nichts an


    VG

  • Ich habe das mal bei mir jetzt auch getestet.

    IPv4 Protos, die ich nicht im tcpdump gesehen habe:

    • 1
    • 6
    • 17
    • 47

    Das kann aber nun auch an anderen Stellen liegen.

    Die Beobachtung, dass bei IPv6 nur Proto 6, 17 und 50 durchgehen – zumindest nicht mehr, mit dem obigen Skript.

  • Habe die

    Zum selbst probieren: [..]

    Bei mir kommen die IPv4 Pakete beim Empfänger an, mit IPv6 erhalte ich beim Versender bereits einen connection timeout. Pingbar ist der Empfänger über IPv6 aber. Sieht irgendwie schon komisch aus, dass ich sowohl bei IPv4 als auch IPv6 einen Fehler angezeigt bekomme, aber IPv4 trotzdem durchgeht.

    Code
    root@blueberry:~# ncat --sctp -4 nc1.host.xxxxxxx.com 80
    Ncat: Protocol not available.                                                                                                                                             
    root@blueberry:~# ncat --sctp -6 nc1.host.xxxxxxx.com 80
    Ncat: Connection timed out.                                                                                                                                               
    root@blueberry:~# ping6 nc1.host.xxxxxxx.com                                                                                                                         
    PING nc1.host.xxxxxxx.com(nc1.host.xxxxxxx.com (2a03:xxxxxxx::1)) 56 data bytes                                                                             
    64 bytes from nc1.host.xxxxxxx.com (2a03:xxxxxxx::1): icmp_seq=1 ttl=63 time=0.360 ms                                                                            
    64 bytes from nc1.host.xxxxxxx.com (2a03:xxxxxxx::1): icmp_seq=2 ttl=63 time=0.389 ms
  • janxb: Du siehst genau das gleiche "Problem" wie ich.

    Wenn auf dem Empfänger kein SCTP Protokoll aktiviert ist, dann stimmt die Meldung.
    Ncat: Protocol not available. heißt: Der Empfänger versteht das Protokoll (SCTP) nicht.

    In tcpdump/Wireshark solltest du eine ICMP Nachricht vom Empfänger mit genau der Fehlermeldung sehen.


    Wenn du auf dem Empfänger (ich nehme an Linux) das SCTP Kernel Modul lädst sudo modprobe sctp, dann sollte ncat mit Ncat: Connection refused. reagieren: Empfänger spricht SCTP, hat aber auf dem Port keinen Dienst.


    Die IPv4 Verbindung verhält sich völlig korrekt.


    Die IPv6 Verbindung sollte allerdings genauso wie die IPv4 reagieren.
    Der Timeout lässt darauf schließen, dass auch bei dir SCTP über IPv6 nicht durchkommt....

  • weinrank Das hier ist primär ein "Kunden helfen Kunden" Forum. Du solltest Dich mit Deinen Beobachtungen eventuell einmal per Mail an den Support wenden, sinnvollerweise mit Verweis auf diesen Forenthread.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • KB19

    Habe ich bereits versucht, jeweils mit Standardphrasen als Antwort...daher war dieses Forum mein Versuch.


    Ein zweiter Anlauf mit etwas mehr Fokus auf "IHR habt da ein Problem!", Antwort:



    Schade, mein bisher sehr positiver Eindruck von Netcup bekommt gerade Dämpfer...

  • Es gibt natürlich Filter, siehe DDos-Schutz. Aber ob die hier eingreifen würden?

    Da könnte man ggf. mit einem zweiten Server testen. Der DDOS-Schutz wird ja eher weniger zwischen den Hostsystemen greifen, sondern an den Routern an der AS Grenze (oder davor im Backbone).

  • Ja, ich habe das eben zwischen zwei Servern bei netcup getestet… Firewall aus und einfach mal mit

    Code
    pkt = IPv6(dst='…')/'Random String'
    pkt.nh # == 59 (no next header)

    ein Paket zwischen den Server versucht auch zu tauschen. Es ging auf dem sendenden laut tcpdump raus, beim Empfänger kam nichts an.

    The value 59 in the Next Header field of an IPv6 header or any extension header indicates that there is nothing following that header. If the Payload Length field of the IPv6 header indicates the presence of octets past the end of a header whose Next Header field contains 59, those octets must be ignored and passed on unchanged if the packet is forwarded.


    Es sollte also ohne Probleme beim Ziel ankommen - selbst netcup intern mag es aber nicht…

  • Post mortem:

    Der Support hat bestätigt, dass bestimmte Protokolle über IPv6 gefiltert werden.

    Meine gewünschten Protokolle wurden (für mich?) freigeschaltet.
    Für mich ist das Thema damit erledigt! :thumbup: