|
Anzeige
|
TelNet Attacken abfragen
Gast
#4563125
Hallo Laut LogFile meines Modems versucht jemand kontinuierlich, per Telnet Zugang zu erhalten (das Modem blockt die Anfragen natürlich ab) Es wäre nun u.A. interessant zu wissen, mit welchen Login Kombinationen sich jemand einloggen möchte Kann ich untere Windows einen (fingierten) Telnet Server bereitstellen, beim Modem die entsprechenen Ports an diesen PC weiterleiten und damit das Geschehen mitverfolgen? ja, kannst Du aber was versprichst Du Dir davon? Daten für eigene Angriffe sammeln?
Gast
#4563160
Ban die IP des Angreifers für 24H und gut ist es, das wird dann automatisch weniger. Eventuell sind das auch nur automatisierte Portscans. Ansonsten wundere dich nicht. Ich hatte auf SSH auch schon an manchen Tagen über 1000 fehlgeschlagene Loginversuche. Dann hab ich den Port verschoben, seitdem ist Ruhe ;-) Wenn du Telnet nicht brauchst (und wer braucht das heute noch?), abschalten. Port weiterleitung zu deinem PC und dort dann "netcat -lp23 > log.txt" Unter Linux schreibt der ssh server z.B. in die /var/log/auth.log. Das ganze sieht dann so aus: sshd[30426]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.3.202.195 user=root sshd[30424]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.3.202.195 user=root sshd[2722]: input_userauth_request: invalid user oracle [preauth] sshd[2722]: Disconnecting: Too many authentication failures for oracle [preauth] Auf jeden fall sollte man per Konfiguration nur bestimmten Usern ein Loginrecht per Remote geben, da die Scriptkiddies auch Kombinationen wie admin/admin oder test/test durchprobieren, wenn man sich sowas mal angelegt hat, hat man dann Gäste auf dem System!
Gast
#4564750
Klaus schrieb: > Kann ich untere Windows einen (fingierten) Telnet Server bereitstellen, > beim Modem die entsprechenen Ports an diesen PC weiterleiten und damit > das Geschehen mitverfolgen? Mit Windows solltest du solche Sachen niemals ausprobieren. F. F. schrieb: > Wenn du Telnet nicht brauchst (und wer braucht das heute noch?), > abschalten. Das war doch gar nicht die Frage!?
Gast
#4564880
Johannes O. schrieb: > Eventuell sind das auch nur automatisierte Portscans. Ansonsten > wundere dich nicht. Ich hatte auf SSH auch schon an manchen Tagen über > 1000 fehlgeschlagene Loginversuche. Dann hab ich den Port verschoben, > seitdem ist Ruhe ;-) Das hilft höchstens gegen leute ohne Erfahrung. Sven L. schrieb: > Unter Linux schreibt der ssh server z.B. in die /var/log/auth.log. > Das ganze sieht dann so aus: > > sshd[30426]: pam_unix(sshd:auth): authentication failure; logname= uid=0 > euid=0 tty=ssh ruser= rhost=183.3.202.195 user=root > sshd[30424]: pam_unix(sshd:auth): authentication failure; logname= uid=0 > euid=0 tty=ssh ruser= rhost=183.3.202.195 user=root > > sshd[2722]: input_userauth_request: invalid user oracle [preauth] > sshd[2722]: Disconnecting: Too many authentication failures for oracle > [preauth] > > Auf jeden fall sollte man per Konfiguration nur bestimmten Usern ein > Loginrecht per Remote geben, da die Scriptkiddies auch Kombinationen wie > admin/admin oder test/test durchprobieren, wenn man sich sowas mal > angelegt hat, hat man dann Gäste auf dem System! So sehe ich das auch. Fail2ban ist oft eine gute hilfe. Sofern man es für das zielsystem bekommt. Ja Fail2Ban ist sehr mächtig, man sollte sich beim Konfigurieren viel Zeit lassen und Ausnahmen für's LAN eintragen, damit man sich nicht ausschließt =)
Gast
#4565013
rpi_homeserver schrieb: > Das hilft höchstens gegen leute ohne Erfahrung. Es hilft gegen schrottige Bots die das Netz nach SSH-Zugängen scannen. rpi_homeserver schrieb: > Johannes O. schrieb: >> Eventuell sind das auch nur automatisierte Portscans. Ansonsten >> wundere dich nicht. Ich hatte auf SSH auch schon an manchen Tagen über >> 1000 fehlgeschlagene Loginversuche. Dann hab ich den Port verschoben, >> seitdem ist Ruhe ;-) > > Das hilft höchstens gegen leute ohne Erfahrung. Natürlich. Aber das Ziel dieser Schutzmaßnahme ist es ja gerade, die einfachen Portscans+SSH-Passwort-Bruteforce abzuwehren. Der Angreifer sucht sich nur irgendeinen Zugang, der ist ja nicht hinter mir persönlich her. Und soweit ich sehe, hatte ich seit einigen Monaten KEINEN EINZIGEN fehlgeschlagenen unbekannten Loginversuch mehr. Wenn wir ein anderes Angreifermodell verwenden (Angreifer, der dir persönlich schaden will, mit großer Erfahrung etc.) dann sieht die Sache wieder anders aus. Ich habe bei mir E-Mail benachrichtigungen bei jedem erfolgreichen Login eingerichtet. Solange niemand über ssh und Co. bei mir rein kommt ist es mir ziemlich egal, ob irgendwelche bots versuchen sich mit Username "admin" und Passwort "Change Me" einzuloggen und dabei scheitern. Falls doch mal einer rein kommt ist es vermutlich kein bot, und ich kann den einfach rausschmeissen, oder ich unterhalte mich mit dem vorher etwas... Zusätzlich sind bei mir alle Services in unterschiedlichen LXC Containern, solange also niemand auf den KVM-Host kommt hält sich der Schaden in grenzen. Und dann gibt es ja noch das Backup und ein identisches Notfallsystem, welches ich letzte woche fertig stellen wollte... Antwort schreiben |
Anzeige
|
