A lezárás 11. éve most kezdődött el.

A gyerekek a házifeladatukat írják az utcai világítás beszűrődő fényénél.

A villanyt lekapcsolták, mert nem tudtam a számlát fizetni. Nagyon nehéz pénzhez jutni. Futárnak nem vesznek fel, hatalmas a túljelentkezés. Az alanyi jogon járó szociális juttatásokra nem vagyok jogosult, mert a családomnak van saját tulajdona. Még.

A gyerekek csillagokról tanulnak. Azt kérdezik, hogy tényleg léteznek-e csillagok? Hát persze – mondom –, elég este kimenni a városból egy sötét helyre, ahol a lámpák fénye és a felhők nem takarják el őket, és felnézni az égre, koronaékszerekként csillognak. „De hiszen akkor megbüntetnek, ha este nem vagy otthon!” – válaszolják. „A tanítónéni mondta, hogy jelentsünk mindenkit a járvány-követő alkalmazással, akit karanténszegésen látunk, mert életeket mentünk vele. A görbét laposítani kell, tegnap is több mint százan meghaltak.” Igazuk van.

Tényleg szörnyű a vírus tombolása. Már szinte nincs is más halálok, olyan pusztító a vírus. Tombol a kaszás. Az éhezőket pedig még jobban fenyegeti. Nincs pénzem. A céget bezáratták és megbírságoltak járványügyi veszélyeztetésért. A barlangtúra miatt. De én vagyok a hülye, miért is szerveztem ilyet… hisz a vírus is a denevérektől származik. Felelőtlen voltam, bárkit megfertőzhettek volna, és ki tudja, talán egy újabb, veszélyesebb törzzsel!

Nézem az eget. A nátrium lámpák fénye sárgára festi a felhők hasát. Gondolkozom a jövőn. Én már sosem jutok el a csillagok közé. Vajon a gyerekek megérik, hogy kiszakadjon az emberiség a bölcsőjéből? Talán ha addig elkészül végre egy olyan vakcina, ami a legújabb mutációk ellen is véd. Nagyon távolinak tűnik ez. Most jelentették be, hogy új mutáció ütötte fel a fejét Észak-Afrikában. Inkább beadom még egy ételfutárhoz a jelentkezésem, hátha felveszenek. Félek ide is túlképzett vagyok. A lakcímem nem merem odaírni, mert látják, hogy nem munkásszállón élek. Jobb lenne, ha nem tudnák, hogy gazdag vagyok.

Ki ne látott volna már bankrablós filmet? Olyan népszerű zsáner, hogy külön kategória a filmeken belül, a maga archetipikus karakterivel, kliséivel. Ha valakit az átlagnál jobban érdekel a téma, mint például engem (részben a Payday 2 játék máig tartó hatása miatt), akkor amint szembejön vele ez a könyv, olvasólistájára veszi. Én is így tettem, mikor valamely internetes magazinban ajánlották ezt a könyvet, ódákat zengve róla, hogy milyen izgalmas eredeti téma (valóban az), ráadásul besztszeller is! Egymillió légy pedig – mint tudjuk – nem tévedhet!

Érdeklődve vettem így kezembe az (e)könyvet, hogy végre olvashassak pár a filmes kliséken kívül eső érdekes történeteket, avagy a klisék eredettörténetét megismerjem, illetve az építészet rejtett, elfeledett, avagy egyszerűen az átlagember által számításba sem vett részeiről kapjak egy összefoglalót. Nem állíthatnám, hogy a könyv nem próbálkozott meg mindezzel, de őszintén szólva amit nyújtott, az elmaradt a várakozásaimtól.

A szerző először a betörés és az épített környezet kapcsolatát és a kettő elválaszthatatlan természetét a híres new-yorki George Leonidas Leslie történetén keresztül, aki építészből vált bankrablók királyává. A betörők hol furmányos zsenik, hogy túljárnak az építészet kliséibe ragadt gondolkodású kispolgárok eszén, hol idióták, hogy nem tudják, hogy az ajtón kell bemenni. Néhol star wars hasonlatok, vagy szuperhősös hasonlatokkal próbálja a kortárs olvasó az ismétlésektől elillanó figyelmét megragadni¹:

But let’s settle, instead, on a middle ground and say it’s some combination of the two extremes: burglars are idiot masters of the built environment, drunk Jedis of architectural space.

Esetleg filmes utalásokkal, amikkel semmi gond nem lenne, ha nem írna oldalakon keresztük iszonyatosan tekervényes túlcirádázott bölcsészstílusban a Nakatomi-toronyról, és egyéb filmekről holott tán nincs ember az olvasóközönségben, aki ne látta volna a Die Hardot, és az egész ömlengés annyit akar csak mondani, hogy a szellőztető rendszert is lehet közlekedésre használni, és a lift tetején is lehet utazni. Ki hitte volna:

Indeed, McClane’s actions reveal a new type of architectural space altogether — a topological condition that we might call Nakatomi space, wherein buildings reveal near-infinite interiors, capable of being traversed through all manner of nonarchitectural means, with their own exhilarating form of boundless fluidity.

Érdekes témákat jár végig a szerző, de sajna a tartalom kevés, a töltelék sok, és a forma nem optimális. Ábrát egyet sem találni a könyvben, pedig nagyon feldobta volna a tartalmat, illetve lehetett volna egy-egy esethez jobban elkülönülő esettanulmányt írni, ahelyett, hogy megemlít rengeteg érdekes esetet, nagyon keveset veséz ki alaposabban, és ott is elkezdi fájdalmasan ismételni magát, vagy iszonyatosan túlírni a szöveget.

A felölelt témák a teljesség igénye nélkül:

• George Leonidas Leslie new-yorki betörései.
• A betörés mint bűnügyi kategória (az angolszász jogrendben), és annak kapcsolata az épület jogi fogalmával.
• A városszerkezet hatása a betörések gyakoriságára, ezek okai: pl. a los-angelesi bankrablás hullám és a gyors menekülés lehetőségének összefüggése.
• A hatóság eszközei a hatékony bűnüldözésre a városokban: rácsrendszerbe szervezett városok, helikopteres őrjáratok, modern képalkotó technológiák és mindent behálózó városi kamera hálózat. Ez eléggé propaganda szagú volt, az egyre inkább panopticonná váló világunk nem annyira kritizálta a szerző, bár nem is dolga a mű keretein belül állást foglalni.
• Interjú egy széf építővel, pánik szoba építővel, illetve egy biztonságtechnikai szakemberrel, aki maga is betörő volt korábban.
• Interjú a new-yorki zár-nyitó (lock-picking) hobbistákkal.
• belső munka, avagy pár eset „kitörés” általi betörésről
• pár alagutas melót is említ, amik körül még kapcsolódó témákról ír

A könyv végén a hivatkozásjegyzék mutatja, hogy a szerző egyébként nem kevés kutatást, forráselemzést fektetett a munkájába: ez mutatja, hogy mennyivel több potenciál is lett volna a témában. Sajnos azonban ahelyett, hogy mélyebben a részletekbe menne, a szerző inkább iszonyatosan túlírtan ismételgeti a szinte a fülszövegen elférő tanulságot, miszerint: a betörők megszegik a szabályokat. Sajnos ez az könyv egészében kitart. Sajnos ez a könyv végéig kitart. A könyv végéig még sokszor találkozunk önmaga kitartó ismétlésével… Azt hiszem érthető.

Nekem ez így csak ⁵⁄₁₀. Csak türelmes és a téma iránt kiemelkedően érdeklődő olvasóknak ajánlott. Az erős kezdés ellenére hamarosan repetitív lett, összességében nem volt élvezetes olvasmány. Külön dühös vagyok a könyvre, mert pár „klasszikus” filmet megnéztem a könyv ihletésére, de mind Az Olasz Meló, mind a Thomas Crown Affair alulmúlta a hírük alapján támasztott elvárásaim.

Az routerem egy Mikrotik gyártmányú termék, és ezen van egy nagyon hasznos funkció: hangjelzéssel jelzi a bekapcsolás vagy újraindítás után a sikeres indulást, amikortól már elvárható a szolgáltatásinak helyes működése. Ez nagyon hasznos funkció olyan headless gépeken, amik a közvetlen környezetemben működnek. Ilyen az itthoni router mellett az itthoni NAS is. Mivel épp belakom az új gépet, amit erre a feladatra raktam össze, és most még viszonylag gyakran újra is indítom emiatt, így megcsináltam ezt a funkciót a NAS-ra is.

A NAS-on Fedora 31 fut, így a leírás arra vonatkozik, de minimális módosításokkal nyilván más systemd alapú Linux disztribúciókon is használható.

Beep-beep!

Először is a gépen szükséges egy hardveres hangkimenet. Én a PC Speakert választottam a feladatra, mert más hangforrást nem akarok a gépre kötni.

Linux alatt legegyszerűbben a beep programmal lehet PC Speakert tütülésre bírni. Ezt a legtöbb disztribúció szállítja. Fedora alatt a telepítése mindössze annyi, hogy:

dnf install -y beep kernel-modules-extra

Ezután a beep parancsot kiadva… nem hallunk hangokat. Be kell tölteni a PC Speaker kernel modulját: modprobe pcspkr. Ezt szállítja a kernel-modules-extra csomag, amibe a cikk eredeti közlése óta átkerült. Ekkor kis szerencsével már hangokat ad a beep, de sudo alól nem szeret hangot adni. Én inkább root felhasználóval belépve kipróbáltam, és működött a nyavalyás: idegesítő sípolást hallatott!

Arra jutottam, hogy a tanácsával ellentétben nem az evdev eszközök jogait fogom beállítani udev varázslattal, mivel úgyis csak bootnál akarom bizgetni, és azt majd a megteszem rootként. Nálam finnyásabbaknak jó szórakozást kívánok az udev bűvöléshez!

Térjünk vissza a kernel modulhoz! Automatikusan be kellene tölteni a gép induláskor. A modern systemd világban ezt a /etc/modules-load.d/*.conf fileokban felsorolt modulokra a systemd meg is csinálja nekünk!

echo pcspkr > /etc/modules-load.d/pcspkr.conf

Ha pedig systemd, akkor nyilván egy service kell a program induláskor futtatására is. Mire is van szükségem? Egy egyszer futó servicere, ami a modulok betöltése, és az ssh indulása után, a multiuser mód előtt fut, egyszer, és nem indul újra kilépése után. Ezt a /etc/systemd/system/beep-after-boot.service file a következők írásával érhetjük el:

# Systemd unit file /etc/systemd/system/beep-after-boot.service
[Unit]
Description=Beep after boot is complete
After=sshd.service systemd-modules-load.service

[Service]
User=root
Group=root
# 100ms 2kHz beep, 100 ms silence (hack: 1Hz beep), 100ms 1kHz beep.
ExecStart=/usr/bin/beep -f 2000 -l 100 -n -f 1 -l 100 -n -f 1000 -l 100
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Ezután már csak a boot folyamathoz kell adni az új szolgáltatást:

systemctl enable beep-after-boot.service

Újraindítás után a gép vidáman csippant kettőt amikor lehet ssh-zni rá! 📯🎉

Újabban ismét többet használok Unixokat, most leggyakrabban Linuxot. Elengedhetetlen társam ebben a tmux terminál multiplexer. Gyakran használom bonyolultabb munkamenetek átlátásához, illetve arra, hogy hosszan futó feladatok egy hálózati problémát is túléljenek.

Amikor megbízható gépekhez csatlakozom, akkor az SSH Agent Forwardingot is használom, mert hasznos, és kényelmes funkció. Persze tisztában kell lenni a biztonsági kockázataival, és azt figyelembe véve szabad csak használni.

Amikor azonban egy új ssh kapcsolattal csatlakozunk egy géphez, és a tmux munkamenethez ismét csatlakozunk, azt vehetjük észre, hogy már nem működik az SSH Agent Forwarding. Ez azért van, mert az új kapcsolat új agent socketet csinált, amin keresztül a távoli ssh a helyi ssh agenttel tud kommunikálni, és a környezetben a korábbi socket elérése található.

Az interneten szétnézve találni erre megoldásokat, amik legtöbbször egy fix helyre symlinkelik a legutolsónak csatlakozó kapcsolat ssh socketjét. Én ezek alapján egy hasonló, de kicsit a saját szájam ízéhez igazított megoldást választottam.

A tmux frissítse a tárolt környezeti változót újrakapcsolódáskor

A tmux támogatja, hogy a környezeti változóit frissítse egy már futó session-nek, így az újonnan nyíló ablakokban induló új shellek már az aktuális értéket kapják.

Ehhez csupán a következőt kell a ~/.tmux.conf fileba írni:

set-option -g update-environment "SSH_AUTH_SOCK \
                                  SSH_CONNECTION"

Ezzel azonban a korábban nyitott shellekből nem fog még működni az agent forwarding, ami kissé kellemetlen.

Futó shellek környezeti változóinak frissítése

Mivel most linuxon tevékenykedek, ezért meg se próbálok úgy tenni, mintha érdekelne a POSIX-kompatibilitás. Inkább valami életszerűbbet, egy Bash shellhez való megoldást mutatok.

A ~/.bashrc fileban a következő függvényt kell létrehozni:

function refresh-env-vars()
{
    if [ -n "$TMUX" ];
    then
        while read env_line;
        do
                eval "$env_line";
        done < <(tmux show-environment -s)
    fi
}

A tmux show-environment -s parancs Bourne shell parancsok formájában soronként kiírja az általa kezelt környezeti változókat, amiket a set-environment, és a korábban látott update-environment parancsaival lehet manipulálni. Ezeket a sorokat az eval segítségével a shell kontextusában lefuttatva frissültek is a megfelelő változók.

💡 Fontos a fent látható Process substitution formátumban kikérni a tmux-tól a parancsokat, mert amennyiben a szokásos parancs | while read ciklus formát használnánk, úgy a while már egy subshellben futna, így a változók értékadásai nem lennének hatással a környezetünkre!

Ezek után egy már futó környezetben csupán a refresh-env-vars parancsot kell hívni, és már működik is az agent forwarding!

Hosszú idő után nem a felhőben, hanem ismét a valódi vasak világában találkoztam régi ismerősömmel, a Linuxxal. Eljött az idő a rendkívül koros Intel Atom alapú házi szerverem ráncfelvarrására, és AMD Ryzen alapokra helyezésére. A régi idők emlékére először a Fedora Linux segítségével próbálom meg feléleszteni a gépet.

Titkosítsunk! Mit és miért?

Ha az ember valódi hardverre telepít, nem a felhőben virtualizálva dolgozik, akkor olyan problémákat kell megoldjon maga, amiket a felhőben már megoldottak a háttérben dolgozó szorgos kezek, és adottságként állnak rendelkezésre. Ilyen a bizalmas adatok hardware selejtezés utáni szivárgásának megakadályozása. Akinek kellett már félig haldokló lemezek szeméttel felülírásával vacakolnia mielőtt selejtezhette volna őket, már biztos elgondolkozott azon, hogy mi lenne ennek a hatékony megoldása. Van aki úthengerre, lángszóróra, vagy kalapácsra szavaz, de mint minden hardveres problémát, természetesen ezt is akad aki szoftver segítségével akarja megoldani: a lemez titkosításával.

Jó pár éve már, hogy olvastam az Apple iPhone telefonokban alkalmazott gyors törlési megoldásában: mivel a teljes háttértárat felülírni soká tartana, ezért a teljes háttértár titkosítva van, csak a kulcs van egy biztonságos tárhelyen tárolva, és a (távoli) törlési kérelem esetén csak a kulcsot kell eltávolítani, így a sok titkosított adat máris hozzáférhetetlen. Ezt a megoldást elég kiterjedten alkalmazzák azóta.

Egy példa: a / filerendszer nem titkosított, így a /etc alatt egy olyan program bizalmas információt (pl. tanúsítványokat) tárol, ami elkerült a rendszergazda figyelmét, aki az általa telepített szolgáltatok általa ismert bizalmas adatait gondosan titkosított tárhelyre helyezte. Ha a teljes lemezt titkosítjuk, akkor minimalizáljuk annak az esélyét, hogy véletlen adatot szivárogtassunk.

Hogy oldjuk fel?

Ha titkosítva van a rendszer, hogyan oldjuk fel a titkosítást a használathoz? Alapesetben egy jelszó a kulcs, amit a telepítés során lehet megadni. A rendszer betöltés korai szakaszában szükséges ezt megadni az initrd scriptek egyike, hogy a root filerendszert fel tudja oldani. Alapesetben egy jelszó-prompt jelenik meg, ahol be kell gépelni a jelszót, hogy a betöltés folytatódni tudjon. Ez egy notebookon megfelelő felhasználói élmény, de egy szerveren nem jó, ha interaktív tevékenység szükséges a konzolon az indítás során.

Több megoldás kínálkozik, a legegyszerűbb, amit alapjáraton is támogat a rendszer, ha egy boot során rendelkezésre álló külső eszközön (pendrive) tárolt kulccsal is feloldható a rendszer.

Az ellen nem véd!

Fontos tudni, hogy mi a fenyegetési modellünk:

• Ha a géphez fizikailag hozzáfér egy támadó, akkor a beledugott pendrivehoz is hozzáfér. Így el tudja indítani a gépet, és a lemezt fel tudja oldani. Azonban, ha fizikailag hozzáfért a géphez, akkor a gép már amúgy sem megbízható többé, más módokon is tudná kompromittálni, és megszerezni a szükséges kulcsokat.
• Ha mindig be van dugva a pendrive, akkor egy megfelelően magas jogokat szerző távoli támadó fel tudja csatolni, és meg tudja szerezni a kulcsot. Ekkor azonban már amúgy is teljes hozzáférése van a géphez, és ekkorra már bármilyen bizalmas adatot meg tudott szerezni.

Mi ellen véd akkor? Ahogy már fent is írtam: Ha a lemezt selejtezzük, többé nem kell aggódni azon, hogy adatot szivárogtatunk róla, mert külön van tárolva a feloldáshoz szükséges titkosítási kulcs.

Lehetséges bonyolultabb, de szűkebb támadási felületet nyújtó nem-interaktív feloldási sémák megalkotása is, például hálózatról letöltött kulcs, amivel pl. betörő ellen védhető a gépen tárolt adat, mert a kulcsforrás feletti ellenőrzés továbbra is megmarad, míg a pendriveot magával tudja vinni a betörő. Ezek azonban számottevő extra erőfeszítést igényelnek.

Sok a rizsa! hogy kell megcsinálni?

Valóban bő lére eresztettem, de a megoldás egyszerűségéhez képest sok macerával járt, mivel sajnos az internetes keresések találatai alapján indultam neki a megoldás keresésének. Így sok elavult, még több gányolt, és számtalan haszontalan tanácsot láttam, sokat ki is próbáltam, de végül tiszta lapról kezdve a dokumentációból dolgozva sikerült megtalálni a következő egyszerű receptet:

Rendszer telepítése

ℹ Az alábbiakat a Fedora 31 verzión végeztem el.

A rendszer telepítése során lehetőség van a titkosítás konfigurálására, ahol a kezdeti jelszót meg kell adni. Így minden partíció, és a swap egyaránt egy LVM PV-be kerül, ami egy titkosított blokkeszközön kerül tárolásra. A titkosítást LUKS segítségével végzi a rendszer.

A telepítés után a rendszer első indításánál a jelszóval kell feloldani a lemezt, hogy a gép betöltsön, és be lehessen jelentkezni.

Jelentkezzünk be rendszergazdaként, majd készítsük el a pendriveot a kulccsal. A lemezt a címkéje alapján fogjuk azonosítani. Lehetséges lenne UUID alapú azonosítás is, ám akkor a drive meghibásodása esetén új filerendszer után több konfiguráció frissítés is szükséges lenne.

mkfs.ext4 -L key-disk /dev/sda1
mount -t ext4 /dev/disk/by-label/key-disk /mnt/
dd if=/dev/urandom of=/mnt/the.key bs=1024 count=4
chown root:root /mnt/the.key
chmod 600 /mnt/the.key

Azonosítsuk a LUKS által használt blokkeszközt:

blkid

Látható a kimenetben, hogy egyetlen crypto_LUKS eszköz szerepel, és a /dev/mapper alatt egy virtuális blokkeszköz van ennek titkosítatlan képével, mely neve luks-<UUID> formát követi. Ebből megállapítható, hogy a titkosított rendszer-partíció a /dev/nvme0n1p2.

/dev/nvme0n1p1: UUID="ad346a3f-115e-4859-912a-ab12d2ec9b7a" TYPE="xfs" PARTUUID="fc06552d-01"
/dev/nvme0n1p2: UUID="e5a1edd8-1e92-4daa-bcf8-3ab26e677e32" TYPE="crypto_LUKS" PARTUUID="fc06552d-02"
/dev/sda1: LABEL="key-disk" UUID="15c0603d-a582-4303-bc10-331a639c2b4b" TYPE="ext4" PARTUUID="dd814dd5-01"
/dev/mapper/luks-e5a1edd8-1e92-4daa-bcf8-3ab26e677e32: UUID="d0prxL-fYml-QPiL-9zBr-624P-w9Kf-3KLTfM" TYPE="LVM2_member"
/dev/mapper/fedora-root: UUID="f58639e1-7369-4244-8751-9f5b0d1ecfc3" TYPE="xfs"
/dev/mapper/fedora-swap: UUID="d6ce8801-e3bd-4dbd-9cf9-3c741dd7c9e4" TYPE="swap"

A partíció LUKS kulcstartójához adjuk hozzá a korábban elkészített kulcsfilet.

cryptsetup -v luksAddKey /dev/nvme0n1p2 /mnt/the.key luks

Ekkor már a kulcsfile képes lenne feloldani a kötetet, de az initrd scriptek futása során kellene ezt automatikusan megtenni. Itt kezdett az internetes források sokasága használhatatlanná válni. Egyes források boot parancssori opciókat javasolnak, de ezek (rd.luks.key, rd.luks.uuid) sajnos nem működtek. Mások kézműves scriptek initrd-be plántálásával dolgoznak, amik szintén nem az igaziak.

A megoldás azonban nagyon egyszerű: a LUKS konfigurációja az /etc/crypttab fileban található. Ezt a filet megfelelően kitöltve, és az initrd-ben frissítve a lefutó scriptek képesek a szükséges filerendszer mountolást, és lemez feloldást elvégezni.

A telepítő által generált file 3. oszlopa, mely a titkosítási jelszót tartalmazza, none értékű, ami az interaktív belépésre kényszeríti az ez alapján dolgozó initrd scripteket. Az alábbi módosításokkal azonban megadhatjuk, hogy a keyfile mely lemezen található, milyen néven, és amennyiben ez nem áll rendelkezésre 30 másodpercen belül, úgy az interaktív belépésre váltson vissza a rendszer.

# /etc/crypttab

#
# this was the original contents:
#
#luks-e5a1edd8-1e92-4daa-bcf8-3ab26e677e32 UUID=e5a1edd8-1e92-4daa-bcf8-3ab26e677e32 none discard

# 
# use file key from the root of the block device identified by its label key-disk, 
# if not found in 30 seconds fall back to interactive password authentication,
# propagate SATA TRIM discard commands
#
luks-e5a1edd8-1e92-4daa-bcf8-3ab26e677e32 UUID=e5a1edd8-1e92-4daa-bcf8-3ab26e677e32 the.key:LABEL=key-disk discard,keyfile-timeout=30

A változtatás érvényre juttatásához frissíteni kell az initrd filet, mert a crypttab abba be van csomagolva. Mivel már létezik a célfile, ezért szükséges a --force kapcsoló.

drakut --force

Frissítések során a telepített újabb kernelekhez automatikusan elkészülnek majd a megfelelő initrd imagek.

Ezen egyszerű megoldás megtalálását kissé megnehezítette, hogy a crypttab manpage a file:blockdevice formátum létezését nem igazán hangsúlyozta, csak egy példában lehetett kiszúrni. Nekem ez csak a sokadik kört futva tűnt fel.

Kész is vagyunk!

Ezzel el is készültünk, nincs más tennivaló, mint újraindítani a rendszert, és a élvezni a munka gyümölcsét!