# Bei ssh-login verwendete Passwörter loggen

## 178238

Hallo zusammen,

In letzter Zeit stelle ich nichtnur am Server, sondern auch am heimischen Rechner etliche fehlgeschlagene SSH-Logins fest. Natürlich ist das nur das übliche Hintergrundrauschen des Internets, trotzdem, als ich letztens in den Logs bei den üblichen Standardusernamen auch meinen eigenen gesehen habe, hätten mich schon die Details des Zugriffsversuchs interresiert.

Nur will ich für meinen Rechner@home kein großartiges IDS a la snort/etc. anlegen, trotzdem hätte ich gern, dass sshd erfolgreiche wie fehlgeschlagene Loginversuche logt. Und zwar nach Möglichkeit mit dem dabei verwendeten Passwort. Ist das überhaupt möglich?

Danke schonmal,

Mfg 

-Lumpi

Edit: Hm... Es ist wohl ein wenig sinnfrei bei erfolgreichen Logins das Passwort loggen zu wollen   :Wink: 

----------

## DarKRaveR

Wenn DU pam authentication benutzt, könntest Du dem entsprechenden modul den debug Parameter aufhalsen udn schauen, was passierrt.

----------

## misterjack

Das sollte doch schon geloggt werden, bis auf das Passwort. In meinen Falle habe ich metalog im Einsatz:

 */var/log/sshd/current wrote:*   

> #Nicht vorhanderer User:
> 
> Apr 25 13:30:11 [sshd] Invalid user a2 from 200.87.179.130
> 
> #korrekter Login mittels publickkey
> ...

 

----------

## 178238

Danke erstmal,

Ich habe ssh bereits mit USE=pam gebaut, das liefert mir auch ein sauberes Ergebnis wie bei misterjack zu sehen ist. Nur würde ich wie schon gesagt gerne zuätzlich noch das bei einem fehlerhaftem Login verwendete Passwort sehen. Würde das einfach interessant finden mal zu sehn was solche bots alles versuchen. Zugegeben stelle ich mir das auch schwer realisierbar vor, aber vllt gibt es ja speziell dafür z.B. ein gepatchtes openssh o.ä. So mancher Sicherheitsexperte ist sicher schon vor dem selben Problem gestanden ist... Naja, vllt kennt ja doch einer eine Möglichkeit   :Wink: 

Mfg

 - Lumpi

----------

## tuam

Guten Abend!

Das Loggen der Passwörter ist sicher aus Sicherheitsgründen unmöglich. Außer man ergoogelt http://unixcluster.dk/index.php?/archives/23-Logging-ssh-passwords,-part-2.html , habe ich aber nicht getestet.

Und was hält Dich als normal paranoiden Admin davon ab, nur public key zuzulassen?

FF,

Daniel

----------

## 178238

 *tuam wrote:*   

> 
> 
> Und was hält Dich als normal paranoiden Admin davon ab, nur public key zuzulassen?
> 
> 

 

Rein garnichts   :Wink:  nur wie gesagt, die ganze Sache is aus reinem Interesse was solche Bots (nehme doch mal stark an das es welche sind) für Passwörter verwenden.

Mfg

 - Lumpi

----------

## c_m

kann ich dir leicht beantworten: wörterbuch attacken.

Kobinationen aus Benutzernamen und häufig verwendeten wörtern.

Was drin steht hängt vom angreifer und/oder der qualität des wörterbuchs ab.

sehr selten wohl auch bruteforce, ist aber idR  zu ineffizient und fällt doch sehr schnell auf.

Meine empfehlung: fail2ban.

Sehr geniale geschichte :-> Da wird selbst ein wörterbuch angriff zum gedultsspiel für den Angreifer und man spart sich das lästige mitschleppen des schlüssels.

//EDIT: in Verbindung mit munin hat man dann auch eine sehr schöne aufbereitung der IP sperren ;->

----------

## 178238

Danke für die Tipps! Ich kannte zwar schon DenyHosts ([url]http://gentoo-wiki.com/HOWTO_Protect_SSHD_with_DenyHosts) was recht nette Featues hat (online Update der Blacklist etc.) aber fail2ban hört sich mindestens genausogut an. munin hört sich ebenfalls sehr interessant an, soll nochdazu auf openWRT laufen.

Wo wir aber schon beim dem Thema Bots sind: Hat irgendwer sich schon einmal ausversehen oder auch gewollt so einen eingefangen und kann mir Sagen was die Viecher machen? Würde gerne selbst einmal mit Sachen wie honeyd/Honeywall experimentieren nur fehlt mir dazu im Moment wirklich die Zeit.

Mfg 

 - Lumpi[/url]

----------

## schmutzfinger

http://www.hexten.net/wiki/index.php/Pam_abl ist auch interessant wenn man sich vor solchen Angriffen schützen will. Ich persönlich nutze einfach iptables und lasse ssh nur von einer Hand voll IPs zu. 

Man muss sich bewusst sein die Ban-Methoden eine Tür für DOS-Attacken aufmachen. Damit kann ein Angreifer eventuell Admins aussperren oder Admins sich selber ... Sollte man wissen, ist aber kein Grund das generell nicht zu verwenden.

----------

## SvenFischer

Wie bitte soll ich ausgesperrt werden, wenn ein Bann Programm gewisse IP's blockt, denen ich nicht angehöre?

Jetzt kommt die Gretchenfrage: Wenn ich geblockt werde, ist das dauerhaft (sollte natürlich nicht sein) oder wo kann man das dann löschen bei z.B. fail2ban?

----------

## think4urs11

 *SvenFischer wrote:*   

> Wie bitte soll ich ausgesperrt werden, wenn ein Bann Programm gewisse IP's blockt, denen ich nicht angehöre?

 

Gedankenspiel:

Gegeben ist ein IPS (nichts anderes ist ja fail2ban und co) das bei Angriffen von IP x diese per iptables blockt.

Was hält einen Angreifer davon ab z.B. die IP-Adresse der z.B. DNS-Server von T-Online zu sperren via udp-attacken gegen dein IPS mit gespoofter Source-IP? Ergebnis - von diesem Host aus geht kein DNS mehr, ziemlich guter DoS.

Oder er kennt dein intern verwendetes Netz und schickt für jeden Host ein gespooftes Packet - ok der Host selbst ist sicher aber das wäre er auch auf dem Meeresgrund, der Unterschied ist marginal  :Wink: 

Sofern dein IPS also auch auf udp anspringt ist extreme Vor- und Voraussicht notwendig; z.B. durch dedizierte Whitelists von Hosts die nicht geblockt werden dürfen.

Angriffe mit gespooften tcp-Paketen sind zwar schwieriger aber je nach Möglichkeiten und Standpunkt des Angreifers nicht unmöglich.

Die meisten Systeme arbeiten vernünftigerweise mit temp. Bans und einstellbaren Banzeiten; für dauerhafte Bans nimmt man lieber gleich eine statische Regel (ala alles was apnic zugeordnet ist gleich mal wegblocken o.ä.)

Ein IPS, auch ein einfaches wie fail2ban sauber so aufzusetzen das man sich nicht selbst in den Fuß schießt bedarf schon etwas Einsatz von Brain v1.0+

irgendwie paßt das alles besser ins Diskussionsforum; verschoben.

----------

## schachti

 *Think4UrS11 wrote:*   

> Oder er kennt dein intern verwendetes Netz und schickt für jeden Host ein gespooftes Packet - ok der Host selbst ist sicher aber das wäre er auch auf dem Meeresgrund, der Unterschied ist marginal 

 

Da ist man als Admin aber selbst schuld, wenn man Traffic auf einem Interface hereinläßt, der von einer IP stammt, die zu einem anderen Interface gehört. Sowas muß eigentlich gleich mit iptables abgeblockt werden, so dass fail2ban etc. davon gar nichts mitbekommt.

----------

## think4urs11

In einfachen Umgebungen geb ich dir Recht aber es gibt Situationen in denen du dir mit Antispoofing ins Knie schießt, bzw. es schwierig bis gar nicht zu implementieren ist. Es gibt leider nicht nur ideale Umgebungen, aka 'gewachsene Umgebung'.

Oder aber du hast schlicht dein WAN-Mgmt. outgesourct und der Outsourcer vergaß solche Kleinigkeiten.

Nicht jeder Angriff kommt aus dem Internet, auch hier gilt eine 80/20-Regel.

Ein IPS ist eine mächtige Waffe - in den falschen (unfähigen) Händen aber nur für den Gegner.

----------

