Hilfe! Mein Server wird angegriffen!

walt schrieb:
Muss sie nicht.
Entweder von Hand oder per cron:
/sbin/pfctl -t sshattack -T show > /root/sshattack
Zum Vergrößern anklicken....

Okay. Scheint leer zu sein. Wie oft leert sich diese table denn? Der letzte "Angriff" war um 14:51 und jetzt kommt hier nichts raus. Wozu muss die Datei denn ueberhaupt angelegt sein, wenn ich da eh standardmaessig nichts rein schreibe?
 
Von alleine leert sich diese Tabelle gar nicht.

Ob Eintraege in der Tabelle sshattack expiren sollen oder nicht, muss jeder fuer sich
selbst entscheiden.

Falls ja, verwendet man:
1.) (seit OpenBSD 4.1) "/sbin/pfctl -t sshattack -T expire 86400" in der crontab
Hiermit werden alle Eintraege aelter als 1 Tag aus der Tabelle entfernt.

2.) expiretable
http://expiretable.fnord.se/
http://www.bgnett.no/~peter/pf/en/bruteforce.html

Wobei ich 1.) praeferiere.

Falls nein, verwendet man:
/sbin/pfctl -t sshattack -T show > /root/sshattack
von Hand oder per cron um den aktuellen Inhalt der Tabelle sshattack vor dem reboot
fuer den naechsten Systemstart in die Datei /root/sshattack zu retten.
Aus dieser Datei wird die Tabelle beim Systemstart geladen und der Stand vor dem reboot ist verlustfrei wiederhergestellt.
 
EDIT: Komischerweise tauchen jetzt Eintrage bei mir auch, scheint also auf einmal doch zu gehen...

Danke ;)
 
max-src-conn(-rate) besagt folgendes:
Code: 
max-src-conn <number>
           Limits the maximum number of simultaneous TCP connections which
           have completed the 3-way handshake that a single host can make.
max-src-conn-rate <number> / <seconds>
           Limit the rate of new connections over a time interval.  The con-
           nection rate is an approximation calculated as a moving average.
anzahl der verbindungen und aufbau _neuer_ verbindungen. wenn die verbindung nun steht und der sshd die verbindung aufrecht erhält, um nutzernamen passwort abzufragen, bedarf es nunmal keines neuen verbindungsaufbaus.
 
Okay, nun tauchen ja auch IPs in der table auf. Wozu brauche ich dann aber das folgende Statement?

Code: 
table <sshattack> persist file "/root/sshattack"

Das file brauche ich dann doch garnicht, wenn ich die IPs nicht über einen Reboot hinweg retten möchte. Dann nutze ich doch lieber das Expire Statement in der Crontab und gut ist...
 
sshd ausschließlich mit Puplik Key Authentifikation ausgestattet und mit Einschränkung auf die meinem Client zugewiesene Dialin Domain des Providers in /etc/hosts
 
sshd auf dem Standardport ausschließlich mit Puplik Key Authentifikation (kein Challenge Response!) betrieben und mit Einschränkung auf die meinem Client zugewiesene Dialin-Domain meines Providers in /etc/hosts.allow

Code: 
....
sshd:.domain.suffix:ALLOW
.....
ALL:ALL:DENY

brachte erfolglose Anmeldeversuche im unteren dreistelligen Bereich je Monat und die Latenzzeit zwischen mehreren Anmeldeversuchen ein und des selben Bots liegen im Minutenbereich. Das kann also auch als effiktive Abwehr eingesetzt werden ohne weitere Firewallregeln und Tabellenaufräum-Cronjobs aufzusetzen.

ACHTUNG:
Gut, bei großen Provideren können schon mal andere Domain-Suffixe ausgeliefert werden und dann steht man da vor verschlossener Tür. Aber nach ein paar neuen Einwahlversuchen bekommt man dann wieder die sonst "übliche" Domain zugewiesen.

Edit:
Sorry für den verunglückten Post.
 
walt schrieb:
Ja - mit folgender pf-Regel:
table <sshattack> persist file "/root/sshattack"
[...]
block in quick from <sshattack> to any
[...]
pass in on $ext_if proto tcp to ($ext_if) port ssh flags S/SA keep state \
(max-src-conn 10, max-src-conn-rate 5/30, overload <sshattack> flush global)

Hier ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.txt nachzulesen.

Das hier ist auch sehr nett:
rdr pass on $ext_if proto tcp from !<sshattack> to MyPublicIP/32 port 25 -> 192.168.10.10 port smtp

und kann beliebig kombiniert werden.
Zum Vergrößern anklicken....

Ich muss den alten Thread noch einmal hochholen, sorry...

Machen solche Regeln für alle eingehenden Verbindungen Sinn? Was ist mit einem OpenVPN Server auf 443 oder aber einem Mailserver? Dafür dann auch eigenes Tables anlegen oder macht das keinen Sinn?
 
Solche Regeln gehören sich IMHO nur bei "privaten" Diensten - für öffentliche Dienste wie SMTP oder gar HTTP sind sie nicht unbedingt eine gute Idee. Woher soll pf schließlich wissen, ob die Gegenstelle ein Pöhser h4xor oder ein (Firmen-, Uni--, AOL-, Privoxy-) Proxy ist, hinter dem sich wer weiß wie viele Clients verbergen? Gerade bei Privoxy-Servern können mehrere zeitnah initiierte Verbindungen auch auf anderen Protokollen als HTTP erfolgen, und die sind einfach nicht von normalem Hammering zu unterscheiden.
 
Meine wärmste Empfehlung: ossec, gibts auch in den ports.

Habe es unter debian unter testweise unter freebsd benutzt.

Du musst halt die Rules noch etwas feintunen und an deine Bedürfnisse anpassen, aber es hilft dir auch bei z.B. Bruteforce auf ssh. (das Programm wertet das an der auth.log und schießt einen lustigen Angreifer für 10 Minuten - oder was du halt einstellst - in die hosts.deny - bei debian halt, schätze bei bsd is es ähnlich)

Gefahr dabei ist, dass jemand dein installiertes ossec für ein DOS ausnutzt. Warum?
Weil die Sperrung von einzelnen IP's natürlich die Gefahr birgt, dass jemand Absender IP's fälscht (zigtausende) und Blödsinn anstellt -> und deine deny Regeln füllen sich ohne Grund... Aber zum Glück ist das nicht sooo wahrscheinlich! :-)

Hast dabei auch noch nette Features wie File Integrity check, rootkit detection etc.
Mir gefällts sehr gut, ist weitgehend easy zum administrieren und es gibt eine optionale WebGUI zum auswerten. Auch nett.

Have a look: ossec.net

Aber merke: mit ossec holst du dir natürlich ein Stück mehr Komplexität an Bord!
Wenn du es aber brav streichelst ist es dir ein guter Freund :D
(und wenns mal läuft wie es soll, und das tut es schnell, hast du lange Ruhe)

PS: habe nicht den gesamten Thread gelesen, evtl. wurde es schon empfohlen.

edit: für standalone maschinen brauchst du "ossec-hids-local-1.4"
Kannst das ganze auch für mehrere Installationen per Server <-> Agent installieren.

Kennt jemand "samhain" als Alternative dazu? Scheint mir komplexer zu sein?
Irgendjemand Erfahrung damit?
 
walt schrieb:
1.) (seit OpenBSD 4.1) "/sbin/pfctl -t sshattack -T expire 86400" in der crontab
Hiermit werden alle Eintraege aelter als 1 Tag aus der Tabelle entfernt.
Zum Vergrößern anklicken....

Dazu ist mir schon länger etwas aufgefallen. Weiß jemand zufällig, warum ich täglich eine Email bekomme, wenn dieser Eintrag in der crontab gesetzt ist? Dann bekomme ich zwar immer ne Info wie viele Einträge expired sind, aber ich möchte die Email einfach nicht bekommen. Wie kann man das am geschicktesten abstellen?
 
ein > /dev/null habe ich schon hintergepackt. Die Mails kommen trotzdem noch...

Cron <root@mail> /sbin/pfctl -t sshattack -T expire 86400 > /dev/null
 
radiohead schrieb:
Dazu ist mir schon länger etwas aufgefallen. Weiß jemand zufällig, warum ich täglich eine Email bekomme, wenn dieser Eintrag in der crontab gesetzt ist? Dann bekomme ich zwar immer ne Info wie viele Einträge expired sind, aber ich möchte die Email einfach nicht bekommen. Wie kann man das am geschicktesten abstellen?
Zum Vergrößern anklicken....

pfclt(8), Zeile 183 (fuer -current).
 
Könnt ihr denn so gnädig sein und den besagten Part hier posten? Auf meiner Firewall sind keine Manpages drauf und Online haben die Manpages keine Zeilennummerierung...

Danke!
 
Ich hab noch mal eine Frage zu dem Einschränken der SSH Logins pro Zeitraum. Ist es möglich und wenn ja wie, eine Email zu verschicken, sobald ein neuer Eintrag in meine sshattack table von pf geschrieben wird?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben