utok na apache

[Tomáš Koželuh]

Já bych řekl, že celý problém leží někde jinde. Už na začátku toho článku je
popsáno, jak se útočník do toho Apache dostane - přes hesla v Total
Commanderu a FTP. 
Další věc, které jsem si tam všiml, že kontroluje, jestli může zapisovat do
adresáře, IMHO velice jednoduchá oprava je zakázat Apachi zápis do
index.php, případně do celého kořenového adresáře nebo do všech php souborů.
Ještě mě napadá jeden způsob obrany, když poběží Apache v chroot, neměl by
se být schopen shodit.

> -----Original Message-----
> From: linux-bounces na linux.cz [mailto:linux-bounces na linux.cz] On Behalf
> Of Petr Stehlik
> Sent: Sunday, September 20, 2009 10:26 AM
> 
> nectu zadny specializovany web/mailling list o bezpecnosti, takze mi
> mozna unika neco, co uz vsichni ostatni vite, ale chtel jsem se tu
> zeptat na toto: existuje utok, ktery dokaze za behu apache ho nejak
> nahradit tak, ze potom na portu 80 nasloucha a odpovida ten utocny kod.
> Je zrejme spusteny jednoduse pomoci php exec(). Podrobnejsi popis jsem
> po vydatnem googleni dobe nasel tady:
> 
> http://www.uptime.cz/100452-site-a-internet_Linux-Apache-Attack.html
> 
> "Vtipne" je, ze to neprezije restart apache, takze jsem na to dlouho
> nemohl prijit, protoze v 6:25 rotujou logy a po nich se apache tak
> trochu restartne, takze behem dne je vsechno v poradku. Az v noci to
> zacne nanovo...
> 
> Mate me na tom par veci: jednak, jestli jsou k takovemu nahrazeni
> apache
> za behu potreba prava roota (tzn., ze server byl kompletne
> kompromitovan
> a muzu ho zahodit), anebo jestli je to nejaka chyba v apache a jde to
> zaridit i s pouhymi pravy uzivatele, pod kterym bezi apache.
> 
> Dalsi vec je, ze se o tom nikde nepise. Mel jsem problemy vubec
> vygooglovat o co jde, a ackoliv je to stare uz nekolik mesicu
> (minimalne
> od cervna), tak na to nejsou zadne opravy? Vypada to, ze se to nejak
> tyka jen apache2, protoze dokud jsem mel apache1, byl jsem v klidu.
> Je-li to chyba v apache, proc se nemluvi o oprave?
> 
> Pokud je to chyba konfigurace ci zabezpeceni serveru, nepodelil by se
> nekdo o napad, jak tomu utoku zabranit? Zatim jedine, co jsem se
> docetl,
> bylo zakazat PHP exec(), ale to je zda se celkem pouzivana funkce.
> Druhym napadem bylo spoustet PHP skripty pod jinym uzivatelem nez
> apache, ale to byla asi spis obecna rada nez konkretni k tomuto utoku.
> Pokud nekdo neco vite, reknete mi nebo poslete pointer ke zdroji
> informaci.