Mehrschichtiges Netzwerk - Wie sicher ist das?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • ..., habe ich heute morgen festgestellt, dass verbindungsaufbauende Programme in einen Timeout laufen, weil sie bei DROP nicht unterscheiden können, ob das Paket einfach nur verloren gegangen ist oder obs tatsächlich gedropt wurde. Es wurde permanent weiter versucht, die Verbindung doch noch zu etablieren. ...

    Ja. Ich benutze DROP nur in der INPUT chain und dort auch nur für Verbindungen aus dem Internet. Die "Portscanner" im bzw. aus dem Internet geben i. d. R. ziemlich schnell auf (... wenn keine Antwort kommt).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ja. Ich benutze DROP nur in der INPUT chain und dort auch nur für Verbindungen aus dem Internet. Die "Portscanner" im bzw. aus dem Internet geben i. d. R. ziemlich schnell auf (... wenn keine Antwort kommt).

    So hatte ich das vorher auch... und genau da habe ich das jetzt geändert.... was meiner Meinung nach dem obigen Testergebnis (siehe 62002/tcp closed unknown) tatsächlich die bessere Einstellung ist.

    Code
    iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset              # TCP = tcp-reset
    iptables -A INPUT -j REJECT                                             # ALL = icmp6-port-unreachable

    Faktisch habe ich damit meine DROP-Policies "ausgehebelt"... aber ich lass den DROP dort trotzdem bestehen... nutzen tun'se nix mehr, schaden aber auch nicht.

  • .... was meiner Meinung nach dem obigen Testergebnis (siehe 62002/tcp closed unknown) tatsächlich die bessere Einstellung ist

    Bessere Einstellung, ... für fremde/unbekannte verbindungsaufbauende Programme/Dienste/Portscanner/etc.? ... die nicht in ein Timeout laufen sollen?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Tja... :conf: .... das ist jetzt ne andere Sichtweise.... kann man so sehen. Wobei ich davon ausgehe, dass nicht irgend so'n Typ davor sitzt und wartet, sondern das da autonom gescannt wird.. und dem Bot isses egal, wie lange er wartet... er erzeugt nur Traffic in meinem Netz, was ich vielleicht mit dem TCP-RESET abwürgen kann.

    Ist letztendlich aber auch egal... ich glaube, dass ist ein Punkt, den man nicht wirklich diskutieren kann, weil da eine eigene subjektive Sichtweise einfliesst. Beides geht, richtig falsch ist imho keins von beiden.... also.. was solls...

  • ..., sondern das da autonom gescannt wird.. und dem Bot isses egal, wie lange er wartet... er erzeugt nur Traffic in meinem Netz, ...

    Doch das kann man z. B. auf einem border device sehen, mit:

    Code
    sudo tcpdump -vvveni <WAN-Interface> portrange 0-65535 and 'tcp[tcpflags] & (tcp-syn) != 0'

    Auch bei der Verwendung von DROP (d. h. ignorieren bzw. nicht antworten), wird kein zusätzlicher TCP-Traffic erzeugt (im Vergleich zu REJECT).

    BTW: Der TCP-Port der hier z. Zt. am häufigsten über das Internet gescannt wird, ist 23 (telnet).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Das bedeutet imho nur, dass tcpdump das Paket nicht sieht, aber nicht, dass das Paket nicht ankommt ... weils bei mir nämlich permanent gesendet wurde. Ich weiss nicht, ob tcpdump die Pakete schon vor dem Netfilter sieht, oder erst hinterher..... aber wenn sie gesendet werden, müssen sie auch ankommen. Wie gesagt, bei DROP kann der "Sender" nicht zwischen DROP und verlorengegangen unterscheiden... also sendet er noch mal... infolgedessen kommen sie auch wieder an. Bei REJECT haben alle Sende-Versuche sofort aufgehört. Für mich hat sich das also vollkommen anders dargestellt.

    BTW: Der TCP-Port der hier z. Zt. am häufigsten über das Internet gescannt wird, ist 23 (telnet).

    Um das festzustellen, müsste der Port ja im Router geforwarded sein... was er bei mir nicht ist. Insofern kriege ich das gar nicht mit.

  • Ich weiss nicht, ob tcpdump die Pakete schon vor dem Netfilter sieht, oder erst hinterher..... ... Wie gesagt, bei DROP kann der "Sender" nicht zwischen DROP und verlorengegangen unterscheiden... also sendet er noch mal... infolgedessen kommen sie auch wieder an....

    Betr. Reihenfolge, siehe z. B.: https://debianforum.de/forum/viewtopi…3&hilit=tcpdump


    Ob der "Sender" verloren gegangene Pakete erneut sendet, ist vom Dienst/Client abhängig. Bei einem Portscan ist das fast nie der Fall. Ein WEB-Browser z. B., der wird erneut senden.

    EDIT:

    BTW: Wenn ich meine providereigene-FritzBox (mit _nicht_ modifizierter Firmware und als "border device") aus dem Internet (d. h. von einem fremden Internetanschluss) mit dem syn-Flag scanne, bekomme ich auch keine Antwort (rst+ack) von dieser. Eine Ausnahme gibt es beim TCP-Port 113. Von dort kommt auf den Portscan mit dem syn-Flag, eine Antwort mit dem rst+ack-Flag (... aber auch nur deshalb, weil die FritzBox z. Zt. nicht für "stealth" konfiguriert ist).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (13. Februar 2018 um 12:42)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!