Liebe Firewall-Freunde...

[gierig]

Das erinnert mich an ein ICQ Gespräch wo jemand meinte er könnte mit seiner ISDN Leitung meinen Server so mit Traffic überfluten das er abstürtzt, ich warte heute noch :roll:

Na ja, so abwegig ist das nicht (und je nach dem wie man Absturz definiert) Man nehme eins bis zwei UDP anfragen an eins bis zwei dutzend Game Server, fälsche die Absender Adresse und freue sich das die Game Server den "Abesender" dicht machen mit Antwortpaketen die vielfach größer sind als die Quell Pakete.....

http://en.wikipedia.org/wiki/Distribute ... ted_attack

Na ja, hab mich schon sehr lange nicht mehr mit dem backTraffic von GameServern beschäftigt. Aber damals im testlan, hatte ich nen CS1.5 den konnte man sehr gut dazu gebrauchen Traffic zu generieren :-) Gut die üblichen Server im RZ sind mit 100Mbit angebunden, da brucht es wahrscheinlich etwas mehr Aufwand. Aber für ne normale Firma die ne 2mbit CoCo in internet pflegt.....

[flo]

2003: Broadcast-Pings ... 2 C-Klasse-Netze :-( das hat gereicht ...

[disi]

Also ich schütze teilweise Dienste mit VPN verbindungen oder knockd.
Fail2ban nutze ich nur für Automatisierte IP-Sperren auf meiner Firewall, aber für rootserver ohne Physicalischen zugriff kann die ganze schose mit Fail2ban und automatisierten Bannen wie schon erwähnt nach hinten los gehen.

Aber wofür gibt es denn die Serielle-Konsole mittlerweile bei fast allen rootserver anbietern. Ich denke wenn man von vornherein diese Zugriffsmöglichkeit von Sperrungen ausschließt hat man doch ganz gute Karten?!

Was meint ihr dazu?

[monotek]

Macht eine Firewall nicht doch Sinn, wenn sie den ausgehenden Traffic blockt?

Also z.B. wenn irgend eine verwundbare Webanwendung über einen Exploit versucht Code nachzuladen, der dann wiederum für einen lokalen Angriff genutzt werden könnte.

In dem Fall bringt mir die Firewall doch auch wieder ein kleines Stück mehr Sicherheit auf nem Root.

[gierig]

Das da noch keiner geantwortet hat....

Was hindert deine Schadens Software ja eh noch Code nachladen will daran ein Iptaples -F auszuführen ?

Klar nur mit rechten des Webservers wird er das nicht schaffen. Aber wenn er schon befehle ausführen darf auf deinen
System um Software nachzuladen. Ist es doch nur eine Frage der Zeit bis er dann zugriff hat auf den NET-Filter.

[daemotron]

Nur weil eine PHP-Applikation irgendwo unvorsichtig mit url_fopen rumhantiert, kriegt man damit noch keine root-Rechte. Dazu müsste ein Angreifer IMHO irgendetwas nachladen (z. B. erst mal eine Webshell), um sie im Kontext des Webservers (bzw. genau des schwachen Skripts) auszuführen. Insofern würde eine Restriktion, die das Nachladen von Daten aus dem www unterbindet, schon einen gewissen Schutz bieten. Aber eben nur nur in dritter Instanz, denn in erster Instanz muss die Sicherheitslücke gestopft werden, und solcher Unsinn wie url_fopen sollte durch eine restriktive Konfiguration unterbunden sein. Es müsste also schon ein Zero-Day-Exploit für die (Web)Applikation mit einem noch nicht gefixten Bug im Dienst oder Betriebssystem zusammenfallen, dass eine Filterregel wirklich mal den Server schützt. Die Gretchenfrage ist also eher die nach den Applikationen... OK, es gibt Szenarien, in denen es dumm wäre, von sicheren oder zumindest aktuellen Applikationen auszugehen (Shared Hosting als Beispiel). In einem solch kritischen Fall würde ich aber eher mit einem Layer-7-Filter arbeiten (z. B. Zorp auf einem dedizierten Firewall-Host oder zumindest mod_security).

[anyware]

Macht eine Firewall nicht doch Sinn, wenn sie den ausgehenden Traffic blockt?

Also z.B. wenn irgend eine verwundbare Webanwendung über einen Exploit versucht Code nachzuladen, der dann wiederum für einen lokalen Angriff genutzt werden könnte.

In dem Fall bringt mir die Firewall doch auch wieder ein kleines Stück mehr Sicherheit auf nem Root.

Eine vernünftige Outbound-Filterung macht durchaus Sinn. Erfahrungsgemäß entstehen 90% der Probleme im Hostingbereich durch schlecht programmierte oder fehlerhafte Webapplikationen. In der Regel wird es so einem Angreier ermöglicht eigenen Code einzuschleusen und auszuführen. Meist wird dann gerne nach Hause telefoniert um Code nachzuladen. Besonders gerne mit Bordmitteln von PHP, wget oder über IRC. Erst der nachgeladene Code macht dann meist richtig Ärger. Eine ausghehende Filterung kann sowas natürlich recht simpel unterdrücken oder erschweren. In Kombination mit Logging (und natürlich einer vernünftigen Auswertung der Logs) kann man so Probleme 'schnell erkennen und Gegenmaßnahmen einleiten.

[blueroot]

Eine "Firewall" macht wenn nur im "Packet" sinn. Die meisten "Normalsterblichen" denken, dass eine Firewall Dienste absichert und eine Art von Internetpolizei darstellt. Dies geht z.B. in Richtung gr_sec, mod_security, se_linux usw. Eine Firewall kann beim Öffnen von Ports für "böse" Dienste helfen. Dann aber nur, wenn der Benutzer keinen root-Zugang hat und/oder Dienste beenden kann. Das Thema kann man wie in der Politik ewig durchkauen, helfen tut es wenig.

Sinnvoller wäre eine allgemeine Anleitung zum sicheren Betreiben eines Servers, wie z.B. iptables, Passwörter, SSH-Keys, Logfilehilfen, Logfileauswertung usw. Sogut wie immer brauch es Gehirnschmalz der Person hinter dem Bildschirm. Man kann hier immer hin und her diskutieren, wie das z.B. ein zu sicherer Server "echte" Hacker anlockt.

Der bestemöglich abgesicherte Server hilft auch nicht, wenn die Benutzer / Mitarbeiter "12345" als Passwort benutzen und/oder Passwörter unter einer Ablage "sichern". Das ganze habe ich schon öfters gesehen, vorallem Beamten 50+ lieben das.


PS: Ich finde es super, dass man hier noch lauter "alte" gesichter von vor einigen Jahren täglich sieht und dass das Niveau wohl einiges höher ist, als vor einigen Jahren, als noch viele Beiträge in bekannten Zeitschriften standen.

[EdRoxter]

Achje, das 50+-Problem.. ;)

Bin ich froh, dass ich mir meine Kunden aussuchen kann. :D