"Leállított Linux" mennyire biztonságos router?

Hálózati eszközök

Sok évvel ezelőtt volt egy cikk arról, hogy a power management nélkül leállított Linux rendszer továbbra is ellátja a routing feladatokat, mert az nem áll le addig amíg power gombbal le nem nyomjuk az áramot. Ugyanakkor nagyon biztonságos router ebben az állapotában a Linux, gyakorlatilag törhetetlen.
Épült azóta erre a "képességre" valamilyen router disztribúció, netán fizikai termék?

( _ventura_ v | 2018. 06. 06., sze – 21:32 )

Arra a cikkre kíváncsi lennék.

Sok sok éve használok linuxot, és volt idő mikor igencsak gyerekcipőben járt a power management, viszont ha leállítottam a masinát, akkor az nagyon le volt állva :D

Fedora 27, Thinkpad x220

Speciel én is emlékszem a cikkre, emlékeim szerint azt taglalták benne, hogy a csomagszűrő alrendszer vígan megyegetett tovább. Már akkor eléggé elképesztően hangzott, aztán feledésbe is merült. (Nekem amúgy valami olyasmi rémlik, hogy nem klasszikusan kikapcsolt állapot, hanem mondjuk egy single-user módba kapcsolt környezet - ami mint ilyen, lévén nem futtat semmilyen szerver szolgáltatást, kevesebb erőforrást igényel, és nem nagyon támadható - kivéve a célzottan a netfiltert támadó eszközökkel.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

and the firewall would remain active but with no drives mounted and no processes running
Ezek szerint két eset lehetséges:
- A firewall nem process.
- Az "active" az áram fogyasztását jelenti és nem a működést.

Értem!

A runlevel 0 az a halt. Ha ennek ellenére fut valami, akkor meg nem 0. Azaz nem halt.
Ha nem halt, akkor meg él.

Világos!

Hát még mindig LOL.

When the machine is halted, the kernel still resides in memory, even when the machine runs through the shutdown process.

Pont azt írja is aztán/közben hogy NEM állít le bizonyos szolgáltatásokat... Tehát a rendszer NEM halted státuszban van. Elindult ugyan a halt processz, de csak a sallagot állította le :)

Meg mondjuk ezek után belépni sem fog rá többet, sőt újraindítani is csak local-hand segítségével lehetne majd ;)

--
zrubi.hu

Szerintem ez az állapot most is megvalósítható úgy, ha leállítod az összes proceszt és unmountolod az összes filerendszert a rootal együtt.
Valószínű a shutdown -h nem ezt fogja csinálni, de semmi akadálya, hogy írj egy ilyen programot. Az eredmény egy gyakorlatilag nem működő rendszer ami alatt fut a kernel és csinálja a tűzfalazást.
Kicsit lehet fokozni a helyzetet, ha a rendszer és a konfiguráció is pendrive-ról indul majd a végén azt ki is húzod. A hátrány az, hogy nem logol a tűzfal sehova. Ha logra is vágyunk akkor nem állhat le minden, de szerintem a memóriába betöltött távoli gépre logoló syslog akkor is megy tovább ha kiszedik alóla a filerendszert.

Szép fogás a cikk. A sok lehurrogás után itt a fricska. Azért ennek a gyakorlati alkalmazása elég problémás. Szerintem a cikk szépen leírt minden lényeges mozzanatot.
Az egyetlen ami ebből gyakorlatba ment szerintem az az, hogy nem telepítjük csak azokat a csomagokat amikre tényleg szükség van. Jellemzően a szükséges egyéb szolgáltatások ellehetetlenítik ennek a featnek az érdemi alkalmazását. Másik hasonló trükk volt a read-only fájlrendszer hw implementálása, de a frissítések amik manapság már heti/napi rendszerességűek elég macerássá teszik ezeket, ahol ennyire biztosak akarnak lenni, hogy ilyen kell ott szerintem airgap van. De ez az irániaknak sem jött be anno... a stuxnet után még volt egy vicces kis Thunderstruck epizód is.

P.S. én ilyen kacifántos tűzfalmegoldást az állami megrendelőkre specializálódott cégek classified prospektusaiban keresnék. A wikileaks persze csak lehallgatási szoftverekre cuppant rá és hozta nyilvánosságra, de van ott más is, ahonnan azok jöttek. Pl atomerőművekhez gondolnék ilyesmit próbálni eladni.

javítsatok ki, de szerintem a cikk szerzője hülyeséget ír, mégpedit itt:

After a relatively short period of time, I concluded that for Red Hat Linux 6.2, removing the following scripts will allow this behavior to occur:

/etc/rc.d/rc0.d/S00killall
/etc/rc.d/rc0.d/K90network
/etc/rc.d/rc0.d/K92ipchains
Removing these three scripts keeps the network up, and keeps ipchains running. Note that removal of the killall script is necessary because its task is to recurse through the /etc/rc.d/rc0.d/ directory and run all scripts that start with a K. This script would run the K90 network and K92 ipchains scripts, which would kill the network and ipchains.

Alul azt írja, hogy az S00killall-t azért kellett törölni, mert az végigmegy az összes K-betűs scripten az rc0.d-ben és így lefuttatná a másik kettőt is.
Ezzel két nagy problémám van:
1. ha azt a másik kettőt már törölte a mappából, akkor ez miért lenne probléma? Ha nincs ott, nem fogja lefuttatni a killall.
2. ha a killall-t törli akkor tulajdonképpen semelyik szolgáltatást nem állítja le amikor kiadja a shutdown-t, vagyis tulajdonképpen ugyan azon a runlevel-en maradtunk ahonnét indultunk és fut minden process.

( nice | 2018. 06. 06., sze – 21:59 )

Érdekes felvetés. Nem ismerek ilyet, de érdemes lenne kipróbálni.

( vl v | 2018. 06. 06., sze – 22:07 )

Szerintem is rég nem igaz ez már (ha egyáltalán valaha igaz volt).

Ha pl. egy ARM-os Pi-szerű cuccon nyomsz egy poweroff-ot, akkor a cpu bizony megáll, a képernyő lekapcsol, pingelni nem lehet többet a gépet. A benne levő hw ethernet switch, az valóban mehet tovább (hiszen annak bootoláskor is elég az áram, és már megy is), és switcheli a packeteket, de ennyi, routolni nem fog a készülékben semmi. Ha lenne benne olyan hw, ami a cpu-tól függetlenül tud routolni, akkor az mehetne elvileg tovább, de ilyet én még sosem láttam.

( saxus | 2018. 06. 07., cs – 09:50 )

Csak akkor, ha eléraksz egy megfelelően konfigurált WGA-t!

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( eff | 2018. 06. 07., cs – 09:55 )

Gondolom halt vs. poweroff lenne a téma, de eddig nem találtam sehol semmit arról, hogy halted system tudna route-olni továbbra is. Sőt soha nem is hallottam ilyenről.

( fefy | 2018. 06. 07., cs – 10:05 )

Érdekes elgondolás, de nem hiszem, hogy van bármilyen valós alapja. Én ezt úgy tudom elképzelni, hogy a hálózati interfészek tartalmaznak valamilyen embedded routing firmware-t és ameddig áram alatt van a vas, addig ez a firmware valahol fut és minimális routing feladatokat ellát és/vagy az uefi csinál(hat) ilyet.
Mindenestre nem találtam erről semmit.

Vizsgára felkészülés végett keresek "kidobásra" szánt menedzselhető Cisco switch-eket és routereket, leginkább Pest és Bács-Kiskun megye területén.

( icserny | 2018. 06. 07., cs – 10:43 )

"leállított Linux rendszer továbbra is ellátja a routing feladatokat"
Az én fogalmaim szerint a "leállított Linux" azt jelenti, hogy a kernel és a CPU leállt. Akkor ki a búbánat routolna (és főleg, milyen szabályok szerint)?

( ironcat | 2018. 06. 07., cs – 10:57 )

Van ilyen. Arról lehet felismerni az erre képes alaplapokat, hogy bekapcsolás után ezt mondogatja a gép: „victim szajsz nevö jútá”

( hunti v | 2018. 06. 07., cs – 12:10 )

Nekem rémlik mintha olvastam volna valami programozható hálózati kártyáról amely hardverből képes a fizikai portjai között routolni, tűzfalazni. Én mondjuk nem emlékszem hogy konkrétan le lett volna írva, hogy operációs rendszer nélkül is működőképes, de igazából logikus lenne ha egyszer felprogramozod, akkor végzi a dolgát amíg áramot kap.

( dentzol | 2018. 06. 07., cs – 14:35 )

Az elmúlt időszakban sok hír volt az Intel Management Engine hibái kapcsán. Akár elképzelhetőnek tartom, hogy az eredeti poszt ezen információknak valamilyen félreértelmezése.

+1
Az intel management engine (néha csak "ME" rövidítéssel említik) egy gép a gépben. Ha a hoszt gép kap áramot és nincs letiltva az ME (van ahol nem is lehet) onnantól az 1 saját IP stack-el működő embedded OS-t futtat vígan, miközben a hoszt gép látszólag be sincs kapcsolva.
--

https://hothardware.com/news/researchers-figured-out-how-to-turn-off-in…

Positive Technologies wrote, "The disappointing fact is that on modern computers, it is impossible to completely disable ME. This is primarily due to the fact that this technology is responsible for initialization, power management, and launch of the main processor. Another complication lies in the fact that some data is hard-coded inside the PCH chip functioning as the southbridge on modern motherboards."

Az a jó ezekben a secret undocumented backdoor-okban, h. amíg nem jön ki róla egy BlackHat/Defcon előadás, addig a laikus nép csak találgatni tud h. tényleg ki tudta-e kapcsolni v. még mindig aktív félig-meddig.
--

( gee v | 2018. 06. 07., cs – 15:55 )

Kivancsi vagyok, hogyan kepzeltek el.

Ha azt mondana, hogy leallt az OS, meg a proci, meg ez-az, de a halokartya kapott tovabbra is tapot es a konfiguraciojat megtartva tovabbra is a halora kapcsolodva maradt, azt meg ugy-ahogy elfogadnam.

Bizonyos dolgok mukodhetnek esetleg egy ilyen kartyan, pl. ha hardverbol megy az ethernet protokol beszede, akkor eszreveheti, hogy neki cimzett uzenet erkezik a droton, stb.

Na de utana mi tortenik, feltetelezve a legjobb esetet? A kartya kommunikal a droton jol. Veszi az adast. Beteszi a bufferbe. Kuld egy interruptot.
Aztan az interruptra nem reagal senki, senki nem uriti ki a buffert, senki nem mondja, hogy rendben, fogadhatsz ujabb frame-et.
Es foleg senki sem fog routolasi donteseket vegezni, uj cimekre csomagokat kesziteni, es a kartyanak szolni, hogy ezt kuldje el ide vagy oda.

Szerintem.

Ha tevedek, akkor szakemberek, lepjetek meg es magyarazzatok el, hogy mukodhetett ez, legalabb elmeleti szinten. (Gondolom nem az a megoldas, hogy az ethernet kartya sajat kis ramjaban/romjaban teljes TCP/IP stack is volt meg routing tabla es hozza tartozo logika meg ARP table meg minden).

( snq- | 2018. 06. 07., cs – 21:46 )

>> Ugyanakkor nagyon biztonságos router ebben az állapotában a Linux, gyakorlatilag törhetetlen.

oO

( carlcolt | 2018. 06. 08., p – 00:23 )

Reg lattam ennyi fogyatekot egy topiknyito textben a hupkon. Elo szokott fordulni, de ehhez hasonlo merteku fogyatek-leak reg volt ilyen formaban.