server gehackt?

menace

Well-Known Member
Hallo,
ich wollte mal fragen, ob mein server gehackt wurde, wenn ich beim nmap scan von zuhause "445/tcp filtered microsoft-ds" fuer die Box vorfinde, aber sockstat (mittels sockstat -4 oder auch sockstat | grep -i 445) mir keinen listening port preisgibt.
Das komische ist, bis auf ein squirrelmail interface (das öffentlich auch nicht gerade leicht zu entdecken ist), ist da kein php-zeug, und sshd, lighttpd und postfix vertraue ich dann doch. die sind auch alle aktuell.
kann es für den output von nmap noch einen anderen grund geben?
ich finde auf dem system für einen einbruch halt sonst gar keine anzeichen, das einzige was sein könnte, wäre ein bsd-kernelrootkit (nix anders könnte nen einbruch so gut verdecken, hab echt alles abgesucht ...)
 
ich wollte mal fragen, ob mein server gehackt wurde, wenn ich beim nmap scan von zuhause "445/tcp filtered microsoft-ds" fuer die Box vorfinde, aber sockstat (mittels sockstat -4 oder auch sockstat | grep -i 445) mir keinen listening port preisgibt.

Dann läuft da auch nix (filtered). Um ganz sicher zu gehen, aktiviere mal ipfw oder pf und lass wirklich nur das rein, was wirklich rein sollte. Was auf einem Server eh zum guten Ton gehört.
 
was soll man bitte für einen computer mit pf filtern? Ich mein, es kommen doch eh bloss Anfragen auf den Ports rein, wo es soll? Und auf Ports wo nichts läuft, brauch ich auch nichts? Fängt ja schon wie bei den desktop firewalls an oO
 
Und auf Ports wo nichts läuft, brauch ich auch nichts?
Wenn Du sicher bist, das da nix lüppt brauchste a auch keine FW.
Im Prinzip ist es aber eine weitere Hürde die genommen werden muss um "schadkommunikation" durchführen zu können... Hürden sind immer gut :D
Je schwerer desto besser.
 
zum erschweren des Scannen und zum Schutz vor flooding. Server im Netz sollten aus diesen Gründen dringend Firewalls haben. Leider ist nicht jeder Teilnehmer des Internets vernünftig. Bei Desktops ist es streitbar, ob man diese Sicherheit braucht zumal meist noch ein NAT router dazwischen ist.

Ich würde auch dringend zu einer Firewall raten, weil
Ich mein, es kommen doch eh bloss Anfragen auf den Ports rein, wo es soll?

das eben nicht der Fall ist, Server im Netz sind auf allen Ports ständigen scans ausgesetzt.

Deiner Nachfrage nach solltest du dich wirklich fragen, ob du dich dazu fähig fühlst einen Server abzusichern. Klingt zwar hart, aber es gibt genug Spam- und Virenschleudern und Botnet-Server. Letzteres ist sogar eher ein Problem bei linux/unix Servern, bevor jemand hier wieder shreit, das passiert eh nur bei den Betriebsystemen aus Redmond.

Ein System ist nur so sicher wie man es macht.
 
ich wollte mal fragen, ob mein server gehackt wurde, wenn ich beim nmap scan von zuhause "445/tcp filtered microsoft-ds" fuer die Box vorfinde, aber sockstat (mittels sockstat -4 oder auch sockstat | grep -i 445) mir keinen listening port preisgibt.

Wieso sollte da sockstat irgendwas finden? Da steht nicht open sondern filtered. Das bedeutet nur, dass irgendwer auf dem Weg zum Ziel, noch nichtmal unbedingt der Zielrechner selbst, diesen Port blockiert. Wird wohl vermutlich der Provider sein der es satt hat, dass die Windowsnutzer dauernd ihre Broadcasts ins Netz blasen und sich gegenseitig ueber offene Microsoft Netzwerk Ports mit Viren infizieren.
 
Bei Desktops ist es streitbar, ob man diese Sicherheit braucht
desktop-firewalls bringen eigentlich nur den sinn der selbstüberwachung. wenn man halt software einsetzt die nicht frei ist, weiß man ja auch nicht ob sie vertrauenswürdig ist, bzw. windowsmenschen setzen ja auch software ein von der sie wissen, dass sie nicht vertrauenswürdig ist.
 
Eine Software wird nicht vertrauenswuerdig, nur weil sie quelloffen ist. Ich kann dir gerne eine OpenSource Backdoor schicken ;)
 
Eine Software wird nicht vertrauenswuerdig, nur weil sie quelloffen ist. Ich kann dir gerne eine OpenSource Backdoor schicken ;)
"opensource software" wird aber normalerweise nicht verbreitet indem person x person y ein datei schickt, sondern über etwas wie die ports. und bei der großen menge an entwicklern denen die software dann ausgesetzt ist, ist die wahrscheinlichkeit relaiv gering unentdeckt zu bleiben.
 
zum erschweren des Scannen und zum Schutz vor flooding. Server im Netz sollten aus diesen Gründen dringend Firewalls haben.
Wenn die Firewall auf einem separaten System vor dem Server steht, ACK. Ansonsten IMHO Blödsinn. Wenn Du offene Ports auf einem Internet-Server hast, die nicht entdeckt werden sollen, ist mit Deiner Serverkonfiguration was oberfaul. Und ein Paketfilter auf einem Single Host System schützt Dich kaum vor Flooding... Im Gegenteil, da das Paket den IP-Stack ohnehin ein Stück weit durchlaufen muss, machst Du es einem Angreifer noch leichter, Dich außer Gefecht zu setzen - durch das Überprüfen des Pakets verbrätst Du pro Paket sogar noch mehr Ressourcen, und Ziel eines Flooding-Angriffs ist es ja, den Server über seine Ressourcengrenzen hinaus zu belasten.

das eben nicht der Fall ist, Server im Netz sind auf allen Ports ständigen scans ausgesetzt.
Und was macht das, wenn auf dem Port eh kein Dienst lauscht? Wenn jemand meint, mit nmap herausfinden zu müssen, dass auf Port 80 meines Servers ein öffentlicher HTTPd läuft - herzlichen Glückwunsch, das muss ein obergefährlicher Hacker sein *SCNR*

Deiner Nachfrage nach solltest du dich wirklich fragen, ob du dich dazu fähig fühlst einen Server abzusichern. Klingt zwar hart, aber es gibt genug Spam- und Virenschleudern und Botnet-Server.
Ich frage mich wirklich, ob Dir bewuss ist, wie TCP/IP und entsprechende Filter funktionieren. Schau Dir mal Sinn und Unsinn von Firewalls auf Rootservern an. Die meisten Angriffe auf Internet-Server (und da namentlich die Webserver) erfolgen auf der Applikationsschicht. Jeder noch so toll konfigurierte Paketfilter wird das betreffende Paket aber passieren lassen, weil Kommunikation auf Port 80 erlaubt/erwünscht ist.
 
Schau Dir mal Sinn und Unsinn von Firewalls auf Rootservern an.
Danke für den Link. Interessant.
Ich für meinen Teil benutze Firewalls nicht nur um eingehenden Verkehr, sondern auch ausgehenden zu reglementieren. Zusätzlich noch eine aktive IP-Filterung um diesen SSH Brute Force Attacken Herr zu werden.
 
Wenn die Firewall auf einem separaten System vor dem Server steht, ACK. Ansonsten IMHO Blödsinn. Wenn Du offene Ports auf einem Internet-Server hast, die nicht entdeckt werden sollen, ist mit Deiner Serverkonfiguration was oberfaul.

Muss man relativieren. Auf einer ans Internet angeschlossenen Workstation oder auf einem Rootserver kann ich manchmal nur schwer kontrollieren, welche Dienste tatsaechlich aktiv werden. Vielleicht probiere ich mal irgendeine Software aus, vielleicht habe ich irgendwo nicht richtig gelesen oder irgendeine frisch compilierte Software gestartet und noch die default Passworte drinnen ...

Selbstverstaendlich ist dann irgendwas oberfaul. Wenn alle alles richtig machen, gibts kein Problem. Das Problem tritt dort auf, wo irgendwem ein Fehler unterlaeuft. Und ein aktivierter Paketfilter gibt mir eine zusaetzliche Stufe von Sicherheit. Ich kann damit exakt definieren, auf welchen Ports Dienste vorgesehen sind. Ein versehentlich/testhalber gestarteter Daemon ist nicht erreichbar. Insofern wuerde ich durchaus dazu raten, wenn man Systeme schon direkt ans Netz anschliesst (wozu ich nicht rate!), dort wenigstens den Paketfilter entsprechend zu aktiveren (incoming policy deny und dann einzelne Dienste freischalten.

Eine weitere Moeglichkeit ist das Nutzen der Faehigkeit des Paketfilters, auf Nutzer und Gruppen zu filtern. Das ist ueberhaupt nur auf dem gleichen Host moeglich.

Sicher ist dieses Verfahren gegenueber allen Szenarien, bei denen der Angreifer nur Nutzerrechte erlangt. Sobald er natuerlich administative Rechte erlangt, ist ein Filter auf dem gleichen System, man muss es kaum erwaehnen, natuerlich voellig untauglich. Aber das sind Zugriffsrechte dann auch und trotzdem setze ich sie. Vielleicht hilft es, wenn man sich einen Paketfilter auf einer Workstation als eine Art Zugriffsrechte auf Ports vorstellt. Hier von Firewall zu sprechen, fuehrt nur zur Verwirrung. Eine Firewall ist mehr als ein Paketfilter.
 
Hallo!

Muss man relativieren. Auf einer ans Internet angeschlossenen Workstation oder auf einem Rootserver kann ich manchmal nur schwer kontrollieren, welche Dienste tatsaechlich aktiv werden.
Der Admin muss das wissen. Er ist der derjenige, der Dienste installiert und startet oder eben nicht. Wenn der Admin nicht weiß, was er da tut, dann weiß er auch nicht, was ihm der Paketfilter bringt und vermutlich weiß er auch nicht, wie er ihn richtig konfiguriert. So ein "Admin" hat von vornherein verloren.

Dass ein Paketfilter auf einem Root-Server Sinn machen kann will ich nicht bestreiten. Ich wehre mich aber gegen die Aussage, dass man einen Paketfilter einsetzen muss (und dass man das dann auch noch "Firewall" nennt). Wenn nur Dienste auf erreichbare Interfaces gebunden sind, die auch erreichbar sein sollen, dann darf man den Paketfiler ruhig weglassen. Es muss halt klar sein, dass der Server dann nicht für Experimente geeignet ist.

Vielleicht probiere ich mal irgendeine Software aus, vielleicht habe ich irgendwo nicht richtig gelesen oder irgendeine frisch compilierte Software gestartet und noch die default Passworte drinnen ...
Mit dem gleichen Argument kannst du aber auch vergessen einen Port mit dem Paketfilter zu vernageln. Ein öffentlich erreichbarer Server ist nunmal kein Spielzeug. Getestet wird in einem Labor, nicht öffentlich.

Insofern wuerde ich durchaus dazu raten, wenn man Systeme schon direkt ans Netz anschliesst (wozu ich nicht rate!), dort wenigstens den Paketfilter entsprechend zu aktiveren (incoming policy deny und dann einzelne Dienste freischalten.
In erster Linie muss sich der Admin darüber im Klaren sein, welche Konsequenzen es hat, einen öffentlich erreichbaren Server ans Internet anzuschliessen. Er selbst kennt das Einsatz-Szenario und kann abschätzen, ob ein Paketfilter sinnvoll ist (kann er das nicht, muss er jemanden damit beauftragen, der das kann).

Man könnte jetzt noch argumentieren, dass ein korrekt konfigurierter Paketfilter selten ein Nachteil sein wird, aber dann sind wir wieder bei "wenn jeder alles richtig machen würde..." (Henne <-> Ei).

Eine weitere Moeglichkeit ist das Nutzen der Faehigkeit des Paketfilters, auf Nutzer und Gruppen zu filtern. Das ist ueberhaupt nur auf dem gleichen Host moeglich.
Das ist schon ein spezielles Szenario und daher in dieser Diskussion Off-Topic. Hier ist klar, dass man das nur mit dem Paketfilter erreichen kann.

Eine Firewall ist mehr als ein Paketfilter.
Full ACK.

Bitte nicht flasch verstehen. Ich administriere selbst 2 öffentlich erreichbare Server auf denen ich den Paketfilter aktiviert habe, weil es das Einsatz-Szenario erfordert (bestimmte Dienste dürfen nur einem sehr eingeschränkten Nutzerkreis grundsätzlich zur Verfügung stehen).

Ciao.
Markus Mann
];-)
 
Wenn Du offene Ports auf einem Internet-Server hast, die nicht entdeckt werden sollen, ist mit Deiner Serverkonfiguration was oberfaul

ssh mal nur als Beispiel...
Ansonsten wenn man einen Server hat der wirklich nur etwas auf port 80 anbietet, gebe ich dir Recht, nur wer hat das schon.

Und ein Paketfilter auf einem Single Host System schützt Dich kaum vor Flooding... Im Gegenteil, da das Paket den IP-Stack ohnehin ein Stück weit durchlaufen muss, machst Du es einem Angreifer noch leichter, Dich außer Gefecht zu setzen - durch das Überprüfen des Pakets verbrätst Du pro Paket sogar noch mehr Ressourcen, und Ziel eines Flooding-Angriffs ist es ja, den Server über seine Ressourcengrenzen hinaus zu belasten.

layer 7 ist dir ein Begriff? gerade wenn da ein Dienst lauscht.

Ich frage mich wirklich, ob Dir bewuss ist, wie TCP/IP und entsprechende Filter funktionieren. Schau Dir mal Sinn und Unsinn von Firewalls auf Rootservern an. Die meisten Angriffe auf Internet-Server (und da namentlich die Webserver) erfolgen auf der Applikationsschicht. Jeder noch so toll konfigurierte Paketfilter wird das betreffende Paket aber passieren lassen, weil Kommunikation auf Port 80 erlaubt/erwünscht ist.

man kann aber bei zu vielen Anfragen die source-address blocken, also Flood Schutz der Applikation. Wie oft genug erwähnt, es kann mehr als nur stupide blocken. Gut habe keine Details gegeben bei meinen ersten Post, da sind Missverständnisse vorprogrammiert.
 
Zuletzt bearbeitet:
soul_rebel: Ich gehe mit deiner Einstellung bzgl. Desktopfirewalls konform, allerdings kenne ich sogar Netzwerk-lehrstühle von Unis und FHs, die das auf Windows einsetzen. Und irgendeinen Grund werden die wohl haben. Vielleicht stehen sie auf defensive in-depth, keine Ahnung :)

Deiner Nachfrage nach solltest du dich wirklich fragen, ob du dich dazu fähig fühlst einen Server abzusichern. Klingt zwar hart, aber es gibt genug Spam- und Virenschleudern und Botnet-Server.
Boah, ich kann den Spruch so nicht mehr hören. Geh sterben.(und alle anderen, die sowas sagen gleich mit, im Channel gibts ja auch so ein paar Exemplare, die das pauschalisiert nach aussen tragen)
Ich weiß wie ich meinen Server sicher zu konfigurieren habe. Das nennt sich dann Betriebssystemsicherheit. Wenn ich dann einen Aspekt der Netzwerksicherheit nicht vollständig kenne, deklassifiziert das nicht meine Qualifikation, den Rechner vor feindlicher Übernahme zu schützen. Achja, selbst erfahrenen Admins wurden schon Kisten aufgemacht. Sind die auch alle zu dumm, Kisten zu administrieren?

Deshalb, lasst das Argument im Stammtisch, wo's hingehört.

Danke.
 
Boah, ich kann den Spruch so nicht mehr hören. Geh sterben.(und alle anderen, die sowas sagen gleich mit, im Channel gibts ja auch so ein paar Exemplare, die das pauschalisiert nach aussen tragen)
Ich weiß wie ich meinen Server sicher zu konfigurieren habe. Das nennt sich dann Betriebssystemsicherheit. Wenn ich dann einen Aspekt der Netzwerksicherheit nicht vollständig kenne, deklassifiziert das nicht meine Qualifikation, den Rechner vor feindlicher Übernahme zu schützen. Achja, selbst erfahrenen Admins wurden schon Kisten aufgemacht. Sind die auch alle zu dumm, Kisten zu administrieren?
Deswegen schrieb ich du solltest _dich_ selber Fragen, aber betroffene Hunde bellen ;)
 
Der Admin muss das wissen. Er ist der derjenige, der Dienste installiert und startet oder eben nicht. Wenn der Admin nicht weiß, was er da tut, dann weiß er auch nicht, was ihm der Paketfilter bringt und vermutlich weiß er auch nicht, wie er ihn richtig konfiguriert. So ein "Admin" hat von vornherein verloren.

Wir reden hier von Multiuser Systemen. Jeder normale Anwender kann auf so einem System einen Socket oeffnen. Jeder unprivilegierte Prozess kann einen Port oeffnen. Zahlreiche Angriffe verlaufen so, dass ueber Buffer Overflows Code eingeschleust wird, der einen Port oeffnet. Verloren hast Du als Admin wenn Du Dir einbildest, das alles zu jedem Zeitpunkt lueckenlos ueberwachen zu koennen. Stimmig ist ein Konzept erst dann, wenn es die eigene Fehlbarkeit einplant.

Es geht am Ende darum, dass Dir die Kiste nicht geknackt wird und dass, falls sie geknackt wird, der Schaden begrenzt bleibt. Da ist mir jedes erdenkliche Mittel recht. Wenn Kratzen und Spucken was helfen wuerde, taet ich das auch noch machen. Die gaengigen Analysen fabulieren gerne von "kein nennenswerter Sicherheitsgewinn". Fuer mich ist nicht nur _jeder_ Sicherheitsgewinn[1] nennenswert, ich geb mich sogar schon mit verminderten Wahrscheinlichkeiten zufrieden. Sobald irgendwann mal ein beweisbar sicheres System auf den Markt kommt, aendere ich meine Ansichten dazu vielleicht. So lange aber noch jede existierende Software mit an Sicherheit grenzender Wahrscheinlichkeit Fehler aufweist und Sicherheit damit zur Worthuelse wird, senke ich weiter Risiken. Und in dieses Konzept passen Portfilter wie die Faust aufs Auge.

[1] Das Wort ist im Grunde schon grober Unfug. Entweder ist irgendwas sicher oder es ist nicht sicher. Da gibts keinen Gewinn. Alle gegenwaertigen Betriebssysteme+Applikationen sind unsicher, so lange sie nicht beweisbar sicher sind. Also gehts schon von vornherein nur um Risikobegrenzung. Echte Sicherheit gibts irgendwo bei den Verschluesslern. Nicht beim Betrieb von Servern.
 
Deswegen schrieb ich du solltest _dich_ selber Fragen, aber betroffene Hunde bellen
ja weil
a) man mit minderwertigkeitskomplexen trotz ausbildung sich immer noch unterqualifiziert fühlen kann
b) weil channelflamer jtsn mir (und auch genügend anderen) das oft/gerne an den kopf wirft.
 
ja weil
a) man mit minderwertigkeitskomplexen trotz ausbildung sich immer noch unterqualifiziert fühlen kann
b) weil channelflamer jtsn mir (und auch genügend anderen) das oft/gerne an den kopf wirft.

Hallo menace,

also nicht verrückt machen lassen, sicher ist es ärgerlich wenn der server gehackt wird, aber das passiert auch den grossen Admins hin und wieder..

Gibt da genug Beispiele in jüngster und älterer Vergangenheit und die sind meistens besser ausgestattet als das Gro..

Wie wäre es denn wenn Du Dir mal einen Honeypot aufsetzt und dann mal schaust was Die Jungs so alles anstellen....

Kann man sehr viel bei lernen ;)

Deshalb versuchen seinen Weg zu gehen und sich nicht verrückt machen lassen, das Leben ist ein stetiger Lernprozess..

In diesem Sinne rudy :)
 
Hallo!

Achja, selbst erfahrenen Admins wurden schon Kisten aufgemacht. Sind die auch alle zu dumm, Kisten zu administrieren?
Da hast du recht, so allgemein gilt das nicht, sorry. Mir ist auch schon ein Server abhanden gekommen, obwohl ich eigentlich weiß was ich tue. In dem speziellen Fall war es aber meine Dummheit, die den Einbruch möglich machte, soviel muss man sich dann schon eingestehen. Man muss natürlich unterscheiden, ob jemand einen Fehler gemacht hat, oder ob er gar nicht abschätzen kann, was man generell unternehmen kann um einen Server abzusichern.

Jedes Szenario ist anders und man kann immer nur für das aktuelle Szenario entscheiden was richtig ist. Aber man sollte das eben entscheiden können und nicht nur von HOWTOs abschreiben ohne genau zu wissen, was man da macht.

Deshalb, lasst das Argument im Stammtisch, wo's hingehört.
Ich finde nicht, dass diese Diskussion auf dem Niveau geführt wird. Es geht nicht darum jeden als Deppen abzustempeln, der schonmal einen Fehler gemacht hat. Es geht darum, dass andere Menschen Schaden erleiden können, wenn öffentlich erreichbare Kisten von Leuten administriert werden, die der Sache nicht gewachsen sind. Klar muss man irgendwo mal anfangen, aber spielen sollte man zuerst Zuhause.

Ciao.
Markus Mann
];-)
 
Zurück
Oben