Credential keresés fájlokban

Fórumok

Üdv,

arról kellene valahogyan meggyőződnöm hogy text jellegű (sh, yaml, forráskód stb) fájlokban van-e olyan string ami valamilyen bejelentkezési adat lehet. Ssh key, API key, plain text password, AWS login adatok, url kitöltött user:pass mezővel stb.

Van valami olyasmi eszköz, mint pl. egy antivírus ami valami adatbázis alapján képes erre?

Vagy?

Köszi

Hozzászólások

szerintem nem kell különösebb adatbázis. egy sor regex a legjobb, noha az is sok false-pozitívot és true-nagtívot fog dobni. gondolj bele, egy akarmilyen "pass=2" sorról egy config fajlban honnan mondja meg bármi is hogy az a jelszó hogy kettő, vagy egy videó konvertálás egyik paramétere. 

tehát én inkább regex gyűjteményre kerenék ebben a témában.


# RSA private key

/-----BEGIN RSA PRIVATE KEY-----/


# URL with credential (at least username) in it

/\b[a-z_]+:\/\/[^/ ]+@/


# AWS IAM identifiers

/\b(ABIA|ACCA|AIDA|AKIA|AROA|ASIA)/

 

api key, plain text password kb minden is lehet, nem igazán lesz benne db-ben. jó, egy haveIbeenPwned adatbázist rá lehet futtatni.

Nem értem a koncepciót.

Ha van egy felhasználónevem, amit ugye te nem ismersz, legyen mondjuk gee, és egy jelszavam, amit te nem ismersz, legyen mondjuk alma, akkor ha nem tudod, hogy mit keresel, akkor elméletileg hogyan találnád meg?

Gondolom, vannak olyan formátumok, amiben van USERNAME= vagy hasonló jól felismerhető mező, amire kereshetsz. De bizonyára vannak olyan formátumok is, ahol nincsenek, csak mondjuk van egy shell script, benne egy here document, amiben éppen az szerepel, hogy:
...
gee
alma
...

Szóval azt értem, hogy esetleg el tudsz kapni egy-két egyértelmű esetet, de arról meggyőződni, hogy tuti nincsen pl. clear text password, az számomra lehetetlennek tűnik (persze lehet, hogy csak valami nem jutott az eszembe).

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

arról kellene valahogyan meggyőződnöm hogy text jellegű fájlokban van-e olyan string ami valamilyen bejelentkezési adat lehet.

Erre szerintem 3 dolgot lehet mondani:

1) nem tudsz meggyőződni* róla, mert nem tudod, hogy mit keresel, tehát hiába találsz meg néhány esetet, más esetekben hiába van ott a bejelentkezési adat, nem találod meg.
2) bármi lehet bejelentkezési adat, tehát ha egy text jellegű fájlban találsz legalább egy karaktert, akkor meggyőződtél róla, hogy van benne olyan string, ami bejelentkezési adat lehet. (Nem biztos, hogy bejelentkezési adat, de lehet az)
3) rossz a feladatkiírás és valami mást keres.

*Szerintem az, hogy meggyőződök valamiről, az 100%-os biztonságot jelent, nem sejtést, meg nem azt, hogy néhány esetre rámutatok.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ez most valami egyetemi beadandó vagy valami elbaszott céges feladat, ami keresztülment a CEO, CTO, Project manager, Architect, Lead Developer láncon és a te segged az utolsó, de a CEO már egyáltalán nem ismerne rá a feladatra?

Azért van a dolognak létjogosultsága. Mindenki tud olyan esetet mondani, amikor egy fejlesztő a verziókövetőbe (lehetőleg olyanba, amiből nem lehet commit-ot visszavonni :D) beküldte a jelszavát véletlenül, mert valaminek a kipróbálásához beleírta a program forráskódjába.

Nyilván nem tökéletesen, de lehet szűrni, pl.: https://rules.sonarsource.com/java/RSPEC-2068

Aaa, ilyen csak urban legendakban van!

 

Nem mondom, hogy dolgoztam olyan cegnel, mert miert mondanek ilyet, de mondjuk azt, hogy hallottam olyan cegrol ahol kiraktak pastebin-re a jelszot. Szerencsere a cegnel ugyanazt a jelszot hasznaltak minden rendszernel, fuggetlenul az ugyfeltol. De az eset ravilagitott arra, hogy ez ross gyakorlat. Ezert korbekuldtek egy xls-t amibe regeneralt jelszavak voltak es arra kellett megvaltoztatni, igy mindenki megnyugodot, hisz az nem fordulhat elo, hogy az az xls kikerul barhova is (nem vedett xls), es igy meg az ugyfelcegek neve is ott lenne a megfelelo felhasznalonev es jelszo mellett.

Na várj, attól függ mit értünk védett alatt. Ha a jelszóvédett munkalapra gondolsz, akkor meg kell nyitni a fájl zip-ként, kikeresni a megfelelő sheet xml-jét, notepadben kitörölni a SheetProtection taget, elmenteni, visszamásolni a zip-be, és kész.

Nyilván, ha mondjuk egy AIP-re gondolsz, akkor valóban. :)

Két külön dolgot csináltatok. Tassadar a teljes excel-t encrypt-eli, azaz jelszavas védelemmel látja el, amit valóban nem tudsz megnyitni úgy, hogy átnevezed .zip -re,  stb.

Gelei féle verzió pedig adott cellát védett le módosítás ellen, nem a teljes excelt. Az ilyen "védelmek" simán kiszedhetőek egy notepad -al akár.

Szerkesztve: 2020. 09. 18., p – 18:39

Nem tudok létező megoldásról, úgyhogy csak néhány ötlet:

  • Lehetne azonosítani a veszélyforrásokat "megfigyeléssel":
    • Pl. naplózni a kommunikációt, és azonosítani mihez kell hitelesítés, illetve ez milyen adatokkal történik. Ehhez szükséges lehet valamilyen "man in the middle" megoldásra (i.e. LD_PRELOAD -dal beinjektálni egy .so -t ami tud titkosítás előtt naplózni). Utána a forrás adatokban lehet célzottan keresni a hitelesítési adatokat.
      A rendszer zártságával lehet kezelni az esetleges érzékeny adatok problémáját.
    • Lehetne naplózni a szkriptek lefutása közben a gépen futó folyamatokat. Ebből azonosítható, hogy mihez kell hitelesítés, ami segíthet a "veszélyforrások" azonosításában. Pl. ha látom, hogy fut ssh, célzottan kereshetem, honnan indul, és hogyan kap hitelesítési adatot.
    • Ha ismered a folyamatokat, tudhatod mihez kell hitelesítés, illetve ezek mivel történnek (pl. SSH). Ez alapján lehet célzottan "támadni" a forrás adathalmazt (szkriptek, json, stb). Sanity check -nek pedig lehet próbálni szigorúan zárt környezetben futtatni a szkripteket, ahol csak az ismert dolgokhoz lehet hozzáférni.
  • Ha kontextusba tudod helyezni az adatot, akkor nem reményételen keresni benne. Pl. egy shell szkriptben lehet tudni milyen parancsoknak kell hitelesítés, és vissza lehet keresni, melyik hogyan kapja meg. Illetve ahol ez nem sikerül, lehet riasztani. "Hopp, egy FTP parancs, azonosítatlan hitelesítési adatokkal."
  • Lehet vaktában lőni, és megpróbálni tipikus problémákra keresni, mint pl. url -ek.

Nezd meg a sonarqube-ot, vannak ilyen szabalyai.

Szerkesztve: 2020. 09. 19., szo – 10:40

Azért a sudoers-t is érdemes néha nézegetni - mondjuk  ilyeneket keresgélve:

www-data        ALL=(ALL:ALL) ALL

Páran felvetettétek, hogy ezt így hogy?

Gondolom, hogy a probléma nem csak nálunk jött elő. Olyan kis cégeket is foglalkoztat a dolog, mint github (Microsoft) meg gitlab:

https://docs.github.com/en/github/administering-a-repository/about-secr…

https://docs.gitlab.com/ee/user/application_security/secret_detection/

Van 1-2 jónak látszó free ill fizetős is pl. https://github.com/zricethezav/gitleaks/wiki/Configuration https://www.gitguardian.com

Ezek közül sokat fel kell configolni rexep-el, de van pár ami by default tud sok mindent.

Köszi az eddigieket!

Nézd, én érzek némi különbséget aközött, hogy

a, mindent is megtaláló credential kereső csodaszoftver, ami mindent is végignéz, aztán meg fél emberév kibogarászni a sok false positive közül a valós találatot, aztán meg nyugodtan hátradőlünk, mert nem tudjuk mennyi a false negative.

b, a CMDB alapján összeállítunk egy véges hosszúságú és kockázatok szerint sorba rendezett listát a szoftvereinkről, majd a dokumentáció alapján ezek credential információit keressük olyan helyeken, ahol az előfordulhat.

Ha tutod, hogy mit és hol kell megváltoztatni :-) meg ha nem production környezetben csinálod, mert ha igen, és amiatt áll meg valami, akkor lehet, hogy a jelszóherélő-cserélő illető lesz nyilvánosan felnégyelve :-)
Néha egyébként nagyon-nagyon hasznos tud lenni az, hogy vannak webes alkalmazásokhoz konfigfájlok, amiben ott van pl. a DB-jelszó :-P

és az jó, ha van egy ember (csapat), aki minden credential-t meg tud változtatni?

Ó, nyilván van egy ember, akinél összeér az összes eszkalációs vonal, na, ő tudja kiadni azt a feladatot, hogy mindenki változtassa meg a hozzáférési adatokat.

De elsikkadt a gondolatmenet másik fele: a hozzáférési adatokat időnként illik megváltoztatni és akkor úgyis kiderül, ha valami nem megy, illetve az, hogy hol van beleégetve. Ha meg valahol más nincs használva, akkor ott maradhat, senkit nem kellene zavarjon.

Attol fugg, milyen kritikussagu rendszereket uzemeltetsz, es kit negyelnek fel, ha az illeto rendszer nem megy. Mivel egy jelszo valtast nem lehet transition modjara vegrehajtani (tehat hogy limitalt ideig megy a regi is meg az uj is), az adott rendszer maintenance window-jai jonnek csak szoba a jelszovaltashoz.

Viszont itt bejon egy masik faktor is: tudnillik, nem biztos, hogy az adott infranak te vagy az elso uzemeltetoje (sot, sokszor nem te vagy). Mondjuk, hogy maintenance window kereteben levaltod az eles jelszot, teszteled, megy faszan, masnap tudod meg, hogy ket masik kritikus rendszer meg amugy orak ota nem megy, mert nem dokumentalt modon azok is ezen a credentialon fuggtek.

Szoval igen, van amikor jobb dontes egy credentialt eveken keresztul ugy hagyni, foleg, ha eleg komplex az infrastruktura ahhoz, hogy atlasd, mi mivel fugg ossze. Es ez teljes mertekben fuggetlen attol, hogy te mennyi ideje dolgozol ott, ot ev utan is tudnak csontvazak kiesni a szekrenybol.

A masik, hogy a beleegetett credentialokat sokszor nagyon nehez megvaltoztatni. Ha nincs meg a forras, ha kulso fejleszto csinalta, ha belsos de mar nem dolgozik ott, es nincs senki a cegnel aki ertene az adot rendszerhez.. ezek mind olyan faktorok, amiket szamitasba, figyelembe kell venni, mielott az ember egyaltalan meghozza azt a dontest, hogy levaltja a jelszavakat. Hidd el, siman van az a szituacio, amikor az a dontes, hogy ezeket a dolgokat jobb nem piszkalni. Nem a legjobb dontes, de ilyenkor mas oldalon kell erositeni a biztonsagot.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

ket masik kritikus rendszer meg amugy orak ota nem megy, mert nem dokumentalt modon azok is ezen a credentialon fuggtek

Ezek nem kritikus rendszerek, különben dokumentálva lenne a credential függésük. Kritikusnak vélt rendszerek, amelyek nem kapják meg azokat az erőforrásokat, ami egy kritikus rendszernek kellene.

Szoval igen, van amikor jobb dontes egy credentialt eveken keresztul ugy hagyni, foleg, ha eleg komplex az infrastruktura ahhoz, hogy atlasd, mi mivel fugg ossze.

Nem, nem és nem. Nem jobb döntés. Kényelmes döntés és segíti a spagetti infrastruktúra tovább burjánzását, ha ilyeneket mindig besöprünk a szőnyeg alá. Szóval tessék betenni a chaos monkey, a toxyproxy és a credential cserélgető botot az éles infrába és akkor nem tunyul el senki abban a hitben, hogy minden fasza, de amúgy senki nem mer semmihez hozzányúlni, mert mi van ha. Hozzá kell nyúlni, munkaidőben és akkor kiderül, hogy mi van ha, és tudod, hogy mihez nyúltál hozzá, nem éjjel csörög a telefon, hogy beszart a cipőbe a kritikus rendszer és azonnal legyen valami, mert különben.

A masik, hogy a beleegetett credentialokat sokszor nagyon nehez megvaltoztatni.

Ha adott időnként cserélni kell, akkor hidd el, hogy nem fogják beleégetni, a harmadik ilyen után úgy kivezetik és ledokumentálják, mint a vöcsök.

Ha nincs meg a forras, ha kulso fejleszto csinalta, ha belsos de mar nem dolgozik ott, es nincs senki a cegnel aki ertene az adot rendszerhez..

Ami kurva nagy üzemeltetési kockázat és szőnye alá söpröd, mert nem nyúlunk hozzá, amíg működik. És amikor nem kezd működni, olyan dolog miatt, amivel kapcsolatban nincs kontrollod, mert egy jelszót azért vissza lehet cserélni, akkor ott fogsz állni letolt gatyával és dobják a földre a szappant. Pedig kiderült volna évekkel korábban, ha cserélgeted az infra paramétereit.

credential cserélgető botot

Elég sok enterprise céggel volt kapcsolatom, egyetlen helyen láttam ilyen megoldást: központi vault szolgáltatás, ami minden jelszót kezelt.
Értsd úgy, hogy periodikusan megváltoztatta az AD account-októl kezdve a local DB account-okat és a PROD Azure Service Connection-ök PAT-jáig mindent IS.

Mivel egy jelszo valtast nem lehet transition modjara vegrehajtani (tehat hogy limitalt ideig megy a regi is meg az uj is)

/etc/pam.d/<service> -be:

# Clients still using the old password
auth            sufficient                      pam_pwdfile.so pwdfile=/etc/shadow.old

# Standard Unix authentication
auth            required                        pam_unix.so nullok_secure use_first_pass

 

Nyilván nagyon sok szolgáltatás nem használ PAM-et, de azért nem teljesen lehetetlen.

Tervezési szempont manapság, főleg mobilos környezetben, hogy nincs ráhatásod arra, hogy mikor fog a tisztelt felhasználó frissíteni, ezért nem lehet például holnap UTC 06:00 credential-t úgy cserélni, hogy a régi nem megy még valameddig és főleg igaz ez az API verziózásra, hogy több verziót kell támogatni egyszerre egy időben.

Viszont annyira el vannak néhol kényelmesedve, hogy meg se értik ennek a szükségességét, ami szomorú annak a fényében, hogy a loose coupling tervezési minta már nagykorú.

Tervezési szempont manapság, főleg mobilos környezetben, hogy nincs ráhatásod arra, hogy mikor fog a tisztelt felhasználó frissíteni

... ezért nem lehet például holnap UTC 06:00 credential-t úgy cserélni , hogy a régi nem megy még valameddig

Én nem látom az összefüggést a mobilos fejlesztés deployolása és a jelszóváltás között, vagy esetleg valami kontextusba tudnád tenni, hogy a hozzám hasonló élességű kések is megértsék? :)

főleg igaz ez az API verziózásra, hogy több verziót kell támogatni egyszerre egy időben.

Ez sem tűnik jelszóváltásnak.

Én nem látom az összefüggést a mobilos fejlesztés deployolása és a jelszóváltás között, vagy esetleg valami kontextusba tudnád tenni, hogy a hozzám hasonló élességű kések is megértsék? :)

Mondjuk úgy, hogy eléggé elterjedt, hogy csak egy adott credential ismeretében tudsz API-t hívni, akárki gyütt-ment nem tudja meghívni az API-t. Ha meg credential-t cserélsz, legyen az bármi, akkor biztosítanod kell, hogy a régi is működik egy ideig.

Ez sem tűnik jelszóváltásnak.

Credential volt említve, nem jelszó; hozzátenném, hogy a kontextus a tervezés során való loose coupling gondolkodásmód volt.

Mondjuk úgy, hogy eléggé elterjedt, hogy csak egy adott credential ismeretében tudsz API-t hívni, akárki gyütt-ment nem tudja meghívni az API-t. Ha meg credential-t cserélsz, legyen az bármi, akkor biztosítanod kell, hogy a régi is működik egy ideig.

Szóval a user authentikálja magát egy API-ba, miért kellene központilag megváltoztatni a jelszavát (periodikusan)?
Vagy valami shared credential-re gondolsz, ami kliens oldalon meg van osztva?

Szóval a user authentikálja magát egy API-ba, miért kellene központilag megváltoztatni a jelszavát (periodikusan)?

Nem a user, hanem az alkalmazás. Jelenleg mobilok esetén, ha átlagos fejlesztést nézünk és nincs is saját API, akkor is 6-8 credential van kezelve, különféle rendszerekhez való hozzáférés okán, ha pedig van saját API, akkor pláne. Elterjedt módszer, hogy a kliensek egy credential ismeretében férnek hozzá funkcióhoz, verziónként új credential kerül kiállításra, amivel az adott mobil kliens képes a szerver adott funkcionalitását a neki megfelelő adatstruktúrával használni.

Vagy valami shared credential-re gondolsz, ami kliens oldalon meg van osztva?

Nagyon nem vagy benne a mobil fejlesztésben, ugye?

A "ha valami nem megy, majd szólnak" a probléma. Szóval a jelszócserénél _előbb_ felmérni, mi kommunikál például az adott DB-vel (adatkapcsolati ábra a prod. rendszerekről), azok hol és hogyan tárolnak jelszavakat, és utána megfelelően tervezett módon végigtolni a jelszó cseréjét. (Példa: Postgres+EDB+PGPool kombónál a technikai user(ek) jelszócseréje - mondjuk úgy, hogy nem triviális elsőre, hogy mit, hol és hogyan,milyen sorrendben "illik"/kell cserélni...)

^ Ez. Vicces egyekbent, ahogy Franko megmondja a frankot, de az a baj, hogy 10+ ev uzemeltetesi tapasztalata mondatja azt velem, hogy ez egy sokkal komplexebb dontes annal, mint "ha nem valtoztatnak jelszot, el kell jonni attol a cegtol". 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Jajj, már megint azok a komplex rendszerek. Ha pedig elsőre nem triviális, akkor tizedikre már az lesz. Vagy pedig le lesz dokumentálva. Minden más üzemeltetési kockázat, amit lehet azzal rejtegetni, hogy kurva komplex komoly kritikus rendszerünk van, amelyiket bla-bla-bla. Lófaszt. Egy tál megpenészedett spagetti van, amihez senki nem mer hozzányúlni és tovább penészedik.

Ez az a hozzáállás, amikor haját tépve vörös fejjel mondta az auditot végző nagyonokos ember, hogy rcp meg ftp tilos... Aztán amikor meg lett neki mutatva az az 1ft hosszú kábel, ami két, a lezárt rackszekrényben egymás fölé beépített gép között volt, és amin az a két khm. problémás protokollt használták, akkor azért megnyugodott picit...

ott van pl. az, amit felhoztam: Postgres Enterprise DB, EFM meg PGpool. Azok a technikai postgres userek, amiket az EFM meg a pgpool hazsnál, azok csak és kizárólag a fürt tagjain belülről jöhetnek (pg_hba.conf), csak arra kellenek, hogy a node-ok tudjanak egymással beszélgetni. Ezeknek példának okáért én nem biztos, hogy forszíroznám a cseréjét - legfeljebb akkor, amikor éles üzemre átveszi az üzemeltetés a szállítótól.
Az alkalmazások pg-s usereinek a jelszava az elvileg más kérdés, de ott is csak óvatosan szabad eljárni - pont DB-hozzáféréssel volt olyanhoz szerencsém, hogy havonta egyszer használt alkalmazás is turkált a DB-ben, és hiába figyeltük heteken át a forgalmat, hogy honnan kapcsolódnak _még_ az adott DB-hez, nem derült ki - aztán lett belőle szaladgálás...
Sajnos a való életben bizony a dokumentáltság, az adatkapcsolatok részletes és naprakész leírása... mondjuk úgy, hogy az setek 9x%-ában csak közelíti az általad feltételezett szintet - és nem, nem éles rendszerkomponens bedöntése a jó módszer arra, hogy a hiányosságok kiderüljenek.

Sztorikat mesélni én is tudok napestig, de ettől még nem lesz jobb a helyzet.

És de, akár az éles bedöntése a jó módszer erre, különben mindenki szépen megszokja, hogy mindent szabad, az élesnél úgyis tojáshéjon lépked majd mindenki, amitől csak annyit történik, hogy évekkel később tapossa laposra a visszaguruló szargalacsin az akkor épp ott dolgozókat, akiknek lövésük se lesz arról, hogy mi merre hány méter.

Chaos monkey, toxiproxy és rendszertelen időnként IP cím váltás, crendetial csere, cert csere... ha ezt túléli a teszt és az éles, akkor fasza a rendszer. Ha nem éli túl és különféle hibák keletkeznek, akkor tele van üzemeltetési kockázattal és csak a szerencse meg a megszáradt szar tartja egyben az egész foshalmot.

A "jajj, mi lesz akkor, ha" hozzáállás egy nagyon rossz hozzáállás, mert hagyja tovább penészedni és burjánzani a penészedő és burjánzó spagettit.

Figyi, nagyon konnyu fotelbol chaos monkey-ezni, de azert amikor sokmillios kar van az eles rendszer bedontesebol, es az a feladat, hogy akkor ezt most ki kellene csengetni,akkor bizony mindenkinek hirtelen eltunnek az elvei a balfeneken. Es innentol valahogy teljesen gusztusos lesz a peneszes carbonara is.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Figyi, nagyon konnyu fotelbol chaos monkey-ezni, de azert amikor sokmillios kar van az eles rendszer bedontesebol, es az a feladat, hogy akkor ezt most ki kellene csengetni,akkor bizony mindenkinek hirtelen eltunnek az elvei a balfeneken.

Nézd, ha a chaos monkey és társai bedöntik és sok milliós kár van ebből, akkor ott komoly gondok vannak, amelyek mind be vannak söpörve a szőnyeg alá. Akkor nem kell kicsengetni, amikor egy instabil és bármitől hanyatt boruló rendszer leállásából van sok milliós kár?

Igen nagy különbség, hogy a "toljunk rá egy káoszmajmot" az _szándékos_ tevékenység, méghozzá egy _stabilan_ de hiányosan dokumentált rendszer működését vágja haza. Ugyanis attól, hogy bizonyos beállítások, credential-ok összefüggése nem ismert minden érintett számára/nincs teljes egészében ledokumentálva még a rendszer betonstabilan tud működni.
Te a "golyóbiztos" (plusz az utolsó bitig részletesen dokumentált, és a dokumentáció alapján minden üzemeltető számára tökéletesen ismert rendszerek) irányt képviseled, mi meg többen azt, hogy "ha működik, ne piszkáld".

méghozzá egy _stabilan_ de hiányosan dokumentált rendszer működését vágja haza

Nem, nem stabil, hanem erősen instabil, de éppen labilis egyensúlyi helyzetben van. A működését nem az vágja haza, hogy ha kicsit is meglököd, akkor felborul, az csak megmutatja a rendszer létező gyengeségeit, amivel bármilyen külső ingerre reagál.

Ugyanis attól, hogy bizonyos beállítások, credential-ok összefüggése nem ismert minden érintett számára/nincs teljes egészében ledokumentálva még a rendszer betonstabilan tud működni.

Lófaszt tud betonstabilan működni. Betonstabilan működik, amíg a környezete változatlan és mivel ugyanazok és/vagy ugyanúgy üzemeltetik, ezért a környezete is olyan, hogy betonstabilan működik, amíg nem változik körülötte semmi, de ha hozzá kell nyúlni bármihez, akkor senki nem mer hozzányúlni, mert bármilyen változástól hanyatt esik a rendszer random része random idő elteltével. Ez nem egy betonstabil rendszer jellemzője, ez az instabil rendszerek jellemzője.

Te a "golyóbiztos" (plusz az utolsó bitig részletesen dokumentált, és a dokumentáció alapján minden üzemeltető számára tökéletesen ismert rendszerek) irányt képviseled, mi meg többen azt, hogy "ha működik, ne piszkáld".

A golyóbiztosnak nem kell utolsó bitig dokumentálva lennie, ha mindenféle üzemszerű stressz teszteket gond nélkül elvisel, de mivel a fejlesztési és üzemeltetési módszertan része a chaos monkey, toxiproxy és társai, ezért a kritikus rendszerek kritikus részei bizony le vannak dokumentálva. Nem alibiből a triviális részek, hogy legyen meg kilóra a dokumentáció, hanem jól felfogott érdekből a problémás és szopatós részek, mert a triviális részeket nem kell dokumentálni.

A "ha működik, ne piszkáld" egy rettentő káros üzemeltetési filozófia, függetlenül attól, hogy mennyien vallják ezt az elvet. Ha nem mersz hozzányúlni, mert mi lesz ha, az üzemeltetési kockázat. Ha egy véletlenszerű eszköz véletlen időpontban történő újraindulása megborít bármit is, akkor ott nem a reboot a probléma, hanem az, hogy ettől bármi megborul. Persze, ezzel szembe kellene nézni, hogy egy foshalmazt üzemeltet az ember, pedig azt a látszatot kell fenntartania kifelé, hogy egy komoly és kritikus rendszert üzemeltet felelősségteljesen, pedig csak futsz mindig oda egy vödör vízzel, ahol éppen nagyobb a tűz. Persze, lehet azt is kommunikálni, hogy egy véletlenszerű eszköz véletlen időpontban történő újraindulása egy incidens, arról készülnek papír hegyek, pecsét, aláírás, fejléc, és minden megy tovább. Na, ezek azok a helyek, amelyeket el kell kerülni.

Az tudott dolog, hogy x, y, z komponens megborulása X, Y, Z mértékű problémát/kárt okoz. Ha megborul. Te azt mondod, hogy tesztelni kell _szándékos_ borogatással, én meg azt, hogy a problémát majd kezeljük akkor, ha bekövetkezik, de ne idézzük elő éles környezetben _szándékosan_. Én pl. még nem láttam olyan külső sérülékenységvizsgálatot, ahol azt mondta volna a megbízó, hogy a feltárt sérülékenységet tessék kihasználni és megborítani a rendszert.

Éles környezetben nem a probléma lehetséges _következményének_ hanem a problémának a bemutatása, feltárása kell legyen a cél. És pl. arra, hogy "egy credential-t hol használunk még" nem a káoszmajom, meg a credential lecserélése, és "ha valakinek fáj, majd szól" az üzletileg elfogadható megoldás, hanem az, hogy felderíteni a logokból, a hálózati forgalomból, a dokumentációkból és az üzemeltetők/alkalmazásgazdák tudásából, hog ymilyen kapcsolatok vannak, hol van még az adott hozzáférés használatban (és miért?), és amikor ebből az iterációból nem jön ki újabb felhasználás, akkor jöhet a kockázatelemzés, hogy szükséges-e ennek a cserélgetése, vagy maradhat fixen beállítva.

 

Te azt mondod, hogy tesztelni kell _szándékos_ borogatással, én meg azt, hogy a problémát majd kezeljük akkor, ha bekövetkezik, de ne idézzük elő éles környezetben _szándékosan_.

Igen, ezt hívják stressz tesztnek, akár éles üzemben is, mert hát ott is tesztelni kellene. Előszeretettel el szokták hagyni, mert anélkül is "működik". Csak amikor bekövetkezik az, amit az el nem végzett stressz teszt kimutatott volna, akkor megy a papírral nem védett seggek keresése a cégen belül, hogy kit basszanak meg.

Idéznék a Chaos monkey első mondatából, kiemelés tőlem: "Chaos Monkey is responsible for randomly terminating instances in production to ensure that engineers implement their services to be resilient to instance failures."

Én pl. még nem láttam olyan külső sérülékenységvizsgálatot, ahol azt mondta volna a megbízó, hogy a feltárt sérülékenységet tessék kihasználni és megborítani a rendszert.

Nem külső sérülékenységvizsgálatról van szó, hanem egy papíron kritikusnak jelölt rendszer (tudod, amire azt mondják, hogy x perc állás y millió forintos kár) stressz teszteléséről, hogy ne legyen x perces állás sem, ha már kritikusnak van jelölve.

Éles környezetben nem a probléma lehetséges _következményének_ hanem a problémának a bemutatása, feltárása kell legyen a cél. És pl. arra, hogy "egy credential-t hol használunk még" nem a káoszmajom, meg a credential lecserélése, és "ha valakinek fáj, majd szól" az üzletileg elfogadható megoldás, hanem az, hogy felderíteni a logokból, a hálózati forgalomból, a dokumentációkból és az üzemeltetők/alkalmazásgazdák tudásából, hog ymilyen kapcsolatok vannak, hol van még az adott hozzáférés használatban (és miért?), és amikor ebből az iterációból nem jön ki újabb felhasználás, akkor jöhet a kockázatelemzés, hogy szükséges-e ennek a cserélgetése, vagy maradhat fixen beállítva.

Ezektől sehol nem lett megoldva a probléma, csak kilóra lett írva belőle papír meg észrevétel és tonnányi levelezés, száz liter bubis víz, ötven kiló pogácsa, fél emberév végigunatkozott meeting, aztán minden maradt ugyanúgy és a következő menetrend szerinti eszközhalál ugyanúgy okozott x perc leállást és y millió kárt és kezdődött előlről minden.

Ha a rendszer szerves részévé teszed azt, hogy bármelyik komponens újraindulhat, leállhat, elromolhat, belassulhat, hibázhat, akkor működni fog, mert üzemszerűen fel van rá készítve a rendszer. Nem évente egy BCP teszt van, amiről mindenki tud előre fél évvel és előtte egy hónappal megáll az élet, mert mindenki a BCP-re készül, hanem bármikor bekövetkező hibákra van rutinszerű és/vagy automatizált élő BCP folyamat, és tényleg nem áll meg semmi.

Olvasnivaló: https://en.wikipedia.org/wiki/Chaos_engineering

Ahhoz az adott rendszer _valamennyi_ komponensét, kapcsolatát, működését már a tervezés kezdeteitől úgy kell kialakítani, hogy elviseljen egy ilyen tesztet. Lehet, de drága lesz - nem kicsit, hanem nagyon. És még csak Oracle sem kell hozzá (azzal ugyanis nem "nagyon drága", hanem "qrvára nagyon drága" lesz) :-)
És a legtöbb helyen nem ilyen "zöldmezős" meg "pénz nem számít" rendszerek vannak, hanem örökölt, mondjuk úgy, organikusan kialakult rendszerek vannak, amikben van spof nélküli rész is, meg olyan is, amiből csak egy van, és tudottan nagy su@r lenne abból, ha megállna nem tervezetten, nem megfelelő időszakban. (Pl. egy jelentéskészítő rendszer, ami havi/heti jelentéseket büfög ki magából nagyon nem jó, ha a havi jelentés gyártása/összeállítása idején elhasal - de némi túlórával túlélhető.)

Amikor csak lehet, úgy kezdem a tervezést, hogy ne legyen spof lehetőség, de vagy szoftveres oldalról, vagy budget oldalról jönnek az alkudozások, a vágások, és azoknak az ismert és tudott(!) üzleti kockázatai. Tudjuk, hogy fájna, ha az xyz szerver megállna? Igen, tudjuk. Kipróbáljuk élesben, hogy mi lesz, ha megáll?  Ha van olyan felelős _vezető_ aki rámondja az áment, hogy az éles környezet xyz elemét leállítva szimuláljuk annak kiesését, hát lelke rajta, de nekem az a meglátásom, hogy elég tudni, hogy mit okozhat, kipróbálni nem igazán szükséges Éles, üzleti környezetben. (DR-tesztet sem úgy csinálunk, hogy az elsődleges környezetet kikapcsoljuk...)
 

Ahhoz az adott rendszer _valamennyi_ komponensét, kapcsolatát, működését már a tervezés kezdeteitől úgy kell kialakítani, hogy elviseljen egy ilyen tesztet.

Nem, nem lesz drága. A drága az, amikor a staff naphosszat egy-egy vödör vízzel rohangál tűztől-tűzig és nem jut ideje arra, hogy a tűz okát megszüntesse.

És a legtöbb helyen nem ilyen "zöldmezős" meg "pénz nem számít" rendszerek vannak, hanem örökölt, mondjuk úgy, organikusan kialakult rendszerek vannak, amikben van spof nélküli rész is, meg olyan is, amiből csak egy van, és tudottan nagy su@r lenne abból, ha megállna nem tervezetten, nem megfelelő időszakban.

Meglepő módon ezeknél a rendszereknél számít a pénz. Pont azért terveznek így és nem csak papíron vannak kritikus rendszereik, hanem a valóságban is. Csak meg kell nézni a cégneveket, akik használják.

Amikor csak lehet, úgy kezdem a tervezést, hogy ne legyen spof lehetőség, de vagy szoftveres oldalról, vagy budget oldalról jönnek az alkudozások, a vágások, és azoknak az ismert és tudott(!) üzleti kockázatai.

Akkor ezeket ne nevezzük kritikus rendszernek, ahol x perc kiesés y millió kárt okoz, mert akkor bizony ezek akkor állhatnak, ha épp úgy hozza a sors. Kezeljük a helyén az üzleti kockázatokat, nem kell vállalni négy-kilences rendelkezésre állást, amikor a budget 95 százalékot fedez, akkor ki kell mondani, hogy ez 95 százalékot fog hozni és ha megáll, akkor majd megjavítjuk a jövő héten, tetszettek volna többet fizetni.

Tudjuk, hogy fájna, ha az xyz szerver megállna? Igen, tudjuk. Kipróbáljuk élesben, hogy mi lesz, ha megáll?

Az egész onnan indult, hogy nem tudod, hogy mit okoz, most már pontosan tudod?

Ha van olyan felelős _vezető_ aki rámondja az áment, hogy az éles környezet xyz elemét leállítva szimuláljuk annak kiesését, hát lelke rajta, de nekem az a meglátásom, hogy elég tudni, hogy mit okozhat, kipróbálni nem igazán szükséges Éles, üzleti környezetben.

Ilyen helyeken mindenki védi a seggét, a rendszer meg néha megborul, aztán incidens, meeting, papír hegyek, marad mindig a régiben, business as usual.

Csak tudod, meg fog borulni változatos módokon, ha csak gondolatban van lejátszva a borulás. Ha jó a rendszer, be mered vállalni a káoszt, ha szar, akkor nem, mert mi lesz, ha. Ez, amit művelsz, az szimplán egy beismerés. És ezt szerintem te is tudod, csak magyarázkodsz, hogy miért szar.

Figyi, nagyon konnyu fotelbol chaos monkey-ezni, de azert amikor sokmillios kar van az eles rendszer bedontesebol, es az a feladat, hogy akkor ezt most ki kellene csengetni,akkor bizony mindenkinek hirtelen eltunnek az elvei a balfeneken. Es innentol valahogy teljesen gusztusos lesz a peneszes carbonara is.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Dev, majd teszt környezetben kell kezdeni. Riport minden héten a menedzsment felé. Akinek a cucca eltörik, csak top vezetői jóváhagyással mehet élesbe. 

Nagy blama ám minden héten magyarázni a főnöködnek, hogy miért képtelen egy reboot vagy jelszó csere után elindulni az alkalmazásod, miközben a cég másik felének sikerült ez a gyakorlat.

Ha _legalább_ az UAT felépítése teljesen azonos a prod. környezettel. De szerintem te is láttál már olyat, hogy prod-ban DB-fürt (RAC, EDB, akármi), UAT-ba meg standalone DB-szerver. Innentől kezdve van olyan credential, ami UAT-ban nem lesz ott, prod-ban meg igen.
"Zöldmezős" rendszerépítésnél lehet erre figyelni, hogy minden _is_ dokumentálva legyen, de meglévő örökölt környezetben nagyon sokáig csak a tojásokon sétálós hozzápiszkálás marad.

Erre igy hulyeseg keresni. Barmilyen string lehet bejelentkezesi adat. Mondjuk, hogy az a jelszavam, hogy "CREATE TABLE IF NOT EXISTS" es innentol talaltad meg az osszes SQL strukturat a Gitben. 

Olyasmire erdemes keresni, hogy "AWS_SECRET_KEY", "password", "username", "login", "hostname", stb. tehat konkret biztonsagi ertekek megadasara, es az osszes szoba joheto ertekadasi formulara (/password\s*[=:]+\*/ peldaul egy ilyen regexp). 

Amugy erre fel lehet kerni kulso cegeket, akik megkeresik neked, mert 8 oraban azzal foglalkoznak, hogy vegigolvassak a kodot, es kiszurjak benne a beleegetett / belecommitolt jelszot. Ennek az alternativaja, amikor egy dedikalt ember vegzi ezt a cegen belul. Ennel hatekonyabb megoldasod nem igazan lesz, minden mas probalkozassal rengeteg false positive / false negative lesz a rendszerben, es nem lehetsz biztos abban, hogy az osszes credentialt megtalaltad.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-