• Liebe User, bitte beachtet folgendes Thema: Was im Forum passiert, bleibt im Forum! Danke!
  • Hallo Gemeinde! Das Problem leidet zurzeit unter technischen Problemen. Wir sind da dran, aber das Zeitkontingent ist begrenzt. In der Zwischenzeit dürfte den meisten aufgefallen sein, dass das Erstellen von Posts funktioniert, auch wenn das Forum erstmal eine Fehlermeldung wirft. Um unseren Löschaufwand zu minimieren, bitten wir euch darum, nicht mehrmals auf 'Post Reply' zu klicken, da das zur Mehrfachposts führt. Grußworte.

SSH Attacke ohne Portweiterleitung

Mitglied seit
23.04.2003
Beiträge
1.252
Reaktionen
0
Ich hatte mir hier mal eine kleinen Server zum Experimentieren aufgesetzt (Ein Debian Linux System). Da ich letzte Woche ziemlich viel unterwegs war, wollte ich heute weiter konfigurieren und den Server noch besser absichern.

Beim Durchsehen des /var/log/auth.log Logfiles waren einige Einträge drinnen ala:

Jan 9 14:24:51 localhost sshd[18956]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx
Jan 9 14:24:53 localhost sshd[18956]: Failed password for invalid user agata from xxx.xxx.xxx.xxx port 54284 ssh2
Jan 9 14:24:55 localhost sshd[18962]: Invalid user administrator from xxx.xxx.xxx.xxx

Ich hatte meinen SSH Port umgelegt, Login funktioniert nur über Zertifikat etc. Aber wie ist es möglich, dass es einen Einbruchversuch auf Port 54284 gab. Diesen Port habe ich über meinen Router gar nicht weiterleiten lassen. Der Server steht auch nicht in einer DMZ o.ä. Weitergeleitet hatte ich nur einen Port. Wie konnte es also passieren, dass die den Port 54284 scannen konnten?

Txh 4 help

€: Kann es sein, dass das nicht der Port ist, von dem von außen drauf zugegriffen wurde, sondern der vom Server selber über den die Verbindung hergestellt wurde?
 
Mitglied seit
15.05.2003
Beiträge
11.307
Reaktionen
8
Ort
Fortuna 1895 Düsseldorf
nun das ist eigentlich ganz einfach: du wurdest port gescannt und der sshd wurde entdeckt. das verlegen des ssh ports schützt dich zwar vor automatisierten abscannen der well known ports , hilft aber nicht gegen full port range scanns. Security through obscourity nennt man das.

wie auch immer, jemand hat entdeckt, das dein ssh sagen wir über port 4711 läuft. die erste anfrage läuft über diesen port, für den rest der verbindung wird dir aber von sshd dann automatisch ein highport zugewiesen über den die verbindung läuft. zur kontrolle mach mal ssh localhost -p 4711 oder ssh deine.dyndns.url -p 4711 und schau dir das logfile dazu an. auch da läuft das über highports. ( du musst natürlich den port angeben, den du für sshd bestimmt hast )

grundsätzlich ist die authentifikation über rsa key sicher. die benutzer wurden ja auch abgewiesen.

das die ganze sache durch die firewall geht, liegt daran, das eine verbindung auf port 4711 erfolgreich war und alles weitere über port 53284 geht. die anwort wird also von innen nach aussen durch die firewall gelassen und damit die anwort von aussen natürlich auch, wie bei jedem andren verbindungsversuch von innen nach aussen, denn das läuft auch alles über highports ( mach mal netstat -anp ) das ist einfach erklärt. keine zeit das jetzt präziser zu beschreiben aber im grunde ist alles in ordnung!

anmeldung mit agata ( kennst du eine? ) oder administrator sieht aber eher diletantisch aus.
kennt jemand deine dnydns url? ich glaube nicht an zufälle ^^


€ ach ich trottel, versteh ich jetzt erst richtig: du hast den sshd zwar auf einen anderen port lauschen, aber nicht durch NAT mit dem internet verbunden? das heisst du der rechner ist über internet eigentlich nicht erreichbar? -.-
 
Mitglied seit
23.04.2003
Beiträge
1.252
Reaktionen
0
Danke für deine ausführliche Antwort. Ich hatte am Anfang noch den Standardport 22 genutzt und hatte dann erst später umgelegt. Und das hier war dann der springende Punkt:

"für den rest der verbindung wird dir aber von sshd dann automatisch ein highport zugewiesen über den die verbindung läuft."

Da hatten mich die hohen Zahlen etwas verwirrt, aber dann ist alles klar. Habe jetzt alles umgestellt und werde mal sehen, wie sich die Logfiles so entwickeln.

Danke dir für die Infos.
 
Oben