Moin moin, Erik P. Roderwald schrieb:
Hallo zusammen,
On Mittwoch 28 Oktober 2009, Markus Heinze wrote:
Nunja, hier ein kleiner Tipp
1.) Anmelden nur mit Public Key's erzwingen
Das ist nicht immer praktikabel. Ich betreue Server, auf die ich auch DAUs per ssh zugreifen lassen muss. Wenn ich den allen erklären müsste, wie sie per key ssh benutzen, müsste ich die Wartungskosten verdoppeln. ;)
Naja 'neue' Sachen empfinden die meisten User als unbequem und rebellieren, du bist Admin du musst dich durchsetzen gerade bei sicherheitsrelevanten Sachen, hier gehts um essentielle Sachen und nicht darum ob der User ein Hintergrundbild setzen darf oder nicht. Ja weiss dummer Vergleich, so wie die meisten Vergleiche aber ich denk Du verstehst was ich meine. Allerdings ist es manchmal einfach nicht möglich Key's einzusetzen, meist wenn verschiedene Systemgenerationen aufeinandertreffen, in diesem Fall ist 'pam_abl' dringend anzuraten
2.) PAM Auth deaktivieren
Warum das? Auf jeden Fall pam_abl konfigurieren und benutzen. Wies eigentlich immer fail2ban? Die pam-Module sind alle da. Man muss sie nur installieren und nutzen. Das ist wirklich denkbar einfach.
Allerdings ist es manchmal einfach nicht möglich Key's einzusetzen, meist wenn verschiedene Systemgenerationen aufeinandertreffen, in diesem Fall ist 'pam_abl' dringend anzuraten, wenn möglich würde ich mich trotzalledem für Key's entscheiden, dies mach ich jetzt seit knapp 6 Jahren und niemand hat damit ein Problem.
3.) root login deaktiviern !!
Der ist afaik von vornherein deaktiviert. Alles andere ist Wahnsinn. Das gilt natürlich nicht für gemietete Server. Da kriegt man meist erstmal nur das root-Passwort. Dann ist das erste, was man tut, den Zugang für root zu sperren. Nein, das zweite. Erst muss ein anderer user eingerichtet werden. Und eine Konsole immer schön offen halten, falls was schief geht. ;)
ACK
4.) SSHD auf einen andern Port legen, das knockt schon die meisten dummies aus
Bringt nicht wirklich was außer Ärger mit den usern. Jedes Mal, wenn die einen neuen SSH-Client installiert haben, muss man denen erklären, dass sie einen anderen Port einstellen müssen. Der kann ruhig so bleiben, wie er ist.
Also ich hab die Erfahrung gemacht das dadurch mehr als 90% der Angriffe verschwinden, ist sicherlich immer an die 'Intelligenz' der Bot's gebunden. Ansonsten ist intern ein bebildertes Howto wie der Zugang einzurichten ist,da ausser dem Port auch Zeichensatzcodierung und Terminalstrings zu setzen sind. Es hat sich noch nie jemand darüber beschwert und wer es damit nicht honbekommt sollte auch keinen SSH Zugriff haben.
5.) ggf. denyhosts einführen, dann wird der Angreifer nach x fehlversuchen gesperrt für Zeit x, aber vorsicht das kann einen auch selbst treffen (bei zu vielen fehlerhaften logins) !!
Auf jeden Fall IPs und auch user nach zu vielen Fehlversuchen für eine Stunde (oder bei noch mehr Versuchen) auch mal so für einen Tag aussperren. Das hilft ungemein. Vor dieser Maßnahme konnte ich meine Wände mit den Logeinträgen täglich neu tapezieren. Nach einer Weile spricht sich das rum und siehe da, heute hatte ich genau 0 Einträge, die auf einen Brute-Force-Angriff hinweisen würden. Endlich kann man /var/log/messages wieder lesen und findet die relevanten Dinge gleich. ;)
Und noch ein letztes. Um das Risiko möglichst gering zu halten, kann man auch bei Usern, die sowieso nicht ssh nutzen sollen, in /etc/passwd die Standardshell auf /bin/false einstellen.
ist eh erstmal default, dies verhindert das man vergisst es zu setzen, nur wer Zugriff braucht wird wirklich eine Shell bekommen und wenn man das vergisst bekommt man schnell entsprechendes Feedback, andersrum net ;)
hth
Liebe Grüße
Erik
Naja so hat jeder seine Ansichten, wobei denk ich beide den erwünschten Erfolg bringen dürften. lg max -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org