Mehrschichtiges Netzwerk - Wie sicher ist das?

  • ..., 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).

  • 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
    1. iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset # TCP = tcp-reset
    2. 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.

  • 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
    1. 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).

  • 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/v…18&t=167623&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).