SSH maximale Fehlgeschlage Logins

Mauser

Mauser

Master Of Disaster
maximale Fehlgeschlage Logins

Hi,

ich habe mich gerade mit folgendem Problem beschäftigt:
ich wollte auf einem linux server festlegen, nach wie vielen fehlgeschlagenen logins (auch remote per ssh) eines users der account [temporär] gesperrt wird. ich habe nun im PAM das pam modul pam_tally in meine common_auth reingebaut.
es funktioniert auch, nur würde ich gerne wissen ob es in der richtung auch noch andere möglichkeiten gibt und wie ihr dieses problem löst.. weiss aus erfahrungen in der schule dass das unter win2000 sehr einfach ist, darum war ich eigentlich schon irritiert als doch recht lange googlen musste um pam_tally zu finden..
(ich hoffe das ich das hier richtig gepostet hab ;-D)
mfg
Mauser
 
Zuletzt bearbeitet:
davon halte ich nichts... damit kann dir jeder deinen login sperren...
 
hi..

natürlich kannst du das alle 2min oder so reseten. allerdings gebe ich dir da vollkommen recht, dass die gefahr vorhanden ist, sich auszusperren. aber wie schützt du dich vor brute force angriffen etc. ?
(ausser mit guten passwörtern...) ich meine wenn jemand sein prog auf den server ansetzt, wird er es schnell aufgeben, wenn er nur 1 passwort pro minute schafft.
ich frage ja, um andere vorschläge zu sammeln..
mfg
Mauser
 
ein erster schritt wäre zb nicht alle anfragen durchlassen sondern eben nur die die von einer voreingestellten ip kommen. desweiteren brauchen die erstmal deinen username....
und wenn du dir regelmäßig die logs anguckst oder dir eine email bei abnormalien senden lässt kann da meinermeinung nach wenig passieren und halt rootlogin deaktivieren und sichere pws und diese auch ab und zu mal ändern
 
hi,

erstmal danke für deine tips.. ja,an das beschränken auf eine ip hatte ich auch schon gedacht. nur dumm das der pc um den es primär ging ein gemieteter server ist und irgendwo im rechenzentrum steht, dh. die verbindung geht übers wan. und nun benötigst du (der,der auf den server zugreifen will) auch eine feste ip, die der normale user zuhause ja net hat. meine zweiter vorschlag wäre gewesen, ssh auf die authorisation per public key zu beschränken und keine "logins" mehr anzubieten. aber das wollte der betreffende widerum net, weil er angst hatte den key zu verlieren..........
und von wegen log dateien anschauen: ich denke mal das das doch bei nem brute force net viel bringt, da man (wenn man net beruflich admin ist...) nicht täglich seine logs durchforsten kann.ich denke das die reaktionszeit da einfach zu hoch ist, darum hatte ich mich für die methode mit den accounts sperren entschieden. ok, mir fällt gerade was besseres ein:
ein skript was die logs durchwühlt und die brute force ip's in hosts.deny einträgt,per mail warnt und -falls die addresse kurz danach wechselt,also eine dynamische ist - die ip nach einer woche wieder entfernt. denke dass die lösung eigentlich net schlecht wär. gibts sowas vielleicht auch schon ?
mfg
Mauser
 
hmm
ich weiß ja nicht was du für vorstellungen hast aber imho dauert ein bruteforce angriff schon seine zeit.. besonders bei langen komplizirten passwörtern.
 
ich will jetz hier keine endlose und sinnlose diskusion losbrechen, aber versuch mal bei mehr als 50 usern nen pwd-standart durchzuringen, ohne die unsicherern passwörter nicht mehr zu erlauben. aus vernunft macht das eh keiner..
mfg
mauser
 
jop das ist schwer da hilft nur ab und zu bruteforce gegen den eigenen server und die user ranbekommen die mist gebaut haben

aber lassen wir das...
 
1. lass den sshd doch einfach auf port *irgendwas* lauschen - dann laufen 98% aller angriffe schonmal ins leere.

2. passwordauthentification ist immer ein sicherheitsproblem! besser ist's ausschließlich mit public-keys zu arbeiten. die müssen natürlich auch per mantra gesichert werden aber solange die keys nicht "auf reisen gehen" (also solange es keine roadwarrior gibt sich den key-file klauen lassen) ist das risiko vernachlässigbar. keys haben noch andere vorteile: du kannst z.b. festlegen das sich z.b. die mitarbeiter zwar von den rechnern des bürogebäudes, nicht aber aus dem außenlager einloggen können (damit wird schonmal verhindert das kollege meier mit seinem key-file auf diskette spazieren geht).

3. root darf sich niemals über ssh einloggen! weder über passwordauthentification noch über pubkey-authentification! für solche zwecke erstellst du dir bitte einen eigenen user der per su die entsprechenden rechte erlangen kann. (wenn du es richtig machen willst, führst du die gruppe wheel wieder ein und entziehst allen anderen usern das recht auf su).

mfg

bananenman
 
afiar kannst du das über die /etc/login.defs machen
 
Zurück
Oben