pptpd bindol httpd helyére, wtf?

Linux-haladó

Hétvégén volt egy probléma, ami kétszer is előjött, de nem tudok rá megoldást. Egy sima CentOS 5.8 x86_64 rajta httpd-vel (default repóból), és pptp-vel 1.7.2-8.el5.

Van egy scriptünk, ami ha a httpd logban segfaultot lát, akkor újraindítja a httpd service-t. Ennek több oka is van, de nem itt lesz a gond mert ez évek óta megy rendesen. A gépen lévő pptp-t kliensként használjuk egy W2K3 szerverhez csatlakozik MPPE titkosítással.

Egy olyan meglehetősen furcsa helyzet állt elő, hogy jött egy httpd segfault, újraindította volna a script a processt, leállítani még le tudta, de újraindítani már nem, mert azt a hibát kapta, hogy már figyel valami a 80-as porton. 


sirius ~ # lsof -i:80
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pppd   22809 root 3u IPv4 2238516 0t0 TCP *:http (LISTEN)
pptpgw 22810 root 3u IPv4 2238516 0t0 TCP *:http (LISTEN)
pptpcm 22817 root 3u IPv4 2238516 0t0 TCP *:http (LISTEN)

lsof-fal kiderült, hogy bizony a pppd és másik két társa (pptpgw, pptpcm) ültek fel a 80/tcp-re. Mivel én nem voltam gépközelben, a kollegám annyit tudott tenni, hogy kilőtte azokat a PID-eket, amiket az lsof visszaadott, és utána már simán elindult a httpd.

Aztán eltelt 2-3 óra, és újra lejátszódott ez az esemény. Most kikapcsoltuk a pptp vpn-t, így nincs gond sem. Mindenesetre az is furcsa, hogy hónapok óta ment minden gond nélkül a pptp és a httpd eggyütt. És ami még fontos: a gépen pptp-server _nincs_, csak a kliens.

Találkozott már valaki hasonlóval? Neten rákeresve semmi érdemleges.

( andrej_ v | 2012. 07. 02., h – 14:38 )

Miután kellőképpen elzártátok a gépet a külvilágtól nézzétek meg, hogy az a 80-as porton futó pppd mit válaszol ha böngészóből ránézel a gép IP-jére. A másik, hogy px xuaw -vel is nézzétek meg, hátha kiderül valami a pathból.

( junior013 | 2012. 07. 02., h – 15:39 )

Amire andrej_ is próbált finoman utalni: sanszos, hogy ez a pptp nem a te pptp kliensed, hanem valami nemkívánatos idegen script, ami egy backdoor-t nyit a gépen. (és az sem lehetetlen, hogy ez küldi segfault-ra a httpd-t pont azzal, hogy "kivágja alóla" a portot)
Sajnos találkoztam már ilyennel - igaz, az enyém konkrétan httpd-nek hazudta magát.

Köszi szépen, szinte biztos, hogy ez van nálunk is. Itt is egy httpd process (egész pontosan abban futó mod_php) indítja el a pon/poff párost, és akkor valami fd kavarodás miatt ezek helyet cserélnek.

Nálunk akkor az lesz a megoldás, hogy nem az apache indítja el a pon/poff-t, hanem csak beír egy semafor fájlba, és egy percenként lefutó cron teljesen más userrel, httpd-t kihagyva építi fel vagy bontja le a VPN kapcsolatot.