ipset hinzufügen liefert Kernel Error

Z

Zumarta

New Member
Hallo,

aufgrund der vielen Bruteforces in den letzten Tagen auf meinen Server aus China möchte ich gerne alle bekannten IPs aus China sperren.

Ich habe mich dabei an diesem Tutorial orientier, erhalte aber, wenn ich das ipset anlegen möchte, folgende Fehlermeldung:

Code: 
ipset v6.20.1: Kernel error received: Operation not permitted

Ich führe den Befehl mit Root-Rechten aus, darum kann ich mir die Meldung nicht erklären. Bei der Suche dazu fand ich leider keine Lösung.

Gibt es vielleicht ein andere simple Methode, um die IP-Adressen zu sperren, bevor sie am ssh ankommen?

Grüße,
Zumarta
 
vServer? Eigener oder Host-Kernel?

Bessere Lösung: SSH vernünftig konfigurieren. Hint: Key-only

GEO-Blocking wird hoffentlich ohnehin bald verboten, daher sollte man sich gar nicht mehr darauf konzentrieren, sondern vielmehr sein OS und seine Dienste richtig auswählen und konfigurieren.
 
Darüber habe ich gar nicht nachgedacht. Der vServer liegt bei Strato, uname -a zeigt mir eine Stratoversionsnummer an, offiziell sei es aber Ubuntu 14.04.

Ich habe ein fail2ban am Laufen und es ging primär darum, dass ich nach ungefähr 12 Stunden jetzt 20 Einträge in der fail2ban Liste gesperrter IPs habe und die sind in 3 Fällen zumindest aus dem gleichen Netz.

Aber Du meinst, ich solle einfach SSH Keys nutzen und den Root-Login deaktivieren? Hilft Port-Verschieben eigentlich etwas? Ich habe hier viel gelesen, dass sich die Geister hier scheiden.
 
@Zumarta:

Kernel verändern geht bei Strato wegen Virtuozzo Virtualisierung nicht.

Fail2Ban oder Port verschieben verringert etwas die Menge an Ausgaben im Logfile und die CPU Last, es kommen trotzdem noch dann und wann ein paar hundert bis tausend Login-Versuche vorbei denn ein echter Schutz ist das natürlich nicht.

Starke Passwörter oder Keys sind der einzige wirkliche Schutz. Mit den trotzdem vorkommenden Login-Versuchen muss man halt leben.

Thomas
 
Zumarta said:
Aber Du meinst, ich solle einfach SSH Keys nutzen und den Root-Login deaktivieren? Hilft Port-Verschieben eigentlich etwas? Ich habe hier viel gelesen, dass sich die Geister hier scheiden.
Click to expand...

Es scheiden sich einfach deshalb die Geister an dem Punkt, da "Security by Obscurity" (also das verheimlichen von Informationen) niemals der korrekte Weg ist ein System ausreichend zu schützen. Nichts destotrotz kann das "Verstecken" des SSH-Daemons helfen die stumpfen IP-Range-Scans auf Port 22 zu verhindern.

Daher folgendes Vorgehen:
1. Wie Joe gesagt hat sichere den Dienst vernünftig ab
2. Optional kannst du den Port umsetzen um das Grundrauschen zu reduzieren

Es sei jedoch angemerkt, dass jeder halbwegs ausgestattete und ausgebildete "Hacker / Angreifer / xyz" in der Lage ist herauszufinden auf welchem alternativen Port dein SSH-Daemon lauscht.

Gruß
Markus
 
Danke euch erstmal für die Hilfe!

Dann werde ich mir das SSH Key Verfahren ansehen und einrichten.
Als 2. Weg sollte ich mich dann wohl vom Nutzen des root-Accounts verabschieden.

Ich hatte noch die Idee, alle Ports, die über speziell über iptables freizugeben und sonst alles abzulehnen. Dazu habe ich zwei Fragen:

1. Ist das eine gute Idee? Sobald ich eine neue Anwendung einrichte, die auf einem anderen Port läuft, muss ich die ja händisch eintragen (wird wohl Zeit für eine Dokumentation für den eigenen Server)
2. Ist hierfür netstat -tulpen | grep -v 127.0.0.1 der richtige Weg, um alle relevanten Ports herauszufinden? Dafür fehlt mir ein wenig die Erfahrung.
 
Wenn Du das System sauber konfiguriert hast kannst Du Dir sparen, nur die benötigten Ports freizugeben und alles andere zu sperren.

Weil - dann auch einem nicht benötigten Port auch nichts laufen / lauschen / ... wird, Du also da gar keinen nach außen offenen Port hast.

Ein Schloss an eine nicht vorhandene Tür anbringen macht ja auch keiner.
 
You must log in or register to reply here.
Back
Top