Server absichern

[matzewe01]

suexec mit CGI oder fcgi ist natürlich Pflicht.

Trotz suexec kann ich auf meinem forum phpinfo(); ausführen und ausgeben lassen ....

 

[chris085]

Zu deinem ersten Post:
Ich finde es gut dass du/ihr euch in dieser Hinsicht engagiert und auch mal die Dreckspatzen die Konsequenzen spüren lasst.

Die Lücke im angesprochenen CMS hat jetzt aber nichts mit ssh & Port versetzen zu tun.
Der Einbruch wurde also über fehlerhafte Scripte im CMS getätigt.

Man kann solche Gefahren aber eingrenzen, wenn man entweder den Safe mod von PHP einschaltet und/oder das Binary als cgi parsen lässt.
Es läuft dann ausschließlich mit Benutzerrechten und kann zu mindestens nichts von anderen Kunden beschädigen.

 

[danton]

Ich gehöre auch zu den Leute, die den SSH-Port nicht verlegen, sondern dort lassen, wo er hin gehört. Die meisten Angriffe der Script-Kiddies laufen ohnehin auf eine Bruteforce-Attacke hinaus und da tun Programme wie Fail2ban gute Dienste. Und auch diese habe ich auf meinen Servern schon deutlich häufiger beobachtet. Mittlerweile sind wahrscheinlich ausnutzbare Lücken in Webapplikationen etc. einfacher zu hacken, um Zugriff auf einen Server zu erhalten. Und gerade Spammer brauchen IMHO ja oft nicht mehr, um ihren Code auf einem Server unterzubringen und dann die Spams zu versenden. Wenn das Verlegen des SSH-Portes ein guter Sicherheitsgewinn ist, dann müßte das doch für die Verlegung eines Webserver-Ports ebenso gelten, oder? MAcht aber keiner, und die Gründe kennen wir ja alle.
Der Webserver wird dann anders abgesichert. Und genauso kann ich auch SSH absichern, ohne einen anderen Port zu verwenden. Und dann bin ich an dem Punkt, das der Sicherheitsgewinn so gering ist, daß der Komfortverlust zu groß wird.
Security by Obscurity ist nun mal eine eher trügerische Sicherheit.

 

[Roger Wilco]

Man kann solche Gefahren aber eingrenzen, wenn man entweder den Safe mod von PHP einschaltet und/oder das Binary als cgi parsen lässt.

Der Safe Mode wird mit PHP 6 zu Recht verschwinden. Sich darauf zu verlassen, dass der Safe Mode die Umgebung tatsächlich sicherer macht, ist mutig.

Es läuft dann ausschließlich mit Benutzerrechten und kann zu mindestens nichts von anderen Kunden beschädigen.

Das setzt aber auch ein durchdachtes und getestetes System voraus. Die meisten Anleitungen, die es dazu im Netz gibt, laufen letztlich darauf hinaus, dass das DocumentRoot der Benutzer zumindest world-readable ist.

Somit hat im schlimmsten Fall jedes amoklaufende Skript lesenden Zugriff auf die darin enthaltenen Dateien, etwa Konfigurationsdateien, welche die Zugangsdaten zur Datenbank eines Forums oder Blogs beinhalten können.

Damit hat der geübte Angreifer dann auch schnell eine Liste von Benutzernamen, ggf. deren E-Mail-Adressen und Passwörtern oder zumindest Hashes, die ungesalzen mit einer Rainbowtable auch sehr schnell geknackt werden können. Es ist leider traurige Realität, dass die meisten Leute ihre Passwörter nicht variieren und wie es dann von diesem Punkt ab für den Angreifer weitergeht, kann sich jeder selbst überlegen.

 

[matzewe01]

Die meisten Angriffe der Script-Kiddies laufen ohnehin auf eine Bruteforce-Attacke hinaus und da tun Programme wie Fail2ban gute Dienste.

Der Einsetz 2.ter und 3. Tools jedoch erhöht die Fehleranfälligkeit und das Risiko an potentiellen weiteren Sicherheitlöcher, drastisch. Einen ambitionierten Angreifer jucken solche tools jedoch auch nicht. Er findet ebenfalls Wege dieses zu umgehen.

 

[Mr.Propper]

Och Jungs und Mädels,

Ich wollte doch ledigluch nur wissen ob ihr noch Tips habt.
Muss den grundsätzlich jeder Thread im SSF in einer endlosen Diskussion enden?

Nun beende ich das aber hier soweit es von meiner Seite aus möglich ist aber zum Abschluss noch meine Absicherung.

ssh port geändert
denyhosts in verbindung mit iptables
mod-evasive
Apache: ServerTokens Prod und ServerSignature Off
MySQL: Verbindung von aussen blockiert
SSH Login NUR über Public-Key-Authentifizierung
kleines bash script das wenn doch wer auf port 22 zugreifen will direkt die ip durch iptables gespeert wird.
Das gleiche gillt für FTP Port 21 (Ich nutze selber keinen FTP)
Keinen Mailserver installiert. Mails laufen über den Provider
Diverse Änderungen an der php.ini

 

[matzewe01]

Och Jungs und Mädels,

Ich wollte doch ledigluch nur wissen ob ihr noch Tips habt.
Muss den grundsätzlich jeder Thread im SSF in einer endlosen Diskussion enden?

;-)

Entnimm doch bestimmte Erfahrungen aus der Diskussion und die geschilderten Probleme.

 

[flugopa]

Unsinn vielleicht nicht. Aber es dient auch nicht zu mehr als Logdateien zu sparen ...

Hallo CentOS-Fan,
den SSH-Port "verbiegen" ist das erste was ich nach der Grundinstallation mache, weil die meisten Skript's "keine Lust haben" alle 65535 Port's zu scannen!
Systeme mit offenen Standartport's sind des Hacker's Lieblinge.

 

[CentY]

Ist eure Sache . Wir machen es weder in der Firma noch mache ichs privat. Und es hat bis jetzt niemandem geschadet . Davon abgesehen geht es für manche Anwendungen einfach nicht die Ports zu verlegen. Und ich habe auch keine Lust am Tag 50mal die Frage für Kunden zu beantworten warum dass und dass net geht. Und am Ende wars wieder nur der dumme Port den sie falsch benutzen .

Vorallem ist mein System deswegen nicht "offen" .

Wenn man seinen Syslog Daemon richtig einstellt und fail2ban usw. benutzt und keinen Rootlogin zulässt. Ist es meiner Meinung Sicherheitstechnisch unbedenklich. Ansonsten würde ich eher Portknocking einsetzen als einfach nur den Port zu verlegen was für mich Pseudosicherheit ist.

 

[daemotron]

@Mr.Propper: Sicherheitsmaßnahmen auf Servern sind eine theologische Frage - da war das Gezänk mit der Frage schon vorprogrammiert

@flugopa: Verlegst Du denn auch die Ports für HTTP, SMTP, POP3, IMAP etc.? Diese Dienste sind ja noch viel stärker gefährdet als SSH...

 

[Mr.Propper]

HiHo,

Klar, im Grunde endet fast jeder Thread in einer Endlosen Diskussion, das macht auch ein Forum aus aber dennoch ist es manschmal extrem unübersichtlich wenn man nur ein Paar Tips sucht und am Ende genau weiss welcher User welches System mit welchen Sicherheitsvorkerungen hat.

Mansches was ich am Server geändert habe zwecks Sicherheit scheint womöglich nicht nötig zu sein aber es geht ja nicht nur um die Sicherheit alleine sondern im Ernstfall auch belegen zu können das das System umgangen worden ist um Schaden anzurichten und genau da Helfen eben auch kleine Sicherheitsvorkehrungen wie Port verlegen, Public Key etc.

 

[CrashOverrideSE]

Hallo,

ich wollte mich hier einfach mal anschließen, bin auch quassi Linux Neuling und wollt mir mal eurer segen für meine Server Absicherung holen.

Server ist ein Debian Lenny 5 AMD64

• Ich habe Fail2Ban Installiert auf die Dienste die ich Laufen habe aufgeschaltet und auf 2x Retry Eingestellt BAN-Time 24H.
  
• rKhunter installiert und eingestellt und lasse diesen Täglich mit einer Mail Benachrichtigung Durchlaufen.
  
• SSH abgesichert durch Verwendung eines Private und Public Keys. Password Login abgeschaltet via SSH.
  
• Webmin und Plesk sind nur noch über meine DynDns Adressen zu erreichen.
  
• Auf dem Server läuft zusätzlich ein TS3 unter einem Seperaten User in einem screen.
  
• Ich mache jeden Mittwoch Updates via Plesk und Konsole

Was denkt ihr was sollte ich ggf. noch machen oder was muß ich noch machen bzw. habt ihr ein paar Tipps die man umsetzen könnten. Sind meine Ansätze richtig ?

 

[daemotron]

Server ist ein Debian Lenny 5 AMD64

Wenn Squeeze released ist, würde ich dringend zu einem Upgrade raten. Grundsätzlich portiert das Debian-Team zwar Security Fixes zurück auf die packetierte Version, aber die Pakete in Lenny sind nun doch schon etwas betagter, so dass möglicherweise für das eine oder andere Paket eine bestehende Lücke gar nicht mehr unbedingt bekannt wird.

Ich habe Fail2Ban Installiert auf die Dienste die ich Laufen habe aufgeschaltet und auf 2x Retry Eingestellt BAN-Time 24H.

Fail2Ban ist keine wirkliche Sicherheitsmaßnahme, sondern eine Form der Untersetzung. Der Sinn liegt darin, das ständige Grundrauschen soweit zu reduzieren, dass nachgelagerte, aufwendigere Stufen Deines Verteidigungswerks nicht zu stark belastet werden.

rKhunter installiert und eingestellt und lasse diesen Täglich mit einer Mail Benachrichtigung Durchlaufen.

Grundsätzlich eine vernünftige Maßnahme, wobei einem klar sein muss, dass ein Angreifer, der ein Rootkit eingeschmuggelt bekommt, auch in der Lage sein dürfte, rkhunter zu manipulieren. Automatische Scans haben eben so ihre Grenzen. Sicherer wäre es, ein statisch gelinktes rkhunter-Binary immer von einem vertrauenswürdigen Speicherort auf den Server zu laden und dann dieses durchlaufen zu lassen.

SSH abgesichert durch Verwendung eines Private und Public Keys. Password Login abgeschaltet via SSH.

Dabei auch daran gedacht, PAM-Authentifizierung abzuklemmen? Wird gerne mal vergessen, ermöglicht dann aber wieder durch die Hintertüre die Anmeldung per Passwort.

Webmin und Plesk sind nur noch über meine DynDns Adressen zu erreichen.

Hier gilt das gleiche wie bei Fail2Ban - verstecken ist nur eine Untersetzung. Die IP-Ranges der meisten Serverhoster sind ziemlich gut bekannt. Damit lässt sich bequem ein Portscanner füttern; der braucht dann gar keine DNS-Auflösung.

Auf dem Server läuft zusätzlich ein TS3 unter einem Seperaten User in einem screen.

TS3 ist ein bisschen kritisch - da tauchen immer wieder mal Lücken drin auf, die dann von einem Angreifer benutzt werden können, um Deinen Server als Bande zu benutzen (v. a. für UDP DoS Angriffe). Wenn Du den TS permanent laufen haben musst, würde ich Dir empfehlen, ein kleines Überwachungsscript auf den anzusetzen, damit Du mitbekommst, wenn der auf einmal anfängt, viel Traffic zu verursachen oder nach draußen zu telefonieren.

Was denkt ihr was sollte ich ggf. noch machen oder was muß ich noch machen bzw. habt ihr ein paar Tipps die man umsetzen könnten.

Die von Dir beschriebenen Maßnahmen zielen darauf ab, erst mal Angreifer von Deinen Diensten fernzuhalten. Die nächste Stufe wäre, mit RBAC/MAC dafür zu sorgen, dass Dienste nur Dinge tun dürfen, die Du für sie vorgesehen hast. Das verhindert zum einen, dass Angriffe zum Erfolg führen, die darauf abzielen, das Verhalten eines Dienstes gezielt zu manipulieren.

In letzter Instanz kannst Du dann noch Maßnahmen ergreifen, die dafür sorgen, dass ein Angreifer, der einen Dienst erfolgreich angreifen konnte, nicht gleich Einfluss auf Dein gesamtes System bekommt. Geeignete Techniken wären hier ebenfalls RBAC sowie einsperren der Prozesse in (gehärtete) chroot-Jails.

Beide Ansätze (RBAC, gehärtete Jails) sind leider nicht im Vanilla Linux-Kernel enthalten und müssen über Kernel-patches nachgerüstet werden. Das bedeutet, man muss sich seinen eigenen Kernel bauen. Geeignete Patchsets sind entweder RSBAC oder grsecurity. RSBAC ist etwas umfangreicher und unterstützt auch bereits den aktuellen Kernel 2.6.35; grsecurity ist etwas hinten dran (2.6.32), dafür aber etwas überschaubarer.