apache hack, wat kan ik er aan doen?

[sparks]

Hoi,

merk laatste tijd dat er zaken op mijn suse10 systeem neergezet worden via apache. Die files worden vervolgens opgestart. Dit zie ik in mijn log:

--09:14:33-- http://209.200.224.166/iron
=> `iron'
Connecting to 209.200.224.166:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 400,972 (392K) [text/plain]

0K .......... .......... .......... .......... .......... 12% 48.75 KB/s
50K .......... .......... .......... .......... .......... 25% 123.83 KB/s
100K .......... .......... .......... .......... .......... 38% 231.62 KB/s
150K .......... .......... .......... .......... .......... 51% 254.62 KB/s
200K .......... .......... .......... .......... .......... 63% 272.20 KB/s
250K .......... .......... .......... .......... .......... 76% 941.85 KB/s
300K .......... .......... .......... .......... .......... 89% 279.23 KB/s
350K .......... .......... .......... .......... . 100% 919.99 KB/s

09:14:36 (170.05 KB/s) - `iron' saved [400972/400972]


Je zit vervolgens iron draaien onder account van apache. De files worden in /tmp of /var/tmp gezet, mijn systeem hacken lukt dus niet echt maar wel gebruiken ze cpu en netwerk verbinding. Nu heb ik wel wat gevonden dat ik via htaccess zaken kan blokken echter vraag me af hoe goed die oplossing is. Morgen gebruiken ze een ander ip adres en dan?

Oh ja: ik gebruik 2.0.54, dacht dat redelijk up to date is.

Bij voorbaat voor tips/hints,
Sparks

[ Voor 3% gewijzigd door sparks op 16-03-2006 18:06 ]

[Gerco]

Mount /tmp als nosuid,noexec,nodev. Dan kan het iig geen programmas meer opstarten uit /tmp. Verder heeft apache helemaal geen rechten nodig in /var/tmp, weghalen dus.

Verder kun je ook /dev/shm op nosuid,noexec,nodev zetten en natuurlijk de execute rechten van apache weghalen op de wget binary.

Dan ben je redelijk veilig voor deze hacks. "Echt veilig" wordt je natuurlijk pas als je iets als grsecurity gebruikt en zorgt dat de user apache gewoon helemaal niets anders kan opstaren dan apache.

[sparks]

ok, met beveiligen van /tmp en /var/tmp kan ik wat.
Dat laatste zou ik natuurlijk kunnen bereiken door apache middels chroot te draaien.

Bedankt,
Sparks

[serkoon]

Bedenk wel dat PHP-sessiebestanden in /tmp worden neergegooid, tenzij je PHP anders configureert. Bedenk ook dat non-exec mounten van een filesystem niet wil zeggen dat er niks meer vanaf uitgevoerd kan worden. Geinterpreteerde bestanden, zoals perlscripts, kunnen nog steeds prima worden uitgevoerd vanaf een non-exec gemount filesystem.

Hardening van PHP scheelt een stuk, beter is geen gare software (lees: PHPBB, oude versies Mambo, dat soort dingen) te draaien. PHP-hardening is vooral met safe mode te realiseren. Helaas kunnen veel scripts er niet tegen, dus het is een beetje een non-oplossing. Op een hosting-platform kun je eventuele nog SuPHP gebruiken, zodat PHP-scripts uitgevoerd worden met uid/gid van de eigenaar van het script.

[Spider.007]

Aanvullend op serkoon hierboven; begin met het zoeken van de oorzaak van het probleem. Apache is dat niet (zo te zien); het zijn brakke scripts die Apache deze zaken laten doen; probeer er dus inderdaad achter te komen waar dit nou precies door veroorzaakt wordt