RootForum Community

Der Titel klingt nach DAU, ich weiss ;-)

Vorwort: Ich kenne mich ein wenig mit IPTables aus und bin es gewohnt selbst Skripte dafür zu schreiben, aber zum Teil aus Zeitgründen und auch weil ich doch nicht perfekt darin bin, suche ich "fertiges".

Und zwar für einen rootserver (also eben kein Skript für NAT etc) ... Wenn ich nicht schon ca. 10 Stunden selbst gesucht hätte, würd ich hier nicht "so blöd fragen", aber ich fand eben nichts brauchbares. (Ich verwende Gentoo ohne X)

Da Ihr ja auch rootserver habt und das Problem Elementar ist, sollte es doch gute Lösungen geben, könnte man meinen.

Mir liegt auch was daran, dass das Skript nicht einfach zb Port 80 oder 22 freigibt, sondern entsprechend mit SYN und Co. umgehen kann, damit man eben die Vorzüge von IPTables nutzt und spoofing behindern kann. Logging sollte auch dabei sein.

Wenn mir keiner einen Tip disbezüglich geben kann, dann vielleicht einen Hinweis, wo ich mal eine gute Zusammenfassung finden kann, welche Vorgänge genau bei welchem Protokoll ablaufen und mit welchen Ports ... dann strick ich es mir dann doch selbst. (Natürlich kurz und bündig)

Danke für gute Tips!

PS: Meine Dienste: SSH, FTP (IN, OUT), HTTP(S) (auch IN, OUT), SMTP, IMAP, POP (TLS/SSL) ... ich glaub das war das Wichtigste.

bist Du Dir sicher, dass es fuer Dein Problem eine Loesung gibt? Es soll speziell fuer Deine Anforderung, aber am besten ein fertiges Script sein.
Die meisten hier verzichten wohl auf eine Firewall, eben weil es dedizierte Root-Server sind.

Und wo Du das Spoofing ansprichst, dagegen kannst Du eh nicht viel machen, denn wenn die gespooften Pakete bei Dir sind ist es eh zu spaet. Es sei denn, Du hast z.B. (UDP)-Dienste laufen, die haeufig mit einer IP-basierten Autorisierung eingesetzt werden (SNMP). Eine ganze Menge koennte man aber mit Bogus-Filtern rausschmeissen (mache ich auf meinen Rootservern auch nicht).

Und wenn Du wissen willst wie die Protokolle funktionieren solltest Du mit einem *guten* TCP/IP-Buch loslegen. Eines der besten (obwohl schon etwas aelter) ist http://www.amazon.de/exec/obidos/ASIN/0 ... lan2wan-21.

Hi,

ich beisse jetzt wohl doch in den sauren Apfel und kaue mich durch iptables und alles was dazu gehört. Ist garnicht so schlimm wie ich dachte.

Das Modul "state" hilft schnell vernünftige Regeln zu formulieren, die auf den Verbindungsstatus aufsetzen. Selbst habe ich das Firewallbuch von SuSE, dass mich aber mit seinen Beispielen nur mehr verwirrte ... vor allem werden diese immer für Workstations beschrieben und mit "state" wird kaum gearbeitet.

Man möge mich korrigieren, aber wenn ich das richtig verstehe: Ohne die Verwendung von --syn, -state oder ähnlichen Flags wird der Vorteil von Iptables, eben den Status der Verbindung zu prüfen nicht genutzt(?).

Also um es in einem Beispiel zu nennen, ein:
öffnet alle Tore für Atacken durch gefakte Antwortpakete und ähnlichem Mißt (richtig?).

Würde man mir zustimmen, dass folgende Zeilen vernünftige Regeln darstellen?

....z.B. http://www.giptables.org/

oder wenns komerziell sein darf, dann http://www.fx.dk

Hi,
ich hab mich ausgehend von einem Routingscript mal mit iptables auseinandergesetzt und so eine Art "Software-Firewall-Krampf" zusammenkopiert.
Das Script dient zum Experimentieren und ist NICHT für produktiven Einsatz irgendwo geeignet.
Link

Grundsätzlich ist ein iptables script auf Servern aber nicht unbedingt sinnvoll - wie schon erwähnt wurde ist's eigentlich eh schon zu spät wenn die SYN/ACK Fakes usw. auf der Netzwerkkarte ankommen und möglicherweise die iptables (!!Kernel!!) aus dem Takt bringen.
Ich erlaube mir hier mal frei aus dem Kopf zu zitieren:

Eine Firewall dient dazu Netzwerk A vor Netzwerk B zu schützen.

<edit>
http://de.wikipedia.org/wiki/Firewall

Cheers

tcs

Das aber die meisten root Server ohne online sind, bezweifle ich aber dann doch sehr stark

chaosad wrote:Das aber die meisten root Server ohne online sind, bezweifle ich aber dann doch sehr stark

Ich sehe den Einsatz von Netfilter nur als sinnvoll an, wenn du ein traffic accounting über iptables realisierst.

Was soll denn sonst eine 'firewall' auf einem root Server tun?
Entweder du öffnest einen Port indem du dahinter einen service lauschen hast, oder du läßt es (und der Port ist eh dicht)...

Du kannst ja den Dienst z.b. auf Teilnetze beschränken. Allemal besser als für alle zu erlauben meiner Meinung nach.

http://www.giptables.org/

Sehr gut! Das ist echt prima, genau was ich gesucht habe. Es sind natürlich noch Anpassungen nötig, spart mir aber viel Zeit.

Entweder du öffnest einen Port indem du dahinter einen service lauschen hast, oder du läßt es (und der Port ist eh dicht)...

Naja, die Dienste sind vielleicht aufgrund ihrer Natur nicht immer spezialisiert darin "böse" Anfragen zu erkennen und zu blockieren. Wenn es nicht möglich wäre einen Dienst mit falschen Paketen lahmzulegen, gäbe es ja gar keine Funktionalität, wie das Prüfen auf den Status der Verbindung seitens iptables.

So Dienste wie mysql kann man zwar auf lokal beschränken, aber ich wäre mir da nicht so sicher, dass er auf eine simulierte 127.0.0.1 Adresse nicht reinfallen würde. Oder verzeichne ich pro Tag mehrere Skript-Angriffe auf SSH (brutforce) ... das läßt sich mit iptables auch gut beschränken.

Und wenn man sich mal doch was einfängt, dann besteht vielleicht auch noch die Möglichkeit den Angriff auf andere zu unterbinden.

Ich glaube es gibt noch ein paar Beispiele, die die Verwendung von iptables in ein gutes Licht rücken.

Du kannst ja den Dienst z.b. auf Teilnetze beschränken. Allemal besser als für alle zu erlauben meiner Meinung nach.

Zeig mir den "Standard-Rootie"-Besitzer, für den diese Anforderung überhaupt besteht....na ja, vielleicht möchte ja jemand ausschließlich das Telekom-Netz, aus dem er per DSL surft freigeben. ;)

Wenn es nicht möglich wäre einen Dienst mit falschen Paketen lahmzulegen, gäbe es ja gar keine Funktionalität, wie das Prüfen auf den Status der Verbindung seitens iptables.

Ein Dienst bedient Layer 7, daher ist es höchstens der Payload, der dem Dienst zu schaffen machen kann. IPtables arbeitet (ohne besondere Maßnahmen) erheblich weiter unten im Stack. Alleine deshalb muss ein Dienst, den du nun einmal per Definition freigeben willst auf solche Eventualitäten vorbereitet sein. Wenn sich der Apache nunmal durch einen Buffer Overflow, hervorgerufen durch eine überlange Anfrage o.ä. aus dem Tritt bringen lässt, hätte dir dein tolles Script aus o.g. Grund auch nicht weiter geholfen.

So Dienste wie mysql kann man zwar auf lokal beschränken, aber ich wäre mir da nicht so sicher, dass er auf eine simulierte 127.0.0.1 Adresse nicht reinfallen würde.

Und wozu brauchst du da einen Paketfilter? Ich werf einfach mal als Stichwort "rp_filter" in den Raum. Ansonsten erzählt dir Onkel Google noch zusätzlich eine ganze Menge über Spoofing.

Oder verzeichne ich pro Tag mehrere Skript-Angriffe auf SSH (brutforce) ... das läßt sich mit iptables auch gut beschränken.

...und noch viel besser durch eine geeignete sshd-Konfiguration... :roll:

Und wenn man sich mal doch was einfängt, dann besteht vielleicht auch noch die Möglichkeit den Angriff auf andere zu unterbinden.

Ist heute der Tag der blauäugigen? ;)

Ich glaube es gibt noch ein paar Beispiele, die die Verwendung von iptables in ein gutes Licht rücken.

Na dann zeig mal...

Also unter SuSE kann man die Firewall auch über Yast konfigurieren. Ich weiß aber nicht, ob das zu empfehelen ist oder nicht.

Hallo CaptainC.

ich weiss ich bin kein Fachmann, aber nach dem wie ich das verstehe was ich glaube zu verstehen, kann man über (!) --syn (bzw -m state) schon losgelöste Pakete abwehren. (Also Pakete ohen Verbindungsaufbau)

Das mit SSH ist klar, ich verwende auch nur SSH mit Key, aber schon aus Prinip will ich nicht, dass hunderte von Anfragen täglich auf meinen Dienst eintrommeln (ich bekomme ja auch immer eine Mail wenn das passiert). Ein einfaches -m limit hilft da schon wunderbar.

Ich muss mich mal schlauer machen was Hackmethoden betrifft (nur aus Schutzgründen).

Was den Schutz von Innen heraus betrifft, kommt es natürlich darauf an, wie entsprechendes Programm arbeitet bzw von welchen Ports es auf welche zugreift. Aber Theoretisch kann man ja untersagen eine SSH Verbindung von meinem Server zu anderen zu erlauben und damit würde doch ein entsprechender Trojaner eben genau das nicht mehr können.

Naja, dummerweise will ich gerade das nicht verbieten und dann gibts noch den schei** FTP Dienst, der wirklich nicht schön zu integrieren ist (zb keine src-port Angabe möglich).

Gibt es denn für iptables kein Modul, dass man die Kommunikation/ Filterung an Programme/ Dienste binden kann (kenn ich so von Windows)?


Hallo web-gear,

das mit SuSE's Yast ist sicher bekannt. Ich verwende jedoch Gentoo als System und da ist es mehr Handarbeit. Auch weiss ich nicht, ob Yast mehr auf Workstations abzielt was die Firewall betrifft. Der Vorschlag mit "giptables" war schon recht gut (setze ich nun ein). Aber danke für deinen Hinweis.

velo wrote:Gibt es denn für iptables kein Modul, dass man die Kommunikation/ Filterung an Programme/ Dienste binden kann (kenn ich so von Windows)?

Owner match

Ok und wenn sie unter root laufen? Dann kann so jeder, der root ist auch Verbindungen herstellen. Gibt es nichts auf Programmebene?

aber nach dem wie ich das verstehe was ich glaube zu verstehen, kann man über (!) --syn (bzw -m state) schon losgelöste Pakete abwehren. (Also Pakete ohen Verbindungsaufbau)

Empfohlene Doku: diverse RFCs zu TCP und IP.
Ja, man kann damit Verbindungsversuche ohen vorhegegangenes SYN "abwehren". Ich wüsste allerdings nicht, was du dadurch abwehren willst wenn du (man möge mir diese "Arroganz" verzeiehen) nicht genau verstehst, was du da überhaupt tust, und was du eigentlich damit "abwehren" willst.

aber schon aus Prinip will ich nicht, dass hunderte von Anfragen täglich auf meinen Dienst eintrommeln (ich bekomme ja auch immer eine Mail wenn das passiert).

Die von mir eingesetzten HIDS lassen sich auch für solche Situationen "feintunen". Darüber hinaus wüsste ich nicht, worüber ich mir Sorgen machen müsste, denn die paar Verbindungsversuche lassen meinen sshd ziemlich kalt. Sorgen mache ich mir höchstens dann, sobald ein neuer Bug in einem der frei angebotenen Dienste auftaucht, was ich zum Glück fast immer sehr schnell mitbekomme.

Ich muss mich mal schlauer machen was Hackmethoden betrifft (nur aus Schutzgründen).

Wieso nur aus Schutzgründen? Und wo ich gerade beim Erbsen zählen bin: vermutlich meinst du eher Crackermethoden. ;)

Aber Theoretisch kann man ja untersagen eine SSH Verbindung von meinem Server zu anderen zu erlauben und damit würde doch ein entsprechender Trojaner eben genau das nicht mehr können.

Irgendwie zeigt mir die Trojaner-Aussage, dass du noch sehr im Windows-Umfeld verwurzelt bist. Zeig mir doch mal den gefährlichen Unix-Trojaner, der immer noch hunderte oder tausende System vollautomatisiert "0wn3d". Natürlich gab's da ein paar Vorfälle, aber im Gegensatz zu Code Red hört, sieht und liest man darüber nichts mehr.
Weiterhin: Die Idee, Verbindungen nach außen kontrollieren zu können ist an sich ganz und gar nicht verkehrt. Je nachdem, wie (und vor allem wer) trotz allem auf deine Kiste kommt, hast du ohnehin verloren, ob mit oder ohne. Einfaches Beispiel: durch eine kürzlich aufgetrenene Lücke in AWStats war es selbst für Scriptkids ein einfaches, Maschinen remote zu übernehmen, und dabei Rootrechte zu erlangen. Sobald jemand auf deiner Kiste root ist, ist er die Kiste selbst, und kann damit tun und lassen, was er / sie will.

Was die DIenste angeht, die unter root laufen: nutz einen vernünftig gecodeten und / oder konfigurierten Dienst, dann hast du dieses Problem schon mal nicht mehr.[/quote]

texmecx wrote:....z.B. http://www.giptables.org/

http://www.zataz.net/adviso/giptables-05222005.txt