mod_Security blockiert mein VHost

Seiyaru2208

Captain
Registriert
Apr. 2008
Beiträge
3.112
OS: Ubuntu-Server 12.04 Servertyp: stationärer Server

Hallo Jungs,

um meinen eigenen Webserver zu sichern möchte ich diesen via iptables und mod_security und .htaccses schütze.

jetzt habe ich mod_security installiert und jetzt komme ich nicht mehr auf meinen aktivierten vHost.

Wenn ich ins Error-Log schaue kommt immer Fehler id 981060.

Dies versuche ich mit einen Eintrag im /etc/apache2/conf.d/modsecurity.conf zu beheben

<LocationMatch '^/Testseite/'>
SecRuleRemoveById 981060
</LocationMatch>

Leider wird es in keiner Anleitung richtig erklärt muss ich einen Pfad in LocationMatch angeben?

Ich hoffe Ihr könnt mir helfen das ich auf meinen VHost wieder zugreifen kann..... Grundlegend will ich Sicherheit aber natürlich auch das ich auf meinen Webserver zugreifen kann ^^

PS: an IPtables kann es nicht liegen da ich noch kein Firewallscript ausgeführt habe.
 
Du verwurtest da viele Ansätze von Sicherheit.

Erstmal solltest du wissen was du willst.

Sicherheit in wie Fern?

Es ist eine "INTERNET" Seite, dH es muss grundlegend erreichbar sein, was genau willst du also schützen ?
 
dMopp schrieb:
Du verwurtest da viele Ansätze von Sicherheit.

Erstmal solltest du wissen was du willst.

Sicherheit in wie Fern?

Es ist eine "INTERNET" Seite, dH es muss grundlegend erreichbar sein, was genau willst du also schützen ?

Ich möchte den Server schützen das A kein dritter (.htaccses) Zugriff auf die Daten hat (die Internetseite ist quasi ein CRM-System und auf jeden Client eine VPN einzurichten ist nicht durchführbar) und B das der Server nicht als Slave für irgend ein Bot-netz oder jemand der ein Server für seine Kinderpornos benötigt missbraucht wird (mod_security,IPtables). Sprich ich will die Eierlegende Wollmilchsau :D

Grundlegend hängt der Server hinter einer Fritzbox wo nur der Port 80 und 443 für HTTP und HTTPS frei ist.

Ich habe es auch erstmal hinbekommen aber sicher ist das nicht die sauberste Lösung.....

[Coede]<Directory /var/www/test/testseite/>
SecRuleRemoveById 981060
</Directory>[/Code]


PS: Und nein ein Webhoster kann und will ich nicht einsetzten
 
Zuletzt bearbeitet:
Ah, schon mal ein Setup das verständlicher wird ;)

In diesem Fall (ich vermute mal eine Art Authentifizierung im CRM), sind keine großen Settings mehr nötig. Die FB lässt nur die 2 Ports durch, dH iptables wäre zumindest "von außen" unnötige Arbeit. (Manch einer will dir da sicher anderes Erzählen aber hey... man kann es auch übertreiben).

Was natürlich das größte Risiko darstellt, ist der httpd (nginx, apache..) sowie das eingesetzte Framework (PHP?). Für php ist der suoshin mod schonmal nicht verkehrt, beim Apache einfach alle Module abklemmen die man nicht braucht.

PS: Wenn du so auf Sicherheit aus bist, klemme dort Port80 gleich mit ab (oder baue nen rewrite der port 80 auf 443 umschreibt)
 
dMopp schrieb:
Ah, schon mal ein Setup das verständlicher wird ;)

In diesem Fall (ich vermute mal eine Art Authentifizierung im CRM), sind keine großen Settings mehr nötig. Die FB lässt nur die 2 Ports durch, dH iptables wäre zumindest "von außen" unnötige Arbeit. (Manch einer will dir da sicher anderes Erzählen aber hey... man kann es auch übertreiben).

Was natürlich das größte Risiko darstellt, ist der httpd (nginx, apache..) sowie das eingesetzte Framework (PHP?). Für php ist der suoshin mod schonmal nicht verkehrt, beim Apache einfach alle Module abklemmen die man nicht braucht.

PS: Wenn du so auf Sicherheit aus bist, klemme dort Port80 gleich mit ab (oder baue nen rewrite der port 80 auf 443 umschreibt)

Okay danke schon mal für dein Tipp =)

Also ich nutze kein PHP sondern die CRM-Lösung basiert auf Ruby and Rails als Datenbank wird mysql genutzt.

Wenn ich 443 nutzen möchte muss ich mir ein Zertifikat erstellen lassen oder?

Sprich IP-Tables wäre nur von nöten wenn ich den Server auch als Router nutzen würde oder?

Ich habe derzeit das Problem das mein Script den DHCP-Server abschießt ^^
 
- Also, für SSL braucht man ein Zertifikat, richtig.

- Du "kannst" zusätzlich mittels IP-Tables alles außer 80/443 abschließen, da die FB aber dazwischen hängt und nix anderes macht, ist das nicht notwendig und spart Arbeit.

Sobald der Server direkt (DMZ, Modem dran, etc) erreichbar ist, "sollte" man iptables konfigurieren (und selbst das ist nicht wirklich notwendig, wo keine Tür, da kein reinkommen... :D dH nur wenn ne Software ne Tür dahin baut, muss man sich darum Gedanken machen, es sei denn man möchte Pakete unbedingt "nicht" beantworten oder ähnliche Spielchen.. für NAT wirds dann auch wieder wichtiger.))
 
Zuletzt bearbeitet:
IPTables ist tatsächlich reichlich unnütz bei dem Setup. Was man damit machen könnte, wäre es mit Fail2ban zu koppeln und für das CRM ein Log der fehlerhaften Login-Versuche anzulegen. Das könnte man dann in Fail2Ban speisen, welches wiederum iptables mit temporären IP-Bans versorgt.

Wenn Apache, dein Ruby-Modul (Passenger?) auf Port 80/443 eine Lücke hat, dann hilft dir kein Security-Modul was. Wenn dein CRM in sich verwundbar ist, auch dann hilft kaum etwas... außer .htaccess.
Wenn aber gar nichts davon (bekannte) Verwundbarkeiten aufweist und der Login des CRM vernünftig gestaltet ist (v.A. mit Brute-Force-Schutz), dann passiert hier genau gar nicht schlimmes.
 
Daaron schrieb:
IPTables ist tatsächlich reichlich unnütz bei dem Setup. Was man damit machen könnte, wäre es mit Fail2ban zu koppeln und für das CRM ein Log der fehlerhaften Login-Versuche anzulegen. Das könnte man dann in Fail2Ban speisen, welches wiederum iptables mit temporären IP-Bans versorgt.

Wenn Apache, dein Ruby-Modul (Passenger?) auf Port 80/443 eine Lücke hat, dann hilft dir kein Security-Modul was. Wenn dein CRM in sich verwundbar ist, auch dann hilft kaum etwas... außer .htaccess.
Wenn aber gar nichts davon (bekannte) Verwundbarkeiten aufweist und der Login des CRM vernünftig gestaltet ist (v.A. mit Brute-Force-Schutz), dann passiert hier genau gar nicht schlimmes.

Danke für die ausführliche Hilfe. Ja genau basiert auf Passenger.

Ich habe es mir so gedacht das ich zwei Linien ziehe zum einen mit . Htaccses (mit Digest Authentifizierung) und dann nochmals durch das CRM selbst. An einer MySQL Authentifizierung habe ich auch schon gedacht.

Meine Sorge ist einfach das mein Server missbraucht wird und dann bei mir der Staatsanwalt steht :D
 
Der Missbrauch erfolgt dann aber so oder so auf Wegen, an die du jetzt gar nicht denkst. Den .hta - Digest kannste ja verwenden, ist nur wie ich finde doppelte Arbeit. Dafür kriegste da sicherlich gute Einträge ins Apache Error Log -> schön zu filtern mit Fail2Ban.
 
Ich habe das via https gelöst sprich der Router lässt nur Port 443 durch. Läuft alles soweit gut auch wenn der Mod_security rum meckert und es nervig war die Fehler id's zu sammeln und einzutragen :d
 
Zurück
Oben