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.
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.
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
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?
"É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....
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.....
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...
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!
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.
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?
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).