<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Zdravím,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">to opravdu není v lidských možnostech.
Kdyby to možné bylo, tak by to například Microsoft asi měl a
nemusel by vydávat každé druhé úterý v měsíci pravidelný
bezpečnostní update který záplatuje 50 - 150 chyb z nichž
pravidelně je tak pět až deset kritických a nejméně jedna bývá
"0-day".</div>
<div class="moz-cite-prefix">U Linuxu je to jen o málo lepší a občas
se stává, že na nějakou kritickou chybu se přijde po mnoha letech.
Což bývá maximální průšvih, pokud je ta chyba v nějaké knihovně,
která se často používá. Třeba Log4J nebo SSL/SSH a podobně.</div>
<div class="moz-cite-prefix">Ono je to částečně dané tím, že drtivá
většina operačních systémů je psaná v C/C++, které zrovna
nevynikají bezpečností. Proto se v posledních cca. 2 - 3 letech
objevuje docela silný tlak na to přepsat kernely třeba v jazyku
Rust, kde je základní úroveň bezpečnosti součástí samotné definice
jazyka. Ale naráží to na problém, že toho kódu je jednak moc (celá
desetiletí práce) a za druhé některé věci jsou prostě příliš
pomalé, pokud nejsou psané v C/C++ nebo přímo v assembleru.</div>
<div class="moz-cite-prefix">No a to už se dostáváme k tomu, zda je
vůbec možné teoreticky zaručit 100% bezpečnost na von Neumannově
architektuře která se v počítačích používá. A na to neumí nikdo
odpovědět a filosofické disputace z této oblasti bývají celkem
často námětem přednášek na mezinárodních konferencích.</div>
<div class="moz-cite-prefix">Harvardská architektura (jako má třeba
PIC nebo AVR) je o hodně bezpečnější protože program a data jsou
striktně oddělené, ale zase má jiné nevýhody. Nevím přesně jaké,
ale faktem je, že mimo mikrokontroléry a specialisované DSP
procesory se příliš neujala. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Zdraví PavelK</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Dne 14.02.2025 v 11:24 Martin Záruba
napsal(a):<br>
</div>
<blockquote type="cite"
cite="mid:bcb304fe-3cef-4d99-92f2-f6f33dcaba7c@volny.cz">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><font face="Arial">Vubec tomuto oboru nerozumím, tak se zeptám
hloupě; Je ten systém tak složitý, že není možné jakoukoli
simulací nebo nějak jinak zajistit, že tam opravdu ty díry
nebudou?</font><br>
</p>
<pre class="moz-signature" cols="72">Martin Záruba</pre>
<div class="moz-cite-prefix">Dne 14.2.2025 v 10:07 Pavel Kořenský
napsal(a):<br>
</div>
<blockquote type="cite"
cite="mid:8c32b617-3e10-4ea5-a1bb-0a57e64115e8@dator3.cz">Zdravím,
<br>
<br>
pokud vím (nestíhám studovat do hloubky úplně všechny nejnovější
informace) tak snapshoty na Synology jsou zatím bezpečné. Tím
"zatím" myslím to, že nevím o žádném malware, který by někdo
napsal cíleně pro Synology resp. její DSM 7.x operační systém.
Nějaký pokus byl kdysi pro DSM 6.x, ale tu díru Synology
zazáplatovala velmi rychle. To, že jsou snapshoty read-only zase
tak moc neznamená. Pokud systém umí snapshot vytvořit a smazat,
musí umět i zapsat. Jde jen o to najít díru, která povede ke
spuštění kódu a následné eskalaci práv. U Synology to zatím
nikomu nestálo za to aby to cíleně hledal a zkoušel. <br>
Jiná situace je třeba u VMWare, kde existuje několik druhů
malware, které právě po snapshotech jdou. A když VMWare jednu
díru zalepí, útočníci hledají další a když jí najdou, je to nová
"0-day" chyba a kolečko se opakuje. Důvod je ten, že VMWare
používají velcí zákazníci u kterých lze očekávat, že případně
zaplatí tučné výkupné. <br>
<br>
Je to bohužel neustálý boj, protože z ransomware se stal
regulérní mafiánský bussiness ve kterém se krom obyčejných
sprostých zločinců pohybují i státem vytvářené a placené
skupiny. Zejména třeba pro KLDR je ransomware významným zdrojem
devizových příjmů. <br>
<br>
Zdraví PavelK <br>
<br>
Dne 14.02.2025 v 8:50 Martin Hanek napsal(a): <br>
<blockquote type="cite">Jak se díváte na snaphoty na btrfs na
Synology NAS? Moje, snad správná, představa je ta, že kdyby
někomu ve firmě napadl ramsonware počítač a ten zašifroval
sdílené disky, tak snapshoty zůstanou nedotčené? Jsou read
only? <br>
<br>
Martin Hanek <br>
<br>
<br>
Dne 13.02.2025 v 23:23 Pavel Kořenský napsal(a): <br>
<blockquote type="cite">Zdravím, <br>
<br>
nevím o tom, že by se to někomu povedlo. Matně si pamatuju,
že před pár lety tam byl nějaký problém s nedostatečným
zabezpečením hesla či certifikátu, ale Synology to celkem
rychle zazáplatovala. <br>
Nicméně, jak vždy platí v oblasti IT Security, co je pravda
dnes nemusí být pravda zítra. Ale taky to používám a jsem
celkem v klidu. <br>
Jak jsem už psal, při používání podobných prostředků nejspíš
při plošném ransomware útoku k zašifrování či smazání záloh
nedojde (není to jako připojit si síťový disk pomocí SMB a
nalejvat na něj kopie souborů) a stačí udělat restore ze
zálohy před útokem. Nejlépe hodně dost dnů před útokem,
protože některé ransomware mají ošklivou vlastnost v tom
smyslu, že se usadí v systému, počkají pár měsíců a pak se
aktivují. <br>
Pokud by útok způsobil, že dojde k zašifrování zálohy třeba
na tom Active Backup, tak to není plošné, ale jde o cílený
(a velmi drahý) útok na konkrétní infrastrukturu. A to je
patrně věc nějaké státem placené APT a tudíž případ pro
písmenkové agentury a o tom opravdu nemohu a nesmím mluvit.
Ale v takovém případě to bude řešit někdo úplně jiný než
lokální admin. Problém lokálního admina bude jen v tom,
jestli nezanedbal nějaký bezpečnostní update. Pokud
nezanedbal, tak je z obliga. <br>
<br>
Zdraví PavelK <br>
<br>
Dne 13.02.2025 v 22:50 Michal Grunt napsal(a): <br>
<blockquote type="cite">A co takove Synology a Active Backup
for Business. Už to někdo dokázal napadnout a vše zrušit?
(pri předpokladu, že není zapnuté SSH, nejsou
nainstalovane žádné kontejnery, zbytečně balicky, nikdo
neexperimentoval s pravy na slozku ABB atd.) <br>
<br>
</blockquote>
</blockquote>
_______________________________________________ <br>
HW-list mailing list - sponsored by <a
class="moz-txt-link-abbreviated" href="http://www.HW.cz"
moz-do-not-send="true">www.HW.cz</a> <br>
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:Hw-list@list.hw.cz" moz-do-not-send="true">Hw-list@list.hw.cz</a>
<br>
<a class="moz-txt-link-freetext"
href="http://list.hw.cz/mailman/listinfo/hw-list"
moz-do-not-send="true">http://list.hw.cz/mailman/listinfo/hw-list</a>
<br>
</blockquote>
<br>
<br>
_______________________________________________ <br>
HW-list mailing list - sponsored by <a
class="moz-txt-link-abbreviated" href="http://www.HW.cz"
moz-do-not-send="true">www.HW.cz</a> <br>
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:Hw-list@list.hw.cz" moz-do-not-send="true">Hw-list@list.hw.cz</a>
<br>
<a class="moz-txt-link-freetext"
href="http://list.hw.cz/mailman/listinfo/hw-list"
moz-do-not-send="true">http://list.hw.cz/mailman/listinfo/hw-list</a>
<br>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
HW-list mailing list - sponsored by <a class="moz-txt-link-abbreviated" href="http://www.HW.cz">www.HW.cz</a>
<a class="moz-txt-link-abbreviated" href="mailto:Hw-list@list.hw.cz">Hw-list@list.hw.cz</a>
<a class="moz-txt-link-freetext" href="http://list.hw.cz/mailman/listinfo/hw-list">http://list.hw.cz/mailman/listinfo/hw-list</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>