Abuse-Meldung

[e0fl2]

@NRG21

Um dieses Problem zur beseitigen, benötigten wir weitere Informationen, sonst kann man nur Rätselraten.

Es ist ein leichtes bei einem "Aktiven" Angriff die Ursache festzustellen.

Hattest du schon einen zweiten "Angriff" ?

 

[d4f]

Alles was bis jetzt an Angriffen reinkam, kostete den Angreifer viel Geld (Aussage eines RZ-Betreibers) und war zielgerichtet.

Botnetze mit einer amplifizierten Kapazität von über 1Gbit/s sind stundenbasiert mietbar und kosten kaum mehr als ein gutes Abendessen (nicht im Restaurant versteht sich)
Ob das für den Angreifer "viel Geld" darstellt ist relativ - die übliche 14jährigen mit der kriminellen Energie und "ich-will" Mentalität von Mafia-Dons müssen eventuell dafür etwas sparen (aber nicht viel... schliesslich hat da ja schon jeder ein eiDings mit Flatrate)
Generell ist der "defense"-Kostenpunkt um mehrere Grösseneinheiten höher als der Angriff - wie übrigens bei allen Angriffsarten, bis hin zurück als die "Clans" noch mit Steinen und Speeren warfen.

Was hat es mit den Längen filtern auf sich? Bzw. warum ist es nicht schlau?

Paketgrössen sind inherent dynamisch. Es ist möglich -wenn auch nicht sehr wahrscheinlich- dass dadurch legimite Pakete blockiert und das Spielen stark eingeschränkt bis unmöglich wird.

 

[NRG21]

Die Antwort von Hetzner ist da:

alles was wir an Protokollen vorhalten, haben Sie bereits erhalten. Da wir Ihren gesamten Traffic nicht scannen und nicht filtern, können wir keine genaueren Angaben machen.

Mit freundlichen Grüßen / Best Regards

...
Da hätte also auch ein telefonischer Anruf vermutlich nichts gebracht.

@NRG21

Um dieses Problem zur beseitigen, benötigten wir weitere Informationen, sonst kann man nur Rätselraten.

Es ist ein leichtes bei einem "Aktiven" Angriff die Ursache festzustellen.

Hattest du schon einen zweiten "Angriff" ?

Informationen bzgl. was das für ein Angriff war, welches Protokoll und welcher Port, habe ich nicht. Einen zweiten Angriff gab es auch nicht.

Letzendlich wäre es von Vorteil zu wissen, was überhaupt für ein Angriff gefahren worden ist, damit man dann etwas unternehmen kann. Jetzt ziellos noch irgendeiner Lösung zu suchen, bringt nicht viel.

Da ich keinerlei Informationen habe was da passiert ist, muss ich wohl den Weg gehen und alle möglichen Löcher stopfen.


Vielleicht kann man an der sysctl.conf noch etwas verbessern? Die habe ich seit heute folgendermaßen:

#net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.tcp_syncookies=1
kernel.exec-shield=1
kernel.randomize_va_space=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.default.accept_source_route=0
# ipv6 settings (no autoconfiguration)
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.default.accept_dad=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.accept_ra_defrtr=0
net.ipv6.conf.default.accept_ra_rtr_pref=0
net.ipv6.conf.default.accept_ra_pinfo=0
net.ipv6.conf.default.accept_source_route=0
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.default.forwarding=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.all.accept_dad=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.accept_ra_defrtr=0
net.ipv6.conf.all.accept_ra_rtr_pref=0
net.ipv6.conf.all.accept_ra_pinfo=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.forwarding=0

Das Paketlimitieren habe ich wie gesagt wieder rausgenommen.