Einschätzung des Sicherheitslevels meines Servers

Für Modsecurity die bezahlten Atomic "gotroot" Rules, finde die ganz gut.
Weil die standard RUles sind mal voll fürn ar......!
Die kostenlosen gotroot sind nicht schlecht, aber schon was älter.

Anstatt sich sorgen zu machen über die Security auf Server Seite , mal besser auf Client bzw den Rechner mit welchem an dem bzw auf dem Server gearbeitet wird.

Denke mal das ne menge Server gehackt werden, weil auf dem Client ein Schad program läuft!
 
Karl34 said:
Anstatt sich sorgen zu machen über die Security auf Server Seite , mal besser auf Client bzw den Rechner mit welchem an dem bzw auf dem Server gearbeitet wird.
Click to expand...

Ja, das macht Sinn, sollte aber selbstverständlich sein. Ich fühle mich hinter einem Router und in reiner (aktueller und mit Verstand aufgesetzter) Linuxumgebung (Ubuntu) eigentlich ziemlich sicher. Wenn jemand rein will kommt er rein, keine Frage, aber die Scriptkiddies bleiben draussen. :D

Die Linkhinweise sind aber interessant und die werde ich über das Wochenende mal genauer begutachten. Danke!

Viele Grüße
Thomas
 
Ja das kann ich begründen!
Die standard Rules welche bei Modsecurity mit kommen sind stark veraltet. Nutze mal die Standard Rules und versuche ein ganz normales CMS Joomla,Drupal,Wordpress zum laufen zu bekommen :eek::eek::eek::eek::eek::eek:
 
Also die letzte Version datiert auf Ende Juli.
http://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/
Ich hab damit keine Probleme und hab aktuelle CMS am laufen. Gut, die ein oder andere Rule muss etwas angepasst werden, aber die Core-Rules zielen ja auch nicht darauf ab, sich auf spezielle CMS zu konzentrieren, sondern sind eher allgemein gehalten.

Bei den gotroot-Rules sehe ich immer das Problem, dass dort sehr sehr viele Rules drin sind, die auf spezielle CMS zugeschnitten sind und ziemlich nutzlos sind, wenn dieses CMS nicht eigesetzt wird.
 
Die gotroot Rules sind halt auf SHAREDWebserver ausgelegt. Da sehr viele Provider grade aus den Usa die einsetzen. Ich hatte damit noch nie probleme und würde die kostenlosen gotroot rules immer den core rules vorziehen.
 
e1i7e said:
"Der Username lautet nicht "root"" <- Dann loggst du dich auch nicht als root ein. Das Problem mit dem rootlogin bestelt im Prinzip nur darin, dass der Benutzername dem Angreifer bekannt ist. Wenn dieser auch noch den Benutzernamen erraten/bruteforcen muss, dauert das ganze halt einiges länger.
Click to expand...
Doch, ich bin dann root. Also ich habe GID / UID 0. Mehr root geht nicht. :D

Bruteforcen wird hier langsam aber sicher "unmöglich".
 
Der Vorteil von deaktiviertem Root-Login ist nicht nur, dass der Angreifer noch den Benutzernamen erraten muss, sondern, dass er nach erfolgreichen Angriff immer noch ein weiteres Passwort (in einer anderen Eingabemaske) braucht, um root zu sein.


Und mal ehrlich:
Ob ein UID-0-User nun root ist, wenn er nicht root heißt ist doch aus technischer Sicht nur Haarspalterei.
 
Jesaja said:
Der Vorteil von deaktiviertem Root-Login ist nicht nur, dass der Angreifer noch den Benutzernamen erraten muss, sondern, dass er nach erfolgreichen Angriff immer noch ein weiteres Passwort (in einer anderen Eingabemaske) braucht, um root zu sein.
Click to expand...
Das ist es doch. Auch in meinem Fall muss man noch einen Benutzernamen vor dem Login erraten. Und Passwort und Username zu bruteforcen ist einfach nicht mehr möglich.


Grüße
 
Bruteforce halte ich auch für unwahrscheinlich bei einem guten Passwort da:
1. Brutefocre wird erkannt
2. Ip wird gebannt :D

Ausser bei Admins welche naja ich sage mal Freizeit Admins , das Passwort GOD Love usw heisst und nichts installiert ist was einen Fehlgeschlagenen Login erkennt und darauf reagiert.

Viel grösser ist die gefahr das der Client infiziert ist. Zur Zeit ist doch so das viele Angriffe auf die laufende Software wie CMS und konsorten statt findet.
Bin mal gespannt was die nächsten Jahre so alles auf uns zu kommt :D
 
inzwischen gibts ja schon heute die möglichkeit durch webseiten besuch OHNE java applets das man infiziert wird.. ist ja echt krass heutzutage
zum glück ist das nur unter windows so...

ubuntu gnome ftw!
 
Hallo zusammen,

Super Beitrag wie ich finde.. ich hab allerdings nochmal eine Frage! Wurde eigentlich auch schon in einem Beitrag erwähnt. Wenn ich unter meinem Debian 6 System nach dem libapache2-mod-security suche dann erhalte ich lediglich das Modul libapache-mod-security! Da die meistens Tuts sich auf Lenny oder Etch beziehen ist meine Frage ob ich nun das Modul installieren kann??
 
Also ein
aptitude search mod-security
Click to expand...

liefert mir:

p libapache-mod-security - Tighten web applications security for Apac
v libapache2-mod-security2 -
p mod-security-common - Tighten web applications security - common
v mod-security2-common -
Click to expand...

Also setz mal eine "2" dahinter :)
 
libapache-mod-security heißt das Paket und ersetzt libapache2-mod-security2. Das Paket stellt mod_security für Apache 2.2 bereit und bereit.
 
Danke für den Hinweis.. da stehts auch! Bin auch noch nicht so firm!! :-( arbeite aber weiter an mir, mich in der Linux Welt besser zurecht zu finden, und das Forum hilft ungemein! DANKE
 
skydrak said:
Bei mir sind Root-Logins auf den Servern erlaubt, da nur per Public-Key connected werden darf. Wer sich per Passwort authentifizieren will, bekommt somit eine Fehlermeldung.
Click to expand...
SSH-Keys sind etwas Tolles :)
Ich finde es interessant, dass immer wieder dazu geraten wird, den direkten root-Login zu sperren.

Ich setze jetzt schon seit einigen Jahren fail2ban ein und lasse mich über jeden Vorfall per Email informieren.
Wenn ich dann nachschaue, welche Benutzernamen zum Login verwendet wurden, sehe ich alles Mögliche - Aber niemals "root" (Abgesehen von meinen eigenen Logins natürlich.)
 
Ja Fail2ban ist nicht schlecht und kann noch viel mehr als gedacht... z.B. 404 Attack Ban's etc.

Bei Netcup hatte ich es sehr häufig das einfach wahrlos alle möglichen Kombinationen von "phpmyadmin" ausprobiert wurden. Mit dabei aber auch beinahe alle üblichen CMS Verzeichnisse etc.

mit nem 404 Ban war dann ruhe. :-)


bei SSH gibt es auch noch die möglichkeit mit knockd zu arbeiten.

und ein Blick auf denyhosts lohnt sich auch mal...
 
You must log in or register to reply here.
Back
Top