A kérdés a témában megfogalmazva: van-e használható real-time antivírus Linuxra?
Eddig eggyel van tapasztalatom, az ESET antivírusával, ez korábban nagyon fasza volt, de megszűnt a desktopos Endpoint Antivírus, ami meg helyette lett, az növesztett egy rosszul konfigurálható, még rosszabbul működő, és Linuxon le egyáltalán nem tiltható tűzfalat. Őszintén, eddig több problémát okozott, mint amennyit megoldott.
Ami érdekelne
- Mennyire fogja meg a gépet egy nagyobb (10-100G állomány) és egy közepes (100M-5G) állomány mozgatása esetén?
- Használod-e virtualizációval, konténerizációval, ha igen, milyennel, és mik a tapasztalatok?
- Server vagy Desktop termék? Van GUI-ja?
- Van belőle otthon használható verzió vagy csak céges? Mindkét megoldás érdekel!
- Ha van céges, tud központi policy-t vagy valamilyen könnyen export/importálható szabályrendszert (pl CSV-be ki tudom exportálni mire ne ugorjon rá)?
FONTOS! Légyszi, kizárólag a fenti kérdésekre keresek választ, elsősorban saját tapasztalatot, kifejezetten valamilyen Linuxon is működő antivírus termékkel.
Ha nem használsz antivírust, ha úgy gondolod hogy nem kell, ha az a véleményed, hogy rossz nyomon járok ezzel a kérdéssel, akkor köszi szépen, hogy idáig elolvastad, de ne válaszolj.
20 éve dolgozom Linuxszal, én tudom hogy kell bánni vele, soha, semmilyen biztonsági incidensem nem volt sem Linuxszal sem Windowsal, de most van 1-2 olyan ok, ami miatt mindenképpen kellene használni valamilyen antivírust (előírás), nem opcionális, nem átugorható, és mocskosul rohadtul senkit nem érdekel az, hogy mennyire vagyok képzett. Ez egy checkbox, ki kell pipálnom, de ha már szopni kell vele, valami olyan megoldásra vágyok, ami mellett dolgozni is lehet. És mindenképpen real-time védelemmel kell rendelkezzen.
Hozzászólások
Nálunk VMWare-ben futó Ubuntu szervereken ESET Antivirus fut, valósidejű védelemmel.
https://www.eset.com/us/business/download/endpoint-antivirus-linux/
+1 az ESET-re. Nalam ugyan ez a felallas, csak homelab-on. Nincs vele gondom.
Ahogy írtam, nálunk a konténerizációval inkompatibilis.
Blog | @hron84
via @snq-
Kockázatelemzés alapján csak ahol nagyon kell, ott legyen, de ez szerintem nem új dolog - ahogy az sem, hogy az IOPS-ot nagyon meg tudja khm. nyesni - nvme -> ATA szintig akár...
A topic felvető pont erre a válaszra volt kíváncsi. jah nem..
Szerintem reszben idetartozik:
Foleg a nvme -> ATA sebesseg resz az eredeti kerdesek kozott adott kerdesre reszben vegulis valasz.
Raadasul sikit a topikrol a scope: compliance.
Compliance tekinteteben van a torveny, vannak a cegek, akik a torvenyt hol jol, hol pedig tul szigoruan ertelmezik. Ebbol adodoan vannak az elvileg torvenyre es szerzodesekre, gyakorlatilag torvenyek es szerzodesek felreertesere (altalaban tul szigoru ertelmezesre) felepitett ceges policy-k. Sot, vannak auditorok, es meg azok sem egyformak, es azok is sokszor keptelenek egyforman ertelmezni a szabalyokat.
Ami "X" multinal compliant volt (Linux + virusirto, de nem realtime), az "Y" multinal nem lesz az (belso policy alapjan real time-nak kell lennie), "Z" multinal sem (belso policy alapjan folyton be is kell kapcsolva lennie), es "W" multinal sem (ahol meg ceges policy hogy az IT csak Windows-ert es macOS-ert vallal felelosseget, Linuxozni el lehet takarodni masik munkaltatohoz). Es kozben audit szempontbol lehet, hogy "W", "X", "Y" es "Z" is ugyanugy SOX compliant, ISO compliant, stb. a nap vegen.
Köszi, a compliance kérdésekkel tisztában vagyok, majd felteszem az illetékesnek, ha oda jutunk. Egyelőre szeretnék választási lehetőségeket, amik jelenleg nincsenek, és így oda sem tudok állni valaki elé, hogy szia, ez a három van, nézzük meg, melyik compliant. Nem vagyok antivírus guru, Linuxon pláne, rengeteget segítenének működő, kipróbált terméknevek, amikből aztán majd választhatunk.
Nem véletlenül tettem fel úgy a kérdést, ahogy, nem véletlen a végén a figyelmeztetés sem.
Blog | @hron84
via @snq-
Symantec Endpoint Protection: https://techdocs.broadcom.com/us/en/symantec-security-software/endpoint…
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Milyen környezetben használod/használjátok, milyen az általános élmény vele kapcsolatban?
Blog | @hron84
via @snq-
Kaspersky eleg jo linuxon, mi azt hasznalunk a szervereken... bar ha Compliance miatt kell akkor vszinu felejtos :)
Több gyártó/termék is van zsákban, de ide TrendMicro-t ajánlanék.
Csak jó viszajelzések jöttek - "hardcore" linux üzemeltetőktől is.
Hány végpontra kellene?
Ha érdekel keress meg privátban, tudok segíteni.
A Trendmájkróból pontosan mit? Mert van nekik olyan motyójuk is, amitől gatya lesz a legmacsóbb hardver is... Mert ugye mindenbe _is_ belenyúl, beleolvas, és nem gyorsan, de legalább lassan...
Ahogy fentebb is írtam, megfelelő kockázatelemzés nélkül mindenhova nagyon nem jó ötlet ilyesmit fullosan felpakolni, és ahova fel is kerülnek, ott is jól kell bánni a kivétellistákkal, mert alapból nagyon gáz tud lenni...
Az az erős sejtésem, hogy NIS2 megfelelés a cél, ott meg sajnos nincs sok minden, amit "kockázatelemezhetnél".
Az _alap_ szintnél is ez követelmény (18.8).
Pont.
Ez is jogászi fa$$ág, már bocsánat... Egy nagy terheltségű, IOPS-ra kihegyezett (local nvme) DB-szerveren, ahova csak és kizárólag az alkalmazásszerverek a DB-hez, és szűrt, védett helyről az adminok SPS-en vagy hasonló eszközön keresztül ssh-n mehetnek be, milyen valós értelme van minden fájlműveletet megnyammognia egy realtime sz@rnak? Ha meg kell, akkor szépen ki kell exclude-olni mindent _is_, ami a DB működéséhez kell, a /usr/lib/* -gal kezdve...
Ez nagyjából olyan egyébként, hogy "ftp, rcp, rsh tilos" - amin fennakadt az auditor, hogy a-b géppár között így mentek az adatok, így dolgozott a fürt, és azt mondá, hogy nem, scp, ssh kell. Aztán amikor a személyijét bekérve kértünk neki egyszeri belépési engedélyt az érintett gépterembe, és kísérettel megmutattuk neki az érintett gépeket tartalmazó, lezárt szekrényt, és abban az 1 feet-es kábelt, amin az érintett forgalmak mentek, na akkor elgondolkodott, hogy az a fizikai védelem, ami van, az valóban elégséges, nem szükséges logikai védelmet is rápakolni az adott forgalomra.
Senki nem mondta hogy nem az, de itt ezt a feladat.
Tudom - ahogy írtam is, az exclude listát kell jól megcsinálni - akkor nem fáj nagyon... Egyébként meg igen...
Lehet h. neked (és még sok embernek) ez a realtime antivirust jelenti minden gépre, de sztem nagyon nem.
"Meghatározott időközönként átvizsgálja a rendszert, és valós időben ellenőrzi a külső forrásokból származó fájlokat a végpontokon, a hálózati belépési vagy kilépési pontokon a biztonsági szabályzatnak megfelelően, amint a fájlokat letöltik, megnyitják vagy futtatják."
Ha pl. egy Linuxos API szerverről beszélünk, ami csak információkat (nem fájlokat) cserél a klienseivel, akkor mindjárt tök más a szitu. Azért ezeket a kontrollokat értelmezni is kell, elolvasni 2x és utána kell tenni olyat, ami megfelel az ebben leírtaknak.
És soha 1 db _file_ sem kerül fel sehogyan sem arra gépre?
Mert itt a kontroll nem egy futó üzleti szolgáltatásra vonatkozik, hanem magára gépre.
Hogy patch-eled pl?
De egyetértek, el kell olvasni és értelmezni a leírtakat. :-)
+ a kérdező is konkrétan filemozgatásokat említett példaként a topicindítóban
"Hogy patch-eled pl?"
A javítócsomagok ha jól rémlik :) aláírt fájlok, ergo azt a kulcskarikát, amin az ellenőrzésre használt kulcs van, azt kell kiemelten védeni, akár úgy is, hogy a módosítása azonnali riasztás váltson ki. A saját fejlesztésnél is olyan kontrollokat kell a folyamatokba beépíteni, hogy a saját fejlesztésű alkalmazásba kártékony kódot a folyamat során (build, teszt, deploy) észrevétlenül ne lehessen beleinjektálni. (kiemelten védett repository, build környezet, aláírt bináris, stb.)
Szeritned pl. a Solarwinds-es incidens esetén (megvan?) a backdoor ami frissítéssel kiment, nem volt aláírva?
Az aláírt bináris lófaszt nem jelent, csak azt, hogy a gyártó aláírta. Azt, hogy nincs benne kártékony kód, nem jelenti.
Én értem, hogy meg akarunk bízni mindenkiben, de még neves gyártóknak is kompromittálódtak már belső rendszerei, és kerültek ki szándékolatlan kódok. Én egy biztonsági rendszertől elvárom, hogy egy védett repositoryból származó cuccra is ránézzen, ha azt nem én védtem be. Mert utólag lehet panaszkodni a gyártónak, hogy szart küldtetek, de a szar által generált fost nekem kell összetakarítanom, abban nem segítenek. És kitörölhetem a seggem a kárpótlással - ha ugyan adnak.
Blog | @hron84
via @snq-
"És soha 1 db _file_ sem kerül fel sehogyan sem arra gépre?"
Karanténon keresztül pl. És ott "van idő" az oda került fájlt ellenőrizni, vizsgálgatni, szétcincálni - mert az a feladata a karantén gépnek. (oda meg úgy kerül, hogy a karantén húzza le valahonnan az ismeretlen megbízhatóságú fájlt, azaz oda _tolni_ nem lehet semmit)
Itt nem az volt a kérdés, hogy tudsz-e olyan elméleti scenario-t mondani ami szerined OK és nem kell, hanem hogy a gépen kell lenni egy ilyen alkalmazásnak - konkrétan: milyen legyen az.
Az auditor erre lesz kíváncsi, nem az okfejtésedre. Ez van sajnos.
Hidd el, ha az a követlemény, hogy legyen valós-idejű vírusvédelem és minden file felmásolásakor _és_ indításakor (ez fontos, mert ez lehet két különböző időpont és az hogy a "karatén" gépen a felmásolás pillanatában "tiszta" volt, nem feltétlen azt jelenti, hogy amikor elindítod az éles gépen, már nem jelezne be, mert pl. a világ/kutatók közben rájöttek hogy sajnos gond van vele)
+ ezek az AV-k már futás közben is nézik (EDR,HIPS funkcionalitás) hogy mit csinál - a karantén gépen meg megfuttatni nem fogod, ha jól sejtem...meg a konfigja se biztos hogy ugyanaz 100%-ra.
Ilyenkor lesz az nvme-ből PATA diszk teljesítmény... Plusz egy-két CPU-mag is elmegy vele - ott is, ahol kizárólag az OS/DB szállítójának aláírt repójából kerül fel bármi is... Ahogy mondani szokás, tapasztalatból hallottam, hogy ez történik...
De szerinted ez tényleg mindig annyira fontos egy IT-s környezetben, ahol a legnagyobb kockázat általában a C és vagy az I, - mert itt az OT/ICS-től eltérően, a CIA modellből nem az A van elöl....
Ezt meg az állapította meg/döntötte el aki a felelősséget vállalja az egészért.
Ha kell, rakat még bele 1-2 plusz CPU-t, mert ha tényleg üzletileg fontos a rendszer ez is még olcsóbb lesz, mint a veszteség ami abból adódhat, hogy szétcsapták, elvitték, meghamisították az adatokat.
De ezt nem a tekik/üzemeltetők döntik el....
És vajon a lokális nvme helyett mit rak a gépbe? Bemegy a Coop-ba venni két kiló húsz deka (kettő harminc, maradhat?) iops-ot? Mert a CPU igényt az ugyan le lehet követni, de ha iops-ban rogy meg egy ilyen eszköz, azt baromi nehéz, hogy finom legyek. Miközben egy olyan valamiről beszélünk, ahova csak és kizárólag ellenőrzött módon/környezetből kerülhet be bármi. Nekem úgy tűnik, hogy a szabály alkotója nem tudott két lépést hátrébb lépni, és rendszerként szemlélni azt, amire szabályokat alkotott, vagy épp abból indult ki, hogy ez egy qrvaegszerűen teljesíthető _és_ vizsgálható pont, -már bocsánat- de a sík hülye aktakukac-szintű auditorok is meg tudják ugrani a "pipálgatós" listájukkal.
Az audiotornak ez a feladata, azt ellenőrzi, hogy ami le van írva, az be van e tartva. Hatásosságot és nem hatékonyságot vizsgál. Max oberservation-t tehet, de kb senkit nem érdekel a véleménye, a szabályzat tartálmára sok ráhatása nincs, az meg a külső-belső követelmények és kockázatok alapján van megírva (jó esetben)
De miért is rogyna össze egy gép egy jól beállított AV-től?
Ha igen, ott vagy nincs jól beállítva az AV vagy a gép van alulméretezve igen csak. Mind a kettő architekturális hiba (secu vagy IT)
+ A kérdező sehol nem írta, hogy csak ellenőrzött környezetből kerülhet be bármi is, sőt ezt igen nehéz teljeskörűen biztosítani egy IT rendszernél, főleg ha a ellenőrzési pontjaidon (többeszám!, mert multlayer-es védelemről beszélünk) nem tudsz minden (pl. viselkedésalapú) ellenőrzést megcsinálni. Erre is van megoldás természeteses- automatikus sandbox integráció - de kevesen mennek ilyen irányba, főleg ha valami miatt csak on-prem-ben gondolkod(hat)nak (>20M a belépő szint)
"Az audiotornak ez a feladata, azt ellenőrzi, hogy ami le van írva, az be van e tartva. "
Listapipáló aktakukac egy jelentős részük sajnos, kis hányaduk értelmes válaszokkal azért még meggyőzhető, hogy adott környezetben az x megoldás, ami nála "nem jó", még bőven lehet jó, bőven belefér a felvállalt kockázat kategóriába. (Tapasztalatból hallottam...)
"De miért is rogyna össze egy gép egy jól beállított AV-től?"
A lényeg a "jól beállított"-on van. Azaz ahogy korábban írtam, jól megírt exclude list kell (kezdve a /usr/lib/* -gal :-P) Alapból viszont nagyon visszafogja a gépet a "mindent is tudó,mindent egyben" csodaszoftver. Mindegyik. Kivéve, ha például a kernelből a legutolsó helyett csak a kettővel-hárommal korábbival tud együttműködni, és rendes gyerekként frissen van tartva a kernel :-) mert akkor egy csomó funkciója (jellemzően azok, amik kvázi láthatatlanul eszik a gépet) nem működik. (Tapasztalatból hallottam ezt is...)
"főleg ha a ellenőrzési pontjaidon"
Bástya elvtársat (akarom mondani bastion host-ot) már el is felejtettük? Oké, két SPS HA-ban csak ssh (csak terminál, scp/sftp/portfwd/egyebek off), csak egy hostra befelé, oda lehúzni tartalmat csak meghatározott forrásokból (aláírt repók, illetve azoknak a szűkített tükrei). Igen, viselkedés-alapú szűrés nincs (éles környezet), de az már régen rossz, ha az élesben kell megfogni egy repóból érkezett, aláírt csomag disznóságát, de akár saját fejlesztésű alkalmazásra is igaz ez. Az UAT-on legyen minden csingilingi _is_, persze az onnan kifelé(!) adatforgalmat ugyanúgy szűrni/korlátozni kell, illetve az ott található adatokat ugyanúgy védeni szükséges, mint az éles rendszert (mivel az UAT jellemzően az élessel megegyező adatokat tartalmaz, kifejezetten hibakeresési céllal).
Továbbra is azt mondom, hogy performancia szempontból jól beállított "mindenes szekus program" eszközt vásároltatni, és listát pipálni lesz jó, de _jól összerakott környezetben nullához közeli értelme lesz.
Ez így van,de tudod hány "jól összerakott" környezetet láttam (az üzemeltető ezt állította, mert mindenre volt benne válasz amire ő gondolt - de csak arra), amin egy PT vagy valós támadás alkalmával úgy mentek/mentünk keresztül, mint kés a vajon? Voltak nagy hallgatások/pislogások ilyenkor.
Mindig csak 1 kis apróság maradt ki és borult össze az egész. És ez cégmérettől kb független volt sajnos.
Ilyenkor a managerek azért kissé el szoktak bizonytalanodni, hogy ez tényleg jól volt így összerakva vagy csak az emberei azt mondták rá.
Ha egy cég eddig nem foglalkozott a secuval (bármi oknál fogva), akkor az majd pont most fog _jól összerakott_ környezetet építeni és üzemeltetni kb. a 0-ról, ahol van SPS, meg minden nyalánkság?
Miből és kivel?
A hálózati/mikroszegmentáció sem megolodtt ezeknél a cégeknél (jó esetben max csináltak 1-2 VLAN-t és azt hiszik az az)
Lehet nekem alkalmazástűzfalam meg webproxym ami mondjuk ellenőriz minden http(s)-en keresztülmenő cuccot, így patchelek pl.
Ugye a NIS2, meg az auditor sem arra megy h. téged megszívasson, tehát pl. az h. az üzemeltetés majd SSH-n felmásolja az MFA bejelentkezésével titkosított kapcsolaton keresztül a rootkit.exe-t, az azért kívül esik az audit scopeján.
Csak azt próbáltam érzékeltetni az adott pont idézésével h. azért az amikor egy security tanácsadó azt mondja h. a NIS2 miatt minden gépre kell fullos realtime védelem, az igazából csak annyit jelent h. ő nem végezte el alaposan a cég és üzemeltetés alapos érdekei alapján a házifeladatát.
Pont ez a lényeg, hogy teljesen mind1 legyen, hogy a file hogy kerül oda, ott és akkor ellenőrizve legyen, nem csak statikus szignatúra alapján.
Nem csak sikeres ssh auth után kerülhet fel egy file a gépre - tudnék mesélni, hogy a ~20 év alatt milyen ügyeink voltak....
Ha meg van ilyen védelem a gépen, akkor nem kell körberaknod mindeféle, szerinted jónak vélt megoldással, incidens esetén meg pingvinezni, hogy de szerinted ez így OK volt. Asscovering.
+ A NIS2 esetében pont ez a gond, hogy a cég érdekei vastagon le vannak sz.rva. A legutolsó rendszerre is a 164 kontrollt hoznod kell.
Az az ISO 27001, ahol erre tekintettel tudsz lenni.
Nem, a lényeg az az egy szó h. "külső forrásból". Nem szeretnék hajbazer lenni, de sztem egy picit túlgondolod. Persze, ki lehet pipálni így is, meg pl. úgy is h. van egy scannelt repo mirrorom, integritás és vírus ellenőrzéssel. Akkor az már nem külső forrás mikor a szomszéd gép lehúzza a mindenféle védelmen keresztül odakerült deb-et (v. rpm-et, vagy exet)
Integritást ugyan tudsz nézi, de ha a hülyeség a fejlesztőnél került bele cseszheted - lsd. solarwinds
Nincs pl. központi konfiguráció-managemented, backup-restore folyamatod, git-es forrásod, egyedileg fejleszett alkalmazásod, ahol jön a fejlesztő egy azonnali javítással pl,...?
Vagy ezek is mind így, a secure "mirror-on" keresztül kommunikálnak a gépeddel? Nem életszerű.
+ Ezeken felül a "nem file alapú" támodásokkal szemben is védtelen a géped, mert a mai AV-k már ezt is tudják alapból. A mirroron viselkedés alapú check-ed nem lesz, mert nem lesz megfuttatva azon a gépen semmi.
Nagyon speciális, jó kontrollált környezet esetében működhet (az első auditig biztosan), de tipikusan most akikre ráborult ez a NIS2-es dolog, nem ilyen cégek.
Örülnek, ha a napi üzemeltetést el tudják látni és hidd el egyszerűbb feltenni egy AV-t az 1 szem linuxos-mindenes szerverére, normálisan beállítani és pipa, mint secure web gatewayt, meg secure repo mirrort csinálni, mert rögtön jön a kérdés, hogy ok, de azt ki fizeti és ki fogja üzemeltetbni és mitől lesz tényelg "secure" és minden esetet lefedő?
Meg ki fogja biztosan meggyőzni az auditort is erről majd?
Szerinted egy 50-70 USD-s AV miatt, ki az a vezető aki felvállaja ennek a kockázatát egy ilyen cégnél, ahol a secu eddig se volt fókuszban?
Hát mesélj.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Mi valahogy így csináltuk:
- belső mirror RedHat-tól
- ha kell patch vagy külső program akkor azt átnézték mehet e
Ezeken a lezárt szervereken nincs routing internet felé, ez alap.
Windows alatt szelidítgetni kellett a WFBS-t, mikor utoljára használtam olyat, erősen ajánlott volt a kivételeket jól megfontoltan beállítani, mert még az ERP klienset is visszafogta.
Több termék, ja, de biztos, hogy real-time, aktív vírusirtóról beszélünk? Mert én még nem futottam bele olyanba Linuxon, és nem véletlen, írnám a topikindítónak az okát, de előre jelezte, hogy olyan válaszokat nem vár.
Egyébként meg ha compliance, nem is értem, hogy melyik írná elő, hogy aktív, real-time írtó jó csak, melyik szabály, szabályzat zárja ki a hagyományos passzív irtókat, mint a ClamAV és társai. Mindenesetre, ha egy cégnél ez a merev, Windows buzi szemlélet van, hogy csak aktív vírusirtó, meg stb., azoknak ajánlani szoktam akkor, hogy a Linuxot inkább hanyagolják, kell egyfajta szemléletváltás hozzá, mivel nem Windows. Nem kell őket valóban győzködni a vírusirtók feleslegességéről, mert ha ilyen szemlélettel mennek neki a dolgoknak, abból csak minden más linuxos területen is gányolás lesz, ami nekik is csak szenvedés. Ezt még home usernek sem szoktam javasolni, hogy ilyen vaskalapos szemlélettel álljon neki a Linuxnak, nagyon keserű szájízzel fogja dobni. Kell egyfajta nyitottság, szemléletváltás, hogy az ember hatékonyan tudja használni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
A clamav tud realtime menni: csak annyi, hogy régen a clamd része volt, most meg külön executable a realtime scanning. Alapértelmezetten csak notify-ol, de nem akadályozza meg a futtatást, viszont ha úgy állítod, hogy meg is akadályozza ("Prevention-mode"), akkor az jelentős performance gondot okozhat, hiszen az access előtt be kell fejeződjön a scanning. De ez minden vírusirtóval így lesz. Engine configjait tudod esetleg állítgatni, hogy csak úgy csináljon mintha csinálna valamit, és akkor gyors(abb) lesz. (Ha csak a compliance megfelelés a cél.)
https://docs.clamav.net/manual/Usage/Scanning.html#on-access-scanning
Wow, ezt nem is tudtam, kösz, hogy felhívtad rá a figyelmem. Akkor a kollégának nem is kell többet keresgetnie. Nincs indok a ClamAV ellen, főleg, hogy csak placebo compliance lesz.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Ha NIS2-ről beszélünk...
Ha tovább olvasod a követleményeket, kiderül hogy:
- valami threat intel-t is használni kell (dinamikus adatcsere IOC és egyéb adatok tekintetében)
- az incidenskezelés rész is támaszt olyan követleményeket, hogy egy XDR-es AV-vel gépenkét kb. 50 USD-ért egyben megoldható normálisan, enterprise szinten a problémakör. És akkor máshonnan (hálózat, tűzfal, proxy,...) érkező eseményekből, korrelálva, viszonylag alacsony false pozitív értekkel, olyan konkrét risztást kapsz, amivel érdemes foglalkozni, nem csak pl az AV nyers eventjeit kapod, - ami vagy secu incidens vagy nem.
Egy cégnél, ahol koráltozottak az erőforrások, nincs secu csapat, SOC,... az is igen nyomós érv, mert az egész NIS2 erre van felhúzva, hogy vedd érsze, kezed és oszd meg/jelentsd! a secu incidenseket. Az auditor ezt is nézni fogja, nem csak hogy fut-e az AV engine a gépeden....
+ ha már telepít, managel (=elb.ssza az idejét vele) egy AV-t, akkor már egy olyan megoldása legyen ami ér is valamit, nem csak úgy néz ki.
Szerintem.....
Értem, hogy ez így van, és nem te találod ki, de akkor is bullshit. Ezekre ilyen öltönyös-nyakkendősök (menedzserek és politikusok) rejszolnak, hogy micsoda 3 betűs rövidítéseket tudnak. Azért te is érezheted, hogy pl. egy full AMD vagy ARM-es linuxos gépre mi a ráknak Intel threat izé. Itt most nem azzal van gond, hogy 50 USD vagy 100, mert cégeknek úgyis telik rá, hanem hogy az egész egy baromság.
Nem véletlen, hogy a nagy, fizetős enterspájz Linux disztrók (RHEL, Oracle, Suse, Ubuntu Pro/Server, de még az Intel Clear Linux és a MS Mariner/Azure Linux) se jönnek vírusirtóval. Secure boot, meghajtótitkosítás, SELinux, stb. adott esetben be van kapcsolva, meg van egy kis hardening itt-ott, de ha megfigyeled, egyik se szállít alapból vírusirtót. A BSD alapú megoldások se, a még támogatott Solaris 10-11 ágakban sincs ilyen. A tárolóikban is max. ingyenes AV van, ClamAV meg társai. Nem véletlen ám, nem hanyagság. Ha ez a sok XDR, IOC izé ennnyire megkerülhetetlen lenne, mér rég kínálnának rá valami piaci rést betömő megoldást.
Értem én, a sok hájfejű, EU-s politikus alkot szabadidejében, mert túl sok idejük van, aztán most nyomják ezt a NIS2-t, meg cybersecurity, és egyéb buzzword-öket, de fogalmuk nincs az egészről. Életükben nem láttak még Windowson kívül semmit, de valaki „szagértő” haver „kályeftélyét” megkérték, hogy „cakkvéleményben” fogalmazzon meg jó kis buzzwordöket, meg jó sok rövidítést, hogy a lobbizó security cégek által kínált, senkinek nem kellő AV/IS szarokat is el lehessen adni, hadd menjen vissza a zsebbe egy kis osztalék.
Értem, hogy a topiknyitó kolléga ettől még kényszerhelyzetbe kerül ezektől a hülyeségektől, de épp ezért javaslom neki a ClamAV-t. Felteszi, kipipálja a compliance-t, ha meg valaki tudálékos ‘csög kötözködik, hogy hol van benne az Intel thread ízé, akkor majd nyomozza ki ő, bizonyítsa be, hogy a megoldás nem ekvivalens. Ez van Linuxra, ez volt elérhető és kész.
Ezeknek a vírusirtóknak egyike sem ér semmit, azt is elárulom. Ha a gépet tényleg vírus fertőzi, annak az első dolga, hogy az AV-t deaktiválja, ha meg nincs fertőzés, akkor meg csak egyfajta pszichológiai biztonságérzetet nyújtanak. Ezeknek a csoda, kernelmodú security cuccoknak sincs értelme, lásd a legutóbbi Crowdstrike botrány, azt a szutykot is felette a sok céges hülye compliance-ból, hogy micsoda extra security layer, és vírust nem is kaptak, valóban, viszont egész ágazatok térdeltek le globálisan kékhalálozások közepette, mikor kijött egy kényszerített, nem tesztelt, bugos frissítés.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
> full AMD vagy ARM-es linuxos gépre mi a ráknak Intel threat izé.
Szerintem az ARM nem véd a vírusok ellen. Oké, hogy az Intel procira fordított ELF bináris nem fog futni rajta, de tudván, hogy már az Amazontól is lehet gyakorlatilag fingért bérelni ARM gépeket, szerinted mennyi időbe kerül egy hackernek lefordítani a szarát ARM-re? Ma már nem az ASM-ben írt hackek korát éljük, a kernel sebezhetősége pedig ARM-en meg MIPS-en is sebezhető lesz. A mai vírusok Go-ban, Rust-ban vagy legrosszabb esetben is C-ben íródnak, és semmibe nem kerül leforgatni őket nem-Intel architektúrára.
> egyik se szállít alapból vírusirtót.
False, szállít, minden disztribúciónak része a ClamAV vírusírtó ilyen vagy olyan módon, méghozzá nem is az extra tárolókban van, hanem az operációs rendszer core csomagjai mellett. Lehet, hogy nem telepíti fel automatikusan, ez valós felvetés, de szállítani szállítja mindegyik. Nem tudom, te mikor néztél utoljára bármilyen Linux disztró csomagkezelőjében körül, de javaslok egy frissítést.
Persze, a ClamAV - eddig - nem minősült real-time víruskeresőnek, de az az állítás biztosan hamis, hogy ne szállítanának a Linuxok vírusírtót.
> Ha a gépet tényleg vírus fertőzi, annak az első dolga, hogy az AV-t deaktiválja, ha meg nincs fertőzés, akkor meg csak egyfajta pszichológiai biztonságérzetet nyújtanak.
Istenem... belegondoltam, hogy 20 évvel ezelőtt valószínűleg én is ennyire naív lehettem, persze azóta kicsit tanultam a szakmámban.
A vírus gépre való felkerülése és az aktív fertőzés között terül el a lappangás tágas időtartománya. A (real-time) víruskeresők feladata éppen az, hogy már a fertőzésig se juthassunk el, egy betokozott, passzív állapotban levő vírus kódját is felismerjük a szignatúra alapján, és ez alapján a felismereés alapján lépéseket tegyünk a fertőzés megakadályozására. Ez olyan, mint amikor látnak egy elhagyot hátitáskát a vonatpályaudvaron, és kiürítik a környékét, majd hívják a tűzszerészeket. Nem azért, mert félnének egy hátizsáktól, hanem hogy ha esetleg abban a táskában egy bomba van, akkor az ne okozhasson sérülést annak a rengeteg ott grasszáló embernek. Ha meg csak két koszos edzőcipő van benne, akkor meg visszaadják a tulajdonosnak.
Blog | @hron84
via @snq-
A "botnet of things" miatt már most van arm-es payload ;)
"Kicsit" bonyolultabb a helyzet, de a NIS2 is benne van a kalapban.
De teljes mértékben egyetértek, még ha van is dedikált secu csapat, nekik is rengeteget segít egy olyan rendszer, ami megszűri a potenciális eseményeket, és nem fogják a fals riasztások elvenni az erőforrást/figyelmet egy-egy valódi fenyegetés kivizsgálásától. Ha nagyon sok a fals riasztás, lanyhul a figyelem is, és esetleg elsiklanak egy valós fenyegetés felett. Ezt már rengetegszer láttam sokkal kevésbé impactful dolgoknál is (monitoring).
> + ha már telepít, managel (=elb.ssza az idejét vele) egy AV-t, akkor már egy olyan megoldása legyen ami ér is valamit, nem csak úgy néz ki.
Igen, pont ezért haragszom nagyon az ESET-re. Nem is csak az a baj, hogy egy kalap szar, mert az egy dolog, de emellé 1) mocsok drága, 2) geci sok idő elment a telepítéssel, a terjesztéssel, a konfigurációval, a hibák nyomozgatásával (volt pár nagyon-nagyon nasty is) és jelenleg azt érzem, hogy a szart pofozgatjuk, és próbálunk egy szarul fejlesztett, végtelenül hányaveti módon támogatott terméket életben tartani. Ennyi pénzért sokkal többet várnék el, mint ami az ESET hibajelző fórumain a témával kapcsolatban megy.
És nem az van, hogy azt mondanák, hogy drágaságaim, ez egy béta állapotú termék, így kezeljétek, nem, ezt eladják éles helyzetbe szánt cuccként. Ez az, ami miatt nagyon el van borulva már az agyam, amikor szembejön valahol a munkámban a gyártó neve.
Blog | @hron84
via @snq-
A secu egy külön szakma. Ha foglalkozol vele, majd idővel belefutsz "real-time" megoldásokba... :-)
Röviden a lényegük: valós időben (on-access) van ThreatIntel bekérdezés, hogy ne a 3 hete frissített(?), statikus szignatúra és reputációs adatokból probálja eldönteni, hogy mi a helyzet.
+ a bennük lévő HIPS/EDR modul által összeszedett viselkedési információk is dinamikusan, a világ történéseinek megfelelően legyenek kiértkelve. Kb ennyi.
És mint írtam, a NIS2 - 18.8 írja elő - el kell olvasni.
Milyen jó is volt, amikor windows-on egy ilyen biztonsági sw-hez kapcsolódó frissítés lerohasztotta a fél világot úgy, hogy konzolhoz menős volt a javítás... De a biztonság fontosabb, mint a rendelkezésre állás... Oh, wait...
Hmm, ez a Trend Micro cég nem nagyon ismerős. Azt tudom, hogy elég régóta foglalkoznak víruskeresőkkel, de mindig ilyen "futottak még" kategória volt a nagyobb nevek (Kaspersky, ESET, McAffee, Avast, stb) mellett.
A végpontok érdekes kérdés, erre majd valószínűleg privátban kitérek, de előbb átfutom a dokumentációját ennek a cuccnak, mert kiváncsi vagyok mit tud. Ha van valami összeszedettebb, kevés körítést tartalmazó feature lista, azt átdobhatnád, nagyon fura az oldaluk logikája. A dokumentációt is csak a Google találta meg.
Másodlagos kérdés, hogy a TM-nek van-e otthoni felhasználóknak is terméke (Linuxra)? Nem véletlenül pedzegettem meg az otthoni felhasználást, szükségem lenne privátilag is ilyesmire, nem csak céges compliance miatt. Ha érdekel, azt is ki tudom fejtni privátban, de most elsősorban a létige is segítség lenne, tényleg nehezen lehet ezen az oldalon navigálni.
Blog | @hron84
via @snq-
Én szeretem a Trend Microt adtak nekem rootot a TP-Link Archer AX50-en ;)
Mondjuk lehet az oem baszta el.
A top mezőnyben van jó pár éve, a többi (említett) erősen a futottak még kategória hozzá képest.
https://resources.trendmicro.com/Gartner-MQ-EPP-2024.html
A weboldal egy kicsit kusza, volt pár intergráció, felvásárlás,... és nem egyértemű mi hova került/tartozik most.
Privátban kibogozzuk :-)
Mondjuk fura, hogy a crowdstrikeot nem photoshopolták le azután ami történt...
semmilyen platformra nincs
Compliance volt a kerdes, nem a valosag. ;)
Amolyan real time-kent hirdetett / real time-kent plecsnizett "anti"virus a keresett eszkoz. :)
Mint kibic írom, de felturbózott ClamAV-t "eladni" mint real-time AV?
Van is ilyen cucc:
clamonacc(8) — Arch manual pages
Microsoft Defender for Endpoint on Linux
:)
Sok jót nem tudok róla elmondani, de biztosan létezik, fut Linux-on, és a munkáltatóm hisz benne - vagy legalábbis elegendő a checkbox kipipálásához :)
Biztosan nem ingyenes, és hogy megfelel-e a te "real-time" definiciódnak azt nem tudom.
Nálunk ez a céges 'image' kötelező eleme.
zrubi.hu
Ez csak akkor nem illegális, ha Edge-dzsel, Powershellel, Windows watermak for Linux, Zoom, Teams, webes Office 365, Gambas, MS-SQL, .NET core, Visual Studio Code, Copilot kíséretében használod Linuxon :D
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Aki ezt a checkboxot megkreálta, informatikus volt. Nem politikus, nem jogász, nem szántóvető.q Igénytelen, a saját maga által bizonyára ismert normákat semmibe vevő szakember. Valahol a legalja.
Vagy nem, csak ész nélkül a NIST 800-53-at beemelte a jogszabályba. (NIS2)
Informatikus be tud emelni dolgokat jogszabalyba? Az nekem uj. Nem is tudtam, hogy mar torvenyalkotok is vagyunk. Mostmar akkor minket is szidni fognak, mint az orszaggyulesi kepviseloket? :)
Persze, mikor készült igen és meg is tették valószínű. Nem "bárkit" kérdeznek meg róla, de volt olyan informatikus, akit igen. Az lehet hogy nem a legjobbat, de ez van. :-)
A "policy" nem tudom hogy jött ide, ez jóval magasabb szintem ki van mondva, mint követelmény.
Ebből magadnak írhatsz policy-t (és alábontva procedure-t, process-t és work instructions-t) felelőségi körökkel,...de ezt, mint "alap" besorolású EIR-ekre vonatkozó követelmény nem szedheted ki belőle. (NIS2-ről beszélünk)
Ez az egyik nagy különbsége az ISO 27001-től.
(For the record: Policy-s reszt azota toroltem, mert rajottem, hogy elsore felreertettem a kommented egy reszet, de te mar arra reagaltal)
Szerintem az ilyesmi demoralizál, pont ott üti meg a szakmát, ami a legfontosabb lenne, mert az igényességet pusztítja. Nem csak arról van szó, hogy milyen informatikus volt, aki beletette (vagy benne hagyta) hanem ezzel a normával aztán szükségszerűen rengetegen dolgoznak tovább, mert a norma munkaeszköz kellene legyen és az ilyesmi minden résztvevőből kiöli a racionalitást. Meg kell csinálni és kész.
Hajlott koromnál fogva én már megengedhetem magamnak, hogy hasonló helyzetekben kirúghassam a széket magam alól azzal, hogy a faszomat. Csinálja meg akinek három anyja van. De más sajnos nem ilyen szerencsés.
Teljesen egyetértek.
A NIS2 tekintetében pont olyan privát cégekre is rátolják ezeket a kontrollokat, akik eddig valamiért úgy gondolták (és akár lehet igazuk is volt) hogy nekik nem kell ilyen szintű - a valós, saját kocázatokat figyelmen kívül hagyó - egyen secus kontrollkörnyezet. Vagy csak nem votl rá pénzük. Ez az ő kockázatuk/üzleti döntésük és ennek így is kellett volna maradnia. Az alap szint bevezetése is meg fogja ölni őket vagy alibizés lesz csak.
El lehet képzelni milyen szuper projektek lesznek ezekből (se valós igény és/vagy se pénz)...csak pipáljunk. Az IT-s üzemeltető is csak azt nézi majd, hogy hol tud keresztbe feküdni.
Emiatt van, hogy én is úgy döntöttem inkább kimaradok ebből és ezeket a nagyszerű "bevezetéseket" meghagyom másnak :-) Max tool-t adok el, ha valakinek pont ez kell...
Friczy kedvéért egészen halkan jegyzem meg, hogy lehet, hogy ez azért van így, mert még nem értünk a végére. Annak idején az ISO is így kezdődött, de ma már simán elküldöm az ISO-s szakembert, ha olyat merne megkövetelni, aminek nincsen meg a vállalat életében a racionalitása. A dolog átalakult, ami értelmes az ISO-ból, ami hasznos, azt úgyis meg kell csinálni, a norma inkább segítség, mint leküzdendő akadály. A felelőtlen faszkalapok, akik pedig annak idején a minőségirányításban basáskodtak, úgy látom egyszerűen eltűntek, kinyírta őket a saját szakmájuk. A norma is ennek megfelelően változott. Lehet másnak máshol más a tapasztalata, én így látom. Talán itt is képes lesz a szakma szembeköpni az igénytelen aljanép informatikusokat. Meglátjuk.
Nekem ne mondd!
6db felhasználónév+ jelszó páros és 2db kétszintű azonosítás után tudok receptet írni, és ez csak 1db program elindítása!
Részben a sok alibizés miatt tartunk itt. Szerintem a közelmúltbeli nagyon komoly secu események hatására keményít be a szabályozó, pont azért, mert nagyon sok cég "úgy gondolja" hogy neki nem kell "ilyen szintű" védelem, aztán megy a meglepett villámpocok nézés, amikor arcul csapja őket a valóság egy nagyon komoly méretű lófasszal. Aztán jön a "nem gondoltuk volna, hogy...". Bro, pont azért vannak ezek a szabályozások, hogy ne kelljen _neked_ gondolkodni, mert vagy szerencséd lesz benne, vagy nem.
Ha az emberek egy kicsit is komolyabban vennék a privacyt és a biztonságot, fele ilyen kemény szabályozás is elég lenne. De nehezükre esik kitalálni egy bonyolultabb jelszót is a Jancsika12-nél, úgy meg azért nehéz bármit is elvárni bárkitől - legyen titkárnő vagy vezérigazgató.
Blog | @hron84
via @snq-
Ebben liberálisabb a nézőpontom. Az államnak épp elég az a feladat, hogy a saját maga által üzemeltetett, fejlesztett rendszereket biztonságossá tegye és olyan normákat hozzon létre, amelyek segítik a védelemben a felhasználót. A szabályozónak nem feladata, hogy segítsen azon, aki ezt nem igényli. Pláne nem úgy, hogy olyan normát ír elő, ami nem racionális. Akit orrba legyint egy zsarolóvírus, annak ez a saját kára és nem másnak kell megvédenie az ilyesmitől, hanem saját magának. Meg az ésszerű normáknak, amelyeket igényes szakemberek állítanak össze, nem felelőtlen disznók. A szálindító téma szerint itt a felelőtlen szabályozó orbitális faszságot írt elő. Ilyesmitől nem javul senkinek a biztonsága.
Hát, akkor úgy. Mondom, valahol a legalja.
Nem. Valószínű valami öltönyös-nyakkendős menedzser, valami üzletpartner miatt compliance-ként felvették követelménynek, ez oké, gondolom céges informatikus se tudott ez ellen tenni. Amit én nem értek, hogy oké, compliance, vírusirtó Linuxra is, de miért kell feltétlen aktív irtó. Aki ezt erőlteti, az nem érti, hogy hogyan működik az egész linuxos ökoszisztéma. A Linuxnak egyik kiemelt előnye ez, lehet utálni érte a hater-öknek, de ezt ők is elismerhetik, hogy soseleszdesktopéve, möh-möhh, corporate bullshit, de mikor vírusmentességről van szó, meg hogy nem kell a rendszeren ilyen anti-akármi bloatoknak futni, akkor azt el kell ismerjék.
Valahogy azt se szokták megérteni, hogy a Linuxos vírusirtó nem linuxos vírusok irtására van. Azért létezik, hogy ha valaki linuxos rendszert üzemeltet, ami fájl-, email-, stb. szerverként működik windowsos gépek felé, akkor ne tároljanak ezek windowsos vírust, amit a windowsos userek letöltenek a gépükre, és összefertőzik. Ergo, hogy linuxos gépek ne segítsenek windowsos kártevők terjesztésében, hanem náluk is szakadjon meg a lánc.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Lehet rossz hír neked, de sajnos már rég nem itt tart a világ. :-)
Egy normális (kereskedelmi) AV ben lévő HIPS/EDR modulok a linuxos gépen futó gyanús, nem file alapú dolgokban is segítenek. Pl valami sérülékenységet exploitálnak (a sok, összefosolt open-source komponenseknél gyakori, hogy sérülékeny a kód), akkor ez képes jelezni/megfogni, ami nem hátrányos dolog, főleg ha nem tudsz/akarsz jóval komolyabb összegeket WAF-ra és egyéb L7-es NG tűzfalakra vagy hálózati forgalam analizátorokra (IDS/IPS) költeni.
Meg tegyük mellé, hogy egy ThreatInteligence használat előnyét, ami már szintén előírás. Nem statilus szignatúrákkal dolgozik a világ.
Erős tévhit, hogy a linux-ot nem kell/érdemes védeni, csak azért mert linux....
A linuxot csak azért nem kell védeni, mert linux. Ez nem tévhit. A Windowsot meg csak azért kell védeni, mert Windows. Olvasd el mivel indult a szál. Linuxos rendszereken ott kellhet efféle védelem, ahol a felhasználó sudozik, programokat fordítgat magának, saját elérése van open source repókhoz stb. Még ott ahol Linuxos desktopot használnak, ott sem szükséges okvetlenül ilyesmi. A Linux persze védhető és a valóságban mindenféle is elképzelhető, de azért botorság lenne emiatt a számítástechnikát összemosni bármilyen Windowssal.
Abból hogy létezhetnek Linuxos veszélyek, amelyek átgondolandók, nem következik, hogy a normának mndenféle előfeltétel nélkül úgy kellene tennie, mintha csak Windowson létezne számítástechnika.
Bocs, de lehet nem teljesen értelek...
Ha van egy sérülékeny komponens egy szerveren vagy szar konfig beállítás, az nem OS specifikus dolog.
Én ezt arra írtam, hogy folyamatosan megy a küzdés a megvilágosodott (és főleg linux-os/Unix-os) rendszergazdákkal/üzemeltetőkkel a SECU szakmában, mert ők meg vannak róla győződve, hogy a linux az nem windows (ami igaz), és emiat _egyáltalán_ semmiféle védelem nem kell rá.
Van 14 karakteres jelszava, meg kulcsos SSH, így semmi baj nem történhet. Aztán mégis szokott....vagy élesben vagy csak egy penetration teszt által. Akkor meg pislognak....
~20 éve csinálom, pár ilyen "érdekfeszítő" beszélgetésen/demo-n már túl vagyok :-)
Persze, ezt értem, de a szál nem arról szól, hogy a linuxon is lehet-e baj, hanem arról, hogy a norma olyasmit ír elő, amelyik esetében teljesen mindegy, hogy hol, mi ellen kell és kell-e védelem. Vagy félreértettem az első posztot.
Mondjuk egy másik szál lehetne, hogy a szekus szakma ;^) mennyire öncélú és mennyire dolga abban a szakmában valakinek reális veszélyekkel foglalkoznia (ha az esetleg nem termelne elegendő profitot) meg hogy van-e jogosultsága pl. afféle mérlegelésnek, hogy létezik-e optimális védelem.
Fiatal koromban volt egyszer olyan, hogy kiraktunk egy linuxot azzal, hogy aki elsőnek írásjogot talál rajta, az kap egy túrórudit. Aztán valamelyik kolléga kiírta CD-re az egészet azzal, hogy nesze itt van, játsszatok.
Nem értetted félre. Azt írja, kell, mert követlemény. Ez így persze lehet hülyeség/szuboptimális is, de ez van, erre szeretne megoldást a topicindító.
Én arra írtam a fentieket, amire jött 1-2 reakció (pedig direkt kérte a topicindító is, hogy ne azon lamentáljunk hogy miért nem kell linuxra - ez itt és most értehető kérés a részéről)Én azt próbáltam szemlélteni, hogy linuxra is igenis kellhet és van is jól működő, nem csak alibi megoldás.
Szerintem azt érdemes látni, hogy a secu nem feltétlen öncélú és inkább az üzlethez tartozó funkció (általában CFO felügyelett alatt szokott jó helyen lenni szervezetileg) és az ő érdekeit próbálja képviselni, nem az IT/üzemeltetését.
Ezért csalóka a DevSecOps-os dolog is pl.. Az azért az könnyen belátható, hogy _secu_döntést_ ő nem fog igazából hozni, csak két dolgot kell üzemeltetnie egyszerre. A végrehatási szinteket vonták csak össze ezzel, mivel van egy alapvető "conflict_of_interest" a két terület között.
Jó, ha a secusnak van üzemletetési tapasztalata, de nem feltétlen az lesz a döntésénél az elsődleges szempontja.Meg kell találnia a jó "leves-hús" arányt. Ez benne a művészt. :-)
Az IT-nak meg elfogadni ezt (még ha nem is ért vele egyet), mert ez nem az ő felelőssége innentől. Sok helyen ezt az "elengedést" nem tudják megugrani könnyen....
Ez az elengedés nálam is problémás. A CFO harmonikus biztonsági megoldást kell kapjon a kezébe. Olyat, ami összefér az IT üzemeltetés feladataival, a működést nem akadályozza (hanem ellenkezőleg, éppenhogy transzparensen támogatja) és a büdzséje van annyira reális, hogy a CFO is támogassa. Ezt a szeku kell megtervezze, kiadja és időközönként felülvizsgálja, két felülvizsgálat között a CFO felel a biztonságért. Ha ezt erőszakkal kell keresztülvinni, mert a szeku nem fogadja el az üzemeltetés akadékoskodását, nem törődik azzal, hogy a felhasználónak is van igénye (pl. dolgozni szeretne a rendszeren) vagy olyan pénzbe kerül az egész, amire a CFO röhögő görcsöt kap vagy esetleg képtelenség betartatni, akkor az egész biztonsági rendszer döglött lesz. Állandóan pofozgatni kell és mindig ott lesz a menekülőpálya azzal, hogy "szarból nem lehet", tologatja mindenki a felelősséget. Értem én, hogy ez nem egyszerű, azért vannak a normák, hogy a szeku széttárhassa a kezét vagy az üzemeltetés leírhassa, hogy ne olvassa tovább a szálat, aki szerint egy Clamav mondjuk tökfölösleges egy adatbázis szerverre (hülye példa, más biztos tudna jobbat) vagy hogy az IT "elengedhesse" a témát, mert nem az ő felelőssége a biztonsági rendszer fenntartása. A magam részéről még azt hiszem megtehetem, hogy leszarom a normát, ha irracionális és olyan biztonságot akarok, amit a szekus a legjobb tudása szerint képes felállítani, a CFO fenntartani, a munkát nem akadályozza és belefér a büdzsébe. Azaz a biztonság "harmonikus". Nem tudom meddig tehetem még meg ezt, talán nálunk is bekopog előbb utóbb az informatikai szakma felelőtlensége valamilyen ostoba norma formájában.
Szerencsére nem ennyire drasztikus a helyzet. Általában egy normális cégnél a security valamennyire érti azt, hogy ennek a dolognak nagyon komoly impactja van az üzemeltetésre, és akár a rendelkezésreállásra is. Ehhez még csak nem is kell érteni az üzemeltetéshez, elég egy olyan üzemeltetési vezető, aki ezt megfelelő formában elő tudja prezentálni a security és a vezetőség felé. Az ilyen cuccok bevezetése ugyanis óhatatlanul több területet is fog érinteni, fel kell tudni készülni a felmerülő problémák kommunikációjára.
Persze, van olyan helyzet, amikor mindent megtesz az üzemeltetés, és süket fülekre talál. Ilyenkor teszed amit tenned kell, de pontosan tisztában kell lenned azzal, hogy te mindent megtettél, ha gond van, nem rajtad fog múlni. És tapasztalatból mondom: ennél nehezebb nincsen. Amikor látod, hogy szar az egész, több évnyi tapasztalatod sikít, hogy meg kellene oldani, mégsem teheted. Ki kell várni a lehetőséget a rendberakásra, addig meg hadd égjen.
Blog | @hron84
via @snq-
Igen, baromi nagy szerencsémnek tartom, hogy eddig nem kerültem ilyen helyzetbe. Valószinüleg ha kerültem volna, kirúgtam volna magam alól a széket. Nagyra tartom, aki az ilyesmit viseli, sajnálom, hogy van akinek muszáj és nem sokra tartom az olyanokat, akiket nem is zavar. Ilyet viszont láttam már sajnos, sokat.
Nekem egyszer volt ilyenre szuksegem, szinten valami megfeleles miatt. Volt valami program, ami beepult a gepbe, az nezte, hogy fut-e neki megfelelo virusirto, es egy webes felulet (amit el kellett ernem) valahogy kommunikalt a helyi gepen futo spyware-rel. Ertelemszeruen nem biztam benne, ugyhogy az egesz szar ment VM-en belulre.
A telepitendo spyware leirasaban benne volt egy lista, hogy milyen virusirtokat ismer fel. Ebbol vegul a clamonacc lett, ami tud demonkent futni, es ingyenes (Clam on-access scanner).
Ha nem valami hulye eloiras miatt kell, akkor nem szorakoznek ilyesmivel.
A strange game. The only winning move is not to play. How about a nice game of chess?
"Ertelemszeruen nem biztam benne". Aranyos hozzáállás:-) A te céged, a te géped?
Ez miért "értelemszerű"? De miért is kéne _neked_ bízni benne? Szereptévesztés van itt szerintem.
Gondolom nem aztért kapod a fizetesed, hogy bízz/higgy dolgokban. De ha van ilyen pozi, szólj. (vallásosok előnyben) :-)
Ha követelmény miatt van, akkor nem a te felelősséged, még ha meg is áll az egész gép miatta, sokkal magasabb szinten, sokkal "okosabbak" eldöntötték helyetted. (és így a felelősséget is vállalták érte)
Ha bármit is számítana a véleményed, biztos megkérdeztek volna, hidd el. Szar érzés, de ez van.
Ezt kéne megérteni és levenni az "önkéntes gatekeeper" sapkát ilyenkot sokaknak...és folyamatosan aláásni, gáncsolni dolgokat, csak azért mert nem szerintük az nem úgy van....vagy csak nem értik.
Meg gondolom van valami jóváhagyott SW komponens lista is cégnél (NIS2 miatt is majd kell hogy legyen pl., ISO ban is elő szokátk írni). Mi alapján döntöttél _te_ az AV engine-ről, meg a beállításairól?
Hiába "csak" követelmény, ha bármi gebasz lesz (bármi, nem kell, hogy secu legyen) és lesz RCA rá, ami kihozza, hogy ja, volt valami AV is, de te VM-ben futtattad a host helyett, szerinted mennyi időd lesz összapakolni? És egy random, plusz VM-et szabad futtatnod jóváhagyott CR nélkül? Komoly hely lehet.....
De tényleg ér ez ennyit? Nem ettől leszel "jobb szakember" hidd el, de jól hangzik sörözés körben a haveroknak mesélni, hogy "de jól átb.sztad őket"....és nem lennél most biztosan a helyükben - (Virág elvtárs/Tanú)
Most kapaszkodj meg: egy cég emberekből áll.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Köszi, most már ezt is tudom, de ez hogy kapcsolódik a fenti dologhoz?
-----------------------------------------------------------------------------------
Mert ezeknek az emberekenk vannak szerepkörrei benne (tulaj, vezető, IT-s,...)
A szerepkörökkel járnak konkrét feladatok meg felelősségek.
A feladat csak annyi, hogy _mindenki_ e szerint viselkedjen/dolgozzon és már működik is a rendszer. :-)
Ha betartasz a dolgozonak, akkor a dolgozo is betart neked (lehetosegeihez merten).
Mondok egy konkrét példát:
Egyszer telepíteni kellett egy új gépsort. Minden egyes reggel (nem viccelek), kb. 1 órát kellett várni, hogy bejussunk a portán.
Minden nap elkérték a személyit, 2. héten se ismertek meg, mindig elkérték a személyit és lefenymasoltak.
Történt egyszer, hogy egy berakodo sinpalyas daru behalt reggel, és leállt a komplett gyártás. Reggel már vártak, a portán ugyanazok valahogy már felismertek, és mindenféle ellenőrzés nélkül be akartak volna engedni, belül kocsival vártak (addig gyalogolni kellett, mert a kocsihoz külön engedély kellett volna, hogy bevigyuk, igy a szerszámokat is kézben vittük majd egy kilométerre minden reggel) volna.
Mondtam nekik, hogy ez így nem lesz jó, és végigcsináltam ugyanazt a belépési procedúrát, mint azelőtt két hétig. Már a vezérigazgató is előkerült, de ha valamibe beleálltak, rajtam nem múlt.
Szóval jah: adok-kapok.
Az után az ominózus nap után a többi reggelen (amíg ott dolgoztunk), a reggeli belépéssel már nem volt gond, a kocsit is bevihettuk utána.
Az, hogy az a cég dolgozik-e annak a cégnek, én nem tudom. Én már nem dolgozok ott (nem emiatt).
Szóval jah, van emberi tényező. Mindenkinél betelhett a pohár.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
De azt kell megérteni, hogy ezzel nem a dolgozónak tart be. Ezt csak a dolgozó hiszi, mert túldimenzionálja a szerepét és/vagy nem érti a miértet az egész mögött.
Pedig nem az ő cége, nem az ő gépe, a bevétel, de a kockázat se az öve. Akkor meg miért akar mindenáron olyanba beleszólni, ami nem az ő dolga. Ill ha problémát lát, akkor ennek meg van a módja, hogy hogy jelezze, de nem így, hogy direkt kersztbe tesz a céges dolgonak, mert szerinte hülyeség/nem hatékony,....nem a hosszú alkalmazotti lét záloga ez a fajta hozzáállás.
Ha egy dolgozó így reagálja le, akkor ne sírjon ha kib.sszák vagy bónusznál "véletlenül" lemarad a listáról,....jár, csak nem jut alapon.
A példádnál maradva:
Miért kell aggódni ezen, ha sokáig tart egy beléptetés, biztos meg van az oka. A timesheetre azt kell felírni amikor megérkeztél a portához, kifizetik. Ennyi. Ha nekik ez jó így, legyen neked is.
De láttad, ha fontos nekik, akkor kocsival mennek eléd, de akkor ezek szerint "normál" időben nem vagy annyira fontos. Ez miért baj?
Péterrel értek egyet.
Nyilván frusztráló, hogy sokáig tart a beléptetés, de nem a te problémád. A partner nem kapja meg a gépsorát hamarabb emiatt. Ezt bele kell kalkulálni az időbecslésbe, ők kifizetik, és ha majd esetleg gyorsabban kell az a gépsor, majd pattognak ők.
Cserébe nincs értelme fasznak lenni a partnerrel sem. Nekem biztonsági őr a párom, nem jókedvükből "szivatják" a jónépet, előírást tartanak be, és ellenőrzik őket is (esetenként utólag is). Hiába ismernek fel, akkor is végig kell csinálnod a procedúrát. Arról nem beszélve, hogy nem csak te létezel a világon, egy forgalmasabb helyen egy portás/őr naponta 100 embert is kezelhet, és nem szükségképpen fog rád emlékezni. Ez nem személyes, és nem ellened szól, csak egyszerűen neki te vagy aznap a 30-adik idióta, aki pattog a beléptetés miatt, és emiatt szar le. Ha felhatalmazás nélkül engedne be téged procedúra nélkül, őt basznák ki az állásából, és biztos vagyok benne, hogy te nem sietnél neki pénzt adni addig, amíg új állást nem talál. Amikor ott volt a vezig, akkor tudomásul kellett volna venni, hogy most akkor nem lesz procedúra, kész, megint nincs értelme fasznak lenni, se neked nem volt jó, se nekik nem volt jó, egy értelmetlen bosszú volt, aminek semmiféle haszna nem volt.
De ehhez sajnos az kell, hogy az emberek kicsit kilépjenek a saját csontgömbjükből, és megpróbálják megérteni legalább egy kicsit a körülöttük nyüzsgő világot.
Blog | @hron84
via @snq-
Egy cég tipikusan projektarat mond, es nem szamol azzal, hogy a munkasai fel lesznek tartva napi 1.5-2 orat. (be-kilepes, auto hianya).
De persze gondolj, amit akarsz.
Annyit mondtam, hogy emberek vagyunk, ki-ki mashogy tűri az értelmetlen szívatást. (és hoztam egy konkrét példát).
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Meg is van a Root Cause :P
Bezonyám... A problémák jelentős része visszavezethető arra, amit úgy szokás röviden leírni, hogy PEBKAC.
De ez annyival árnyaltabb eset, hogy:
- nem elfelejtette - mert csinált valamit, de direkt nem azt amit kértek
- nem erőforrásgondja van
- mert nem jelentette, hogy ez nála kimérten/igazoltan performancia vagy bármi más problémát okozna
- futtatja a vason, és még egy VM-et is pluszban miatta (pazarolja az erőforrást)
A kontrol szándékos megkerülését elég nehéz ebben az esetben letagadni, és az ok, "mert ő nem bízik benne" :)
Ez nem az, hogy hibázunk, mert emberek vagyunk, talán ebben egyet érthetünk.
Így igaz. Anno amikor nekem performancia gondot okozott egy "must have" szutyok, akkor ezt a tesztelés során jeleztem, aztán "cc magasabb szint" is jeleztem, utána lesz...tam - azóta nem tudok az adott környezetről/rendszerről, mert már nincs hozzá közöm, de ahogy hallottam, a probléma érdemben nem nagyon lett kezelve, pláne nem megoldva. De onnantól kezdve, hogy nem én szívok a teljesítményprobléma miatt, már egyből mvp a dolog (más valaki problémája).
Kicsit jobban kifejtem.
Egy ismerosom kert meg ra, hogy segitsek. Ez egy ceges online form volt, amit kotelezoen ki kellett toltenie. A ceges gepen nem volt jogosultsaga telepiteni a ceges spyware-t (sem), szoval mondtak neki, hogy sajat geprol toltse ki. Amire persze nem akarta beengedni azt a fene tudja miket csinalo programot. Eroforras nem szamitott, leven a VM-et majdnem egy eve nem inditottam el (most is csak, hogy megnezzem mi volt anno a megoldas). Eleve csak azert nem toroltem, mert meg kellhet kesobb is.
Amugy ugy dolgozik, hogy a ceg altal biztositott geperol belep tavoli asztallal a ceges VM-be. Aztan onnan esetleg meg egy masikra. Szoval sok reteg van egyebkent is.
A strange game. The only winning move is not to play. How about a nice game of chess?
Nem ez a lényeg ebben meglátásom szerint.
Kapott egy feladatot amihez elmondásod szerint nem volt adott minden feltétel. Pont.
Szóljon, kérjen hivatalos segítséget, de ne azon agyaljon, hogy miként lehet megkerülni, mert szerinte egyébként is hülyeség.
Legyen ez annak a problémája aki kitalálta a feladatot - biztosan van rá OoB valamije, ha meg kiderül hogy valamire tényleg nem gondoltak (nem támogatott OS, hiányzó jog,...), akkor is jó hogy visszadobja, mert ebből tanulni fognak + valszeg másnál is elő fog jönni, ki tudnak valamit találni rá,...
Ez lenne szerintem az elvárható hozzáállás egy ilyen esetben, a pontosabb részleteket nem ismerve.
Egy cegnel van az a mennyisegu kaosz, amikor mar nem probalod meg kijavitani, hanem alkalmazkodsz hozza. Foleg, ha nagy, es sok retegen keresztul menne csak.
Engem is hivott mar hozzajuk, volt is pont nekem valo pozicio, de nem veletlenul nem mentem. Ha kicsit tobb tapasztalata lesz, szerintem o is menekul onnan.
A strange game. The only winning move is not to play. How about a nice game of chess?
A probléma az, hogy "kötelező volt kitöltenie". Ilyenkor le kell írni, hogy "nem volt adott minden feltétel az online form kitöltéséhez" el kell küldeni a közvetlen főnökének meg annak akit érint a dolog, és utána nézni kell a lángokat. Amennyiben emiatt kirúgják, kedvesen meg kell említeni a munkaügyi bíróságot.
Hidd el, általában már az első résznél hirtelen megkapja a szükséges jogosultságot, ha _tényleg_ ki kell töltenie. Ha meg nem kell kitölteni - eggyel kevesebb gond. Egy fejlődési pont azt felismerni, hogy mikor mi kinek fontos. Mert annak kell a legjobban kapálni, akinek a legfontosabb, a többi elég, ha nem akadályozza. Az ilyen "oldjuk meg mindenáron" törekvéseknek van néha nagyon szomorú vége (pl: nem jól sikerült megoldani, esetleg még bajt is csinált vele, emiatt a végén kirúgják, míg ha szólt volna, hogy ez így no-go, akkor nem történt volna semmi).
Blog | @hron84
via @snq-