-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 03/16/2014 01:54 AM, Ondrej Mikle wrote:
Diky za podrobnou odpoved, jsem se z toho dost naucil.
On 03/15/2014 11:20 PM, Pavel Snajdr wrote:
On 03/15/2014 10:52 PM, Ondrej Mikle wrote:
ma OpenVZ vlastnost, ze napriklad pri premigrovani kontejneru nebo nejake jine zmene se taky zmeni inode numbers souboru na filesystemu?
A jeste jsem ti neodpovedel uplne, tvoji VPS jsem prave migroval nedavno z ext node na ZFS node, to zpusobilo tu zmenu inodu. Dal tedka jakakoliv obnova ze zalohy, dalsi migrace atd. bude menit cisla inodu.
OK.
Ale jakmile budeme ZFS only, povolime send/recv funkcionalitu a pak by mel ten filesystem VPS vypadat porad konzistentne v case, at je uz se na ten cilovej node dostal migraci nebo obnovenim ze zalohy.
Osobne mi prijde ZFS jako velmi dobry filesystem, mozna to kapku prehnali s pouzitim SHA256 na "error-detection/integrity protection" (postacila by jednodussi funkce). Ale jsem rad, ze ZFS driver pro linux je uz pouzitelny :-)
Z manu ZFS:
- --- checksum=on | off | fletcher2,| fletcher4 | sha256
Controls the checksum used to verify data integrity. The default value is on, which automatically selects an appropriate algorithm (currently, fletcher4, but this may change in future releases). The value off disables integrity checking on user data. Disabling checksums is NOT a recommended practice. Changing this property affects only newly-written data. - ---
Tzn. da se to nastavit per dataset (FS/ZVOL), default je fletcher4, kterej je paradne rychlej. Ale hodi se jenom na checksumy, protoze je hodne nachylnej na (a opravdu pravidelne generuje) kolize.
Tzn. fletcher4 by se nedal pouzit v deduplikacnich tabulkach ZFS, ale ty jsou separatni, takze tam neni problem pouzivat jinej algoritmus, tam se prave pouziva ta sha256.
Ale deduplikace je blbost, zere to pamet, je to pomaly a realne to zadny vyznamny misto pro vetsinu usecases neusetri. Misto toho je lepsi pouzivat kompresi, my se bezne pohybujeme minimalne u 1.3 kompresniho pomeru, to ti zadna deduplikace neda :)
Ptam se proto, ze rkhunter to "spatne nese" a reportuje to. Pri porovnani SHA256 checksumu s cistym systemem i s rpm --verify checksumy sedi. Souboru se zmenenym inode je velka spousta, tim padem z predchoziho vyplyva, ze jde o spis false alarm.
Jop, a to neni jedina aplikace, kterou to afektuje, i trivialnejsi programy se ridi cislem inodu (tusim i treba git tak detekuje mv souboru).
Tady jen drobna poznamka pro lidi, co treba taky rkhunter pouzivaji
- rkhunter je "prvni linie obrany" proti backdoorum, ale mam cim
dal vic pocit, ze uz hodne outdated v principech, ktere pouziva.
Ja se prave divim, ze vubec rkhunter pouzivas, ja mel za to, ze uz to dal nikdo nevyviji, vzdycky mi to prislo jako takovej polomrtvej projekt - nebo se mylim?
/snajpa
Doporucuji napriklad analyzu Ebury backdooru: http://www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/
Nad tim kodem se nekdo zamyslel a stravil na tom pravdepodobne nezanedbatelny cas. Krome featur jako pouzivani obskurnich gcc atributu "__attribute__((constructor))" to sleduje, jestli je sitovka v promiskuitnim rezimu (a pak nic neposila) a zaroven exfiltruje hesla pres DNS (kdo filtruje DNS?).
Tady treba rkhunter nezabere, protoze to exploituje vlastnosti dynamickeho linkeru. Patchuje to instrukce v binarce a ma dokonce vlastni SIGSEGV handler, coz se moc casto nevidi.
Ondro
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list