PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : apache und ssh loginversuche sperren



PeHeller@gmx.net
04.08.12, 12:54
Hallo,

bei mir läuft ein Webserver den ich von ferne auch mit ssh warten kann/will.
Um nun die Anzahl der Fehlversuche zu minimieren habe ich folgende Einstellungen in der

/etc/sysconfig/SuSEfirewall2

FW_CONFIGURATIONS_EXT="apache2"
FW_SERVICES_ACCEPT_EXT="0/0,tcp,80,,hitcount=100,blockseconds=300,recentname =http
0/0,tcp,22,,hitcount=3,blockseconds=300,recentname=s sh"

sowie in der
/etc/ssh/sshd_config

PermitRootLogin no
PermitEmptyPasswords no
MaxAuthTries 2
LoginGraceTime 5m
StrictModes yes
PublicAuthentication yes
MaxStartups 3:30:10

Eigentlich ist es doch doppelt bzw. eine Einstellung unnötig, beide wollen das selbe bei Port 22.
Es funktioniert zwar aber ich weiß nicht warum bzw. durch genau welche Einstellungen es funktioniert. Ich will es auch nicht einfach testen, nicht das ich mich aussperre.

Gruß
worst_case

PS: die hitcounts am Port 80 sind OK, es kommen max. 3 user gleichzeitig.

corresponder
06.08.12, 10:08
kleiner tipp:
ssh port nicht (nie!) auf 22 lauschen lassen...

gruss

c.

DrunkenFreak
06.08.12, 16:41
Mit nem Portscan findest du den SSH-Port immer. Daher schaltest du damit nur das Hintergrundrauschen der Skriptkiddies ab. Anständig konfiguriert, kann dir nichts passieren.

Edit:

@TE: Die Einstellungen sind nicht doppelt. Der SSHd unterbricht nur die Verbindung, eine neue ist aber sofort möglich. iptables sperrt dich für die Zeit aus. Mehr dazu in den entsprechenden Manpages.

hafgan
06.08.12, 19:36
Für sowas bietet sich fail2ban (http://www.root-on-fire.com/2011/06/29/howto-linux-server-mit-fail2ban-absichern/) sehr gut an.

pulsar
10.08.12, 17:54
Hi

fail2ban ist wirklich eine feine Sache und wie corresponder schon sagte ssh port besser verschieben. Es ist wahnsinn wieviele automatisierte Angriffe auf Port 22 einschlagen.

Einfach mal in die Logfile sehen dann weiß man (manchmal) wie der Hase rennt ;)

PeHeller@gmx.net
11.08.12, 15:38
Hallo,



@TE: Die Einstellungen sind nicht doppelt. Der SSHd unterbricht nur die Verbindung, eine neue ist aber sofort möglich. iptables sperrt dich für die Zeit aus. Mehr dazu in den entsprechenden Manpages.

Was hat es dann für einen Sinn, wenn trotzdem automatisch wieder ein login an ssh möglich ist. Dann würde doch die "Firewall" alleine reichen, oder :confused:

Danke
worst_case

jake
17.08.12, 09:30
fail2ban kann ich auch nur empfehlen.

PeHeller@gmx.net
17.08.12, 17:52
Hallo,

OK ich werde mir "fail2ban" ansehen. Somit brauche ich den ssh Schutz und die Regel in der Firewall nicht mehr... ??

Wenn irgendwie möglich, möchte ich nur eine Lösung ("fail2ban") benutzen und nicht mehrmals irgendwo rumprobieren.

Hat jemand Erfahrung mit fail2ban und port 80 (html-server)... man könnte doch auch den port 80 z.B. 50 anfragen pro Minute absichern ??

Danke
worst_case

DrunkenFreak
17.08.12, 18:45
Der Idealfall sieht so aus, dass nur ein bestimmtes Netz auf deinen Server auf die Dienste, die nicht öffentlich sein sollen, Zugriff hat. Am besten ist es, wenn dir das Netz komplett "gehört".

Die Firewall sollte man daher auch konfigurieren unabhängig von Fail2ban. Genauso ist ein Schutz von SSH selbst empfehlenswert. Dazu gibt es aber mit Sicherheit zig Threads hier und bei Tante G.

jake
18.08.12, 11:19
Hi schau mal hier,

http://www.server-wissen.de/security/mit-fail2ban-webserver-gegen-dos-attacken-schutzen/

Ich habs selbst noch nicht eingerichtet, will ich aber auch noch machen.

framp
18.08.12, 12:41
Wenn Du den ssh so konfigurierst, dass man nur mit einem Key reinkommt (also Password authentication abschaltest) kannst Du die ganzen geloggten Zugangsversuche laechelnd ignorieren :rolleyes:

PeHeller@gmx.net
18.08.12, 18:39
Hallo,


Wenn Du den ssh so konfigurierst, dass man nur mit einem Key reinkommt (also Password authentication abschaltest) kannst Du die ganzen geloggten Zugangsversuche laechelnd ignorieren :rolleyes:

das werde ich in Zukunft machen, aber alle "alten Server" sollen mit "fail2ban" geschützt werden.

Gruß
worst_case