Vlákno názorů k článku
Linuxové jádro 3.18 padá, problém se možná týká i 3.17 od Dominic Havilah - Tady je vidět, jak je linuxové jádro špatně...

Fuha, myslim, ze tam bezala nejaka webka, firemna aplikacia, ale to tretie co tam bolo si nepamatam.

Já zase znám pár servletů pro Tomcat, které dovedou sežrat veškeré zdroje - na Windows, Linuxu i kdekoliv jinde. Asi to na Linuxu nebude až tak zřídkavý úkaz :)

Tak. Widle potřebují restart jak koza drbání a Lael trolování.

To ve Windows samozřejmě většinou také. Nicméně kolegovi se nechtěl zastavovat servis, a odstřelit procesy (což udělá i ten restart) ručně nebo skriptem je asi moc práce.

Už to umí? Paráda, časem z toho možná bude i použitelný systém :-) Ještě Server 2003 R2 měl s úklidem po sestřelených aplikacích dost zásadní problémy, novější jsem naštěstí už nemusel používat.

To je vlastně pravda. Vy jste se omezil na výlevy o tom jak je IIS na nic, protože ta aplikace má problém :D

Ad 2k12 se uz prosychr nerestartujou ani cisty - ty vaše možná ne, ostatním lidem bootují bez problému. Schopný admin si zapne boot log aby zjistil co je špatně, neschopný plácá nesmysly v diskusi.

Dozvíte se tam ve které fázi bootu to ztuhlo. Příčinou nejspíš bude poslední natahovaný modul, typicky driver.

Pokud vám blbne ovladač řadiče, možná se vyplatí zkontrolovat, jestli nemá novější verzi.

Jenomže po stažení čehokoliv z Windows Update je vždyzky o zábavu postaráno... Nehledě na to, že když GUI nenaběhne a z textové konzoly se nedá dostat do registrů k nastavení (protože se nenačetly ovladače, tak se nemůže načíst ani nic jinýho), tak se to docela dobře fixuje.

O řešení jako
ssh root@mujserver
vi /etc/konfigurak

si může mrkvosoft nechat jenom zdát.

Kolega Jeronýmek popisoval, že systém tuhnul během bootu a nereagoval ani na ping. V takovém případě vám ssh fakt nepomůže :). Pokud síť funguje, můžete se samozřejmě připojit k Registry vzdáleně. A když nefunguje, můžete samozřejmě zabootovat z instalačního média a použít regedit.

Ad nezustane viset kvuli tomu, ze nenajely X - a on snad někdo tvrdil, že ty Windows nenajely kvůli grafice? To se prakticky nestává, protože když driver nesedí s HW, tak se zavádí Basic Video Driver (nebo možná driver pro dotyčný HW, pokud je nainstalovaný). Ve Windows je GUI důkladně integrované, ne přilepené náplastí a dobastlené klubkem drátů :), takže funguje velmi spolehlivě.

Ad zabootuji live distro a edituji konfiguraky... - jinými slovy stejně jako když zabootujete z instalačního média Windows.

Můžete si spustit nástroje pro správu systému, včetně regeditu.

"Ad zabootuji live distro a edituji konfiguraky... - jinými slovy stejně jako když zabootujete z instalačního média Windows."

Ne, to opravdu není to samé. S live distrem mám k dispozici komplet funkční systém, včetně přístupu na net a Google. Widle nic takového nemají.

Ve Windows RE samozřejmě máte přístup k síti, její zapnutí je na jeden příkaz. Browser by asi měl fungovat, ale nezkoušel jsem to.

Drahý Jeronýmku, antivirus není aplikace. Vlastní on-access skenování provádí File System Filter Driver, tedy je kernelový modul. Jenže vy samozřejmě nic netušíte o API, filter driverech, implementaci on-access skenování, nebo čemkoliv co požaduje nějaké hlubší technické znalosti. Vašimi slovy: lol.

Ja myslel, že Windows jsou mikrokernel, kde se podobně pády nastávají.

BTW. Linux umí on-access skenování taky. A i přes prehistorickou monolitickou architekturu jej pád skeneru neshodí.

Windows jsou modifikovaný mikrokernel, kde z důvodu výkonu běží kernelové moduly ve společném address space. Jinými slovy si z konceptu mikrokernelových OS bere modularitu, nikoliv oddělení serverů.

Linux umí on-access skenování například pomocí kernelového modulu DazukoFS. Když ten modul spadne, tak sletí systém. Nehledě na to že poslední verze je tři a půl roku stará, kód není udržovaný, a skener běžící v user mode bude nutně pomalejší (při každé operaci na FS vám přibydou dva mode switche a dva context switche). Vyjma toho musíte k souborům přistupovat přes DazukoFS, při modifikaci souboru bez této vrstvy hrozí kernel panic. Jo a ještě nepodporuje mmap() pro read-write přístup, a zdroják je potřeba přeložit, s nutností patchovat ho pro konkrétní verze kernelu (přičemž patche pro recentní verze kernelu asi neseženete). Je to takové... silně linuxové.

Aha, takže MS dokázal vyrobit mikrokernel se stabilitou monolitu. Bravo! Zajímavé je, že Linux, přestože je monolit, tak při pádu ovladače většinou nespadne.

Pokud používáte tři roky starý antivirus, tak potřebujete Dazuko. Otázka je, k čemu vám je tři roky starý antivirus. Všechny novější používají FUSE.

Ad Linux, přestože je monolit, tak při pádu ovladače většinou nespadne - což je chyba. Driver běží v adress space kernelu, a pokud spadne na výjimku, mohl ještě před tím napáchat další škodu. Samozřejmě můžete spoléhat, že se to náhodou nijak neprojeví :)

Ad všechny novější používají FUSE - to si moc nepomůžete, protože problém s výkonem zůstává.

Tak ono hlavně na linuxu se antivir používá tak jedině na mailových serverech kvůli widlím virům, na desktopu žádný výkon řešit nemusím, páč tam žádný antivir nemám ;-)

Kdyby byl Linux rozšířený tak aby pro něj stálo za to psát viry, tak byste ten antivirus potřeboval :)

Pro Android se nevyplatí psát viry? Nebo pro servery Googlu? Ale no tak…

Pro Android se zjevně vyplatí psát malware, najdete ho i v Google Play. Servery jsou trochu jiná kategorie, protože bývají ve srovnání s desktopy poměrně slušně administrované, a virus zpravidla vůbec nespustíte.

Já se zeptám znovu: pro Android se nevyplatí psát VIRY? Pokud je uživatel tupý a nainstaluje si sám o vlastní vůli do systému škodnou, na to žádný antivir nepomůže.

Kolik toho malware se na ten Android instaluje automaticky přes bezpečnostní díry, jako to dělají viry ve Windows?

Dneska se malware instaluje v naprosté většině případů za pomoci uživatele.

Jistě, například vložením USB do počítače

"Kdyby byl Linux rozšířený tak aby pro něj stálo za to psát viry, tak byste ten antivirus potřeboval :)"

Prdičky naší babičky (chtělo se mi napsat kdyby byly v ... ryby) :-) Tohle je typický nesmysl prezentovaný win-lovery.

Tak se koukněte třeba na Firefox. Ten byl svého času oproti MSIE velmi bezpečným browserem s minimem bezpečnostních děr. A když se rozšířil, najednou to vypadá jinak. Za rok 2013 měl Firefox 270 bezpečnostních děr, MSIE 126. Jak se SW rozšíří, stojí za to v něm hledat chyby a exploitovat je.

Linux je velmi rozšířený na serverech, takže zajisté stojí za to v něm hledat chyby a exploitovat je. Když připočtu, kolik "adminů" není schopno/ochotno své systémy řádně zabezpečit, atraktivita se ještě dále zvyšuje. Přesto je většina botnetů složená z widlích desktopů. Linux je prostě pro viry mnohem nehostinnější prostředí.

Desktopů je daleko víc než serverů, jsou špatně administrované, a uživatelé rádi otevřou email s "upomínkou", nabídkou medikamentů apod. Uvědomte si, že servery s Windows jsou zatraceně rozšířené, a součástí botnetů jsou přesto prakticky výhradně desktopy. Proč asi? *Servery* jsou prostě pro viry mnohem nehostinnější prostředí.

Mohl, na to tam jsou různé watchdogy. Ale zkuste se zamyslet, jestli je pro vás lepší zkusit uložit všechna data, případně zkusit analyzovat problém na běžícím systému, a až poté restartovat (při pádu ovladače vás Linux upozorní, že došlo k problému a bude potřeba restartovat), nebo raději natvrdo ztratíte všechna neuložená data a rozhodíte souborový systém. Samozřejmě jako u všeho v Linuxu, pokud chcete to druhé, je to změna jedné položky v sysctl.

To ve Windows musíte prověřovat každý soubor při každém přístupu, i když se vůbec nezměnil, že to tak strašně zpomaluje?

Porušenou konzistenci kernelových struktur nezjistíte, resp. ne spolehlivě. A pokud systém dál běží, říkáte si o velký problém.

Ad musíte prověřovat každý soubor při každém přístupu, i když se vůbec nezměnil, že to tak strašně zpomaluje - ve spoustě případů ano, protože se může jednat o soubor který jste ještě neskenoval, nebo jste ho neskenoval se současnou verzí patterns. Samozřejmě pokud máte soubor oskenovaný současnou verzí patterns, skenovat znovu nemusíte.
Na Linuxu je to zpomalení v každém případě, protože FUSE i Dazuko vám dá jen callback při přístupu k souboru, který je u user mode callbacku prostě drahý. Ve Windows máte prostě nainstalovaný filter driver, takže se jedná o pár instrukcí v kernel mode, bez mode switche a bez kontext switche. To je rozdíl v režii vlastního callbacku. Když jde o vlastní skenování, tak tam je další rozdíl v overheadu. Na Linuxu když potřebujete z user mode skeneru načíst nějakou část souboru, vede to k syscallům, a tedy dalším mode switches. Na Windows ten filter driver čte soubory přímo v tom filter driveru, takže je to bez mode switche, tedy rychlejší.

Jak jsem psal, je jen na vás, jestli necháte systém běžet dál nebo ho restartujete. Většinou jde třeba uložit rozdělanou práci. S BSOD máte smůlu.

A pokud všechno poběží v kernel mode jako v dobách DOSu, bude to ještě rychlejší. Jen s tou bezpečností to bude opět na úrovni DOSu.

Driver vám poškodí kernelové datové struktury, a vám dál běží DB server, aplikační server nebo cokoliv jiného. To je fakt výhra, protože z dat můžete mít během vteřiny řezanku. Wow.

Ad pokud všechno poběží v kernel mode jako v dobách DOSu, bude to ještě rychlejší - zrovna u toho antiviru je rychlost dost důležitá, protože by počítač neměl zpomalovat. Navíc bezpečnost zvyšuje, nikoliv snižuje.

Zatím se mi nestalo, že by to nějaká data poškodilo, a naopak pokud to data poškodilo, tak ten modul stejně nespadl, protože to byla např. chyba off-by-one, při které se nedostal mimo alokovanou paměť. Pokud se toho ale tak strašně bojíte, tak si to samozřejmě můžete snadno nastavit, že to vyvolá kernel panic či okamžitě restartuje počítač.

Neměl by ale dělat kontrolu obsahu souboru v kernel space. Vzhledem k tomu, jak komplexní algoritmy to používá, je tohle prostě zvěrstvo. Jinak máte naprostou pravdu, pokud antivir sestřelí Windows, tak se tam žádné viry nespustí :-)

Jinými slovy jste měl zatím štěstí :)

Ad Neměl by ale dělat kontrolu obsahu souboru v kernel space - proč ne? Vždyť se jedná o hloupý pattern matching. Pokud potřebujete například soubor rozbalit, nic vám nebrání operaci posunout do user mode.
Když bude dělat on-access scanner komplet v user mode, a složí se vám to, tak úplně stejně rozbijete veškerý přístup k FS. V čem si tedy pomůžete (vyjma toho že to bude pomalejší)?

BTW dělat on-access scanner přes Dazuko, FUSE apod. je velký nesmysl. Musíte u toho mít namountovaný originální FS, a malware může přistupovat přímo k němu.

Hloupý pattern matching používaly antiviry na začátku 90. let. Dnes snad již všechny ví, že to je na polymorfní viry nestačí.

Pokud se vám ten user-space skener složí, tak jej stačí restartovat, ne?

Ten můžete mít namountovaný tak, že se tam dostane jen ten skener. Třeba pomocí pivot_root a umount -l.

Ad hloupý pattern matching... na polymorfní viry nestačí - přesto skenování na patterns potřebujete. Kombinací hledání fragmentů a wildcard matchingem můžete detekovat spoustu malwaru. Na některé problémy můžete používat emulaci kódu, opět ji můžete implementovat jak v kernel mode tak v user mode.

BTW jeden pěkný on-access scanner pro Linux. Fakt krása.
http://www.sophos.com/en-us/support/knowledgebase/118216.aspx

Image kernelu má na mém počítači 7.12MB, což mi nepřipadá až tak moc :)

Problém byl s HW nebo mezi židlí a klávesnicí? Neříkám, že se nemůže rozpadnout, ale ztratit data uložená na SW RAIDu s paritou, to už vyžaduje hodně umu.

Měl jsem na mysli, jestli jste náhodou nezkoušel používat NTFS v tom SUSE. Vlastnosti má hezké, ale já preferuji souborové systémy, které si samy jen tak ze srandy nemažou inode table (MFT v microsoftí hantýrce).

Ad problém byl s HW nebo mezi židlí a klávesnicí - RAID se rozpadl, operace končily záhadnými chybami, nakonec se FS odmountoval a už nešel přimountovat. Nechal jsem to řešit admina. Nakonec systém jel bez RAIDu. HW to asi nebyl, bez toho RAIDu to jelo v pohodě. Pokud jsem si všiml, tak SW RAID5 je (byl?) na Linuxu dost zabugovaný.

Ad jestli jste náhodou nezkoušel používat NTFS v tom SUSE - samozřejmě ne. Používat NTFS jinde než na Windows (nebo na certifikované implementaci) by mě ani nenapadlo.

Ad souborové systémy, které si samy jen tak ze srandy nemažou inode table - to NTS nedělá, tedy na Windows. Samozřejmě nevím co pánové implementovali pro Linux, ale chyby nepřekvapí.

HW to asi nebyl, bez toho RAIDu to jelo v pohodě

Hmm, to byl nějaký kompetentní admin, když to HW „asi nebyl“, to by snad měl vidět z logu. Při použití MD RAIDu se (ve výchozím nastavení) třeba používají jiné timeouty, takže pokud ten disk měl problémy se zápisem, tak bez RAIDu nějak pojede, ale RAID jej velmi rychle vykopne. Nebo pokud potom několik disků odpojil, tak nedostatečné napájení se taky často projevuje restarty disků.

Pokud jsem si všiml, tak SW RAID5 je (byl?) na Linuxu dost zabugovaný.

Občas se nějaké bugy v MD RAIDu najdou, ale od označení md-raid5 jako stabilní nevím o žádném, který měl potenciál ničit data, maximálně se ten RAID odmítl automaticky sestavit (za určitých okolností se mu mohl smazat seznam disků, dost snadné na opravu, stačilo ty disky uvést), chyběl mu paritní disk (to se za určitých okolností mohlo stát, pokud bylo pole restartováno během rebuildu) nebo se omylem sestavil read-only a degraded (typicky pokud disky lhaly o flushi).

to NTS nedělá, tedy na Windows. Samozřejmě nevím co pánové implementovali pro Linux, ale chyby nepřekvapí.

Windows XP a 2003 Server mi to udělaly tak čtyřikrát na čtyřech různých počítačích, vždy po BSOD. Chápu, že BSOD není zrovna standardní způsob ukončení, ale souborový systém by s tím snad měl alespoň trochu počítat. Windows už pak ten disk nenašly (NTLDR nebyl nalezen, v jiných Windows to řeklo, že disk není naformátovaný) a NTFSDOS k tomu zahlásil, že $MTF je vadné a po načtení ze zálohy byl disk prázdný. Disky byly vždy v pořádku, SMART ani memtest žádné chyby nenašel a to BSOD nebylo způsobené MCE.

V syslogu hlášky o chybě HW nebyly. Je to už pár let zpátky, syslog uschovaný nemám. Když jsem se na to ptal, bylo mi řečeno, že používat SW RAID5 na Linuxu je velmi špatný nápad, protože je plný bugů.

Ad ztráta MFT po BSOD - aha. Viděl jsem jednu konkrétní konfiguraci (AMD CPU s VIA chipsetem), kde se uživatelům pravidelně tak do roka podělal FS po BSOD. Vzhledem k tomu že jsme podobných desktopů (naštěstí ne serverů) měli po firmě minimálně desítky, bylo to nemilé. Příčinou byly podle všeho nějaké drivery toho VIA chipsetu, z neznámého důvodu došlo k přepsání začátku disku nulami. Tyhle drivery měly vůbec spoustu zajímavých vlastností. Například u jiné konfigurace se v případě použití UDMA a kopírování obsahu CD z mechaniky na HDD přístupy postupně zpomalovaly, až systém úplně ztuhnul. Po téhle zkušenosti jsme VIA (a nakonec i AMD) zavrhli.
V daném případě (přepsaný začátek disku) se dá použít záložní kopie boot sectoru. Ta je u do NT 3.51 v půlce volume, od NT4 je to poslední sektor volume. Boot sector zkopírujete na původní místo pomocí utility dskprobe.exe. Pak systém už najde FS, a chkdsk se vypořádá se případnými chybami. MTF má dvě kopie (druhé se říká MTF mirror), takže oprava většinou skončí beze ztráty dat, nebo s minimální ztrátou.

Myslím, že VIA to byla, ale ten ovladač byl z Windows UIpdate a s HW problém nebyl, takže jak jste tu sám několikrát psal něco podobného o ovladačích pro Linux, tohle je to chyba MS ;-)

MTF mirror obsahuje jen první čtyři clustery. Po jeho načtení skončil disk prázdný.

Nevím o tom, že by se takové ty VIA 4in1 drivery dodávaly přes WU.

To chce namountovat ten disk ve Windows, ne s driverem pro DOS. Samozřejmě je možné, že jste měl nějaký jiný problém. Každopádně šlo zjevně o důsledek BSOD, nikoliv o funkční vlastnost FS.

"BTW NTFS je FS který můžete uživatelům Windows závidět. Žurnál, vestavěná komprese, sparse files, Volume Shadow Copy, podpora ACID transakcí nad daty (včetně transakcí nad více soubory nebo stroji), šifrování, kvóty, online defag atd. A všechno v jednom FS, velmi rychlé a spolehlivé."

No a hlavně si můžu vybrat kompresi NEBO šifrování, oboje jaksi ten úžasný FS nezvádá :-)

Ad můžu vybrat kompresi NEBO šifrování - to máte pravdu. Ale můžete šifrovat celý disk (BitLocker), a k tomu komprimovat.

Windows umí full-disk encryption? Wow! Teď ještě jestli to používá nějaký fungující šifrovací algoritmus nebo si jej napsali v MS sami jako MS CHAP, NTLM či EFS a obsahuje to spousty chyb.

BitLocker je ve Windows už 8 let. Používá AES-CBC + Elephant diffuser.

Ad NTLM a MS-CHAP - oba pocházejí z doby, kdy jste na Unixech ještě používali telnet a ftp :D

NTLMv2 i MS-CHAPv2, které jsou oba děravé, jsou z roku 1998, SSHv2 je o dva roky starší. Ještě větší WTF je to, že originální (a mnohem starší) CHAP ty díry nemá.

Kdežto SSHv2... je děravé taky:
http://www.kb.cert.org/vuls/id/958563

CHAP pokud vím vyžaduje znalost plain-text hesla na obou stranách, což je bad practice. MS místo MS-CHAP dávno používá Kerberos.

tak hlavne ze Kerberos nebyl deravej "vcera" a neumozoval ziskat domain admin ze ;)
FUDarum no nazdar ! :)

To byla "jen" chyba v implementaci. Takové jste samozřejmě mohl vidět i u OpenSSH.
http://www.openssh.com/txt/gcmrekey.adv

Tenhle útok je jen velmi teoretický, protože potřebujete v průměru přes 11 000 pokusů, než těch 14 bitů vytáhnete, což i při obnovení spojení každou sekundu dostanete v průměru kolem 4 bitů za hodinu. Prosté omezení počtu restartů spojení pak činí tento útok nepoužitelným.

Což NTLM vyřešilo tak, že oběma stranám stačí znát jen hash toho hesla, který je navíc velmi snadné získat. Fakt skvělé řešení.

Mimochodem jistě víte, že Kerberos je UNIXový protokol, že? A jako tradičně, nadstavba, kterou si tam vymyslel MS, je nebo alespoň byla děravá.

Ad NTLM vyřešilo tak, že oběma stranám stačí znát jen hash toho hesla, který je navíc velmi snadné získat - snazší než heslo z komunikace telnetu nebo ftp? :)

Ad Kerberos je UNIXový protokol - API je unixové, protokol ne. MS tradičně učesal technologii do použitelné formy. Ano, měl recentně díky v implementaci. Oproti MIT byl zjevně pár let pozadu :)
http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2007-003.txt
http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2007-002-syslog.txt