ich wollt kein flame-war erzeugen! aber die fragen sind auch nicht so gemeint, sind rein informativ! aber passt schon, ich werd nicht weiter posten :lol:Joe User wrote:Muss dieser Thread auch im "Distribution<-->Distribution"-Flamewar enden, wie es seine Vorgänger bereits taten?
Ich habe nicht behauptet, dass die Debian-Kernel (im Vergleich zum Vanilla-Kernel) nicht gepatcht sind. Dort fließen halt nur sehr moderate Patches ein, die auch die Stabilität so wenig als irgend möglich beeinflussen.- debian hat keine "ueberzuechtete" kernel? sprich es sind keine patches drin (laut CaptainCrunch)!
MySQL. Angenommen mein Subnet sei 192.168.0.0/24 sowie 192.168.1.192/26. Wie mach ich das dann?CaptainCrunch wrote:Kann eine vernünftige DB auch alleine.Mittels iptables beschränke ich den Zugriff auf mein Subnetz.
Ja *lol*. Entschuldige, aber mir scheint du hast mit DDoS noch überhaupt keine Erfahrung gemacht. Syn-Cookies sind nicht das Allheilmittel. Im Gegenteil. Bei einer breitbandigen Attacke können die Kekse sogar für das Aus sorgen. Pro Syn Paket wird eine connection im state filter hinterlegt. Ist die Attacke niederbandbreitig, dann kommt der Rechner bei syncookies 1 mit dem Rechnen hinterher und hat nicht so viel Müll in der conntrack table. Bei breitbandigen Attacken kommt der Rechner mit dem Rechnen nicht mehr hinterher, der Load steigt > 100 und mehr und das wars. SSH Connect? Kannst du abschreiben. Eine sinnvolle Begrenzung auf die Anzahl der SYN Pakete pro Sekunde/IP ist wirksamer als jeder Cookie. Wird eine IP gefloodet, so verwirft der Paketfilter alle SYN-Pakete über dem Limit noch *bevor* sie in der INPUT Chain landen und verhindert so schon steigenden Load noch bevor er überhaupt eintreten kann. Somit lässt sich problemlos weiterarbeiten und mittels tcpdump die target-ip finden um einen Block am router setzen zu können.Wozu ? Dazu gibt's Syncookies.Des weiteren kann man sich mit iptables sehr schön gegen SYN Flooding schützen(limit im PREROUTING).
Gebe ich dir selbstverständlich recht, sofern das auf die Allgemeinheit bezogen ist(und du mir nicht mangelnde TCP/IP kenntnisse unterstellst, wovon ich nicht ausgehe).Um diese umzusetzen sollte man sich aber mindestens mit den Grundlagenm von TCP/IP auskennen. Sofern man das tut, wird man schnell erkennen, das es die Kiste erheblich sicherer macht, den Hirnschmalz in eine gute Konfiguration zu investieren.Etc.pp... gibt noch viel mehr Anwendungsgebiete.
Wozu willst du überhaupt ein komplettes Subnetz zulassen ? Im Normalfall reicht die Beschränkung für user@HOST.MySQL. Angenommen mein Subnet sei 192.168.0.0/24 sowie 192.168.1.192/26. Wie mach ich das dann?
Da hast du absolut Recht, und da ich mich nicht in den Kreisen rumtreibe, bei denen (D)DoSsen zu "Volkssport" gehört, mache ich mir da auch herzlichn wenig Sorgen drüber. Weiteres s.u.Entschuldige, aber mir scheint du hast mit DDoS noch überhaupt keine Erfahrung gemacht.
Da wir uns hier über dedizierte Mietserver unterhalten, bringt dir das verhältnismäßig wenig, daSomit lässt sich problemlos weiterarbeiten und mittels tcpdump die target-ip finden um einen Block am router setzen zu können.
Du hast richtig erkannt, dass ich nicht von dir rede ;) . Da ich aber so ziemlich jedes Postingt hier im Forum lese, weiß ich, dass du in dem Fall (leider) eine der wenigen Ausnahmen bist.Gebe ich dir selbstverständlich recht, sofern das auf die Allgemeinheit bezogen ist(und du mir nicht mangelnde TCP/IP kenntnisse unterstellst, wovon ich nicht ausgehe).
Im Falle desjenigen, der glaubt, er wäre durch eine "Firewall" sicherer, obwohl er die Grundlagen nicht kennt / versteht ist das aber leider der beste Rat, den man Leuten geben kann, da der Schuss auch schnell nach hinten losgehen kann.Grundsätzlich aber halte ich eine pauschale Behauptung wie "ein Paketfilter hat auf der zu sichernden Maschine nichts verloren" für sinnfrei.
Stimmt zwar. Aber da meine Server i.d.R. mehr als eine IP haben und es meines Wissens nicht möglich ist dem Server zu sagen: verbinde dich über deine IP xy... du verstehst die Problematik? :)CaptainCrunch wrote:Wozu willst du überhaupt ein komplettes Subnetz zulassen ? Im Normalfall reicht die Beschränkung für user@HOST.
Geht in Ordnung, aber leider gibt es genügend Kinder, die DDoS ganz toll finden. Ich kanns auch nicht nachvollziehen, aber dann ist es doch gut zu wissen, dass man sich dagegen schützen kann. Mir wärs natürlich auch lieber, wenn die Attacken komplett ausblieben..Da hast du absolut Recht, und da ich mich nicht in den Kreisen rumtreibe, bei denen (D)DoSsen zu "Volkssport" gehört, mache ich mir da auch herzlichn wenig Sorgen drüber. Weiteres s.u.
Sofern du das wirklich auf Mietserver reduzierst, hast du vermutlich recht. Ich ging nicht davon aus, dass es hier nur darum gehen sollte. In meinem Fall wird Traffic ab Switch berechnet.Da wir uns hier über dedizierte Mietserver unterhalten, bringt dir das verhältnismäßig wenig, da
a) der ankommende Traffic immer noch am Switch / Router vor der Kiste berechnet wird, und
Beim Otto-Normal Rootie sicher wieder richtig. Bei entsprechend qualitativer(und teurer) Co-Location bei eigener Hardware sieht das wieder anders aus.b) du auf diesen Router keinen Zugriff bekommen wirst.
FULLACK. Aber wenigstens hilft dieses Forum die größten Katastrophen zu vermeiden ;)Du hast richtig erkannt, dass ich nicht von dir rede ;) . Da ich aber so ziemlich jedes Postingt hier im Forum lese, weiß ich, dass du in dem Fall (leider) eine der wenigen Ausnahmen bist.
Dann sind wir uns ja einig :)Im Falle desjenigen, der glaubt, er wäre durch eine "Firewall" sicherer, obwohl er die Grundlagen nicht kennt / versteht ist das aber leider der beste Rat, den man Leuten geben kann, da der Schuss auch schnell nach hinten losgehen kann.
Gerade "N00bs" sollten sich viel eher damit befassen, wie sie die Dienste, die sie anbieten (und auch nicht durch die "Firewall" absichern) richtig konfigurieren, da die wenigsten Angriffe auf Netzwerkebene kommen, sondern (nach allem, was mein IDS bisher gesehen hat) sämtliche Scriptkiddies auf Lücken in den jeweiligen Diensten losgehen.