Fail2ban ist ein komplett anderer Ansatz.
Schau dir mal das an
https://github.com/rpthms/nft-geo-filter
Ich nutze verschiedene blocklisten. Aktuell glaube um die 200000 IPs drin.
Fail2ban ist ein komplett anderer Ansatz.
Schau dir mal das an
https://github.com/rpthms/nft-geo-filter
Ich nutze verschiedene blocklisten. Aktuell glaube um die 200000 IPs drin.
cschlosser: Naja, rausgehend ist ja nicht unbedingt schlimm, Hauptsache es kommt nix rein.
p2pool.io hat er bei mir nur in der hosts gefunden, weil ich dort diese Domain ins Nirvana umleite. 20749 findet er in der fail2ban.sqlite3 und im Nextcloud Flyer.pdf
Aber journalctl zeigt mir das hier:
kernel: [UFW BLOCK] IN=ens3 OUT= MAC=4a:2e:36:66:58:2a:bc:0f:fe:3d:a3:a7:08:00 SRC=98.217.189.211 DST=152.xxx.xxx.xxx LEN=284 TOS=0x00 PREC=0x00 TTL=114 ID=49932 DF PROTO=UDP SPT=20749 DPT=28286 LEN=157
Mein Server ist gesperrt worden, weil jemand von dem Port 20749 versucht was aufzurufen?
Hille: Ich glaube es reicht, wenn ich die bösen sperre, die auf meinen Rechner zugreifen - eigentlich.
Da Netcup anscheinend bei mir jetzt sowas wie eine DDOS-Attacke nicht als solche erkannt hat und meinen Rechner wohl nur deswegen gesperrt hat, weil irgendein Mining-Netzwerk auf meinen Rechner zugreifen will und ich die blocke, muss ich vielleicht doch umdenken ![]()
Mein Server ist gesperrt worden, weil jemand von dem Port 20749 versucht was aufzurufen?
Unwahrscheinlich. Die abuse Meldung sagt ja auch inbound und outbound.
Das durchsuchen war nur eine Idee ob da irgendwo eine config.json oder ähnliches in einem docker volume persistiert ist.
Naja, rausgehend ist ja nicht unbedingt schlimm, Hauptsache es kommt nix rein.
Ausgehend kann aber auch eine kompromittierte Maschine weniger kaputt machen.
cschlosser: für den unwahrscheinlichen Fall, dass mein Rechner auch Outbound aktiv war, er hat nie Antwort erhalten, weil Inbound alles gesperrt ist. Also richtige Übertragungen haben gar nicht stattgefunden und damit auch kein Mining.
Ich hätte schon ein wenig mehr Input von Netcup erwartet - z.B. seit wann und wie häufig diese Transfers stattgefunden haben sollen. Lieber lassen die mich im Nebel irgendwelche Protokolldateien nach irgendwas durchsuchen anstatt mir den Server komplett zur Verfügung zu stellen, damit ich einfach sehen kann, welcher Prozess den angeblichen Outbound macht. Naja, Servicewüste halt. Können ihn ja nach 4? Stunden wieder sperren, wenn ich das nicht abgestellt habe. Aber nein, wäre ja zu einfach für den Kunden ...
Vielleicht doch keine Autoupdates mehr? Oder gar keine Updates? Vielleicht habe ich mir eines der kompromitierten Pakete bei so einem Update eingefangen? Ich weiß es nicht, ich weiß nur, dass bei meinem Server alle Miner so wie es sich gehört gesperrt werden.
Übrigens, ich nutze einen eigenen DNS-Server. p2pool.io wurde von dem deaktivierten Server niemals angefordert. Also, wie kommt Netcup auf diese Domain? Interessant, beim DNS-Server kann ich sehen, dass die letzte DNS-Abfrage genau 24h nach der Abuse-Email kam. Dann wurde der Rechner brutal abgeschaltet.
Toll, danke Netcup: Nach genau 4h wurde jetzt auch das Rettungssystem abgeschaltet. Abschalten und deaktivieren können die ![]()
für den unwahrscheinlichen Fall, dass mein Rechner auch Outbound aktiv war, er hat nie Antwort erhalten, weil Inbound alles gesperrt ist. Also richtige Übertragungen haben gar nicht stattgefunden und damit auch kein Mining
Stateful firewall die established/related incoming erlaubt. Wie kommst du sonst an apt Pakete und docker images?
Übrigens, ich nutze einen eigenen DNS-Server. p2pool.io wurde von dem deaktivierten Server niemals angefordert. Also, wie kommt Netcup auf diese Domain?
Hardcoded IP im miner und dann reverse dns wäre meine Vermutung.
Nach genau 4h wurde jetzt auch das Rettungssystem abgeschaltet.
Hoffe du konntest einen snapshot ziehen in der Zeit.
Trotz gedrosselter Leitung mit 10MB/s konnte ich ein Archiv runterladen.
Jetzt muss ich wohl bis Freitag Mittag warten, bis Netcup wieder arbeitet.