On 28 Nov 2013, at 15:45, Stanislav Petr &lt;glux(a)glux.org&gt; wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Tohle je dost zavisly odpouzite distribuce. Pokud pouziju napriklad CentOS/Scientific Linux/RHEL a necham automaticky aktualizace jen ze zakladnich repozitaru, muzu bejt celkem v klidu a verit ze se nic nerobije. Na hruhou stranu u distribuci jako Gentoo, Arch a podobnejch jsou automaticky aktualizace naprosta silenost. - -- Stanislav Petr > On 28/11/13 15:22, Robin Obůrka wrote: > Ahoj, já si jen dovolím jednu malou poznámku. > > Mám takový pocit, že se poměrně důrazně nedoporučuje dělat > automatické aktualizace. Že vždycky by se měl člověk pečlivě koukat > jestli se něco nerozbilo, jestli není před aktualizací potřeba > nějaký další úkon apod. > > Jednoduše řečeno, myslím, že nechat dělat automatické aktualizace > není úplně dobrý zvyk a že bychom asi neměli masivně podporovat > špatné zvyky. Jestli by nebylo lepší sepsat nějaký návod, "jak se > nechovat nebezpečně" a k aktualizacím se postavit několika radami. > > 1) pravidelně je kontrolovat 2) pokud jsem moc líný, tak něco "jsou > nějaké dostupné?" nechat cronem posilat na email jednou za.. .den, > 2, 3? 3) pokud jsem moc líný i na tohle, tak se aspoň zregistrovat > do security mailing listu příslušné distribuce. > > Moje interakce se serverem je poměrně dost častá, takže nemám > problém aktualizace zjišťovat často, navíc jsem zaregistrovaný v > mailing listu, takže jakákoliv kritická aktualizace je u mě > nasazena v řádu minut až hodin. Nemám pocit, že by mě to stálo > nějaký čas, ale chápu, že spousta lidí chce ať to funguje a nemusím > o tom vědět - ale... asi bych na to opravdu nešel automatickými > aktualizacemi, člověk pak neví co se na serveru vlastně děje a to > může časem vyvrcholit v ještě větší bezpečnostní problém. > > Pokud jde o debian a moji zkušenost s apt, tak některé aktualizace > se nedají provést přes upgrade, ale je potřeba dist-upgrade. A ten > doinstalovává nově vzniklé neodsouhlasené závislosti, které se > tímto v podstatě odsouhlasí. Takže buď časem nutně některé > aktualizace uváznou při čekání na dist-upgrade, nebo automaticky > nechám tahat nové závislosti a netuším co nového - co by případně > vyžadovalo administrátorský zásah, aby bylo bezpečné - se mi na > serveru zjevilo. A ano, šance, že se něco takového nebezpečného > objeví je asi velmi malá, ale není to zase sci-fi, dle mého > názoru. > > Já jen jestli by tohle nestálo za úvahu. > > R. O. > > Dne 28.11.2013 10:01, Pavel Snajdr napsal(a): >> No, aby me zas nekdo nebral doslovne - ty technologie, co pise >> Standa i jini, maji svoje misto, ale moje pointa je, ze diskuze o >> nich nema valnejsiho vyznamu, dokud vsichni nebudou splnovat >> aspon ta minima :) >> >> Kdo mate na VPS automaticke aktualizace? >> >> Najde se nekdo, kdo je ochotnu to zpracovat na nasi Knowledge >> Base? Nabizim mesic clenstvi gratis, pripadne nejake misto na >> NASu :) >> >> S pozdravem, >> >> Pavel Snajdr >> >> Odeslano z mobilniho zarizeni. >> >> On 28 Nov 2013, at 09:39, Pavel Snajdr &lt;snajpa(a)snajpa.net >> <mailto:snajpa@snajpa.net>> wrote: >> >>> Ahoj, >>> >>> 3x ne :) >>> >>> Ale je mi trochu smutno z toho, ze vsichni resite "blbosti". Ja >>> chapu, ze tyhle technologie maji svoje misto, ale ty hacky, co >>> se nam deji, jsou zpusobene banalitami a vubec je to cela >>> diskuse na mnohem primitivnejsi urovni - aktualizujte. >>> >>> Pokud vim, jeste jsme nemeli prunik zadnou 0day zranitelnosti, >>> vsechno jsou to trapnosti typu par mesicu neaktualizovany >>> system, slabe heslo ci propujceny pristup takovym "co s tim >>> linuxem, teda jako taky umi". >>> >>> Trochu jsem rozladenej z toho, ze existuji v podstate 2 skupiny >>> lidi - ti co neresi bezpecnost vubec a pak ti, kteri to radi >>> prehaneji a pridelavaji si praci zbytecnou paranoiou :) Pritom >>> fakt naprostou vetsinu problemu by vyresil pristup k veci nekde >>> mezi tim - dodrzovat zakladni pravidla jako nepoustet, co >>> nepotrebuju, aktualizovat, jak casto to jde, nerozdavat pristup >>> k tem strojum nikomu, kdo nedodrzuje stejna pravidla a pouzivat >>> silna hesla (hlavne dlouha, kratka random hesla jsou blbost). >>> Dal bych jmenoval jeste nepoustet pod rootem co vylozene >>> nemusim (hlavne vsemozne weby, to pustit pod rootem = >>> sebevrazda). >>> >>> Zkus mi to prosim nemit za zle, ale docela si dovolim zastavat >>> nazor, ze v situacich, kde opravdu realne vyzadujes veci jako >>> SELinux, si stejne nemuzes dovolit byt na sdilenem hardwaru s >>> nekym dalsim, protoze si nemuzes dovolit, aby ti nekdo videl do >>> pameti - a ze to fakt neni slozity, teda obzvlast pokud tam mas >>> tak bezny system, jako je RHEL/debian... Vysvetlit tomu >>> systemu, ze ma spustit novy shell a podobne ve spravnem selinux >>> kontextu pro tak motivovaneho jedince, ktery bude mit zajem se >>> tam prolamat, nebude asi az tak problem. A ze zranitelnosti, >>> jak se vylamat i z KVM uz bylo docela dost, nemuzu to najit, >>> ale nekde jsem videl video, jak se z kvm diky zranitelnosti ve >>> virtio vylamali na hypervisora pingem(!). >>> >>> Teda, abychom byli na stejne strance spolu - absence SELinuxu >>> vadi i mne, akorat ne kvuli zabezpeceni proti hrozbam z venku, >>> ale proti lepsi izolaci procesu v ramci jednoho systemu. Az >>> bude chvili cas, pokusim se vyuzit nas Parallels OpenVZ >>> maintenance partnership prave na to, aby se kouknuli po >>> implementaci SELinuxu. >>> >>> S pozdravem, >>> >>> Pavel Snajdr >>> >>> Odeslano z mobilniho zarizeni. >>> >>> On 27 Nov 2013, at 20:57, Stanislav Petr &lt;glux(a)glux.org >>> <mailto:glux@glux.org>> wrote: >> Kdyz uz jsme u ty bezpecnosti, tak mam par dotazu: >> >> 1. Podpora SElinuxu jeste porad v OpenVZ neni? Nebo na tom nekdo >> pracuje? Spouste utokum (zejmena 0day exploity) to dokaze velice >> efektivne zabranit. Pripadne jinej bezpecnostni modul (AppArmor, >> TOMOYO)? >> >> 2. Co se tyka firewallu, slo by doplnit moduly iplimit, u32, >> mport, pkttype, psd (mozna i ||ipv4options)? Dost uzivatelum by >> to asi pomohlo. >> >> 3. Muze uvnitr OpenVZ guestu jadro vyuzivat tc? Jak se ve >> vyslednym provozu projevi qos nastaveny uvnitr konternerove >> virtualizace? >> >> >> Chapu vyhody OpenVZ v maximani efektivite vyuziti systemovych >> prostredku serveru, ale pokud se jedna o bezpecnost, tak tam mi >> prijde ze obcas OpenVZ hazi klacky pod nohy... >> >>>> >>>> >>>> >>>>

<http://www.avast.com/> _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list