Re: server schützen gegen ssh wörterbuchattacken

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Thu, 15 Sep 2005 13:05:53 +0200 (CEST)

J. Erik Heinz <list(at)jerik.de> wrote:
> ich hab mir letztens mal meine /var/log/auth.log angeschaut, und über
> 2 Monate hinweg rund 14.000 fehlgeschlagene ssh loginversuche von
> insgesamt 14 IP-Adressen.
>
> Erste Frage: ist da Viel?

Ziemlich normal. Es gibt Gehirnamputierte, die tagtäglich
IP-Adressen auf Port 22 abklappern, und wenn sie jemanden
gefunden haben, wo der Port offen ist, lassen sie ihre
Skripte drauflosackern. Je nachdem, in welchem Netz Deine
IP-Adresse liegt, können da durchaus hunderte bis tausende
Versuche pro Tag zusammenkommen.

Ein Verlagern des sshd auf eine ungewöhnlichere Portnummer
bringt in so einem Fall drastische Besserung, da i.allg.
aus Effizienzgründen nur auf Port 22 gescannt wird. Diese
Maßnahme darf allerdings nicht als Sicherheitsmaßnahme an-
gesehen werden, d.h. sie bewahrt nicht vor der Wahl guter
Paßwörter und Aktuellhalten des sshd! (Stichwort »security
by obscurity«.)

> Jetzt hab ich mir überlegt, die IpAdresse zu blocken. Hatte mir
> überlegt, ich checke die /var/log/auth.log und sobald ich 4
> aufeinderfolgende Illegale logins habe, blocke ich die IP.

Das kannst Du ziemlich leicht automatisieren und quasi in
Echtzeit machen: Einfach in /etc/syslog.conf zusätzlich
ein Skript oder Programm für »auth.info« eintragen, das
dann alle diese Logmeldungen auf stdin bekommt. Das kann
dann einfach die relevanten Meldungen rauspicken, sich die
IP-Adressen merken, mitzählen und ggf. eine Paketfilter-
regel erzeugen, die die betreffende IP-Adresse für einen
gewissen Zeitraum erdet.

Allerdings sollte Dir klar sein, daß man dann die herr-
lichsten DoS-Attacken gegen Dein System fahren kann. Bei-
spielsweise könnte jemand durch IP-Spoofing die Adressen
Deiner DNS-Server sperren -- lustig für den Angreifer,
lästig für Dich. Oder durch Spoofen vieler verschiedener
IP-Adressen deine Paketfilter-Tabellen überlaufen lassen.
Man kann sich bestimmt noch weitere lustige Dinge einfallen
lassen. ;-)

(Mal ganz davon abgesehen, daß Dir so ein Verfahren nichts
hilft, falls der Angreifer bereits bei den ersten Versuchen
zufällig das Paßwort richtig errät, was bei »schwachen«
Paßwörtern durchaus nicht ausgeschlossen ist; auch muß man
an die Möglichkeit des Social-engineering, Keylogger oder
andere Umwege zum Erlangen von Paßwörtern denken. Werden
aber »starke« Paßwörter verwenden, ist ein Wörterbuchan-
griff nutzlos, und obiges Sperrverfahren somit auch über-
flüssig.)

> Da das ein ziemliche simple - denke ich mal - verfahrensweise ist,
> wollte ich mal frage wie ihr sowas handhabt.

1. Ignorieren.

2. Root-Login von außen per ssh verbieten (sollte eh der
    Default sein).

3. Gute Paßwörter verwenden. Wenn Benutzer Zugang zu dem
    System haben, denen man nicht unbedingt zutraut, daß
    sie das hinkriegen, dann sollte man selbst einen
    Checker installieren, der jedesmal das Paßwört prüft,
    wenn ein Benutzer seins ändert.

4. Login per ssh mit Paßwort ganz ausschalten, bzw. nur
    noch Login mit RSA/DSA-Key zulassen.

5. Falls ssh-Logins regulär nur von einer begrenzten An-
    zahl bekannter IP-Adressen stattfinden, dann sollten
    nur diese Adressen freingeschaltet werden.

6. Hab ich schon erwähnt, daß man gute Paßwörter verwenden
    sollte?

> Was haltet ihr von IDS (Intrusion Detection Systems)? Hab da ein
> interessante bericht über Snort, ACID und Mysql gelesen.

Kann man machen, ist aber auf isolierten Einzelsystemen
nach meiner Erfahrung zur Prävention ungeeignet.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
(On the statement print "42 monkeys" + "1 snake":)  By the way,
both perl and Python get this wrong.  Perl gives 43 and Python
gives "42 monkeys1 snake", when the answer is clearly "41 monkeys
and 1 fat snake".        -- Jim Fulton
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 15 Sep 2005 - 13:06:49 CEST

search this site