RootForum Community

Moin allerseits,

als ordentlicher Paranoiker habe ich mir überlegt, wie ich einen Server, auf dem Kunden-Webs gehostet werden sollen, möglichst wasserdicht bekomme. Meine Überlegung: Der Webserver (geplant ist ein lighttpd mit PHP5/FastCGI) wird chrooted und an localhost gebunden.

Extern soll ein Proxy lauschen, der dann die Inhalte von lighttpd holt. Ziel der Übung ist es aber definitiv nicht, Inhalte zu cachen, sondern den HTTP-Request nach allen Regeln der Kunst zu sezieren, um Angriffsversuche zu unterbinden. Kommerzielle Software dieser Art ist mir zwar bekannt, kommt aber für mein Szenario nicht in Frage.

Prinzipiell sehe ich drei Möglichkeiten:
- Squid + ?
- Apache2 + mod_proxy + mod_security
- Lighttpd + mod_proxy + ?

Meine Überlegungen hierzu:

• Squid ist von der Auslegung her auf Caching und Client Access Control ausgelegt und für meinen Zweck wohl eher oversized
• Womit ließe sich bei Squid der Filter realisieren?
• Apache + mod_security ist bei umfangreicheren Rulesets ein Performance-Problem
• Aufgrund der guten Performance und simplen Konfiguration würde ich Lighttpd vorziehen, weiß allerdings auch hier nicht, wie ich den Filter realisieren kann. Mit mod_setenv, mod_access und Traffic Shaping (core) kann man sich zwar selbst was basteln, aber eine integrierte Lösung ähnlich mod_security wäre mir lieber

Meine Fragen an Euch:
Wie bewertet Ihr den Sinn (Sicherheitsgewinn) bei so einer Aktion? Hat von Euch jemand schon mal so ein Szeanrio umgesetzt?
Welche Fallstricke hab ich eventuell übersehen?
Welche Lösung würdet Ihr bevorzugen?

Grüße
Jesco

Eine solche Lösung suche ich seit ewigen Zeiten auch schon, finde aber nichts. Will eigentlich auch spieleplanet.eu auf Lighttpd, PHP5 und Mysql5 umstellen mit FastCGI, nur dann fehlt mir mod_sec. Ich würde zwar ein Kompromiss eingehen mit dem FastCGI Server, weil ich jede Domain mit einer eigenen Rechteinstanz starten würde, den Lighttpd setz ich via "server.chroot = '/var/chroot/lighttpd' " auf ein eigenes Verzeichniss und in GRSec eine Regel rein, das User (UID und GID) von 10001-11000 keine Shell haben dürfen. An was für Kernelpatches hast du bisher gedacht?

Bei Squid könnte man ja jetzt rein theoretisch hergehen und die mod_sec regeln dorthin
"portieren", danach dürfte Squid auch eine solche Instanz sein. Allerdings wäre das doch schon overdozed, ein paar mod_rewrite Regeln aus den gotroot Regeln gemacht hätte den selben Effekt und ich muss nicht bei https umständlich den Squid als Relayhost einsetzen dafür, sofern https im einsatz ist. Wieviele Kunden sind auf dem Server, sind die überschaubar? Bei 2 oder 3 Kunden dürfte das kein Problem sein da ein paar Regeln zu bauen aus den mod_sec Regeln.

MFG
Lord

Gott sei Dank, dachte schon, die Idee wäre obsolet, weil kaum was dazu zu finden ist :D

Lord_Pinhead wrote:An was für Kernelpatches hast du bisher gedacht?

Ich lass Gentoo Hardened laufen - GRSec und PAX sind aktiv, SELinux ist mir zu aufgeblasen (und remote zu gefährlich - hab keine Remote Console dran und das Rescue-System kennt kein SELinux :? )

Lord_Pinhead wrote:Wieviele Kunden sind auf dem Server, sind die überschaubar?

Ich rechne momentan mit 5-10 virtuellen Hosts, allerdings alles fette Typo3-Installationen, die jeweils mehrere Domains (und Sites) versorgen. Dazu käme noch ein Apache/Tomcat-Gespann mit openXchange. Daher eigentlich die Idee, eine Proxy-Instanz davor zu setzen, weil ich sowieso mindestens zwei HTTP-Server laufen haben muss...

Squid habe ich mittlerweile so gut wie ausgeschlossen; ist einfach mit Kanonen auf Spatzen geschossen - zumal ich wie gesagt das Caching aus nahegelegenen Gründen nicht benötige und auch nicht haben will (für openXchange wär's Schwachsinn, und Typo3 hat eigene Cache-Mechanismen und die Möglichkeit, Seiten statisch zu exportieren).

Hatte erst überlegt, mir notfalls selbst 'n primitiven Daemon zu schreiben, der nur die HTTP-Header per Regex gegen ein Regelset prüft und dann weiterreicht oder mit 403 antwortet. Aber da auch HTTPS mit im Spiel ist, lass ich da lieber die Finger von.

Wahrscheinlich werde ich jetzt versuchen, mir für lighty mit mod_setenv, mod_access und Traffic Shaping was zu basteln und zusätzlich ein Kettenhund-Skript, das meine access_log auf "merkwürdige" Requests tailt und böse Jungs (zeitlich begrenzt) per iptables rausschmeisst. Die Prüferei auf dem App-Layer kostet ganz schön Performance...

Warum schreibst du nicht ein Modul für lighttpd, wenn du schon ans selber programmieren denkst?

Oder: Für das kommende Release 1.5 wird mod_cml so umgebaut, dass es universeller handhabbar sein soll, mit lua kannst du dir dann vemrutlich die gewünschten Filtersets basteln. Habs zwar noch nicht selber ausprobiert, aber nach dem was ich bisher gehört habe wäre das eine Richtung in die es sich zu überlegen lohnt...

Da kann er gleich mod_sec auf Lighttpd portieren ;)

Wobei ich aber keine angst hätte, wenn die Vhosts im CGI Modus mit geringen rechten liefen. Was dort laufen soll ist eigentlich sehr stabil und sicher, das sollte zusammen reichen.

Ja, nur was mir Angst macht sind selbstgeschriebene Typo3-Extensions... oder solche, die eigentlich auf einem Produktivsystem noch nix verloren haben. Man weiß ja nie, auf was für Ideen die Leute so kommen, und für mich wäre es schon schlimm genug, wenn schlechter Code SQL-Injection ermöglicht... und damit eventuell auf die DBs anderer Typo3-Instanzen durchschlägt. Dann hocke ich genau da wo ich nicht hinwollte und fange an, PHP-Skripte zu verschlimmbessern... (wohlgemerkt nicht meine eigenen!)

Ich hatte auch schon daran gedacht, ein lighty-Modul selbst zu schreiben bzw. mod_security zu portieren, aber für solche Spielchen hab ich eigentlich nicht die Zeit... Muss mir mal bei Gelegenheit die APIs anschauen, wie komplex sowas umzusetzen wäre. Ansonsten hat man bei sowas natürlich auch gleich die Maintenance am Hals 8)

Unter'm Strich ziehe ich auch in Betracht, einfach einen Apache 2.2 ohne jeden Schnickschnack zu nehmen - nur mod_access, mod_setenv und mod_security. Wenn man da ein schönes Preemtion Model wählt, dürfte das auch recht performant laufen.

So, hab noch mal ein bisschen Material gesichtet:

• BSI: Überblick über die Konzeption von Sicherheitsgateways
  Interessante Ausführung, es wird ein 232-seitiges PDF zum Download beretsgestellt, das das Thematik "Sicherheitsgateway" (zu neuhochdeutsch: Firewall) gewidmet ist
• Squid Portal
  Deutsches Portal rund um Squid - leider momentan ziemlich ohne Inhalte
• Dirk Dithardt: Squid Handbuch
  Deutsches Buch zu Squid in Online-Veröffentlichung

Lord_Pinhead wrote:Bei Squid könnte man ja jetzt rein theoretisch hergehen und die mod_sec regeln dorthin "portieren", danach dürfte Squid auch eine solche Instanz sein.

Ja. Die Bordmittel von Squid (ACLs und Regelsteuerung) sind schon recht beeindruckend. Hab mir auch mal SquidGuard angeschaut, aber leider ist die letzte Version von 2001 - das sieht für mich nach ner Projektleiche aus...

Wie steht's denn mit dem Ressourcenhunger? Mit den Features, die da drin stecken, müsste das doch noch weit schlimmer sein als Apache mit mod_proxy und mod_security, oder täusche ich mich da?

Sorry, muss diese alte Kamelle noch mal aufwärmen. Wurde etwas stutzig, als ich auf der Homepage von mod_security lesen musste:

ModSecurity wrote:ModSecurityTM is an open source intrusion detection and prevention engine for web applications (or a web application firewall). Operating as an Apache Web server module or standalone,[...]

Na ja, nach ein bisschen Recherche war klar, dass bis dato ein standalone-Ableger noch nicht existiert. Allerdings wurde einer von Thinking Stone angekündigt, und zwar für Ende des Jahres unter dem Namen "ModSecurity Network Gateway" (siehe http://www.thinkingstone.com/products/modsecurity/roadmap.html)
Na ja, vielleicht wird da ja noch was drauß, und v.a. - hoffentlich wird's OpenSource!

Hm, das ist mal interessant, hoffe das wird rechtzeitig fertig :)

Für mich kommt's leider zu spät, aber wenn's kommt, werd ich mir mal anschauen, ob ich damit nicht meine Selfmade-Lösung (Reverse-Proxy aus Apache 2.0, mod_proxy und mod_security) ablösen kann, um 'n bisschen Leistung zu sparen. V. a. das Umbiegen der Requests wird dann vielleicht obsolet :)

Hi,

meine Apache2-Proxy auf Apache2-mod_php (mit eigener Instanz pro Kunde) erwies sich als durchaus funktional, aber auch als massiver Ressourcenfresser. Auf der Kiste (Athlon64/3000/512MB) läuft nur Apache, Proftp, munin-node. 1xApache als Proxy, 20xApache als Backend.

Dazu hat der Apache noch einige Macken - ein Kunde von mir benutzt WebEdition und konnte dann nur noch ein Bild hochladen statt mehrerer Bilder in einem Aufwasch - sowohl mit direktem Apachen als auch mit Pound ging das. Einzelupload habe ich noch durch tunen an Kernelparametern hingebracht, aber der Mehrfachupload hat nicht funktioniert.

Den Frontend-Apachen habe ich jetzt auf einer Ersatzmaschine mit mehr Speicher durch Pound ersetzt und werde dieses Wochenende moven - mod_sec gibt es dafür natürlich nicht. :-(

flo.

/me wirft einfach mal noch Zorp als ALG in den Raum, und freut sich schon auf die Testversion der bald herauskommenden Appliance. ;)