Announcement: there is an English version of this forum on 
Moin, ich schaue grad in mein auth.log, was meine chinesischen, rumänischen und russischen Freunde so machen und sehe dass die wieder sehr aktiv sind. Rund um die Uhr 24/7 ist mein Server den Brute Force Anriffen ausgesetzt. Ist mir eigentlich völlig wumpe, da das Passwort eh viel zu lang ist und ein Zertifikat benutzt wird. root Zugriff ist per se abgeschaltet. Ich habe fail2ban installiert, ein Python Sript und überlege ob das alles so richtig ist? Leider nur ein Screenshot möglich, da Copy & Paste auf dem ssh Fenster nicht funzt. Ich würde eigentlich erwarten, dass für die angreifende IP 42.7.26.49 nach Ablauf der MaxRetries erstmal für 10 Minuten komplett Ende ist, also kein Eintrag kommt. Aber die Zeitangaben sagen etwas anderes, das geht im Sekundentakt so weiter. Nach Disconnecting geht es direkt weiter. MaxRetries bei ssh und fail2ban sind gleich 3 gesetzt, sind die unterschiedlich gibt es eine Fehlermeldung von PAM. Alles klar oder stimmt da was nicht?
Angehängte Dateien:
-
Unbenannt.JPG
315 KB, 497 Downloads -
p1.JPG
335 KB, 371 Downloads
was sagt das fail2ban-Logfile? Was steht in den fail2ban-iptables-Rules? Beispiel für's logfile, /var/log/fail2ban.log:
1 | 2017-11-12 07:57:01,983 fail2ban.filter [2702]: INFO Log rotation detected for /var/log/auth.log |
2 | 2017-11-13 07:45:57,010 fail2ban.filter [2702]: INFO [sshd] Found 58.201.138.17 |
3 | 2017-11-13 07:45:57,016 fail2ban.filter [2702]: INFO [sshd] Found 58.211.138.17 |
4 | 2017-11-13 07:45:58,810 fail2ban.filter [2702]: INFO [sshd] Found 58.201.138.17 |
5 | 2017-11-13 07:45:59,434 fail2ban.actions [2702]: NOTICE [sshd] Ban 58.201.138.17 |
6 | 2017-11-13 07:46:01,444 fail2ban.filter [2702]: INFO [sshd] Found 58.201.138.17 |
7 | 2017-11-13 17:45:59,974 fail2ban.actions [2702]: NOTICE [sshd] Unban 58.201.138.17 |
iptables-Rules kannst du mit
> sudo iptables -L -v -n
anzeigen.
Sollte eine Chain "f2b-sshd" geben, da sind die geblockten SSH-Angreifer
drinnen. Und in "INPUT" in Sprung in diese chain.
Benutz doch einfach xtables und mach geoblocking. Dann müllen Deine ausländischen Freunde Deine Logs nicht voll.
Ich kenne mich mit dem anderen nicht aus und nachher sperre ich mich noch selbst aus, alles schon dagewesen. Zudem habe ich den Fehler gefunden, ein falsches Target, lag nicht auf auth.log. Habe ich vermutlich verstellt. Klappt alles inzwischen, mit -1 ist eh Dauerban.
So eine Tageausbeute sieht inzwischen so aus, die reinste Verschwendung von Bandbreite... leider kein Verbot in Sicht.
1 | 2017-12-11 02:36:41,603 fail2ban.actions: WARNING [ssh] Ban 110.53.183.228 |
2 | 2017-12-11 02:48:31,532 fail2ban.actions: WARNING [ssh] Ban 60.12.126.53 |
3 | 2017-12-11 03:21:45,963 fail2ban.actions: WARNING [ssh] Ban 89.46.72.126 |
4 | 2017-12-11 05:14:10,103 fail2ban.actions: WARNING [ssh] Ban 185.103.108.210 |
5 | 2017-12-11 06:07:41,922 fail2ban.actions: WARNING [ssh] Ban 190.13.56.8 |
6 | 2017-12-11 07:08:26,854 fail2ban.actions: WARNING [ssh] Ban 110.53.183.227 |
7 | 2017-12-11 07:22:15,755 fail2ban.actions: WARNING [ssh] Ban 60.12.126.51 |
8 | 2017-12-11 07:28:49,183 fail2ban.actions: WARNING [ssh] Ban 94.177.213.174 |
9 | 2017-12-11 07:45:06,221 fail2ban.actions: WARNING [ssh] Ban 103.246.152.34 |
10 | 2017-12-11 08:05:01,489 fail2ban.actions: WARNING [ssh] Ban 60.12.126.50 |
11 | 2017-12-11 08:05:53,560 fail2ban.actions: WARNING [ssh] Ban 95.177.213.164 |
12 | 2017-12-11 08:20:09,469 fail2ban.actions: WARNING [ssh] Ban 60.12.126.52 |
13 | 2017-12-11 08:31:52,224 fail2ban.actions: WARNING [ssh] Ban 110.53.183.252 |
14 | 2017-12-11 08:38:17,644 fail2ban.actions: WARNING [ssh] Ban 42.48.1.173 |
15 | 2017-12-11 08:53:28,612 fail2ban.actions: WARNING [ssh] Ban 180.87.154.30 |
16 | 2017-12-11 12:28:25,879 fail2ban.actions: WARNING [ssh] Ban 193.201.224.236 |
17 | 2017-12-11 14:55:06,179 fail2ban.actions: WARNING [ssh] Ban 112.161.187.208 |
18 | 2017-12-11 15:37:29,857 fail2ban.actions: WARNING [ssh] Ban 220.231.47.58 |
19 | 2017-12-11 16:55:29,829 fail2ban.actions: WARNING [ssh] Ban 218.87.109.154 |
20 | 2017-12-11 18:05:12,285 fail2ban.actions: WARNING [ssh] Ban 183.239.228.51 |
21 | 2017-12-11 18:18:30,138 fail2ban.actions: WARNING [ssh] Ban 222.185.185.81 |
22 | 2017-12-11 19:11:42,544 fail2ban.actions: WARNING [ssh] Ban 179.90.184.112 |
23 | 2017-12-11 19:21:57,201 fail2ban.actions: WARNING [ssh] Ban 101.228.197.15 |
24 | 2017-12-11 21:41:16,264 fail2ban.actions: WARNING [ssh] Ban 106.75.164.186 |
25 | 2017-12-11 21:44:13,540 fail2ban.actions: WARNING [ssh] Ban 115.238.245.2 |
26 | 2017-12-11 21:47:11,788 fail2ban.actions: WARNING [ssh] Ban 115.238.245.8 |
27 | 2017-12-11 21:52:27,197 fail2ban.actions: WARNING [ssh] Ban 115.238.245.6 |
Ich hoffe zunächst, dass du das Ding nur privat benutzt. Dass dir keine Möglichkeit einfällt, die log Datei als solche zu posten zeugt leider schon von sehr wenig Erfahrung. Allerdings will ich mal fail2ban recidive in den Raum werfen, damit kannst du wiederkehrende Übeltäter länger blockieren. Für weitere Infos wäre die aktive Konfiguration, als lesbare Datei, sehr nützlich.
:
Bearbeitet durch User
Ich habe auf meinem Fedora-basierten Server auch Fail2Ban benutzt. Trotzdem, dass ich mir sehr Mühe gegeben habe, alles richtig zu konfigurieren, hat es doch nicht sauber funktioniert. Ich habe dann was anderes gemacht: ich habe den SSH-Port von 22 auf was anderes geändert. Habe mir irgend einen der well-known Ports raus gesucht, den ich sicher nie brauchen werde. Das ist nun schon >1 Jahr her, und ich hab keinen einzigen Angriffsversuch mehr in der auth.log und btmp. Diese Bots sind halt dumm und versuchen es nur auf Port 22 ;-)
Tobias P. schrieb: > ich habe den SSH-Port von 22 auf was anderes geändert. > Habe mir irgend einen der well-known Ports raus gesucht, den ich sicher > nie brauchen werde. Das ist alles schon passiert.... nach außen hat der Port eine Nummer "mittendrin" aber das nützt dir auch nichts, da die Portscanner verwenden, irgendwann haben sie dich. Bei einem 12 stelligen passwort bzw Zertifikate Identifizierung eigentlich egal, aber es erzeugt halt Traffic und müllt die Logs zu.
Chris J. schrieb: > Leider nur ein Screenshot möglich, da Copy & Paste > auf dem ssh Fenster nicht funzt. Starte den mc mal so "mc -cd". Damit wird die Mausunterstützung abgeschaltet und man kann normal kopieren.
Port ändern und Auth nur per Key Verfahren erlauben. Passwort braucht keine Sau.
temp schrieb: > Starte den mc mal so "mc -cd". Damit wird die Mausunterstützung > abgeschaltet und man kann normal kopieren. Falls PuTTY: Beim Markieren einfach Shift gedrückt halten.
Stefan P. schrieb: > Falls PuTTY: Beim Markieren einfach Shift gedrückt halten. Ja, Putty.. von Windows aus ging das nicht, unter Linux aber schon. auf das ALIX Board kann ich nur per ssh zugreifen.
Chris J. schrieb: > Stefan P. schrieb: >> Falls PuTTY: Beim Markieren einfach Shift gedrückt halten. > > Ja, Putty.. von Windows aus ging das nicht, unter Linux aber schon. auf > das ALIX Board kann ich nur per ssh zugreifen. Leider auch nicht so prickelnd, wenn man sich dass mal durch ein Update, was nicht läuft oder beim nächsten Booten hängen bleibt zerschossen hat.
Chris J. schrieb: > So eine Tageausbeute sieht inzwischen so aus, die reinste Verschwendung > von Bandbreite... leider kein Verbot in Sicht. > >
1 | > 2017-12-11 02:36:41,603 fail2ban.actions: WARNING [ssh] Ban [...] |
2 | >
|
Spaßeshalber habe ich mir jetzt einmal die Auth-Logs eines ungenutzten
(!) Servers genommen, die IPs per Geoip aufgelöst, analysiert und
visualisiert (Elasticsearch + Kibana). In nur einem Monat gab es
(mithin: ohne "message repeated"-Einträge) sage und schreibe 247.000
Login-Versuche, Top 3:
77% China
9% USA
6% Südkorea
Gerade im Falle von China mit seiner berühmten "great firewall"
erscheint es mir unmöglich, daß soetwas ohne die Unterstützung oder
jedenfalls mit Wissen und Tolerierung durch staatliche Stellen
stattfindet. Zumal fast ein Fünftel (44.505) von den IPs
61.177.172.{10,22,40} kommt: diese gehören zum "jiangsu province
network" der staatlichen China Telecom.
Naja, eigentlich sollte mich das nicht überraschen. Aber etwas eh gewußt
zu haben ist eben doch noch was anderes als es bestätigt zu sehen. ;-)
> Ja, Putty.. von Windows aus ging das nicht, unter Linux aber schon. auf > das ALIX Board kann ich nur per ssh zugreifen. Leider auch nicht so > prickelnd, wenn man sich dass mal durch ein Update, was nicht läuft oder > beim nächsten Booten hängen bleibt zerschossen hat. Wenn es keinen VGA hat, dann aber eine serielle Schnittstelle. Das ist dann dein Terminal, falls du dich ausgesperrt hast. Ansonsten kannst du auch die CF Karte, oder von was aus auch immer du bootest, in einen anderen Rechner stecken und den Fehler in der Konfiguration beheben. Zum kopieren von Dateien bietet sich u.a. scp an - mit rsync oder winscp, oder ...
:
Bearbeitet durch User
Soeren K. schrieb: > Wenn es keinen VGA hat, dann aber eine serielle Schnittstelle. Das ist > dann dein Terminal, falls du dich ausgesperrt hast. > > Ansonsten kannst du auch die CF Karte, oder von was aus auch immer du > bootest, in einen anderen Rechner stecken und den Fehler in der > Konfiguration beheben. Ich bin mit Linux schon recht gut vertraut, auch um einfache Skripte zu schreiben und ein Netzwerk mit 3 Rechnern, wlan, ftp, telnet in Betrieb zu nehmen. Nur die Wahl dieses "Alix" Boards aus Preisgründen war ein Fehler (vor 4 Jahren). Klar kann ich da notfalls über die rs232 dran, die CF Card aber kannste dir nur anschauen, mehr nicht. Wenn das Filesystem strubbelig ist, wie neulich, ein paar verlorene Cluster, dann bleibt der erstmal stehen beim booten ud zwar bevor er die eth aufgebaut hat. Und dann fängste wieder an.... Monitor abstöpseln, Raspberry Pi aus der ecke holen, FTDI Adapter usw. Das Board hat weder Monitor noch Tastaturanschluss. Und gegen die heutigen Banana Pis auch keine echten Nutzen mehr. Die Banane M3 ist inzwischen genauso fix wie der Celeron und hat SATA.
Chris J. schrieb: > Ich bin mit Linux schon recht gut vertraut, auch um einfache Skripte zu > schreiben und ein Netzwerk mit 3 Rechnern, wlan, ftp, telnet in Betrieb > zu nehmen. Was treibt einen im 21 Jahrhundert ein telnet zu betreiben? mal ehrlich vielleicht kann man denn Client noch verwenden (zum Debuggen von Netzwerken) aber sonst, dass Ding hatte seine Zeit, aber die war irgendwann im letzten Jahrtausend.
Imonbln schrieb: > Was treibt einen im 21 Jahrhundert ein telnet zu betreiben? Telnet ist deutlich mehr als "TCP->Terminal", das kann z.B. auch Authentifizierung per Public-Key, verschlüsselte Verbindung usw. IAC WILL ENCRYPT -> IAC DO ENCRYPT usw.... https://tools.ietf.org/html/rfc2946 &co. Nur: Kam viel zu spät, da waren dann schon alle (zurecht!) auf SSH umgestiegen.
Telnet ist Spielerei an einem Spielrechner. Aber apropos Spielerei :-) Gestern mal die Festplatten abgeklemmt, fail2ban ausgeschaltet, root Zugang für ssh frei, Passwort: admin Kaffee angemacht und logfile anschauen :-) Es dauerte ca 2 Stunden, bis PAM meldere, dass der erste Gast drin war. Die Schweinebacke änderte als erstes das Root Passwort, dann lief vermutlich ein .sh Skript ab, was im root Verzeichnis diverse weitere Dateien aus dem Netz holte. Da war plötzlich so einiges mehr vorhanden. Dann gingen ihm leider die Lichter aus, weil ich die CF Karte aus dem Slot zog und auf dem PC ihren Ursprungszustand wieder herstellte zudem der Wixer mich als root ausgesperrt hatte. Die Welt ist schlecht, einfach nur schlecht ;-)
Sheeva P. schrieb: > Gerade im Falle von China mit seiner berühmten "great firewall" > erscheint es mir unmöglich, daß soetwas ohne die Unterstützung oder > jedenfalls mit Wissen und Tolerierung durch staatliche Stellen > stattfindet. Zumal fast ein Fünftel (44.505) von den IPs > 61.177.172.{10,22,40} kommt: diese gehören zum "jiangsu province > network" der staatlichen China Telecom. Das ist doch eine etwas gewagte Interpretation. Die "great firewall" wird kaum jeglichen Verkehr ins Ausland unterbinden, die sperrt nur konkrete Ziel-bereiche/-adressen. Auch ist der Adressblock von "jiangsu province network" so wenig ein Indiz für staatlich chinesische Hackerei, wie Adressen aus dem Telekom-Bereich für deutsche Betrüger...
Thread beobachten
Seitenaufteilung abschalten