RootForum Community

Joe User wrote:Muss dieser Thread auch im "Distribution<-->Distribution"-Flamewar enden, wie es seine Vorgänger bereits taten?

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:

gruss
wudmx

Um einfach mal bei den (IMHO) Fakten zu bleiben :

- debian hat keine "ueberzuechtete" kernel? sprich es sind keine patches drin (laut CaptainCrunch)!

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.
Wenn andere Distributoren (ich nenne extra keine Nahmen) hingehen, und alle möglichen Patches, die das Arbeiten auf einem Desktop-Rechner angenehmer machen einfließen lassen, leidet in den allermeisten Fällen (je nach Patch) als allererstes darunter leidet.

CaptainCrunch wrote:

Mittels iptables beschränke ich den Zugriff auf mein Subnetz.

Kann eine vernünftige DB auch alleine.

MySQL. Angenommen mein Subnet sei 192.168.0.0/24 sowie 192.168.1.192/26. Wie mach ich das dann?

Des weiteren kann man sich mit iptables sehr schön gegen SYN Flooding schützen(limit im PREROUTING).

Wozu ? Dazu gibt's Syncookies.

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.

Etc.pp... gibt noch viel mehr Anwendungsgebiete.

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.

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

Grundsätzlich aber halte ich eine pauschale Behauptung wie "ein Paketfilter hat auf der zu sichernden Maschine nichts verloren" für sinnfrei. Ein lokaler Filterregelsatz kann zweifelsfrei zum Sicherheitskonzept beitragen. Erst in größeren Netzen macht die explizite Umsetzung einer DMZ imho sinn, bei 1-2(oder mehr) Servern ist das glatter Overkill, sofern man schlicht eine Webserver Farm o.Ã?. betreiben möchte.

Gruß,
Nico

MySQL. Angenommen mein Subnet sei 192.168.0.0/24 sowie 192.168.1.192/26. Wie mach ich das dann?

Wozu willst du überhaupt ein komplettes Subnetz zulassen ? Im Normalfall reicht die Beschränkung für user@HOST.

Entschuldige, aber mir scheint du hast mit DDoS noch überhaupt keine Erfahrung gemacht.

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.

Somit lässt sich problemlos weiterarbeiten und mittels tcpdump die target-ip finden um einen Block am router setzen zu können.

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
b) du auf diesen Router keinen Zugriff bekommen wirst.

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

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.

Grundsätzlich aber halte ich eine pauschale Behauptung wie "ein Paketfilter hat auf der zu sichernden Maschine nichts verloren" für sinnfrei.

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.

CaptainCrunch wrote:Wozu willst du überhaupt ein komplettes Subnetz zulassen ? Im Normalfall reicht die Beschränkung für user@HOST.

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? :)
Ausserdem ist das /24er Netz auf mich registriert und wird auch nur von mir genutzt, deswegen halte ich das für nicht weiter schlimm.

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.

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 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

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.

b) du auf diesen Router keinen Zugriff bekommen wirst.

Beim Otto-Normal Rootie sicher wieder richtig. Bei entsprechend qualitativer(und teurer) Co-Location bei eigener Hardware sieht das wieder anders aus.

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.

FULLACK. Aber wenigstens hilft dieses Forum die größten Katastrophen zu vermeiden ;)

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.

Dann sind wir uns ja einig :)

Grüssle,
Nico