RootForum Community

Hallo,
ich habe jetzt 2 Tage lang alles gelesen was ihr hier so zu IPTABLES geschrieben habt.
Nun aber mein Gedanke.
Also, ich habe nur die Dienste laufen die ich auch will und brauche somit keine Firewall. Das is OK.
Nun aber mal angenommen den Fall es wird einer dieser Dienste gehackt wegen einer Sicherheitslücke. Somit hat der Hacker schonmal Userrechte (weil die Dienste ja nicht unter root laufen sollten) und kann somit irgendwelche Sachen starten, die irgendwelche ungewollten Ports aufmachen. Das ist nicht OK.
Wenn ich nun aber per IPTABLES erstmal alles sperre und die Ports aufmache die ich auch will, hat der Hacker keine chance irgendwelche Ports aufzumachen (weil dazu ja root Rechte nötig wären)
Somit ist mein Fazit das eine Firewall nicht von schlechten Eltern ist.

Aber ich bin für alles offen :-)

Mfg

Peter

Wenn dem so wäre, warum wird es dann nicht von jedem verantwortungsvollem Admin genutzt und tausendfach in jeder sicherherheitsrelevanten Dokumentation empfohlen?

Prinzipiell sind deine Ã?berlegungen richtig, d.h. eine Personal Firewall auf einem Endystem "kann" gegen gewisse Dinge schützen, sofern das Betriebssystem eine strikte Userverwaltung hat und die Personal Firewall als Root/Administrator/whatever läuft.

Andererseits bin ich persönlich der Meinung, dass man sich durch Blocking von OUTGOING Traffic extrem leicht in den eigenen Fuss schießen kann und dieser Nachteil wiegt (für mich) schwerer als die Vorteile, die man dadurch erhält.

Deshalb nutze ich keinen Paketfilter auf meinem Rootserver.
YMMV.

Wenn dem so wäre, warum wird es dann nicht von jedem verantwortungsvollem Admin genutzt und tausendfach in jeder sicherherheitsrelevanten Dokumentation empfohlen?

Wenn du dieser These also widersprichst, kannst du das auch belegen, warum sie falsch sein soll?

dodolin wrote:

Wenn dem so wäre, warum wird es dann nicht von jedem verantwortungsvollem Admin genutzt und tausendfach in jeder sicherherheitsrelevanten Dokumentation empfohlen?

Wenn du dieser These also widersprichst, kannst du das auch belegen, warum sie falsch sein soll?

Ich habe nicht behauptet, dass seine These als Solche falsch ist. Ich wollte lediglich die mögliche Interpretation seiner These als potentielle Wollmilchsau gar nicht erst aufkommen lassen. OK, der erste Halbsatz hätte etwas ausgeprägter formullliert sein können, am eigendlichem Inhalt meiner Aussage ändert dies allerdings nichts.

Nehmen wir mal an ich lasse auf meinem Server nur Apache laufen, dann koennte ich (vereinfacht, ich spar mir mal icmp, dns oder was man sonst noch so laufen lassen moechte) in der Firewall ausgehend nur TCP Pakete von Port 80 meiner Internet IP erlauben. Mit den stateful Optionen sogar noch eingeschraenkter. Sollte jemand eine Sicherheitsluecke in Apache oder einem Script ausnutzen und die Rechte vom Apache bekommen koennte er damit wenig anfangen, da er keine Pakete nach draussen schicken kann, da a) diese nur von Port 80 aus erlaubt werden und b) nur fuer schon bestehende Verbindungen.

Klar hilft das nicht gegen local root exploits. Aber es verhindert zum Beispiel einen ssh/ftp/http Daemon auf Port 1024+. Die Firewall bietet also in diesem Szenario zusaetzliche Sicherheit.

Als Gegenargumente hab ich bis jetzt nur gehoert:

1) es ist ein weiterer Dienst, der weitere Sicherheitsluecken enthalten koennte.

Hmm, stimmt, so wie jeder andere Dienst auch den man laufen laesst. Risikoabschaetzung sollte jeder selbst betreieben, aber soweit ich weiss ist iptables nicht als inherent unsicher bekannt. Ist also nur ein Argument wenn man gewillt ist auf JEDEN Dienst zu verzichten der Sicherheit bringt, also am besten keine IDS, keine Logfileparser, kein nichts.

2) man koennte fehleranfaellig/unvollstaendig konfigurieren bei der Firewall.

Ja, wie bei jedem anderen Dienst auch. Wenn man keine Dienste konfigurieren kann sollte man vielleicht keinen Server betreiben. Ist ein Argument gegen schlechte Administration und nicht gegen Firewalls.

3) Wiegt einen in falscher Sicherheit.

Das Dummschwaetz-Argument vor dem Herrn. Die falsche Sicherheit schafft nicht die Firewall, sondern die mentale Einstellung des Admin. Nicht jeder der ne Firewall benutzt haelt sie fuer eine goettliche Rundumloesung. Es gibt Leute die koennen das Pro und Contra abwaegen. Ich kenne nen Windows Admin der keinen Plan von Netzwerken oder Rechnersicherheit hat, keine Firewall und keinen Virenscanner benutzt, seinen Rechner so dicht macht dass er kaum an sein eigenes CD-Rom Laufwerk kommt und sich fuer sicher haelt... ganz ohne ne Firewall zu benutzen. Jeder der dieses Argument benutzt sollte mal ueberlegen was er da sagt: er behauptet der Gespraechspartner wuerde sich alleine durch seinen Wunsch nach einer Firewall schon disqualifizieren, waere leichtglaeubig oder sogardumm, usw. Das nennt sich Unterstellung, oder auch Beleidigung.

4) bringt keine zusaetzliche Sicherheit.

Fuer ein System in dessen Diensten niemals wieder Sicherheitsluecken auftauchen stimmt das, aber (siehe oben) fuer den Fall dass mal eine Sicherheitsluecke in einem gewollten Dienst auftaucht kann es sehr wohl etwas helfen. Es schafft also sehr wohl zusaetzliche Sicherheit, in einem Bereich den ich fuer nicht nur theoretischer Natur halte. Wenn ihr natuerlich kein ssh/http/ftp/etc laufen habt (hatten alle schon Sicherheitsluecken) oder sicher seit dass die Patches schon vor dem Bekanntwerden der Sicherheitsluecken geschrieben werden (und mir sagen koennt wie sowas gehen soll), koennt ihr auf diese zusaetzliche Schicht verzichten.

Ich moechte niemanden ueberreden eine Firewall zu benutzen, aber ich habe noch kein Argument gesehen dass wirklich GEGEN eine Firewall spricht. Bei den Gegenargumenten ist oft nur was in der Art "schafft truegerische Sicherheit weil du dumm bist und dann denkst du waerst sicher und alle anderen Dienste falsch konfigurierst" zu lesen, was einfach nur boesartige Unterstellungen sind. Ich koennte genauso behaupten Apache oder SSH schaffen truegerische Sicherheit. Ich lasse mich ja echt gerne eines besseren belehren, aber entweder habe ich noch kein Argument gegen eine Firewall gelesen oder die Argumentation nicht in der ganzen Tragweite verstanden.

in dem moment wo derjenige bei dir nen deamon oder sowas installieren kann, ist er sicherlich auch in der lage den iptables filter zu modifizieren ;)

Man sollte außerdem bedenken, dass, wenn ein Dienst gehackt wurde, und der Hacker nun die Rechte hat, unter dem dieser Dienst läuft, er einfach den gehackten Dienst beenden kann, und dann für seine Dienste den nun feien (und offenen) Port von dem gehackten Dienst nutzen kann. (uff, wasn Satz)

Funktioniert natürlich nicht bei Diensten, bei denen ein "parent" als root läuft, um Ports < 1024 zu öffnen.

Ansonsten denke ich auch, würde diese Methode "wirklich" bzw "effektiv" mehr Sicherheit bringen, würde dies auf viel mehr Sicherheitsseiten erwähnt werden. Dies ist aber nicht der Fall, somit kann die dadurch gewonnene Sicherheit nicht wirklich hoch sein...

Peter213 wrote:Hallo,
ich habe jetzt 2 Tage lang alles gelesen was ihr hier so zu IPTABLES geschrieben habt.
Nun aber mein Gedanke.
Also, ich habe nur die Dienste laufen die ich auch will und brauche somit keine Firewall. Das is OK.
Peter

hierzu meine ganz persönliche meinung/erfahrung :

ich hatte in den ersten wochen, während ich meinen root-server eingerichtet hatte, grosses glück, dass ich einen bastard genau erwischte, als er meine kiste hackte. auch ich hatte nur die dienst die ich wollte, aber noch keine filterregeln....! also : IMMER filter aktivieren, warum folgt nun :

gegeben sei folgendes szenario :
- dienst x hat einen fehler, pufferüberlauf mit shell-zugriff möglich
- der kernel hat einen bug, der root-rechte gewährt ( wie etwa der ptracebug in 2.4.23 ??? )

folgendes ist dann möglich:
- per wurm wird der schadhafte code an zig maschinen / minute verteilt, und ein dienst installiert, der sich beim "scheff" meldet.
- der scheff meldet sich dann auf dem installierten server an, installiert per shell einen root-exploit, und voila... ist root.

wären folgende filterregeln aktiv gewesen :
- verbindung eingehend nur zu definierten ports mit sicheren diensten.
- verbindung ausgehend nur zu "related" ports, die zu den o.g. verbindungen gehören, und zu wellknown-ports die nun mal unabdingbar sind, wie smtp etc.
siehe hierzu stichwort "ip_conntrack"

dann wäre die ausgehende anfrage des wurms unterbunden worden.

o.g. vorgehensweise ist natürlich kein 100%-paket, etwa könnte der scheff auf port 25 lauschen, aber das wird er in der regel nicht tun, da er anonym bleiben will, und deswegen über einen irc-kanal über seine bots herrscht, und nicht direkt mit seinem rechner. ABER es lässt sich hiermit einiges unerwünschte ausfiltern, wass nicht mit massiv kriminellem hintergrund getätigt wurde.

persönlich würde ich folgende massnahmen empfehlen :
- filterregeln ähnlich der o.g.
- insmod deaktivieren (etwa mit echo/no/suche/file>/proc/sys/kernel/modprobe)
- kernel updates IMMMER !!! und zwar IMMMER sofort machen
- über die security-mailingliste des linux-distributors, in der man natürlich eingeschrieben ist, gemeldete buggy software SOFORT !! und zwar SOFORT! updaten
- idealerweise hat man einen zweiten dns-eintrag für den entsprechenden server, der auf eine "momentane wartung" -seite für die zeit des reboots verweist.
- apache o.ä. IMMER im safe-mode betreiben.
- gelegentlich mal mit "chkrootkit" prüfen, ob was verdächtiges auf dem server ist.
- wichtige files 700 chmodden.
- logfiles von portscans per email veschicken

vielleicht kann die liste ja jemand ergänzen, x*2 augen sehen mehr als 2 :)
gruß,
steady

Was ein Unsinn. Wenn der Angreifer sowieso Rootrechte hat, kann er auch flugs ein iptables -F ausführen.

Ich stimme dir vielleicht sogar in ein paar Teilen zu, einen Punkt halte ich aber für hahnebüchenen Unsinn:

- logfiles von portscans per email veschicken

Wer solche Panik vor Portscans hat, sollte sich überlegen, ob er überhaupt einen öffentlich erreichbaren Rechner betreiben will. ;)

SCNR

Ã?ber solche Themen kann man Stundenlang referieren.

"Sicherheit" ist Pflicht, nur leider ist es nicht mit einmal updaten getan.
Man kann sich hinter noch so vielen Sicherheits- Tools verbarickadieren,
im Endeffekt erwischt es dich dann doch durch eine Hintertür die
du nicht beobachtet hast.

Ein kleiner Leitsatz: "A chain is only as strong as its weakest link".
Es ist also verschwendete Zeit den Schaden zu begrenzen und so
die Symptome zu "fixen", wenn die Ursachen noch offen sind. Ich
sollte diese Zeit lieber in das fixen von Ursachen investieren.

Dann noch: "A system should not be judged by how it works, but by how it fails."

Was passiert, wenn ich solche Filter "vermurkse", was für Seitenkanäle
gehen auf? (Wenn ich mich auf den Filter als Schutz verlasse und der Hacker
kann meine Filter so ändern dass ich nichts merke? Was passiert dann?)

Ich bin stark dafür, dass Serveradmins sich eine Scheibe mehr von
Kryptoanalytikern abschneiden sollten. (Stichwort Paranoia- Modell).

Zum Thema Updates: Nicht jede neue Version ist besser als sein Vorgänger
und Versioninitis kann der Nagel an deinem Sarg sein. Bitte immer schön
vorsichtig mit Wortkombinationen ala "IMMER SOFORT", mehr als einmal
hat ein panischer Patch mehr Schaden angerichtet als die Hacker
jemals selbst geschafft hätten.

Gruss,

Out

PS: Security ISN'T!

øxygen wrote:Was ein Unsinn. Wenn der Angreifer sowieso Rootrechte hat, kann er auch flugs ein iptables -F ausführen.

na wieso denn nun unsinn. es geht ja genau darum, dass der angreifer NICHT root-rechte bekommt.... :?

Wie will micht ein Portfilter vor local root exploits schützen? (Oder zumindest vor remote root?)

steady286 wrote:

øxygen wrote:Was ein Unsinn. Wenn der Angreifer sowieso Rootrechte hat, kann er auch flugs ein iptables -F ausführen.

na wieso denn nun unsinn. es geht ja genau darum, dass der angreifer NICHT root-rechte bekommt.... :?

War das nicht die Prämisse deiner Ã?berlegung:

steady286 wrote:gegeben sei folgendes szenario :
- dienst x hat einen fehler, pufferüberlauf mit shell-zugriff möglich
- der kernel hat einen bug, der root-rechte gewährt ( wie etwa der ptracebug in 2.4.23 ??? )

es ging mir vor allem um das "automatisierte" szenario :

Solch automatisierte Szenarien sind "in the wild" aber eher selten anzutreffen. ;)

steady286 wrote:- insmod deaktivieren (etwa mit echo/no/suche/file>/proc/sys/kernel/modprobe)

Den Support für Module und die initrd erst gar nicht zu aktivieren ist definitiv sicherer, als Dein echo.

steady286 wrote:- idealerweise hat man einen zweiten dns-eintrag für den entsprechenden server, der auf eine "momentane wartung" -seite für die zeit des reboots verweist.

Schwachfug, für diese ~2 Minuten braucht man soetwas nicht.

steady286 wrote:- apache o.ä. IMMER im safe-mode betreiben.

Apache != PHP

steady286 wrote:- gelegentlich mal mit "chkrootkit" prüfen, ob was verdächtiges auf dem server ist.

Und zum 1000sten mal mit der bindshell im RootForum aufschlagen?

steady286 wrote:- wichtige files 700 chmodden.

s/700/0400/

steady286 wrote:- logfiles von portscans per email veschicken

Siehe CCs Antwort.

Den Support für Module und die initrd erst gar nicht zu aktivieren ist definitiv sicherer, als Dein echo.

...und wenn's dann schon ein modularer Kernel sein soll (wogegen meiner Meinung nach wenig spricht) bitte wenigstens /dev/kmem schreibgeschützt.

Ich habe jetzt nicht alles hier gelesen aber hier ein Staement von 1&1 zum Thema Firewall auf nem Rootie:

http://faq.1und1.de/server/root_server/security/2.html

Gruß Outi

Anscheinend haben die auch Umgedacht. In der alten FAQ wurde ein Paketfilter IIRC empfohlen ;).

Tja, wie es aussieht, orientieren die sich jetzt ans Rootforum, zumal das Rootforum in der letzten PC Pro auch wieder genannt wurde .... ;):D

Gruß Outi

[x] Send Scan

Sascha wrote:Anscheinend haben die auch Umgedacht. In der alten FAQ wurde ein Paketfilter IIRC empfohlen ;).

Nö, es wurde lediglich geschrieben, dass man sich bei Bedarf selbst drum kümmern muss ;)

An den Paketfilter kann ich mich auch noch erinnern ....

Gruß Outi