Wie laufen DoS-Attacken technisch ab?

[TomL]

Vor einigen Tagen gabs den Thread Virenschutz unter Linux, in dem Novalix die Notwendigkeit von fail2ban herausgestellt hat. Jetzt gibt es einen zweiten Thread, in dem von DoS-Angriffen gesprochen wird.

Mich beschäftigt das Thema auch, weniger aus Betroffenheit, sondern viel mehr aus Interesse daran, die Zusammenhänge zu verstehen und wie man damit umgehen kann, wenn sowas passiert.

Novalix sagt, dass man auf TCP-Ebene da nichts gegen ausrichten kann und man den Prozess selber monitoren muss. Ich kann das nicht widerlegen, und ich verstehe das auch noch nicht wirklich. Bei mir gibts momentan nur den einzigen relevanten nach außen geöffneten Prozess "openvpn", der also gemonitored werden müsste... und spannenderweise läuft dieser Prozess bei mir auch noch auf dem neuralgischen Port 443, auf dem obligatorisch immer was los ist.

Und genau da beginnt mein Unverständnis. Es gibt in dem überwachten Prozess keine Auffälligkeiten, auf die beispielsweise fail2ban überhaupt reagieren könnte. Das gleiche wäre meiner Meinung nach der Fall, wenn ich den Mailserver nach außen öffen würde. Es ist ja nicht so, dass bei mir nix passiert, im Gegenteil, ich habe da täglich mehr oder weniger hartnäckige Kandidaten, siehe Listing unten. Die unten gelistete IP 184.154.189.90 steht allerdings genau ein einziges Mal im Openvpn-Log, welches ja überwacht werden müsste - das hier gezeigte Listing kommt nämlich vom Paketfilter. Der Filter-Effekt ist hier, Folge-Pakete der gleichen IP kommen gar nicht erst bis zum Service durch, fail2ban würde hier also nie reagieren können, weil eine IP bereits beim 2. TCP-Paket sofort dynamisch gesperrt wird und weil es deshalb im Log gar nicht erst zu Auffälligkeiten käme, auf die fail2ban überhaupt reagieren könnte.

Meine eigentliche Frage ist, was passiert also bei einer solche Attacke? Bisher bin ich davon ausgegangen, dass sehr viele Verbindungsversuche von einer IP oder einer bestimmten Anzahl von IP ständig wiederholt versucht werden. Aber bei genau solchen Attacken kann hier auf meinem System wirklich nur das erste Paket beim eigentlichen Service ankommen, von allen anderen Paketen sieht der Service tatsächlich gar nix, weil die vorher schon gedropt werden ... und in Folge würde auch fail2ban nix davon sehen. Deshalb nicht, weil mein Paketfilter das schon vorher dynamisch im Sinne einer Stateful-Firewall selber handhabt. Das heisst, in den Logs meines Openvpn-Prozesses, also die eigentliche Quelle für fail2ban, steht jede IP mit einem Verbindungs-Fehlversuch genau ein einzige Mal drin. Es gibt dort keine zweiten oder dritten aufgelisteten Fehlversuche,, wegen derer sich fail2ban zum Handeln aufgefordert fühlen könnte. Bei meinem Mailserver wäre das imho auch nicht anders.....

Und jetzt frag ich mich, wo ist da mein Gedankenfehler? Was passiert wirklich bei einer DoS-Attacke...?... anscheinend gehe ich hier von falschen Voraussetzungen aus?

Code: Alles auswählen

Journal last 24h:
Mai 07 11:38:31 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:32 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:34 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:37 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:38 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:40 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:42 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:43 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:45 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:48 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:49 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:51 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:54 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:55 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:38:57 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:39:00 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:39:01 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:39:03 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:39:06 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:39:07 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 11:39:09 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=184.154.189.90 
Mai 07 13:02:40 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=62.4.15.163 
Mai 07 13:02:46 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=62.4.15.163 

[mat6937]

Novalix sagt, dass man auf TCP-Ebene da nichts gegen ausrichten kann und man den Prozess selber monitoren muss. Ich kann das nicht widerlegen, und ich verstehe das auch noch nicht wirklich. Bei mir gibts momentan nur den einzigen relevanten nach außen geöffneten Prozess "openvpn", der also gemonitored werden müsste... und spannenderweise läuft dieser Prozess bei mir auch noch auf dem neuralgischen Port 443, auf dem obligatorisch immer was los ist.

..., weil mein Paketfilter das schon vorher dynamisch im Sinne einer Stateful-Firewall selber handhabt.

Benutzt Du für OpenVPN UDP oder TCP?

[TomL]

Benutzt Du für OpenVPN UDP oder TCP?

Beides... in dem Sinne, dass für beide Protokolle ein eigener Daemon läuft. Primär wird von unterwegs UDP auf einem hohen Port > 55000 genutzt. TCP auf Port 443 ist als Fallback gedacht, wenn ein übereifriger Open-AP-Admin mal wieder pauschal UDP gesperrt hat. Auf UDP kommen hier überhaupt keine Attacken an, auf TCP hingegen täglich unzählige.

[mat6937]

..., auf TCP hingegen täglich unzählige.

Ich denke der beste Schutz gegen DoS-Attacken ist nicht aufzufallen, d. h. IP-Adresse und lauschender TCP-Port zu "verstecken". Wenn das nicht (immer) möglich ist, sollte man m. E. sein System so konfigurieren, dass der DoS-Angriff nicht einen übermäßigen Ressourcenverbrauch (CPU, Speicher, Firewall, ...) zur Folge hat.

[TomL]

Wenn das nicht (immer) möglich ist, sollte man m. E. sein System so konfigurieren, dass der DoS-Angriff nicht einen übermäßigen Ressourcenverbrauch (CPU, Speicher, Firewall, ...) zur Folge hat.

Ja, dem kann ich folgen. Aber was mich mal mehr interessiert, was charakterisiert überhaupt eine Attacke, was unterscheidet die Attacke von einem legalen Zugriff. Mir ist schon klar, der legale Zugriff mündet schließlich in der Akzeptanz der Verbindungsaufnahme durch den Dienst, das heisst irgendeine Art des Logins war erfolgreich.... was ja bei der Attacke nicht passiert. Aber ein einzelner abgewiesener Verbindungsversuch ist ja noch keine Attacke.

Und an dem Punkt habe ich das Verständnis, dass 'derjenige' mit der Abweisung nicht einverstanden ist und es sofort wieder versuchen wird, und das dann immer und immer und immer wieder.... schließlich ist er ja ein Angreifer und diese wiederholten Versuche werden eben erst durch deren Anzahl zur wirklich Attacke. Ein andere Attacke wäre meines Verständnisses nach, nicht einen Login zu erschleichen, sondern das Server-System zu schlichtweg zu stören oder gar zu zerstören.... was weiss ich wie... ungültige Pakete, kaputte Paketlängen, Flooding, eben alles was da technisch denkbar wäre. Aber auch hier wieder meine Annahme, es wird niemals nur ein einzelnes Paket sein, weil das für echten Schaden wohl nicht ausreicht, sondern vermutlich wirds ein TCP-Dauerfeuer von einem oder vielen Absender-IPs sein.

Also... das ist die Frage ... was sind charakteristische Merkmale eines Angriffs? Ich hatte bisher gedacht, es sind immer viele, viele, viele (immer jedoch fehlschlagende) Pakete... aber die primäre Eigenschaft ist halt "sehr viele Pakete". Und da weiss ich halt nicht, ob meine Interpretation überhaupt richtig ist.

Ganz am Ende glaube ich nämlich, ich kann solcherart bekannte Angriffsmechanismen wirklich wirksam nur dann abwehren, wenn ich die Charakteristik eines solchen üblichen Angriffs überhaupt verstanden habe. Erst dann kann ich auch eine passende Abwehr erstellen. Sofern es um diese vielen Pakete geht (wie von mir angenommen), glaube ich im Moment noch, dass meine Firewall das Just-in-Time handhaben kann, ohne meiner Meinung nach erst viel zu spät über ein gemonitored'tes Log reagieren zu können.

[mat6937]

Sofern es um diese vielen Pakete geht (wie von mir angenommen), glaube ich im Moment noch, dass meine Firewall das Just-in-Time handhaben kann, ohne meiner Meinung nach erst viel zu spät über ein gemonitored'tes Log reagieren zu können.

Ja es geht um diese vielen Pakete, aber es gibt ja im Internet jede Menge Information bzw. Definitionen bzgl. DoS.

Ich denke, wenn man einen DoS-Angriff auf die externe IP-Adresse seines border device, mit einer Firewall mildern will, dann sollte das ohne connection tracking bzw. stateless gemacht werden. Für iptables gibt es z. B. das target NOTRACK, das mit der raw table in der PREROUTING chain genutzt werden kann.

[bluestar]

Und an dem Punkt habe ich das Verständnis, dass 'derjenige' mit der Abweisung nicht einverstanden ist und es sofort wieder versuchen wird, und das dann immer und immer und immer wieder.... schließlich ist er ja ein Angreifer und diese wiederholten Versuche werden eben erst durch deren Anzahl zur wirklich Attacke. Ein andere Attacke wäre meines Verständnisses nach, nicht einen Login zu erschleichen, sondern das Server-System zu schlichtweg zu stören oder gar zu zerstören.... was weiss ich wie... ungültige Pakete, kaputte Paketlängen, Flooding, eben alles was da technisch denkbar wäre.

Die Frage "was ist ein Angriff" lässt unterscheidet sich durchaus auch je nach Dienst, bei HTTP sind mehrere parallele Anfragen von einer IP Adresse durchaus normal, bei VPN würde eher die Devise gelten "eine aktive/im Aufbau befindliche Verbindung pro IP", wenn man es in der Theorie betrachtet und dabei NAT außen vor lässt .. In der Realität mit CG-NAT (Mobilfunk, DS-Lite) hast du natürlich mehrere Verbindungen pro IP, wie viele sind es denn wirklich?

Aber auch hier wieder meine Annahme, es wird niemals nur ein einzelnes Paket sein, weil das für echten Schaden wohl nicht ausreicht, sondern vermutlich wirds ein TCP-Dauerfeuer von einem oder vielen Absender-IPs sein.

Achtung, du verlässt hier bereits das DoS Thema und gehst zum DDoS (= Angriffe von unterschiedlichen IPs) Thema über.

[novalix]

Ich habe mir angewöhnt beim Bergiff DoS automatisch an DDoS zu denken.
Ein Angriff von einer handvoll oder gar nur einer einzigen IP auszubremsen, ist in der Theorie ein recht geringes Problem und lässt sich im Zweifel auch auf einer Werkbank recht gut austesten.

Interessant ist imho auch die Frage, wozu solch ein Angriff dienen soll.
Man versucht einen Server in die Knie zu zwingen,
1) weil man mit dem Opfer noch eine Rechnung offen hat, bzw. eine aufmachen will.
Das ist der erpresserische Ansatz.
2) weil man den Opferrechner als lohnendes Ziel zur Übernahme oder Ausbeutung (Daten) ausgemacht hat.
Das ist der einbrecherische Ansatz.

In einigen Fällen werden Opfer gezielt, ob ihrer Namen bzw. gesellschaftlicher Stellung bzw. Funktion ausgewählt.
Wenn man die Server einer Bank, von Microsoft oder den Webauftritt eines umstrittenen Politikers betreut, kann man sich auf einiges gefasst machen.

In anderen Fällen werden Opfer nach einem score ermittelt. Grundlage dazu bilden die Datensätze, die kontinuierlich per Gießkannen-Prinzip vom Verband der hackenden Industrie eingesammelt werden. Das sind die Millionen scans und Login-Versuche, die scheinbar ziellos durchs Netz mäandern.
Wenn dann Zero-Days-Exploits vorliegen werden die Datenbanken nach lohnenswerten Zielen abgefragt und ecco, die ganzen smarten Fernseher, Glühbirnen und Toaster verrichten ihren Zweitjob.

Ganz theoretisch könnte jetzt so eine Hackergruppe über ihre vorbeifliegenden Helferlein herausgefunden haben, dass auf TomLs Server auf Port 443 ein VPN-Server lauscht und dessen wahrscheinliche Bau- und Betriebsart bestimmt haben. Dann müssten sie noch ein wenig kramen, ob 's noch einen passenden Exploit im Kästlein hat und los geht die Sause.
Allerdings wäre das Szenario schon sehr gezielt oder verzweifelt. Ein Server, der so wenig Flanke bietet, ist kein geeignetes Ziel.

[mat6937]

... herausgefunden haben, dass auf TomLs Server auf Port 443 ein VPN-Server lauscht und dessen wahrscheinliche Bau- und Betriebsart bestimmt haben. Dann müssten sie noch ein wenig kramen, ob 's noch einen passenden Exploit im Kästlein hat und los geht die Sause.

Das wird davon abhängig sein, ob sein Server direkt im Internet steht (d. h. border device ist) oder sich hinter einem Router befindet. Wenn hinter einem Router, dann wird evtl. der Router (... wenn es ein "Consumer-Router" ist) im Falle des DDoS-Angriffs, der Flaschenhals sein und ziemlich schnell "zumachen", so dass der Server gar nicht mehr erreicht wird.

[HZB]

JAber was mich mal mehr interessiert, was charakterisiert überhaupt eine Attacke, was unterscheidet die Attacke von einem legalen Zugriff.

Nichts und alles. Ein HTTP GET ist nicht gleich einem HTTP TRACE oder DELETE. Trotzdem ist nur Port 80 auf der Firewall.

Mir ist schon klar, der legale Zugriff mündet schließlich in der Akzeptanz der Verbindungsaufnahme durch den Dienst, das heisst irgendeine Art des Logins war erfolgreich

Wenn es überhaupt einen Login gibt. Stichwort Mail.

.... was ja bei der Attacke nicht passiert. Aber ein einzelner abgewiesener Verbindungsversuch ist ja noch keine Attacke.

Das ist so nicht ganz richtig, denn Du weißt ja nie ob der Angriff nur von eeiner Source kommt oder von vielen. Stichwort Hail-Mary-Cloud

Und an dem Punkt habe ich das Verständnis, dass 'derjenige' mit der Abweisung nicht einverstanden ist und es sofort wieder versuchen wird, und das dann immer und immer und immer wieder.... schließlich ist er ja ein Angreifer und diese wiederholten Versuche werden eben erst durch deren Anzahl zur wirklich Attacke.

Jein. Das ist so bei penetranten Passworttestern die den Dictonary durchegehn. Die hat man aber eher einfach rausgefiltert. Handelt es sich aber um einen DDoS Angriff kann sich das über Wochen und Monate ziehen und Du siehst immer nur eine IP die sich gerade bei mit einem Passwort versucht. Und diese zu erkennen ist sehr sehr schwierig bis unmöglich.

Ein andere Attacke wäre meines Verständnisses nach, nicht einen Login zu erschleichen, sondern das Server-System zu schlichtweg zu stören oder gar zu zerstören.... was weiss ich wie... ungültige Pakete, kaputte Paketlängen, Flooding, eben alles was da technisch denkbar wäre. Aber auch hier wieder meine Annahme, es wird niemals nur ein einzelnes Paket sein, weil das für echten Schaden wohl nicht ausreicht, sondern vermutlich wirds ein TCP-Dauerfeuer von einem oder vielen Absender-IPs sein.

Das wäre der klassische Dos. Mehr Traffic, wie Du richtig schreibst egal wie und was, was dennoch am Ende Deinen Server überlastet und in die Knie zwingt. Kannst Du ja auch selbst testen. Low Orbit Ion Canon wäre da ein ganz gutes Mittel.

Also... das ist die Frage ... was sind charakteristische Merkmale eines Angriffs? Ich hatte bisher gedacht, es sind immer viele, viele, viele (immer jedoch fehlschlagende) Pakete... aber die primäre Eigenschaft ist halt "sehr viele Pakete". Und da weiss ich halt nicht, ob meine Interpretation überhaupt richtig ist.

Das ist nur eine von zig Möglichkeiten. Ich glaube wonach Du suchst ist SNORT und die Definitionen eines IDS. Es gibt gewisse Signaturen anhand man erkennen kann was das überhaupt ist.

Ganz am Ende glaube ich nämlich, ich kann solcherart bekannte Angriffsmechanismen wirklich wirksam nur dann abwehren, wenn ich die Charakteristik eines solchen üblichen Angriffs überhaupt verstanden habe. Erst dann kann ich auch eine passende Abwehr erstellen. Sofern es um diese vielen Pakete geht (wie von mir angenommen), glaube ich im Moment noch, dass meine Firewall das Just-in-Time handhaben kann, ohne meiner Meinung nach erst viel zu spät über ein gemonitored'tes Log reagieren zu können.

Kommt auf den Begriff Firewall an. Manche Firewalls sind nur Paketfilter die einen Port erlauben. Was sich auf diesem Port abspielt wissen sie nicht. Oder anders ausgedrückt. Ein reiner Paketfilter weiss nicht was er bei Port 80 durchlässt. Kann http sein oder ein telnet welcher auf port 80/tcp lauscht.

[TomL]

Hallo @ all

Zunächst mal vielen Dank für diese neuen Perspektiven auf das Thema. Ich denke, ich habe damit ein etwas besseres Verständnis über die Risiken, den Möglichkeiten solcher Angreifer und insbesondere auch deren Motivation bekommen.

Und jetzt ist mir auch klar (und ich bin nun auch davon überzeugt), dass mein Firewall-Konzept durchaus das durch mich erreichbare (!) Maximum an Sicherheit darstellt, aber das das eben auch -wie Novalix angemerkt hat- für andere Systeme völlig untauglich ist, weil die extreme Schärfe meines Paketfilters den Normalbetrieb eines öffentlich erreichbaren Servers faktisch unmöglich macht.

Der Unterschied ist, das habe ich jetzt hier in diesem Thread verstanden, dass bei einem Mailserver oder einem Web-Server nicht nur eine TCP-Verbindung von der gleichen Absender-IP ankommen wird, sondern durchaus auch viele, die allesamt legal sind oder sein können. Zum Beispiel konnte ich das jetzt durch einen gezielten Test bei meinem Mail-Server verifizieren. Sobald ich Thunderbird auf meinem PC öffne, wird für jedes Postfach eine TCP-Verbindung zum Server etabliert. Aber genau das verhindert mein Paketfilter mit brachialer Effektivität, er lässt nur eine einzige Verbindung zu. Bei der zweiten (die hier natürlich obligatorisch kommen muss) wird die IP sofort komplett gesperrt... und zwar gnadenlos. Warum funktoniert das hier trotzdem? Ganz einfach, weil der Paketfilter lokale Absender bereits vor dem Hackmesser erlaubt und weil unsere eigenen Zugriffe über das Internet vorher schon zu 'lokalen' Absendern gemacht wurden... und zwar durch OpenVPN.

Das bedeutet, am Filter (der Hackmesser-Rule) kommen gar keine lokalen Pakete an, sondern primär nur Pakete aus dem Internet, also zunächst auch unsere eigenen Zugriffe aus dem Web. Und auch für die ist ebenfalls nur ein einziger Verbindungsversuch pro Minute erlaubt, kommt der zweite, wird die IP umgehend dynamisch für 60 Minuten gesperrt. Aber weil es sich hier um eine OpenVPN-Verbindung handelt, funktioniert das bei unseren Clients perfekt. Sobald die Verbindung via HMAC-FW und Cert/Key autorisiert und etabliert ist, sind unsere entfernten Clients zu lokalen Clients geworden und haben dann auch den Zugriff auf die Netz-Ressourcen. Nur alle anderen Verbindungsvesuche (eben die Angreifer) kriegen sofort eins auf die Zwiebel, wenn sie via TCP/Port 443 über einen zweiten Versuch rein wollen, nachdem der erste Versuch fehlgeschlagen ist .... dann ist die Tür sofort zu. Tatsache ist, durch diesen Filter kommen Hacker-Pakete gar nicht erst bis zum Service durch, das Hackmesser rasiert sie bereits im Kernel. Eben genau der Effekt, denn fail2ban nachgeschaltet hätte, hier passiert das nur unmittelbar und dynamisch direkt im Paketfilter. Aber es stimmt, ein öffentlich erreichbarer Web-Server oder Mail-Server würde mit diesem radikalen Filter gar nicht funktionieren können. Btw, OpenVPN ist genau der Grund, warum ich bisher darauf verzichtet habe, unsere Dienste direkt von draußen erreichbar zu machen. Ich empfinde den kleinen Zusatzaufwand für OpenVPN nicht als Belastung... die damit einhergehende Sicherheit ist mir das dreimal wert.

@mat6937
Das mit dem NOTRACK halte ich für kontraproduktiv und schließlich die Sicherheit sogar wieder reduzierend. NOTRACK ist meiner Einschätzung nach nur eine Notlösung, gewissen Traffic aus dem Tracking herauszunehmen, wenn die Tracking-Tabellen aufgrund hohen Paket-Aufkommens an die Grenze stoßen und deshalb Paketverlust droht. In dem Fall würde ich wohl eher das Limit hochsetzen, um eben nicht das Tracking zu verlieren. Aber dieses Problem stellt sich bei unserem Familien-Server natürlich nicht, wir werden die Tabellen niemals überlasten können.... insofern erkenne ich mit NOTRACK keine Verbesserung.

Kommt auf den Begriff Firewall an. Manche Firewalls sind nur Paketfilter die einen Port erlauben. Was sich auf diesem Port abspielt wissen sie nicht. Oder anders ausgedrückt. Ein reiner Paketfilter weiss nicht was er bei Port 80 durchlässt. Kann http sein oder ein telnet welcher auf port 80/tcp lauscht.

Ich würde eher sagen, es kommt auf den Unterschied "stateless" oder "stateful" an. Natürlich weiss ich im Paketfilter nicht, was ein TCP-Paket enthält und welcher Prozess es entgegennimmt, aber ich habe schon eine Auge auf Wiederholraten und kann genau darauf in einer Stateful-FW flexibel reagieren. Deswegen halte ich Stateless-FWs auch eher für Router und so geeignet, weil an der Stelle Stateful-Rules bezogen auf die expliziten Services einer einzelnen Maschine im Netz eher nicht so gut implementiert werden können, ohne dass es nachher undurchschaubar wird. Denn, was für die eine Maschine gut ist, kann ja auch durchaus den Knockout einer anderen Maschine im gleichen Netz bedeuten. Ich denke, diese Gefahr wird durch Stateless-FWs reduziert. Weil der Paketfilter aber bei mir direkt auf meinem Server läuft, kann ich den natürlich "statful" maßschneidern.

[mat6937]

In dem Fall würde ich wohl eher das Limit hochsetzen, um eben nicht das Tracking zu verlieren.

Im Falle von DDoS wird dieses Limit immer zu niedrig sein.

Aber Du hast Recht wenn es um die Sicherheit geht, die Du meinst bzw. Du haben willst, da wird NOTRACK (bzw. no state) nicht benötigt. Ist dein Familien-Server direkt im Internet oder an einem Router angeschlossen?

[TomL]

Ist dein Familien-Server direkt im Internet oder an einem Router angeschlossen?

Ich glaube, dass ist bei der Schärfe meines Paketfilters vermutlich nicht absolut relevant. Aber ja, der Server hängt natürlich noch hinter dem Router und wird für IPv4 auch genattet. Lediglich mit IPv6 hat er zwei öffentliche Adressen. Aber dennoch (der DSL-Router forwardet nur TCP/443 und einen hohen UDP-Port), ich hätte trotzdem das Vertrauen in meinen Filter, dass der auch dem Druck als Border-Device standhalten könnte.