Umstellung des Webservers danke .com und Script-Kiddies

[redbrick]

Hallo zusammen!

Ich suche eine Lösung für einen Webserver, der mir die beste Performance bietet. Auf dem Webserver liegen sehr viele große Bilder und als CMS wird eine abgewandelte Version von PostNuke verwendet.

Die Seite hat ca. 240.000 Seitenaufrufe und 11.500 Visits pro Tag.

Es stehen zwei nahezu identische Systeme zur Verfügung.

Grund für eine Umstellung vom aktuellen System (MySQL Backend auf einem Server plus Apache 1.3 auf dem anderen System) ist, dass die Seite ein zu großes angriffsziel ist, dank .com-Domäne und immer wieder scriptgesteuerte Angriffe auf den Apache stattfinden.

Nach einigem Hin- und her komme ich zu folgenden Möglichkeiten an

Webservern um an die bestmögliche Performance zu gelangen:

1. Tux auf Port 80 für die statischen Dateien und Apache2 + mod_cache + PHP4 auf einem andern Port als 80 für die dynamischen Seiten auf einem System. Auf dem zweiten System MySQL4.

2. Apache2 + mod_cache + PHP4 für die dynamischen Seiten auf einem

System und Tux für die statischen Dateien und MySQL4 auf dem anderen System.

3. lighttpd + PHP4 (fastcgi) auf einem System und MySQL4 auf dem anderen

System.

4. thttpd für die statischen Seiten und MySQL4 auf einem System. Apache 2 + mod_cache + PHP4 für dynamische Seiten auf dem anderen System.

Gibt es für diese Konfigurationen irgendwelche aktuellen Benchmarks?

Hat jemand alternative Lösungsvorschläge?

Die Systeme haben jeweils:

- 2 XEON CPUs

- 3 GB RAM

- als OS Debian GNU/Linux

Untereinander sind die Systeme mit 1 GBit verbunden und der Webserver

ist mit 100 MBit an das Internet angebunden. Aus oben genannten Grund soll der Server mit dem Apache natürlich immer im Hintergrund liegen und nicht direkt ans Internet angeschlossen und nicht über Port 80 erreichbar sein (mod_proxy?).

Eine weitere Lösung, bei der der Apache direkt am Internet ist, wäre eine Verschleierung der WebServers-Applikation und seiner Version (komplett ohne Versions-Auskunft oder mit gefälschter Versionsangabe wie AOLserver oder ein anderer Server, der nicht für seine Häufigkeit und Schwachstellen bekannt ist), sofern das möglich ist. Ich wüsste jetzt auf Anhieb leider keine entsprechende Lösung.

Greeting

Chris

[Jaraz]

Hi,

Grund für eine Umstellung vom aktuellen System (MySQL Backend auf einem Server plus Apache 1.3 auf dem anderen System) ist, dass die Seite ein zu großes angriffsziel ist, dank .com-Domäne und immer wieder scriptgesteuerte Angriffe auf den Apache stattfinden.

das verstehe ich nicht..

Ist das Debian nicht gepatcht?

Registrierst du nur Angriffsversuche oder wird die Maschine tatsächlich gehackt?

Gruß Jaraz

[redbrick]

Aus irgendwelchen Gründen finden ständig scriptgesteuerte Angriffe auf die .com Domäne statt. Als wäre sie in irgend einem forum oderso zum Abschuss freigegeben worden.

Allerdings wurde die Kiste schon einmal gehackt, dank falscher PHP-Konfiguration. Der Angreifer hat eine Shell bekommen. Jedoch konnte das Script dank des Paketfilters nichts weiter anrichten - alle Verbindungen zum telnet- / ssh-server, der vom Script installiert wurde, wurden geblockt. Daraufhin wurde der MySQL-Server zusätzlich als Webserver umfunktioniert und der gehackte Server vom Netz genommen.

Da wir so wie so die Systeme komplett neu machen müssen um nicht einen Server für Datenbank-Backend und Webserver zu nutzen, überlegen wir zur Zeit, wie man den Angriffsversuchen entgehen kann, da sie doch eine beachtliche Last verursachen.

Weil der Apache als Webserver extrem weit verbreitet ist, gibt es für ihn auch die meisten Scripts um eventuelle Lücken für eine Shell auszunutzen.

Wenn man nun von Apache weggehen würde, dann sollte sich die Anzahl der Angriffe auf drastisch Weise verringern (zumindest hoffen wir das).

[Jaraz]

Na ja, wie viele mich angreifen, ist mir ziemlich egal.

Wichtig ist nur das Sie es nicht schaffen.

Deswegen halte ich auch nichts von Versionen usw. zu verstecken.

Wenn der Apache nicht sicher wäre, wär er nicht so verbreitet.

An deiner Stelle würde ich eher php sicherer konfigurieren.

Also:

disable_functions

open_basedir

register_globals

usw. vernünftig konfigurieren!

Gruß Jaraz

[redbrick]

Ich weiß nicht was ich davon halten soll... Jeder rät dazu, weiterhin den Apache zu nutzen. Das will mir einfach nicht in den Kopf, denn laut Benchmarks schneitet der am schlechtesten ab, was die Performance angeht.

Je mehr Vergleiche ich mir ansehe, umso rätselhafter wird mir die Tatsache, das der apache am weitestens verbreitet ist.

Was die PHP-Konfiguration angeht: Die ist nach dem Einbruch in das System gefixt worden. Einige sicherheitsrelevante Einstellungen konnten jedoch wegen des verwendeten CMS nicht aktiviert/deaktiviert werden (und ein Umstieg auf ein anderes CMS steht leider nicht zur Diskussion).

[Wurstwasser]

der apache schneidet am schlechtesten ab?????

zeig mir mal nen benchmark oder sosnt einen vergleich zwischen apache und iss?????in welchem wettkampf schneidet der apache schlechter ab?

[Monty82]

Hier findet man z.B. einen Vergleich...

[redbrick]

der apache schneidet am schlechtesten ab?????

zeig mir mal nen benchmark oder sosnt einen vergleich zwischen apache und iss?????in welchem wettkampf schneidet der apache schlechter ab?

Zeig mir einen wo es nicht der Fall ist apache.org Lasse ich nicht gelten!

[TheyCallMeGeek]

Also zur Verschleierung der Version: Habe mal gelesen, dass man das vor dem kompilieren in den Sourcen ändern muss - setzt natürlicht voraus, dass du den selbst kompilierst - womit debians Aktualisierungen dann natürlich nicht greifen und du das bei jeder Version neu machen musst. Obwohl das sicher irgendwie mit deb-src geht.

[redbrick]

Habe mittlerweile erfahren wie es mit der Verschleierung gehen würde. Da muss man nichts im Sourcecode ändern.

Folgendes in der httpd.conf ändern:

ServerTokens Prod

mod-security laden und dann:

SecServerSignature "_meine_httpd_software"

Für die, die das auch interessiert...

[Jaraz]

Zeig mir einen wo es nicht der Fall ist apache.org Lasse ich nicht gelten!

Nun ja, einen Benchmark von einem anderen Produkthersteller lasse ich allerdings auch nicht gelten. Warum einen 2,4 Xeon nur mit 256MB RAM laufen lassen?

Das Apache nicht so schnell wie kleine spezialisierte Webserver sein kann, ist auch klar.

Baue dir deinen Apache statisch selber mit allem was du brauchst und lasse alle überflüssigen Features weg. Erst dann kann ein Benchmark sinnvoll sein.

Wobei der Aufwand sich bei den meisten nicht lohnt, da Hardware oder nur mehr RAM einfach billiger ist.

Gruß Jaraz

[redbrick]

Da hast du wohl recht... Aber ich denke mal, dass ich mir dennoch die Mühe mal machen muss. Ich kann dann ja meine Benchmark-Daten auch mal publizieren.

BTW: Kennt jemand ein anderes Benchmarktool für Webserver als den Apache Benchmark?

[redbrick]

Also zur Verschleierung der Version: Habe mal gelesen, dass man das vor dem kompilieren in den Sourcen ändern muss - setzt natürlicht voraus, dass du den selbst kompilierst - womit debians Aktualisierungen dann natürlich nicht greifen und du das bei jeder Version neu machen musst. Obwohl das sicher irgendwie mit deb-src geht.

Habe gefunden was du vermutlich meintest: http://www.cgisecurity.com/lib/ryan_barnett_gcux_practical.html#Edit%20httpd.h

So kann man es natürlich auch machen.

[Amstelchen]

über das thema liessen sich glaube ich bücher drüber schreiben

die 4 lösungswege finde ich ja ganz nett, und ich würde nicht wirklich apache nehmen, wenns nicht aufgrund spezifischer erfordernisse (im konkreten fall ein cms mit php?) notwendig wäre.

wenn aber, würde ich mir apache selbst compilen, alle module raus, auch

mod_cache und mod_proxy. also vollständig abmagern (und im zuge dessen auch serversignature raus). das logging nicht über files machen, sondern über den syslogd. urls und request header (in abstimmung mit dem cms-system) begrenzen mit den entsprechenden direktiven.

vor das ganze einen squid und eine firewall, die unter iptables läuft. zum lastausgleich (falls das spruchreif wäre), ein dns round robin einsetzen.

mod_php (muss ja nicht auf apache laufen) soweit konfigurieren, dass enable_track_vars, register_globals, magic_quotes, open_basedir usw. sicher eingestellt sind (siehe auch posting von Jaraz). allenfalls apache nur mit suexec oder suphp laufen lassen (ist insofern eine einschränkung, als dass apache dann php nicht als shared module betreiben kann, sondern nur als cgi, und die performance in den keller geht). die wahl des threadmodells (worker, mpm, whatever) wäre dann auch noch eine überlegung wert und müsste an die spezifischen erfordernisse der hardware angepasst werden. und dann würde ich mit php immer aktuell bleiben.

thttpd würde ich auf jeden fall für statische sachen nehmen, wenn aber, dann auch selbst konfigurieren. bin mir aber nicht sicher, ob das projekt überhaupt noch aktiv ist.

just my 2 eurocents,

s'Amstel

[bsdlamer]

FreeBSD + chrooted Apache ? (jail ?)

[redbrick]

Kein Weg an Debian vorbei. Ein Derivat-Wechsel liegt nicht in meiner Hand Sonst wäre auf den Kisten schon lange FreeBSD

[Schlaubi]

Hallo,

aus aktuellem Anlass, vielleicht für dich ganz interessant:

--- LiteSpeed: Schneller Webserver in Version 2.1 ---

Mit LiteSpeed bietet die gleichnahmige Firma eine Alternative zu den

WebServern Apache und Zeus an. LiteSpeed soll bis zu sechsmal

schneller sein als Apache und dabei eine vergleichbare Flexibilität

bieten. In der neuen Version verarbeitet die Software Apaches

Konfigurationsdateien direkt.

http://www.golem.de/0509/40585.html

[redbrick]

...da der Webserver, so wie Zeus auch, Kostenpflichtig ist, kommt der leider nicht in Frage. Obwohl er durchaus interessant ist!

Chris

[Lt.Storm]

Ich möchte auch noch mal kurz meinen Senf dazu abgebgen. Ich denke das groesste Gefahrenpotenzial dein CMS bietet. In der Vergangenheit gabs ja mehr als genug Angriff auf diverse CMS. Dein Ansatz mit modproxy ist gut. Einfach einen Rechner mit modproxy oder squid einen reverse proxy auf deinen "internen" Webserver machen. Vielleicht noch snort und nen schönen iptable auf die Büchse mit dem reverse proxy packen. Zum Thema "ServerSignature", die sollte immer auf off stehen, da der Angreifer sofort Anhand er Versionsnummer die passenden Angriffe fahren kann.

Hast du evtl. mal geguckt aus welchen Ländern diese nervigen Scrptkiddies die Angriffe fahren? Manchmal hilft es auch, gewisse Subnetze, passend zu den Ländern zu sperren...