Liebe Firewall-Freunde...

[Matthias Diehl]

Genau.
Leider wird auch dies durch die Werbung so dargestellt. Und das ist der springende Punkt: In speziellen Fällen UND bei vorhandenem Wissen kann ein Paketfilter sinnvoll sein. Aber das ist so selten der Fall das ich lieber behaupte, das eine Firewall (oder besser ein Paktefilter) auf einem Rootserver nix bringen.

[dtdesign]

Hmm, also an der einen oder anderen Stelle, sollte ich mein Prinzip mal überdenken.

Eine ordentlich konfigurierte und gewartete Firewall / Paketfilter halte ich in so fern für sinnvoll, dass diese mir bis jetzt immer den nötigen Zeitrahmen gab, den ich brauchte um die Sicherheitslücke(n) beheben zu können. Eine Firewall zählt bei mir nur als "nice-to-have" und nicht als absolute Sicherheitsmaßnahme. Ich weiss nicht so recht, aber eine Firewall hat - eine vernünftige Konfiguration vorausgesetzt - durchaus Vorteile.

Gruß
dtdesign

[Joe User]

Ich weiss nicht so recht, aber eine Firewall hat - eine vernünftige Konfiguration vorausgesetzt - durchaus Vorteile.

Wenn man einen vernünftig konfigurierten Paketfilter als Hilfsmittel versteht und nicht als Sicherheitsinstrument, kann er unter Umständen hilfreich sein, ja. Aber die meisten "Admins" verstehen es leider genau andersrum und wiegen sich in falscher Sicherheit...

[ghoster1970]

Man muss knapp und nüchtern betrachten: es gibt keine absolute Sicherheit. Man kann zig Zertifikate zum Thema Sicherheit erworben haben, seine Kenntnisse umsetzen und sich danach hinstellen und behaupten "Mein System ist sicher" wäre absolut fatal.
Sicherheit bringt weder ein Paketfilter noch sonstwelche PFW auf einem Rootserver.
Die Frage ist nun, wie bringt man Sicherheit und Nutzbarkeit meiner Dienste auf einen Nenner?
Was nützen tausende Rules wenn das System derart lahmarschig und damit für den Nutzen unattraktiv wird?
Für mich fängt "Sicherheit" bei der Konfiguration des Servers bishin zu allen benötigten Diensten an. Was nicht benötigt wird, deinstallieren. Dann ist man IMHO erstmal eine Sorge mehr los wo eingebrochen werden kann.
Zur Sicherheit trägt IMHO keine Automatisierung bei, man sollte sich die Zeit nehmen seinen Server tagtäglich im Auge behalten.
Permanente Sperrungen von IPranges sind solange es anonyme Proxies gibt nutzlos. Ob man China, Korea oder Brasilien aussperrt, wenn irgendwelche Leute deinen Server bombardieren wollen, lassen diejenigen sich nicht von deinen Sperrungen beeindrucken.
Der Schaden wird größer, wie schon vorher angedeutet, wenn Kunden der Telekom/AOL/Arcor etc aufgrund einer automatisierten Sperrung des IPranges nicht mehr in der Lage sind Bestellungen durchzuführen. Was hat man dann noch von seiner selbsternannten Sicherheit?

Zum Punkt: wer Dienstleistungen anbietet muss sich im klaren sein das diese von jemand anderem mißbraucht werden können.

MfG
Christian Schattner

[flo]

Zum Punkt: wer Dienstleistungen anbietet muss sich im klaren sein das diese von jemand anderem mißbraucht werden können.

Full ACK - hatten wir nicht mal die Antwort "Stecker ziehen" auf die Frage, wie man den (Root-)Server wirklich sicher machen kann? ;-)

[r. u. serious]

Ich habe niemals behauptet das Firewalls prinzipiell nutzlos sind, aber nicht bei Rootservern, sondern vor Netzen.

Dass hast du genauso eloquent getan wie beim formulieren des Satzes - nämlich so, dass das was du geschrieben hast etwas anderes aussagt, als das du vielleicht gemeint hattest...

Und was ist das denn für eine abstruse Logik in der Du den Sicherheitsgurt gegen Carjacking einsetzen willst? Ich glaube Deine Logik ist wesentlich abstruser als meine. Welchem Trugschluß soll ich denn aufgesessen sein?

Sie ist genauso abstruse wie deine (man bezeichnet es landläufig als Analogie), das war ja genau der Punkt. Eine Firewall arbeitet (eigentlich) auf anderen ISO-Layern, als die Andwendungsdaten, sprich sie versucht auch gar nicht gegen Angriffe gegen die öffentlich erreichbaren Anwendungen zu schützen. Genausowie ein Sicherheitsgurt nur bei Unfällen schützen soll, aber nicht gegen Raubüberfälle oder Diebstähle.
In dem was du geschrieben hast (wo du aber vermutlich wieder abstreitet wirst es gemeint zu haben), benutzt du das Argument "hilft nicht gegen alle potentiellen Schäden" um zum Schluß zu kommen "ist nutzlos". Das ist ein Trugschluß. Soll ich es aussagenlogisch formal formulieren, oder ist jetzt klar, was mich an der Art deiner Argumentation gestört hat?

Es ist viel eher gefährlich Anfängern zu erzählen eine Firewall sei hilfreich

Wie und was man Anfängern erzählt und wie gefährlich das ist, ist vollkommen unabhängig vom Thema der Kosten-/Nutzen Abschätzung eines Paketfilters. Wenn Werkzeuge falsch eingesetzt werden, können sie immer wirkungslos oder im schlimmsten Fall schädlich sein, das ist eine Binsenweisheit die man eigentlich nicht extra wiederholen müßte...

(bei einem Rootserver und darum geht es in diesem Forum ja nun mal)

Das eine schließt das andere nicht aus. Ich würde sogar behaupten, dass die weitaus größere Mehrheit hier im Forum mehr als einen Rootserver, und oft genug auch kleinere Netze betreibt. Aber selbst bei einem einzelnen Rechner ist eine vorgeschaltete dedizierte Firewall sinvoller als ein Paketfilter auf dem Rootserver - und was im Forum immer (zurecht) kritisiert wird ist v.a. letzteres, aber nicht ersteres.

das Problem sind [...] Leute die eine Firewall als Allheilmittel anpreisen.

Zeig mir bitte 3 Beiträge aus diesem Forum, in denen dies explizit getan wird. Falls nicht, dann bitte wenigstens 3 Beiträge in denen implizit behauptet wird, dass eine Firewall ein "Allheilmittel" ist, sprich, dass es nach der Einrichtung einer Firewall keiner weiteren Sicherheitsmaßnahmen bedarf. Ich bin gespannt.

Leuten die ein so grundsätzlich falsches Verständnis von Zusammenhängen haben, wird man ohnehin nicht helfen können. Sie werden auch bei Verzicht auf einen Paketfilter auf dem Root oder einer externen Firewall, den Aufwand immer noch nicht auf andere sinnvollere Sicherheitsmaßnahmen verwenden. Insofern ist die Haltung solcher Leute vollkommen irrelevant für die Problematik, oder die Kosten-/Nutzenabwägung des Einsatzes der Maßnahmen.

Sorry, aber das ist absoluter Unsinn!
Genau diese Leute sind es doch die sich in falscher Sicherheit wiegen weil das technische Verständnis fehlt und deren Server dann übernommen werden.

Lies noch mal ganz langsam was ich geschrieben habe. Ich schrieb, dass die genannten Leute sowieso "verlieren", denn auch wenn sie den Paketfilter nicht installieren, dann verwenden sie die gewonnene Zeit ohnehin nicht für nützlichere Sicherheitsmaßnahmen auf - eben weil sie keinen Peil haben und sich nicht mit der Materie beschäftigen wollen. Wenn sie das wollten/könnten, würden sie das ja schon beim Thema Paketfilter tun.

Davon abgesehen habe ich ja weiter oben geschrieben, dass ich, im Ergebnis, ebenfalls der Meinung bin, dass es Maßnahmen gibt, welche ein besseres Kosten/Nutzenverhältnis haben als Paketfilter, und natürlich sollte das Anfängern so vermittelt werden.

Die Frage ist nur was man als Ursache für die gehackten Server feststellt, und das ist eben IMO nicht das "Vertrauen in den Paktefilter" (außer in seltenen Einzelfällen wie im Eingangsposting referenziert), sondern in aller Regel das Mangel an Know-How und Interesse bzw. die mangelnde Fähigkeit sich in die Zusammenhänge einzuarbeiten. "Security is a process, not a product" - aber Produkte pauschal als nutzlos zu bezeichnen ist dennoch ein Trugschluß.

[flo]

aber Produkte pauschal als nutzlos zu bezeichnen ist dennoch ein Trugschluß.

ich denke, das kam zwar jetzt von ihm so rüber, war aber eher in Richtung derjenigen gemeint, die Firewall (=Security Appliance) mit iptables, zonealarm usw. gleichsetzen ...

Und da - sorry, hatten wir einige in den letzten Monaten ...

[daemotron]

Eieieieiei, dabei wollte ich doch nur auf eine Sicherheitslücke im Linux-Kernel hinweisen... Na, so wird der Thread wenigstens gelesen - und zum Glück ist's ja Smalltalk :lol:

[Joe User]

und zum Glück ist's ja Smalltalk :lol:

Noch ;)

/me: wenn ausdiskutiert, archivieren.

[flo]

Gleitet jetzt langsam in Smalltalk ab - wäre aber schon fast was für "wichtig" ...

[dodolin]

1) Zugriffe, die nur falsch sein können - (was bringt es, 2MB-Pings aus dem Hindukusch zu droppen oder zu rejecten, Traffic fiel an)
2) Filtern auf Applikations-Ebene (SQL-Injection oder sonstwas)

Und da liegt wohl eher der Hase im Pfeffer - iptables kann keine Firewall ersetzen, und die 300 Ports, die auf dem Server eh nicht lauschen, muß man auch nicht droppen ...

Das ist in dieser Allgemeinheit auch nicht korrekt. Prinzipiell gebe ich dir Recht, dass droppen unschön ist und legitime Nutzer unnötig ausbremsen kann, Probleme beim debuggen von Problemen machen kann usw.

Es gibt aber sicher auch Fälle (z.B. DoS), bei denen droppen Sinn hat und alles andere die Situation nur verschlimmern würde.

[flo]

@dodolin - darum ging es nicht :-) iptables für Trafficvermeidung, das ist eben auf der Maschine selber nicht möglich, da der Traffic schon anfiel.

[Matthias Diehl]

@R.U.Serious
Vielen Dank für Deinen Beitrag.
Mein Einwand, das sei absoluter Unsinn bezog sich auf Deinen letzten zitierten Satz. Die Haltung "solcher Leute" mag für Dich und Deine persönlichen Kosten-/Nutzenabwägungen irrelevant sein, aber den Rest der Welt bombardieren die kompromiitierten Server dann. Deine Beispiele mit einzelnen Rechnern sind ja durchaus richtig, aber ich habe hier immer von Paketfiltern auf Rootservern (ich weiss, auch das ist der falsche Ausdruck) gesprochen.
Toll fand ich diesen Satz:

Dass hast du genauso eloquent getan wie beim formulieren des Satzes - nämlich so, dass das was du geschrieben hast etwas anderes aussagt, als das du vielleicht gemeint hattest...

Sorry, aber wenn Du schon besser weisst als ich was ich meine, dann scheint es Dir nicht mehr darum zu gehen auf die sachlichen Argumente einzugehen sondern darum, meine Beiträge zu kritisieren. Dabei wünsche ich Dir weiterhin viel Spass :)

[sledge0303]

Es kann jetzt sein das einige nicht meiner Meinung sind. Es ist aber meine:

Sicherheit eines Servers hängt von der Konzeption des (dedizierten) Servers und der darauf zu laufenden Dienste ab.
Wie schon mal erwähnt muss beachtet werden, die Kiste soll benutzbar sowie persönliche-/Kundendaten, so gut wie es geht, abgesichert werden.
Da sind eine Firewall, Iptables - however - sicherlich gute Hilfsmittel, aber keine Allheilmittel.
Was nützt es mir eine Firewall wenn der Web-/Maildaemon darüber abgesichert ist, die darauf laufenden Skripte weich und damit einen Angriffspunkt bieten?
Ist der Angreifer einmal auf der Kiste, dann kann er schalten und walten wie er möchte ohne das 'Schutzmechanismen' greifen können.

Wie sieht es aus mit veralteten Kernel die verwendet werden? Dienste die nach draußen lauschen weil diese niemals beansprucht werden und deswegen 'vergessen' werden? Unregelmäßiges einpflegen von Sicherheitsupdates?

Genau dort liegt meiner Meinung nach das Problem und nicht in irgendwelchen Firewalls oder iptables Rules.
Ich möchte nicht wissen wie viele Suse 9.0, ohne Support oder Sicherheitsupdates - teilweise nie eines gesehen haben, noch rumgeistern und nur darauf warten entweder gehackt oder vom Admin 'erlöst' zu werden...

Sorglosigkeit und der Gedanke... ich hab ja Plesk und alles ist gut... sind der beste Freund jedes Skriptkiddies.
Wer darf den Mist am Ende ausbaden? Richtig, wir!

[r. u. serious]

Matthias, du dichtest mir Dinge an die ich nicht gesagt haben.

Die Haltung "solcher Leute" mag für Dich und Deine persönlichen Kosten-/Nutzenabwägungen irrelevant sein, aber den Rest der Welt bombardieren die kompromiitierten Server dann.

Die Haltunng der Leute ist mir nicht egal. Ich habe gesagt, dass sie keinen Einfluß auf die Entscheidung eines Rootserver-Administrators nimmt wenn er den Einsatz des Werkzeugs paketfilter beurteilt. Der Thread dreht sich nicht darum, was man blutigen Anfängern empfiehlt, sondern er dreht sich um den Einsatz eines Werkzeuges und ob jenes "nutzlos" ist oder nicht (was man offensichtlich verneinen kann, denn ganz offensichtlich erfüllt iptables den Zweck zu dem es geschrieben wurde), und im zweiten Schritt darum, ob nach dem Abwägen der Kosten und Nutzen des Werkzeuges man es einetzen will oder nicht (hier neige ich idR gegen den Einsatz).

dann scheint es Dir nicht mehr darum zu gehen auf die sachlichen Argumente einzugehen sondern darum, meine Beiträge zu kritisieren.

Deine sachlischen Argumente, bzw. die Logik die du verwendet hast um zu Schlüssen zu kommen war falsch. Darüberhinaus hast du nach eigener Aussage andere Dinge gemeint, als du zuerst geschrieben hast. Das festzustellen ist notwendig, damit ich mit deiner dargestellten Position überhaupt auseinandersetzen kann. Das ist nichts persönliches, und ich hab auch keine Freude dran Beiträge um ihrer selbst willen zu kritisieren, wie du mir so freundlich unterstellt hast. ;)

[Matthias Diehl]

Ich sagte ja nur das es so scheint. Leider rauche ich nicht mehr sonst würde ich Dir jetzt die Friedenspfeife anbieten :) Von meiner Seite aus ist alles (fachliche) gesagt. Vertragen wir uns wieder und warten auf den nächsten Thread zu dem Thema? :roll:

[guwapo]

(...) Server sitzt fröhlich hinter der Firewall von 1&1 (Cisco), die sehr große Adressranges per se blockt (Brasilien, China, etc brauchen wir nicht!). (...) blockt iptables (gefüttert durch ein Skript) einfach alles von der IP ab.

Ich bin immer wieder erstaunt Leute anzutreffen die tatsächlich IP-Ranges komplett sperren - klar es ist einfacher eine IP zu sperren, als die eigentliche Lücke zu schließen.

Davon mal ab, das IPs sperren (zumindest als dauerhafte Lösung) imho nicht wirklich sicher ist (gibt diverse möglichkeiten seine IP zu ändern ;) ), wo steht denn überhaupt, dass IPs aus Brasilien "Böse" sind? Hat man nicht aus der "Vergangenheit" nicht schon gelernt bestimmte Gruppen nicht zu pauschalisieren?
Es gibt genügende "bösen" IPs von deutschen, weil die ganzen Opas ihre Rechner nicht absichern können... (http://www.heise.de/newsticker/result.x ... -merkel.de)

Desweiteren sollte man nie Schutz "automatisieren", sonst kommen solche Lücken wie bei Denyhosts/F2B ;)

[flo]

klar es ist einfacher eine IP zu sperren, als die eigentliche Lücke zu schließen.

Und was ist die Lücke? Daß der Webserver Anfragen beantwortet, die automatisiert sind? :-) Bei den besagten Tools geht es nicht darum, per se Lücken zu vermeiden, sondern Brute Force auf Passwörter auszuschließen - Applikationsspezifische Lücken sichert die "Firewall" (=iptables!) eh nicht wirklich ab.

flo.

[Joe User]

Bei den besagten Tools geht es nicht darum, per se Lücken zu vermeiden, sondern Brute Force auf Passwörter auszuschließen

Das funktioniert allerdings mit geeigneter Konfiguration (pubkey) und/oder beispielsweise Portnocking wesentlich effektiver und vor Allem ohne Kollateralschäden...

[daemotron]

Das funktioniert allerdings mit geeigneter Konfiguration (pubkey) und/oder beispielsweise Portnocking wesentlich effektiver und vor Allem ohne Kollateralschäden...

Aber nicht bei öffentlich angebotenen Diensten (z. B. httpd, smtp, etc.) - und das sind erfahrungsgemäß die, die den meisten Angriffsversuchen ausgesetzt sind - und wenn man die diversen "Hilfe mein Server spammt" Threads hier im Forum zu Grunde legt - wohl auch die, die am erfolgreichsten angegriffen werden. Dagegen hilft weder Portknocking noch SSL-Auth oder ein Paketdropper - nur eine vernünftige Konfiguration, Security Fixes einspielen, ein gutes Risiko-Management und eine Portion Glück, dass man nicht von einem Zero-Day-Exploit erwischt wird...

[flo]

<...> vor Allem ohne Kollateralschäden...

Das Risiko sehe ich nicht - sicher, Public-key und/oder Portknocking sind bei ssh sinnvoll, aber nicht unbedingt bei einem SSL-Verschlüsselten vHost. Und hier greift dann wieder Hirn 1.0 - die "mein Provider hat meinen Rootserver super konfiguriert und der läuft jetzt auch schon drei Jahre" tangiert das eh nicht - ssh und Passwörter per Brute Force sind da wohl der am wenigsten empfindlichste Punkt, ergo die Tools nur eine Ergänzung zum vorhandenen Konzept.

Ich komme bei meinen Servern (bis auf einen) grundsätzlich noch per Konsole rein, mir ist es also relativ egal, ob mich einer per SSH rauswerfen möchte und eine Fehlermeldung mit meiner IP produziert.

[lord_pinhead]

Hach ja, einmal im kurzurlaub, schon schlägt man sich hier im Forum :D Ich werfs gleich mal rein, ist auch so ein ideologisches Thema: VI ist besser als Emacs ;)

Packetfilter sind in so fern nützlich wenn ein Dienst schlecht Programmiert wurde (99,9999% der Gameserver z.b.) und man einen Dienst nur von einer Adresse zugänglich haben möchte, oder eben wie schon erwähnt einen Dienst einer ganzen Schaar von Mitarbeitern zugänglich machen ohne sich vor der Welt nackt hinzustellen. Wobei ich letzteres doch lieber über ein VPN machen würde, OpenVPN ist da schnell eingerichtet. Aber wer hat im Forum je behauptet das eine IPTables Konfiguration vor einem Systemeinbruch schützt? Ich hab das nur mal in einem anderen Rootserver Hilfe Forum von Pseudo Administratoren gelesen und gelacht.

Ich finde es aber erstaunlich das noch nicht gefallen ist, das sich mit ein paar Byte Shellcode die IPTables Config komplett löschen lässt, die paar Byte bekommt man sogar auf milw0rm.org oder diversen Newsgroups. Noch ein netter kleiner Shellcode mit ran um das ganze als root auszuführen, und dann eingeschleust. Das schafft man am einfachsten über PHP ( system(), exec() ) und eine Connect Back Shell ( was für ein witziger Name ) verbindet dann einfach zum Hacker und stellt eine Shell zur Verfügung. Wenn dann via Cron die IPTables Config wieder geladen wird, ist es zuspät, den die Verbindung steht (state established) und es wird von der Konfiguration sowisso meist zugelassen. Wäre ja dumm wenn man alle 5 min eine unterbrechung in der SSH Verbindung hat :roll:

Ich bin persönlich der meinung, das eine Firewall auf einem Server eigentlich wirklich nix zu suchen hat, dazu sollte man wirklich eine dedizierte Kiste nehmen (die hoffentlich sicher ist) oder eine sogenannte "Hardware Firewall" (was auch nur ein Embedded System ist auf dem man oft Linux findet). Das entlastet nicht nur den Server, sondern auch die Leitung. Was bringt es mir wenn der Server versucht den Traffic zu regeln wenn er zu 80% ausgelastet ist? Verzögert alles nur. Je komplexer die Regelwerke werden (und die wachsen mit der Zeit), desto langsamer wird die Kiste.
Mal davon abgesehen das IPTables so extrem komplex ist, das die Manpage schon die Dicke der Bibel erreicht, gibt es massenhaft voreingestellter Scripte die meinen sie sind ein allheilmittel, nicht das noch im Titel steht "Ich bin der Weg"

Beispiel aus der Realität: Firma XXX hat ein Admin, der setzt zur einfachen Routerverwaltet IPCop ein. Dort ist IPTables mit Layer 7 Patches aktiv und alles was er einstellen konnte war eingestellt. Trotzdem kam ein Mitarbeiter mit seinem Laptop ins Netz, bekam eine IP vom DHCP und konnte saugen. Das trieb den Traffic der Standleitung in die höhe, entsprechend auch das Geld das die Firma zahlen sollte, und was war der Fehler? Man hat sich darauf verlassen IPCop das regelt, die Klicki Bunti Oberfläche war eingestellt, kein Schutz von unbekannt Mac-Adressen im DHCP und der Mitarbeiter nutzte eben ein Netzwerk das IPCop nicht kannte. Warum die IP Adresse genatet wurde ist eine gute frage, den von Haus aus müsste alles über einen Proxy, aber ich habe das Gefühl dass das noch Reste von der früheren Konfiguration war. Aber das verlassen auf eine einzelne Instanz, nähmlich IPTables mit dem Layer 7 Patch, kostete fast 500 Euro. Warum auf IPTables verlassen wenn die allgemeine Struktur fürn Eimer ist?

Und das ist auch bei den Dedizierten Servern so. Die "Admins" sind pflaumen, denken Webmin reicht und schalten darin die heulSuSe Firewall an und denken sie sind genauso sicher wie die Profis. Süß an sich oder nicht ;) Der erste wo das hier ins Forum schreibt bekommt den "Dau of the year award"

Wer daheim auf seinen Rechner eine Firewall hat, der sollte dabei bedenken das es schon einbrüche gab gerade WEIL eine Firewall auf den Rechner aktiv war. Kein Dienst, kein Angriff. Ein guter Ansatz für das ganze ist eigenlich auf http://dingens.org/, danach hat man keinen extenen Dienst mehr und ist entsprechend sicher. Getestet habe ich das ganze mit einem Windows XP unpatched und nach dem Dienste abschalten ins Netz gehängt (nur eine Bridge dazwischen). Massenhaft einträge in der Snortlog wegen Sasser und Konsorten, das störte aber die Kiste nicht. Also wozu brauche ich eine Ressourcen Fressende Firewall die 60 Euro oder mehr kostet wenn ein kleines 48 KB großes OSS Programm das ganze ersetzt? Danach kommt man nur noch durch Fehler in den Programmen der User ins System, aber das verbuche ich da eher ins Fach "Dummheit des Anwenders". Und jetzt kommt nicht mit den Standardantworten "mein Norten filtert alles" oder "Outpost/Kaspersky/Tinylittlefirewall macht mich sicher". Ich glaube aus dem Alter sind wir mittlerweile doch draussen. Den eine Firewall ist nur so gut wie die Regeln die es beinhaltet, die Signaturen die es hat oder wie gut sie Programmiert wurde. Und noch mehr Sachen laufen zu lassen damit ein Angreifer/Virus noch mehr Fläche zum hinpinkeln hat, das braucht man doch nicht. Ausserdem erinnern mich die Einträge in den tollen Firewalls immer an folgendes Bashscript:

Code: Select all

#!/bin/bash
echo -n Starting firewall.
while true; do
  sleep 1
  echo -n .
  if [ $(($RANDOM%13)) -eq 2 ]; then
     break;
  fi
  done
  echo
  echo Your system is now secure!
while true; do
  sleep $(($RANDOM%53))
  echo "Blocked attack from host
$(($RANDOM%256)).$(($RANDOM%256)).$(($RANDOM%256)).$(($RANDOM%255+1))
on port $(($RANDOM%65535+1))!!!"
done
exit 0

[gierig]

LOL,
das "Firewall Script" von Lord hat mich überzeugt.
Das setze ich ab jetzt auf meinen Lokalen Rechner ein. Dann bin ich endlich sicher :-)

Back to Topic so oder so ähnlich wurde ich (A) mal im ICQ vom einem Typen (F) angesprochen:

~~~~~~Schnapp~~~~~~~~
F: Nutzt du iptables auf deinen Server ?
A: Ja, nutze ich.
F: Cool, FW-Builder oder SuSecure110%SaveGuard oder 100%Secure.sh ?
A: Nicht von allem dem, ich habe selber nachgedacht.
F: WOW, kennst dich gut aus wa ? ist das besser als die oben geannten ?
A: Ahm, für mich ja!
F: Fette Sache, kann ich mal sehen ?
A: NÖ
F: Ach ich vestehe, glaubt wohl das ich dich dann Hacken kann, wa ?
A: LOL, warum soll ich DIR mein iptables scipt geben ? Kannst doch eh nicht mit anfangen
F: Echt versprochen, wenn ich nen Loch finde dan hack ich dich nicht OK ?
A: Und wiso immer hacken ? Warum glaubst du das du mich hacken kannst nur weil ich dir mein Iptables Script gebe ?
F: Na klar, wenn ich in dem Script nen Loch finde hack ich den Port.
A: LOCH ?
F: Wenn du was nicht geschützt hast
A: AH Du meinst Dienste auf den Ports 22, 25, 80, 110, 443, 143 oder ?
F: Ja, wenn die nicht geschüzt sind kann ich dich hacken
A: LOL, dann mal los. Die Ports werden nicht geschützt
F: scheinst dich dann ja doch nicht so auszukennen, wa ?
A: Wenn du meinst.
F: Ha, er bekommt angst
A: *PRUST* ja stimmt, ich kack mir gleich an bein vor angst
A: Weist du überhaubt was ich mit IpTables mache ?
F: Na deinen deinen Server absichern.
A: NE kein Stück. Ich nutz das nur um Portbezogende Traffic Statisiken zu erstellen.
F: Was ist den das ?
A: .....
~~~~~~~~Schipp~~~~~~~~~~~~


Ausage:
IPtables auf den Root macht sinn, wenn mann genau weiß was es in
diesem Contex zu leisten vermag und man auch genau weiß was nicht.

Gute Bereiche um Iptaples lokal auf dem Server zu nutzen wären für
mich Traffic Statisiken und Traffic Umleiten. Durchaus
denkbar (bei mir aber nicht nötig) wäre auch als zweite
Instanz um einzelne Dinsten nur für einzelene IPs erreichbar
zu machen. Wobei das WIRKLICH nur die zweite (oder erste) instanz
sein sollte. Der Dienst selber sollte schon Möglichkeiten besitzen
um einen User zuzulassen oder auch nicht (z.B mysql).

Ich denke man kann festhalten das "Firewalling" kein einzenes Programm
oder Tool ist das mann einmalig einstellt und dann Sicher ist.
Zu einer Firewall gehört ein komplettes Security Konzept, bei
dem mann sich NIE auf nur ein Programm verlässt oder sich in falscher Hoffnung wiegt.

[dodolin]

Sorry, wenn ich den alten Thread nochmal aufwärme, aber ich war im Urlaub und konnte daher nicht früher.

@dodolin - darum ging es nicht :-) iptables für Trafficvermeidung, das ist eben auf der Maschine selber nicht möglich, da der Traffic schon anfiel.

Klar, deine Aussage gilt aber nur für den eingehenden Traffic. Worauf ich abzielte war der zusätzliche ausgehende Traffic, den die Maschine selbst erzeugt. Insofern kann IPTables durchaus Traffic vermeiden, auch wenn es direkt auf dem jeweiligen System läuft. Dass ein externes Filtersystem effektiver ist, bestreite ich auch nicht, aber gerade im Rootserver-Umfeld ist sowas oft nicht im Preis inbegriffen und ein lokaler Filter mag dann besser sein als gar kein Filter.

[lord_pinhead]

Sorry das ich nochmal den Thread pushe aber das ist ja zu genial:

F: Ja, wenn die nicht geschüzt sind kann ich dich hacken
A: LOL, dann mal los. Die Ports werden nicht geschützt

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: