-----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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iF4EAREIAAYFAlMk+q0ACgkQMBKdi9lkZ6ocDQD+OaD9fKQdlw1cyBtQDDNXeklO
iTvNECchKfqGl0v8Fe0A/0M3SITTaNnPd9aEEG43lQViiVFkxWKC5t4p6VR/NDl8
=Vu/V
-----END PGP SIGNATURE-----