Na, de térjünk rá a mai témánkra, miért rossz az OpSec-es azaz én? Igen, tudom, hogy azt írtam, hogy rendszergazda vagyok, de emelett OpSec-es is. A rendszergazdák ülnek a legközelebb a tűzhöz. Ők látják meg elsőként a ransom üzenetet is, ha bekövetkezik a legrosszabb. LEL. Szóval én vagyok az OpSec-es IS a cégnél és szeretem ekézni ezzel a témakörrel a kollégákat. Tudjuk jól, hogy feltörhetetlen vagy tökéletes rendszer nem létezik, de azért a házon belül javítható lukakat érdemes befoltozni. A miért is rossz kérdésre meg később választ kaphatunk. A mai napon eléggé kényelmesen indult, nem is gondoltam volna, hogy milyen magasságokban fogunk a nap végén szárnyalni UX vs Security témakörben. A reggeli meeting-en megbeszéltük, hogy mik a task-ok, hogyan tudjuk a jövőben megelőzni ezeket a self-dos eseteket és majd érdemes nem minden egyes billentyű lenyomást beküldeni a szervernek talán. A mai fő task-om az új stateless hitelesítés workflowjának megtervezése volt. Előző pénteken egy kis baráti megbeszélés konklúziójaként fogalmazódott meg, hogy az eddigi megtervezett statefull autentikációt kukázzuk, mivel a fejlesztők nem fognak tudni rá értelmesen fejleszteni. Nagy vidámsággal és örömmel álltam neki a feladatnak. Egy ismételt megbeszélésen körvonalazódott a sokat átrágott és megemésztett, majd ismételten megrágott téma, végre a UI department tudott engedni a gyeplőn, így csak minden weboldallal indított interakciónál kell aláírni manuálisan digitálisan a kéréseket. Ha ha ha. Ez az, végre valami biztonságos és még nehezen használható, ezt nektek! (Gondolom ez a kép alakult ki rólam a túloldalon).

5:50-kor elhagytam a bázist, mentem a fizetős “továbbképzésre”, Keleti Arthur magánestjére. Előadás közben jön a notification, hogy nagy baj lenne-e, ha a nonce-ot csak opcionálissá tennénk, ha nem küldenek be nonce-t, akkor nem ellenőrizzük. Mondanom se kell, hogy milyen jó érzés, mikor egy magán elfoglaltság űzése közben megerőszakolják a kisdedemet, az általam tervezett hitelesítési rendszert. Nice.Aki nem tudná, hogy mi az a nonce, annak röviden annyi, hogy egyszer használható érték. De miért is csinál D3v azaz én belőle ekkora ügyet, hogy ki merik belezni a nonce-t a hitelesítési rendszerből? Ez is jó kérdés, viszont ezt egy kicsikét hosszabban fejteném ki.Szóval adott egy üzenet, amit szeretnénk aláírni digitálisan. Ekkor a aszimmetrikus kulcsú vagy nyílt kulcsú kriptográfiát vehetjük segítségül. A privát kulccsal aláírjuk az üzenetet és a publikus kulccsal meg validálni tudjuk.

Na de mi van akkor, ha azt szeretnénk elérni, hogy csak 1x lehessen azt az üzenetet felhasználni? Ha van egy backend logikánk, akkor az hogyan tudja eldönteni, hogy többször került-e beküldésre ugyan azon tartalmú kérés? Ekkor jön végül is segítségül a nonce. A backend legenerál egy kriptográfiailag biztonságos pszeudorandom szám generátorral készített nagy entrópiájú értéket, amelyet letárol egy adatbázisban vagy a memóriában és visszaad a kliensnek. A kliens mellékeli ezt az aláírandó üzenetbe, majd a digitális aláírás után visszaküldi a szervernek. A szerver ellenőrzi, hogy a digitális aláírás érvényes-e, azután, hogy a nonce megtalálható-e az adatbázisban. Ha igen, akkor kitörli onnan és végrehajtja a kérést. Ha nem, akkor elutasítja a kérést. Egyszerű nem? Na de miért baj, ha nincsen benne? Azért, mert akkor elég 1 db kérést megszereznünk, hogy onnantól kezdve korlátlanul tudunk garázdálkodni a backenden. A project manager és/vagy a UI department arra fogta ezt a döntést, hogy ne legyen annyira bonyolult az API-nk. Szegény fejlesztőknek egy plusz kérést kell végezni a backend felé, ezzel elrettentjük őket az alkalmazásunkra fejlesztéstől. Na, persze erről is meg van a véleményem, de ezt nem osztanám meg veletek, főleg mert nem tűr biteket(nyomdafestéket). Röviden és határozottan a következőt írtam a Discord chat-re: “Nem nem nem nem nem nem nem nem nem és nem.”A beszélgetést végét azzal zártam, hogy majd megbeszéljük, ha visszaértem. Az előadásra visszatérve, érdekes volt, viszont kevés volt benne a technikai tartalom szerintem. Előadás után mentem nyomatni 1000-el a networkinget, beköszöntem az előadónak és elbeszélgettem vele egy kicsikét. A rendezvényközpontot otthagyva és a bázis felé közeledve nem is gondoltam volna, hogy milyen meeting fog következni ezután, Jeeeeez!

“Én teremtőm! mért is értem E napot?”

Na, megérkeztem, kényelembe helyeztem magamat, majd belekezdtem a mondókámba. Miért kellene kiszedni a nonce-t? Mert a jövőbeni fejlesztőknek nehéz lesz meghívni még egy kéréssel az API-nkat? “Összezavarodnak, hogy most 1 kérést akarnak küldeni, de akkor most 2 kell?” Igen, kettő kell, mert máshogy nem kapják meg a nonce-t. “De az infura-nál is csak 1 secret van és az nem változik, örökre ugyan az marad.” Ha mások szarul használják a rendszerüket, akkor használjuk mi is szarul? “Mondjál egy példát, hogy mikor nem lenne biztonságos ez? Mi lenne ha a fejlesztőknek a saját döntése lenne, hogy beleépítik ezt a nonce-t vagy nem. Arról már nem mi tehetünk, ha ellopják vagy megszerzik az aláírt üzenetet.” Na ekkor égtem ki és emeltem fel a hangomat. Ne már egy olyan ember beszéljen a security-ről és zsonglőrködjön a felhasználók adataival, aki nem tudja megkülönböztetni a stateless és a statefull hitelesítést egymástól. Hát persze, hogy mi tehetünk erről, mivel mi nem követeltük meg szigorúan ezen fajta védelmi mechanizmust ebben az esetben.

Sajnos nem tudtam olyan érvet mondani, amit nem vétóztak volna meg, pedig nagyon nagyon nagyon akartam. Miért ennyire negatív az OpSec-es, miért csinál ilyen felesleges round-trip-eket, miért erősködik, miért nem jó az, ami most van, miért járjon le a secret, miért kell ilyen bonyolult dolgokat beleépíteni a rendszerbe? Ugye milyen irritáló ez az OpSec-es!A security az a kategória, mikor a legrosszabbra készülünk fel. Ezért se szeretik az emberek/fejlesztők/felső vezetők/senki se az IT security-s arcokat, mert mindig olyan negatívak, paranoidok stb stb. Még az édesanyámtól és még a párjától is már megkaptam azt, hogy paranoid vagyok a magánéletemben. (Tisztázzuk azt, hogy van miért félnem, láttam, hogy mi hogyan működik (vagy nem) az állami rendszereknél és hogy hogyan dolgozik az elhárítás… Na, de már túl sokat is mondtam. Glownigger trigger)

Szóval rendesen kaphatja az ember az ívet, hogy miért kell ezt beépíteni és szükség van-e rá. Azt persze tiszteletben tartom, hogy a használhatóság nem mehet teljesen a biztonság rovására, de könyörgöm, ez már tényleg megerőszakolása az egész szakmámnak, ha egy random magát fejlesztőnek tituláló arc egy jól megírt example alapján nem tudja működésre bírni a faék egyszerű API-t. Nevermind. Végtére is én csak egy rendszergazda vagyok(mivel ez van írva hivatalosan a munkaszerződésembe), ezt szépen közöltem is a kollégákkal, ha gyakorlati edge case-eket szeretnének látni akkor van sok profi auditor cég, akik nagyon sok pénzért rá tudnak mutatni ugyan erre a problémára, amit én is felvázoltam. Hát persze, hogy ezt se szerették volna hallani a számból.

Szóval és tettel elkezdtem nagy idegességemben turkálni az egyik “kompetitorunk” alkalmazásában, hogy ők végül is hogyan csinálják azt, amit csinálnak. Végül is arra a következtetésre jutottam, hogy a timestamp-et használhatjuk arra, hogy invalidáljunk régi/használt kéréseket, viszont nem ad akkora védelmet mint a nonce, mivel itt egy időintervallumban érvényes csak az adat. Ekkor már vérszemet kapott az egész UI department és már ki akarta szedni az egész rendszerből a nonce-t és csak timestamp-et szeretett volna használni. Mondjátok, hogy átérzitek a monitoron keresztül a fájdalmamat, ugye? Ilyenkor ténylegesen mit tud tenni az ember? Na, mind1, ezt már lógva hagytam és a továbbiakban beérkező kérésekre az alábbi lvl 1000-es counter spell-t alkalmaztam: “Nem tudom”. Ez a világ legerőteljesebb varázsmondata az IT szakmában. Mint ahogy a fentiekben említettem, dolgoztam állami cégnél. Ott aki ezt a mondatot nem tudta alkalmazni, annak dolgoznia kellett. Aki megfelelően tudta ezt utilizálni, az kellemesen töltötte semmittevéssel a napját, napjait és meg merem rizikózni, hogy akár az éveit is! Szóval a múltamból előhúztam ezen technikát, na és tökéletesen működött! Az este további részében tanulmányokat nyálaztam át és vadul kutattam az interneten, hogy találjak egy silver bullet-et a problémámra(vagy egy valós lövedéket plusz fegyvert olcsón, ha ha ha), de nem nagyon találtam semmit se. Kb itt tartok jelenleg most, remélem szebb és biztonságosabb lesz a holnap.

Szurkoljatok nekem!

Patcheljetek sokat!

Korán kelés, reggel egy kis családi program, majd be a melóba. Az előző napi történésekre nehezen emlékeztem vissza, nem tesz jót a 4 óra alvás, na de mind1. A mai fő taskom a domainek átcserélése, mivel problémánk adódott a hitelesítéssel. Az a fránya cookie store, hogy mer rendeltetésszerűen működni!!! Miért nem fogad el más domainről jövő cookie-kat. Igen, igen tudom, utána mi is rájöttünk. Fátylat arra az elvesztegetett fél napra! Meg is kezdtem nagyban az előkészülgetést, konfigolgatást. Duplikáljuk az openresty konfigot, hogy ha gond van, akkor gyorsan tudjuk rollback-elni. Ezt vegyük ki belőle, ez sem kell, szerintem ez se, ezt ide, azt oda…. Mondanom se kell, néha én is elveszítem a fonalat, hogy pontosan mit csinálok. Közben megérkezett kedves senior/lead dev kollégám is és örömteljesen tudattam vele, hogy lehet, hogy megint el fogom törni a prod-ot. Mondhatnom se kell, hogy mennyire örült ennek. A UI fejlesztőkkel is felvettük a kapcsolatot, hogy lassan kellene majd egy maintenance is a weblapra! Minden rendben ment, amíg át nem kötöttem a domain-eket. Puff egy 502

Tudni illik rossz és lusta rendszergazda vagyok és ez egy tény! Sok proxy-t, webszervert és a kettő ötvözetét próbáltam már ki, de mindig valahogyan oda jutottam, hogy vagy a szoftver szar vagy a teljesítménye rossz vagy egyszerűen nem tudod, hogy éppen kit tiltott le, mert túl sok 404-et kapott az illető (bunkerized-nginx, érdemes kipróbálni, de ne reméld, hogy meg fogod tudni, hogy tényleg kit sikerült fekete listá… akarom mondani tiltó listára tenned). Szóval arra a következtetésre jutottam, hogy az utóbbi 3 hónap szívásaiból tanulva egyszerűen rakjuk az backend-et a CloudFlare mögé és ha már úgy is domaint cserélünk, akkor kössük össze a hasznosat a hasznossal. Hogy mi az a CloudFlare? Ez egy nagyon jó kérdés! A szakmai ismerőseim csak ClownFlare-nek becézik, illetve a megtestesült gonosznak is. Képzeld magad egy 3 betűs állami szervezet helyébe. A plebs már TLS-t használ szinte minden weboldal meglátogatásánál. Hogyan tudnád ezt a fajta enkapszulációt lefejteni szépen az adatfolyamról anélkül, hogy ne kelljen valós kvantumsebességű kvantumszámítógépet spawnolnod a semmiből? Hát adjál ki egy “védelmi” szolgáltatást ingyen, amely közbeékelődik a kliens és a szerver közé, megbontja a titkosítást és azt ígéri, hogy megvéd téged minden fajta DOS/DDOS támadástól, még WAF-ot is ad mellé. Na, röviden ez a CloudFlare. Jó kis MITM.

502, Bad Gateway hirdeti vidám sárga színekkel a CloudFlare. Ekkor már teljesen elborult az agyvizem, arról nem is beszélve, hogy rátett még egy lapáttal a hirtelen felerősödő imposztor szindróma is. Mi lehet a baj, mi lehet a baj, mi lehet a baj? Vadul csapkodom a kommandokat a terminálomba. Újraindítom a konténert, leállítom, ismét újraindítom és ismét leállítom. Gyorsan megnézem a logokat, de a konténerizált kis alpine based image-el rendelkező openresty-m boldogan jelenti nekem az stdout-ra, hogy minden rendben. 4-5 perc ideges debug után, persze miközben állt az egész infra lel, megtaláltam, hogy mi a baj. Hát nem kitöröltem az upstream definíciót a konfigból, gondoltam úgy sem kell. Ha ha ha. Gyorsan visszaírtam a portot, hogy hová kell neki pontosan mutatnia. Érdekes, rögtön megjavult minden is. Egy szolgáltatásnál még át kellett írni az env-ben a domaint, meg ad-hoc feldobni egy reverse proxy-t is, mert persze, hogy elfelejtettem, de utána minden rendbe jött.

Na pörög a prod api! Juhééé! Trigger lvl 100 UI wizard: Hi, mehet ki a rendes weboldal. Jött is rá az ack. Elkényelmesedettem a székemben és ebben a nagy kényelemben elkezdtem nyomkodni a CloudFlare-t. Pár perc után jött egy resp, hogy nem fordul a Vercelen a PWA-s frontend. Az illetékes kolléga már el is kezdte a debug-ot. Hát nem kiderült, hogy a CloudFlare azzal a mozdulttal, hogy végül is átengedtem a teljes backend api-nk forgalmát letiltotta a node-fetch user-agent-tel érkező klienseket. Hatalmas “szerencsénkre” ez pont a build által használt tool volt. Ha ha ha! Egy gyors fix után már gyönyörűen fordult a weboldal és a JAMStack fekete mágiájának köszönhetően már kint is volt a weboldal. Pfuh, kész, juhé!

A következőekben volt pár köröm az új all-in-one dev szerver megfelelő beállításával kapcsolatban, de az tényleg elhanyagolható. Túl hosszú lenne elsőre ez a cikk, ha még azt is leírnám(meg már vagy 02:28 van, aztán reggel meló).

Ezután pihenés képen egy kis magán programon vettem részt, leállítva minden idő pontos mérőjét a clockify-t. A programom végeztével visszatértem már a második otthonomnak titulált irodába és vad részletekbe menő beszélgetésekbe kezdtem a kollégáimmal. A téma a CORS volt, ebbe most nem annyira szeretnék belemenni, max egy másik bejegyzésben. Konszenzusra jutásunkat viszont hirtelen megszakította a hír, miszerint nem megy a prod Discord runner.

Minden probléma megoldható, ha megfelelően állunk neki a probléma gyökerének felderítéséhez. Na, itt ez a tétel mondat pont nem volt igaz. Érdekesen nem válaszolt a Discord runner egyes kéréseinkre. A háttérben elsunnyogva hirtelen becsuktam az éppen szerkesztés alatt lévő WAF ruleset-et. Egy finom kis hang megszólalt a fejemben: Basszus, már megint mit sikerült eltolnod? Jóindulatból beszálltam a velem együtt három fős debugger csapatba, hogy megtaláljuk a probléma gyökerét ÉS ELPUSZTÍTHASSUK AZT EGYSZER ÉS MINDENKORRA!!!!!!!! Spoiler alert: Hát ez egy jó 3 órás round-trip volt.

Először és megnéztük, hogy jó-e az infra. Hála az égnek jó volt. Működött a backend és a Discord runner közötti kommunikáció is. Pfú, egyre jobb. A kedves lead kolléga megállapította, hogy nem válaszol a Discord a kiküldött kéréseinkre, de így egyáltalán nem. A biztonság kedvéért a try catch mellé még egy adag console log-ot is belehegesztettünk, de hát így sem akarta a jót. Teszteltük, hogy megy-e a ping a discord felé, hát ment. Curl-el rápróbált a kérésre a gépén, utána a szerven is, a szerveren nem kaptunk választ. 2 óra szenvedés után feldobtam, hogy csinálok egy snapshot-ot a VPS-ről és elindítom egy másik példányban. Szerencsére a szolgáltatások közötti kommunikáció biztonságossá tételét WireGuard-al oldottam meg, szóval csak tényleg annyi volt a teendőm, hogy systemctl stop wg-quick@runner aztán meg a másik hoston systemctl start wg-quick@runner. Az élvezetek hajszolása csak most kezdődött. Itt az indulásnál dobott egy hatalmas error-t, aztán minden command interaction-nál meg összeszarta magát a bot és újraindult. A hibaüzenetre rákeresve csak nested issue-kat találtunk, amelyek egymásra mutogatva próbáltak konzisztens megoldást adni, persze sikertelenül. Nice, ennél már csak jobb lehet, ugye? Hát….. nem. Szerencsétlen próbálkozási kísérleteink sorban kudarcot vallottak. Mindent kipróbáltam már eddigre, ping, mtr, tűzfal szabályok újraírása, MINDENT! Azon is gondolkoztunk, hogy rate-limitet kaphatunk, de nem. Felmerült az is, hogy lehet, hogy több példányban fut valahol a bot, ezért forgattunk Discord API secret-et is. NOPE!

Milyen érzés eset 23:00-kor a cégnél bent ülni és meghegeszteni a product-ot, ami legalább 10000 user-t kezel a Discord-on? Nem, annyira, jó. Legyünk pozitívak, legalább 3-an szálltunk csatába az ádáz bug-ok ellen a javascript hátborzongató tengerén! Viccből feldobtam, hogy indítsuk el a lead gépén docker nélkül a kódot és a WireGuard-al csatlakoztassuk fel a backend-re. A megfelelő beállítások migrálása után elindítottuk a kis M1-es laptopon a product-unk egyik fő komponensét és ami ekkor jött, az hideg zuhanyként ért bennünket… Elindult és működött!

Ez meg hogyan? De tényleg hogyan? Ne már, NE MÁR NEEEE MÁÁÁÁRRRR! Ez egy vicc! És működik, tényleg működik? De hogy? ???????????????????????????????????

23:40-50 Főnököm - Akkor most hagyjuk itt a gépedet nyitott állapotban és holnap megjavítjuk valahogy!

Már felkészültünk rá, hogy a laptopról fog menni egész este a prod, persze WiFi-ről! Gyorsan megnyitottunk egy 200 órás YouTube videót meg egy Twitch stream-et. A legrosszabbra próbáltunk felkészülni. Utolsó megoldásként megpróbáltam, hogy egy teljesen tiszta VPS-re felhúzni az alkalmazást, egy teljesen másik adatközpontban persze. Szokásos terminálban való kalimpálózásom után sikeresen migráltam minden szükséges komponenst. Eljött az igazság pillanata. x86_64 vs ARM, AMD vs Apple, szimmetrikus gigabites uplink vs Telekomos delmásdobozos 20 Mbps-os upload.

Most vagy soha!

Elindult a drága és még működött is! Nem firtattuk tovább a helyzetet, becsuktuk gépeinket és elhagytuk az objektumot.

P.S.: Ide a végére beszúrok egy elköszönést, remélem tetszeni fog ez az unrelated kis szlogen :

Patcheljetek sokat!!!!