Dotaz: Neco prebere port od Apache

[RadekXxX]

Zdravim,
mel bych jeden dotaz. Na debianu me bezi Apache, vzdy tak po 2 dnech prestava byt dostupny, kdyz provedu jeho restart, tak hlasi, ze port 80 se jiz vyuziva, ale nevim jakou aplikaci, kdyz se podivam do vypisu bezicich aplikaci, tak tam nic nenajdu. Da se nejak zjistit jaka aplikace otevrela server socket ? Jedina naprava zatim je pouze restart serveru a nejakou dobu to zase bezi. Zajimave je, ze pres telnet se da na port 80 pripojit.

Dik za kazdou radu

Odpovědi

[xxx]

netstat -at

[RadekXxX]

Aha, tak problem bude asi nekde jinde, ve vypisu jsem nasel pouze:

tcp6 0 0 *:www *:* LISTEN

kazdopadne to vypada na IPV6, ale nevim jaky program to ma otevrene

[dobrak]

Mel jsem stejny problem. Vyresil jsem to tak, ze jsem "zabil" apache beziciho na tcp6 a pak jsem dal jen restart :)

[dobrak]

Jeste pro upresneni

pouze priklad:

netstat -plnt
ps 3595
kill 3595
/etc/init.d/apache2 restart

[Ash]

netstat -natp, myslím že může být port označen jako používaný ještě chvíli po ukončení aplikace, dá se k němu v aplikaci připojit s nějakým reuse flagem, už si nepamatuji detaily, ale u apache bych podobný problém nečekal.

[RadekXxX]

Na portu 80 je pouze toto:

tcp6 0 0 :::80 :::* LISTEN 27633/httpd

mail:/# ps ax | grep http
27633 ? R 10872:58 /usr/sbin/httpd
24452 ? S 0:00 /usr/sbin/httpd

Podle tohoto vypisu bezi program HTTPD, ale v /usr/bin zadny takovy program neni

[Filip Jirsák]

Je to /usr/sbin/httpd, což je pravděpodobně Apache.

[RadekXxX]

Tento proces nelze ukoncit, a soubor /usr/sbin/httpd ani neexistuje

[Ash]

Hledáte ho pod rootem?

[RadekXxX]

Ano

[rastos]

Čo tak zobrať z výstupu netstat -ltp PID a urobiť cp /proc/PID/exe /tmp/foo. Potom môžeš skusiť pozrieť do /tmp/foo. Prehnať to cez strings, podhodiť to nejakému antivíru (človek nikdy nevie), atď. atď.

Je pravdou, že dobrý útočník, ktorý dostane root-a dokáže efektívne zahladiť stopy. Ale ak mám súdiť podľa toho čo stretávam vo Windows, tak sa s tým dnes už nikto nepára. Takže by som a priori nezahadzoval možnosť nejaké stopy na systéme nájsť. Treba si stanoviť priority. Či ide o to dostať systém do prevádzky - vtedy to treba restornúť z dobrého backup-u, resp. nainštalovať znova a nahrať užívateľské dáta z backupu, alebo ide o to dopátrať sa čo sa stalo - s tým sa dá stráviť veľa času, podľa toho, ako hlboko chceš ísť.

[David Karban]

Zdravím,

tohle se stává při napadení serveru. Útočník spustí pomocí php skript, který se maskuje např.jako httpd (v Debianu je apache zván apache2, httpd binárka tam není).

Skript se nejmenuje httpd, ale třeba w, nebo jakkoliv jinak, doporučuju se podívat do /tmp a dalších oblastí, kde má webserver právo zápisu a pohledat neobvyklé skripty.

A určitě by bodlo projít si kód aplikace co tam běží a pokud je to nějaký balík tak updatovat na nejnovější verzi ;).

[RadekXxX]

Bohuzel to vypada, ze jste mel pravdu. v /etc jsem nasel nejakou binarku slouzici k vymazu logu (takze ani z logu nic nevyctu) a vytvoreneho uzivatele "Raoul". Zadny jiny script nebo neco jineho jsem nenasel. Da se nejak zjistit co spustilo proces httpd a kde se nachazi ten soubor ?

[PanZvedavy]

Server reinstalovat, pokud dokazal utocnik vytvorit systemovy ucet, tak je uz pozde. Reinstal, nahodit posledni verze sw, a predevsim chroot apache. S chrootlym apachem by nemohl udelat to co ted.

[David Karban]

Ono záleží i kdy se útočník dostal na roota, pokud rovnou skrze apache tak ani chroot by nepomohl.

Ale to už je v tomto případě jedno, jestliže byl někdo schopný vytvořit uživatele, pak jedině čistá instalace ...

[Jendа]

Ale to už je v tomto případě jedno, jestliže byl někdo schopný vytvořit uživatele, pak jedině čistá instalace ...

A ještě by to chtělo najít chybu, aby za chvíli neskončil stejně. Podle mě to totiž nebude děravou PHP aplikací, protože PHP snad nikdo nespouští pod rootem, takže i kdyby stokrát chtělo, tak prostě uživatele nevyrobí. Takže bych tazateli doporučil dávat si velký pozor na služby běžící pod rootem, aby byly bezpečně nastavené, a případně bych měl podezření na kompromitaci hesla nebo SSH klíče.

[RadekXxX]

Jedna se pouze o mail server kde jsou povoleny pouze emailove porty a web s aplikaci roundcubewebmail, navic SSH je povoleno pouze z jedne venkovni IP adresy. Ale co me nedoslo, tak byl nejspis povolny cely IPv6, protoze v auth.log jsem nasel nejake zaznamy na pokusy prihlaseni roota z IPv6. Nevim jakym zpusobem se IPv6 nastavuje a blokuje v iptables, nikdy jsem toto neresil, vychazel jsem z toho, ze kdyz sitovka ma nastavenou pouze IPv4, tak neni treba nic resit.

[aceman]

Najlepsie vyhodit moduly pre ipv6 z jadra.

[Jendа]

I tak… Pokud někdo dokáže zaútočit na SSH, řešil bych především, proč se mu to podaří, než jak mu v tom zabránit… Nicméně podle mě to v SSH nebude, v jeho konfiguraci toho není zas tak moc co pokazit - leda tak mít heslo 123456.

[aceman]

Pokial by to slo cez SSH, mal by vidiet v logoch kto a kedy sa tam prihlasuje, nie? Takisto, ci niekto vyuziva to nove vytvorene konto. Ano, napisal, ze mu podstrcena binarka maze logy, takze by tam nic nenasiel. Ale mohol by si napr. logy posielat na dalsi syslog server odkial by mu ich nevymazalo.

[Jendа]

Pokial by to slo cez SSH, mal by vidiet v logoch kto a kedy sa tam prihlasuje, nie?

Ne. Pokud měl roota, tak mohl log upravit nebo smazat. Tedy za předpokladu, že neloguješ na vzdálený stroj.

[aceman]

Presne to jsem ale napsal:)

[David Karban]

Jak je zabezpečeno php na tom stroji ?

Jsou vypnuty funkce exec., system, passthru a podobně ?

Jaká verze roundcube a odkud (z repositáře, stáhnutá, ...) ?

Je nastaven safe mód ? Open_basedir ?

[David Karban]

Nope, php neběhá většinou pod rootem, ale na neupdatovaném systému je to celkem jedno, pokud můžete uploadovat soubor, který pak spustíte (což se teď stalo) a máte třeba zranitelné jádro ... pak je jedno pod kterým uživatelem to běželo původně.