PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : IP Adressen temporär sperren?



Thomas79
14.08.07, 13:08
Hallo zusammen,
ich hoffe ihr könnt mir ein wenig weiterhelfen.

Folgende Situation bei uns in der Firma.
Wir haben 2 Root Server bei Strato und ich (als nicht sehr versierter Linuxnutzer) bin im Moment für diese Server zuständig. Ich habe mir mittlerweile schon mehrmals unter "/var/log" die Datei "messages" angeschaut.
Dort gibt es u.a. folgende Einträge

Aug 14 11:05:58 h1175145 sshd[20927]: reverse mapping checking getaddrinfo for corporativos_245173-147.etb.net.co failed - POSSIBLE BREAKIN ATTEMPT!
Aug 14 11:06:00 h1175145 sshd[20929]: reverse mapping checking getaddrinfo for corporativos_245173-147.etb.net.co failed - POSSIBLE BREAKIN ATTEMPT!
Aug 14 11:06:01 h1175145 /usr/sbin/cron[20934]: (root) CMD (/usr/local/visas/server/visas-event.sh)
Aug 14 11:06:02 h1175145 sshd[20931]: reverse mapping checking getaddrinfo for corporativos_245173-147.etb.net.co failed - POSSIBLE BREAKIN ATTEMPT!
Aug 14 11:06:03 h1175145 sshd[20939]: Invalid user network from ::ffff:201.245.173.147
Aug 14 11:06:03 h1175145 sshd[20939]: reverse mapping checking getaddrinfo for corporativos_245173-147.etb.net.co failed - POSSIBLE BREAKIN ATTEMPT!
Aug 14 11:06:05 h1175145 sshd[20941]: Invalid user word from ::ffff:201.245.173.147

oder

Aug 11 07:59:58 h1175145 sshd[12712]: Invalid user chiltlin from ::ffff:85.19.135.21
Aug 11 07:59:59 h1175145 sshd[12714]: Invalid user chimpy from ::ffff:85.19.135.21
Aug 11 07:59:59 h1175145 sshd[12716]: Invalid user chrisg from ::ffff:85.19.135.21
Aug 11 08:00:00 h1175145 sshd[12718]: Invalid user chrome from ::ffff:85.19.135.21
Aug 11 08:00:00 h1175145 sshd[12720]: Invalid user cimtig from ::ffff:85.19.135.21
Aug 11 08:00:01 h1175145 sshd[12722]: Invalid user civsoc from ::ffff:85.19.135.21


Ich würde nun gerne wissen ob es eine Möglichkeit gibt, solche IP Adressen nach z.B. 10 fehlgeschlagenen Loginversuchen für einen bestimmten Zeitraum zu sperren?

Auf den Systemen laufen Suse 9.3 bzw. Suse 9.0.

Wie gesagt, bin da nicht so vertraut mit. Hoffe dennoch ihr könnt mir eine Lösung mitteilen und mir irgendwie verständlich machen wie ich da vorzugehen habe.

Vielen Dank für eure Bemühungen.
Thomas

zyrusthc
14.08.07, 13:10
Lege einfach den sshd auf einen höheren Port >10000 und du hast Ruhe!

Wir haben 2 Root Server bei Strato und ich (als nicht sehr versierter Linuxnutzer) bin im Moment für diese Server zuständig.
http://www.root-und-kein-plan.ath.cx

Greeez Oli

marce
14.08.07, 13:10
(1) völlig normales Hintergrundrauschen. Wenn das System vernünftig konfiguriert ist ist das kein Problem.

(2) Such mal nach fail2ban

Thomas79
14.08.07, 13:39
danke für die Antworten.
werde mir den Link mal genauer anschauen und mich ein wenig mit fail2ban auseinander setzen.

marce
14.08.07, 13:50
... übrigens, gerade aufgefallen - Suse 9.0 und 9.3 sind inzwischen aus der Wartung, also evtl. mal über ein Update nachdenken...

BedriddenTech
14.08.07, 17:52
Lege einfach den sshd auf einen höheren Port >10000 und du hast Ruhe! Ich denke nicht. Dienste auf anderen Ports lauschen zu lassen ist keine Lösung.

zyrusthc
14.08.07, 18:04
Ich denke nicht. Dienste auf anderen Ports lauschen zu lassen ist keine Lösung.
Beim sshd ist das immer der erst Tip der fällt
zb.
http://www.linuxforen.de/forums/showpost.php?p=1209144&postcount=2
Weil kein Bot auf zb. 12345 probiert, sondern nur auf den Standartports.


Greeez Oli

marce
14.08.07, 18:07
Allein um Logfiles sauber zu halten ist der Tip auch ok - man darf nur nicht denken, dass es etwas mit Sicherheit zu tun hat.

zyrusthc
14.08.07, 18:08
Na dann hier noch ein TIP für den Threadersteller
http://www.ende-der-vernunft.org/index.php?p=869

Greeez Oli

Thomas79
15.08.07, 16:44
vielen Dank für die zusätzlichen Tipps.
Leider komme ich z.Z. immer nur sporadisch dazu mich mit dem einen oder anderen Hinweis auseinander zusetzen :(

piepre
16.08.07, 10:13
Da ich keine Lust hatte bei uns Fail2Ban einzurichten, habe ich es einfach direkt über iptables gelöst:


iptables -N SSH_WHITELIST
iptables -A SSH_WHITELIST -s XXX.XXX.XXX.XXX -m recent --remove --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-level debug --log-prefix "FW: SSH-Brute-Force "
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

funktioniert bisher wunderbar.