[Megoldva, nincs baj] Gyanús furcsaságok Fedorán

Red Hat, Fedora, CentOS

Sima, otthoni használatú desktop gép. Dinamikus IP-címen van, nincs hozzá domain név, dyndns és effélék sem. Fut rajta egy httpd, de weblap nincs hozzá, csak néhány file. Egyszerűbb, ha ismerősnek mutatnék valamit, mint e-mailben küldeni.

Az alábbi levelem jött az rkhunter-től:

Warning: Package manager verification has failed:
         File: /usr/bin/top
         Try running the command 'prelink /usr/bin/top' to resolve dependency errors.
         The file hash value has changed
         The file size has changed
Warning: Package manager verification has failed:
         File: /usr/bin/watch
         Try running the command 'prelink /usr/bin/watch' to resolve dependency errors.
         The file hash value has changed
         The file size has changed

Mind a top, mind pedig a watch a procps-ng-3.3.3-2.20120807git.fc18.x86_64 csomagban található. Letöltöttem a csomagot, s valóban van eltérés. Nálam a top 79056 byte hosszú, míg az eredeti 73672 byte. Hasonlóképpen nálam a watch 26408 byte, míg a csomagban található 20648 byte.

Az első dolgom az elsápadást követően ez volt:

yum reinstall procps-ng

Logokban eddig nem találtam szokatlant, de nem is néztem át még elég alaposan.

Mi történhetett? Mit érdemes megvizsgálnom? Mit volna jó cselekednem?

  • 4738 megtekintés

( Dacr (nem ellenőrzött) | 2013. 02. 02., szo – 08:18 )

Nincs kizárva, hogy megpatkolták.
Az adott binárist érdemes lehet megvizsgálni egy elszeparált virtuális gépen, de első körben én lehúznám a hálókébelt. Egy reinstall sem fog ártani.
A jövőben meg email, vagy csak akkor nyitni a httpd-t, mikor éppen kell.

( log69 | 2013. 02. 02., szo – 08:22 )

SELinux be van kapcsolva? httpd-hez milyen SELinux flag-ek engedélyezettek?

Mi volt a 2 fájl módosítási dátuma? Mi lenne ha a módosított binárisok hash-ére rákeresnél a neten? Virustotálra feltöltve dobnak valamit a vírusírtók?

SELinux természetesen engedélyezve van, lényegében a default beállítások vonatkoznak a httpd-re. Helyesebben van valahol a /var-on viszonylag mélyen egy alkönyvtár, amelybe megengedtem, hogy írjon a httpd, mert egy php-ban írt webes alkalmazást gányoltam, annak kell. Viszont ez a webes alkalmazás csak localhost-ról érhető el.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

És valóban, valószínűleg a prelink módosította a binárisokat.

Szerk.: leteszteltem. Fordítottam egy C-s progiból binárist. Lemásoltam. A másolatra futtattam root-ként egy "prelink prog" parancsot. Ekkor ugye megváltoztatta a binársit. Majd "prelink --undo prog" visszaadta az eredetit.

Javaslom, hogy backup-ok készítése után, futtass a szóban forgó két binárisra "prlink --undo" parancsot, és nézd meg hogy az egyezni fog-e a csomagban lévővel.

A prelink lesz az, köszönöm mindkettőtöknek az értékes hozzászólást. Kezdek megnyugodni már. Egyébként Fedora 18 tiszta telepítése történt két hete, egyedül a /home alatt tartottam meg a felhasználói profilokat.

Az igaz, hogy a prelink futtatását ajánlotta, ugyanakkor nem tudtam, hogy a binárisokat módosíthatja. Éppen ezért úgy voltam vele, nem akarom elfedni a hibát, hanem szeretném tudni, mitől változtak egyes bináris állományok. Hibaelfedésre azt is tehetném, hogy megmondom az rkhunternek, hogy az új bináris a helyes, de akkor kár egyáltalán futtatni az rkhuntert.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( uid_4656 v | 2013. 02. 02., szo – 09:40 )

Otthoni desktop gép? Ne gondolkozz, húzd újra, kész...

( locsemege v | 2013. 02. 02., szo – 12:04 )

Mindig tanul az ember:

prelink is a program that modifies ELF shared libraries and ELF dynami‐
cally linked binaries in such a way that the time needed for the
dynamic linker to perform relocations at startup significantly
decreases. Due to fewer relocations, the run-time memory consumption
decreases as well (especially the number of unshareable pages). The
prelinking information is only used at startup time if none of the
dependent libraries have changed since prelinking; otherwise programs
are relocated normally.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A Wikipedia-s bejegyzés beszédeseb és tanulságosabb ezzel kapcsolatban (nekem is mond új dolgokat):
http://en.wikipedia.org/wiki/Prelink

Viszont akkor felmerül a kérdés, hogy hogyan tudunk ennek tudatában rendszer integritást ellenőrizni? Mert a Wiki alapján, ha pl. frissül egy lib, amelytől függ egy adott bináris, akkor változni fog a bináris is a lib frissülésével, mert a prelink le fog futni mindkettőre, és újra relokálja a lib-et, így a lib új virtuális címét a binárisban is frissíti.

Mondjuk ennek az egész prelink-nek kicsit gány és hack szaga van számomra. Nekem az lenne a tuti, ha a telepített binárisokhoz semmi másik utility nem nyúlna hozzá egy újjal sem.

Az rkhunter esetében meg a "bal kéz nem tudja mit csinál a jobb" a helyzet. Persze a biztonsági szoftverek legyenek is teljesen függetlenek az ellenőrizendő rendszertől, de ez is probléma marad.

A kérdés viszont adott.

Egy érdekesebb bejegyzés ezzel kapcsolatban az Avira-tól:
http://www.avira.com/en/support-for-home-knowledgebase-detail/kbid/616

Szerk: Még egy:
https://bugzilla.redhat.com/show_bug.cgi?id=504949

vagyis:

"Why can't the checksum verification code take the prelinking into account (like rpm -V does)?"

Tehát itt a válasz. Az rpm-mel való integritás ellenőrzésnél figyelembe veszi a parancs a prelink-et, és undo-t csinál a check előtt. Vagyis RTFM ismételten, és integritás ellenőrzést először is csináljunk a beépített megoldással, vagyis: 

rpm -V packagename

Jó, hogy RTFM, de éjszaka megijedtem, gondoltam, kérdezek. Jobb több helyről értesülni, hogy nincs baj.

Ami még nem teljesen tiszta, hogy az rkhunter miért nyafogott. Gondolom, megcsinálja az undo-t ő maga is, de akkor ezen két file esetében mi történt? Úgy emlékszem, nem állítottam le a gépet a prelink futása közben, persze akár tévedhetek is ebben.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE