Re: Passwort-Security-Test
On Don, 12 Jän 2006, RalfGesellensetter wrote:
> Am Mittwoch 11 Januar 2006 17:49 schrieb Florian Reitmeir:
> > SSH Zugriff freizuschalten halte ich uebrigens fuer generell
> > bedenklich, im Sinne von, "Wenn ich mir meine Zugriffs LOGs ansehen
> > wieviele SSH-Probes da sind.. "
> Hallo Florian, danke für deine wertvollen Hinweise.
>
> Wie nun, wenn der SSH-Zugang nur für ausgewählte User (nicht: root!) und
> nur auf einer von außen zugänglichen Workstation (nicht auf Tjener)
> zugelassen wird? Zum einen müssten SSH-Scanner erst einmal auf den
> Nutzernamen kommen (die Passwörter dazu sind sicher), erfolgreiche
> Angreifer landen auf einer Workstation. Von da aus wäre der ssh-Zugriff
> auf Tjener gesperrt (erlaubt allerdings: Webmin, NFS).
Grundsaetzlich um bei der Theorie zu bleiben ist es wahrlich so, dass ein
gehackter Rechner in einem Linux Netz reicht.
- kommt NFS zum Einsatz? Das ist ja gegen gar nix gesichert..
- wird das Netz ueberwacht? also Firewalllogs ausgewertet?
- kann der Angreifer Dich dazu bringen dich auf der Workstation als root
einzuloggen? Indem er z.b. die Kiste einfach oft genung abstuertzen laesst?
- ich gehe davon aus, dass wenn man mal einen lokalen Account hat, Root-
rechte nur eine Frage der Zeit sind.. und meistens gar keine allzu lange
Zeit.
Wegen des SSH-Probes, es ist nur so, und es ist vielleicht auch nur paranoid
von mir, aber auf einem der Server habe ich schon stundenlange probes gehabt
von mehreren hundert Versuchen, und es ist dann ganz egal ob ich mir "sicher"
bin, dass alle Kennwoerter passen, unheimlich bleibt es. Und einen Exploit in
SSH kann man auch nie ausschliessen.
Angesehen davon dass ich es laestig finde super lange logcheck Mails
zugeschickt zu bekommen. (logcheck ist ein tool das alles was es im
/var/log/syslog nicht kennt dem Admin als Mail schickt)
Wenn du SSH offen machts dann zumindest mit entsprechendes Firewall rules,
der Debian Admin Guide hat dazu ein sehr gutes und wirksames Beispiel:
http://www.debian-administration.org/articles/187/print
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
--set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
--update --seconds 60 --hitcount 4 -j DROP
sobald dann eine IP Adresse mehr als 3 Anfragen in einer Minute macht wird
sie gedroppt/geblocked. Das schoene daran ist, dass das Limit von selbst nach
einer Minute "Ruhe" wieder verschwindet.
Ich setz bei mir etwas krasserer Limits ein, die aber einen normales Nutzer
nie treffen werden..
iptables ... -m recent --set
iptables ... -m recent --update --seconds 6 --hitcount 4 -j DROP
iptables ... -m recent --update --seconds 60 --hitcount 6 -j DROP
also in 6 Sekunden 4 Verbindungen, oder in 60 Sekunden 6 Verbindungen. Die 2.
Regel hab ich noch nie gebraucht die erste hat alle SSH-Probes zumindest nach
der 3. Verbindung (alle in der ersten Sekunde) geblockt.
Aber wie gesagt, eleganter, stabiler, und mit mehr Kontrolle ist eine
OpenVPN Loesung. Wenn dann z.b. ein Wiki im Netz ist braucht man gar keinen
NX Client. Und du kannst am VPN Server schoen festlegen welche Hosts/Services
sichtbar sein sollen.
(wau.. ich glaub das war bisher meine absolut laengste Mail ueberhaupt)
--
Florian Reitmeir
Reply to: