Server absichern

[Mr.Propper]

HiHo,

Zurzeit sicherich meinen Server ab bevor er Produktiv genutzt wird.

Immonet wurde folgendes vorgenommen:

ssh port geändert
denyhosts in verbindung mit iptables
mod-evasive
Apache: ServerTokens Prod und ServerSignature Off
MySQL: Verbinfung von aussen blockiert

Für mein Geschmack ist das noch zu wenig. Habt ihr noch Tips?

 

[mr_brain]

Lediglich den SSH-Port zu ändern, ist keine Verbesserung der Sicherheit. Besser den root-Zugang der SSH verbieten und statt dessen einen SSH-Login-Benutzer.

 

[matzewe01]

ssh port geändert
denyhosts in verbindung mit iptables
mod-evasive
Apache: ServerTokens Prod und ServerSignature Off
MySQL: Verbinfung von aussen blockiert

ssh authkey Anmeldung nichts anderes!
Nur einen oder wenige Benutzer zulassen ggf. auf eine Gruppe beschränken.
Port verlegen= Unsinn.

Apache in Verbindung mit php,

chroot / Jails der einzelnen Benutzer
Dito FTP, sofern man das wirklich will und braucht.

Web Benutzer login shell /bin/false.
PHP entsprechend absichern
http://www.heise.de/security/artikel/Grundsicherung-fuer-PHP-Software-270918.html
http://andreas-lehr.com/blog/archives/80-PHP-absichern-mit-suhosin.html


Weniger ist ja typischerweise immer mehr, also alle nicht benötigten Dienste abschalten!

 

[Ben.]

Port verlegen= Unsinn.

Nein, ist es nicht.

 

[CentY]

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

 

[Ben.]

Naja, je übersichtlicher die Logfiles, desto einfacher fällt es Angriffe bzw. Schwachstellen zu erkennen.

Oft werden Angriffe von Kiddies nur voraus geschickt um eben die Logfiles zu füllen und so interessantere Einträge "zu verstecken".

Ich ändere den Port auf jedem Server. Es ist kein Garant für direkte Absicherung, aber indirekt m.E. durchaus.

Aber letztlich bleiben es Erfahrungen und Ansichten.

 

[matzewe01]

grep ist hier ein wertvolles tool um seine Daten entsprechend zu filtern.
Da der sshd bei mir zumindest seperat loggt, bzw. eigentlich jeder Dienst sein eigenes Log hat, verstecken sich da kaum Einträge.

Anders ist es, wenn der sshd mit vielen anderen Diensten nach /var/log/messages schreibt.

Einen wirklich Vorteil beim Port verlegen finde ich dabei nicht.
Für eine spätere Gerichtsbarkeit ist jedoch der Nachweis über den systematischen Versuch ein System zu hacken kein Nachteil ganz im Gegenteil, damit lässt sich noch besser die Massive kriminelle Energie beweisen.

Entsprechend ist auch für weitere Auswertungen, wer mit welchen Mitteln und welcher Aggressivität versucht zu hacken nicht unbedeutend.
Logs beschönigen .......
Ich stauche diese Informationen später auf der DB Zusammen.
Ein Cleveres DB Design ermöglicht schon die Datenmenge der Logs um einen Faktor xx und mehr zu reduzieren. Die Auswertungen die dann möglich sind hingegen ein sehr hoher Mehrwert.

 

[chris085]

Falls du einen Webserver einsetzt würde ich nicht alle vhosts auf eine IP laufen lassen sondern nach Möglichkeit verteilen.
So kannst du bei einem Dos leichter reagieren und einfach mal die IP zeitweise sterben schicken.

Das ist jetzt nicht präventiv, aber es hat mir schon oft geholfen schnell zu sein.
Falls du dann noch eine Kombi von sendmail zum Webserver einsetzt würde ich die Mails der Spaces entsprechend verteilen, so sinkt das Risiko auf eine Blacklist zu kommen.

Und ssh Port zu versetzten bringt definitiv was.
Ganz elegant wären natürlich zwei ssh server.
Einer für evtl. Kunden und einer für dich zum administrieren.

Dann setzt du noch ne schöne Range via IPtables und kannst sicher sein das keine bösen Ostländer drauf kommen ^^

 

[matzewe01]

Und ssh Port zu versetzten bringt definitiv was.

Erläutere mal genau, was es bringt ;-)

 

[chris085]

Ok, ich schreibe einen Script, der auf Server x einen Bruteforce starten soll.
Zufällig ist mir bekannt, dass alle Rootserver des Anbieters xy im Netz 127... stehen.

Szenario 1 (Junior Kiddie)

So... meine Vorgehensweise wäre jetzt auf jede potenzielle IP einen telnet auf Port 22 zu checken um zu prüfen ob darauf ein sshd läuft. Es könnte schließlich auch ein Windows Server sein.. oder was anderes.

Erst wenn diese Bedingung erfüllt ist starte ich die Bruteforce.

Szenario 2 (Senior Kiddie)
Ich mache mir etwas mehr Mühe und scanne den Server zuvor mit einem Portscan und prüfe ob dabei ein sshd antwortet.
Natürlich ist es für mich aus zeitlichen Gründen nicht möglich von 1 -65535
zu scannen. Deshalb prüfe ich nur die üblichen Ports.
Leider kann ich keinen sshd auf meinen üblichen 1024 finden.
Designiert ziehe ich zur nächsten IP weiter.

 

[matzewe01]

Und?

Bei einer guten Absicherung des SSHD (reine Konfiguration auth_key und kein root Login) wo ist da der potentielle höhere Schutz?

Mich intereressieren nicht die Szenarien, sondern lediglich die Erhöhung der Sicherheit.
Etwaige Lücken sind nach wie vor vorhanden mit dem Verlegen des Ports.

Entgegen stelle ich das Szenario Advanced Hacker.

Er findet Deinen sshd weil er durch andere Signaturen schon längst weiss, dass es eine Linux möhre ist (Webserver auf Port 80 genügt) und kennt Deinen Provider, weiss also es gibt kein vLan und Remote Console ist ebenfalls unzumutbar.

Munter scannt er drauf hin findet in wenigen Minuten bis Stunden oder Tage, je nachdem wie Auffällig er es macht, Deinen SSHD und weiss ihn mit den bekannten Lücken sofort zu knacken.

Davon abgesehen, dass ein Advanced Hacker auch nur dann auf den sshd los geht, wenn er zuverlässig über Lücken und Probleme weis. Ein anderer spart sich den Aufwand und sucht nach einfacheren Lücken die in vielen CMSe etc. PHP Scripte vorhanden sind.

 

[CentY]

Wenn dann bringt das Verlegen des SSH Ports nur was, wenn du einen "Honeypot" betreibst der auf Port 22 lauscht und diese IPs sofort in iptables einträgt. Dann ist es ventuell wirklich erstmal sicherer, da jeder Portscan darüber läuft und der Angreifer blockiert wird.

 

[chris085]

Naja auth_key only ist natürlich der beste weg.
Leider kann ich es nicht von meinen Kunden verlangen, dass sie mit auth Key only auf die Konsole zugreifen.

Genauso wenig wie ich verlangen kann alle Daten in Zukunft via sftp zu übertragen.

Alles tolle Ansätze, aber niemand hält sich dran.

 

[chris085]

Und?

Er findet Deinen sshd weil er durch andere Signaturen schon längst weiss, dass es eine Linux möhre ist (Webserver auf Port 80 genügt) und kennt

Und wo läuft bitteschön der IIS ?

Munter scannt er drauf hin findet in wenigen Minuten bis Stunden oder Tage, je nachdem wie Auffällig er es macht, Deinen SSHD und weiss ihn mit den bekannten Lücken sofort zu knacken.

Du gehst davon aus, dass der Hacker es explizit auf deinen Server abgesehen hat und damit Stunden/Tage verbringt.
Das ist aber nur in ungefähr 0,01 % aller Angriffe wahrscheinlich der Fall.

 

[matzewe01]

Warum nicht?

authorzied_keys zu pflegen ist nicht so aufwendig wie mans immer glaubt.
Und wenn sich eine Kunde erstmal daran gewöhnt hat, nicht den ganzen Tag lästige Passwort einzutippen, dann ekzeptiert er auch winscp z.B.

Wobei ich einen Kunden nicht per SSH aufs System lassen wollte.
-> Aus einem chroot ist man schnell ausgebrochen und es gibt heute noch anwendbare Lösungen, wie man als normaler priveligierter Benutzer ganz schnell Rootrechte erlangt.

 

[matzewe01]

Du gehst davon aus, dass der Hacker es explizit auf deinen Server abgesehen hat und damit Stunden/Tage verbringt.
Das ist aber nur in ungefähr 0,01 % aller Angriffe wahrscheinlich der Fall.

Falsch, ein Hacker sammelt unentwegt Informationen zu unzähligen Systemen und wertet diese aus.
Der Webserver Port 80 reicht für die wichtigsten Informationen aus.
Eine vergessene php.info hilft natürlich ungemein.
Der sshd spielt hier nahezu keine Rolle.
ftp ggf. noch dann snifft der potentielle Einbrecher aber in Deinem Netz mit.

 

[matzewe01]

Und wo läuft bitteschön der IIS ?

Auf dem Windows und dann versuche ich halt den rdp zu knacken.... ;-)

 

[chris085]

Ich weiß, deshalb ist es auch immer eine Gratwanderung, da gebe ich dir vollständig recht.
Deshalb wird wohl unser Job nie aussterben

 

[chris085]

Eine vergessene php.info hilft natürlich ungemein.

suexec mit CGI oder fcgi ist natürlich Pflicht.

 

[matzewe01]

Das Problem an der ganzen Sache ist:

Mit dem Portverlegen, was sich nun in der Hackerszene auch rum spricht und es entsprechende Scripte auch dafür gibt, ist kein Hindernis.

Damit sperrst Du ggf. Angreifer aus, die gar keine Problem gewesen wären.
Aber die die ein Problem sind, hast Du damit nicht abgewimmelt.

Ergo:
Du hast damit ggf. die Menge der qualitativ schlechten Angriffe drastisch reduziert und u.U. auch einen hochwertigen Angriff damit parriert.

Aber generell bremst das einen qualitativ hochwertigen Angriff nicht aus.
Die potentielle Bedrohung hat also nicht abgenommen.


Jetzt kommen wir aber wieder zurück zum Informationsgewinn:

Folgenden Fall hatten wir vor knapp 2 Jahren.
2 Kunden, einer der tatäschlich Ports verlegt hatte und der andere der Sie nicht verlegt hatte.

Beide wurden über die gleiche Lücke im CMS gehackt.

Kunde eins mit vollständigem Nachweis, dass der Angreifer über alle mögliche Arten versucht hat auf das System zu kommen.

-> Ergebnis Verhandlung: Der Angreifer bekam ohne lange diskussion eine Haftstrafe aufgebrummt. Keine Bewährung da die kriminelle Energie nachgewiesen sei.

2. Kunde, konnte nur noch per http log den Einbruch nachweisen:
Verwarnung des Angreifers durch das Gericht.
Angreifer beteuerte dass es nur eine versehen gewesen wäre Hätte sich da vertippt und wollte sein eigenes System testen.....