Virussen in GNU / Linux: feit of mythe?

Wanneer het debat voorbij is Virus y GNU / Linux het duurt niet lang voordat de gebruiker verschijnt (meestal Windows) wat zegt het:

«In Linux zijn er geen virussen omdat de makers van deze kwaadaardige programma's geen tijd verspillen met iets doen voor een besturingssysteem dat bijna niemand gebruikt »

Waarop ik altijd heb geantwoord:

"Het probleem is niet dat, maar de makers van deze kwaadaardige programma's zullen geen tijd verspillen aan het maken van iets dat gecorrigeerd zal worden met de eerste update van het systeem, zelfs in minder dan 24 uur"

En ik had het niet mis, aangezien dit uitstekende artikel in de Inverse 90 (Jaar 2008) van Todo Linux Magazine. Zijn acteur david santo orcero voorziet ons op een technische manier (maar gemakkelijk te begrijpen) de verklaring waarom GNU / Linux mist dit type kwaadaardige software.

100% aanbevolen. Nu hebben ze meer dan overtuigend materiaal om iedereen die spreekt zonder een solide basis over dit onderwerp het zwijgen op te leggen.

Artikel downloaden (pdf): Mythen en feiten: Linux en virussen

BEWERKT:

Hier is het getranscribeerde artikel, aangezien we van mening zijn dat het op deze manier veel comfortabeler is om te lezen:

================================================== ======================

Het debat over Linux en virussen is niets nieuws. Af en toe zien we een e-mail op een lijst met de vraag of er virussen zijn voor Linux; en automatisch antwoordt iemand bevestigend en beweert dat als ze niet populairder zijn, dat komt doordat Linux niet zo wijdverspreid is als Windows. Er zijn ook regelmatig persberichten van antivirusontwikkelaars die zeggen dat ze versies van Linux-virussen uitbrengen.

Persoonlijk heb ik af en toe een discussie gehad met verschillende mensen per post, of via een distributielijst, over de vraag of er virussen bestaan ​​onder Linux. het is een mythe, maar het is ingewikkeld om een ​​mythe, of liever een bedrog, af te breken, vooral als het wordt veroorzaakt door economisch belang. Iemand is geïnteresseerd in het overbrengen van het idee dat als Linux dit soort problemen niet heeft, dit komt doordat maar heel weinig mensen het gebruiken.

Op het moment dat ik dit rapport publiceerde, had ik graag een definitieve tekst willen schrijven over het bestaan ​​van virussen in Linux. Wanneer bijgeloof en economisch belang hoogtij vieren, is het helaas moeilijk om iets definitiefs op te bouwen.
We zullen hier echter proberen een redelijk volledig argument te maken om de aanvallen van iedereen die ertegen wil argumenteren te ontwapenen.

Wat is een virus?

Allereerst gaan we beginnen met te definiëren wat een virus is. Het is een programma dat automatisch kopieert en draait, en dat tot doel heeft de normale werking van een computer te veranderen, zonder toestemming of medeweten van de gebruiker. Om dit te doen, vervangen virussen uitvoerbare bestanden door anderen die zijn geïnfecteerd met hun code. De definitie is standaard en is een samenvatting in één regel van het Wikipedia-artikel over virussen.
Het belangrijkste onderdeel van deze definitie, en het onderdeel dat het virus onderscheidt van andere malware, is dat een virus zichzelf installeert, zonder toestemming of medeweten van de gebruiker. als het zichzelf niet installeert, is het geen virus: het kan een rootkit of een Trojaans paard zijn.

Een rootkit is een kernelpatch waarmee u bepaalde processen kunt verbergen voor hulpprogramma's voor gebruikersgebieden. Met andere woorden, het is een wijziging van de broncode van de kernel waarvan het doel is dat de hulpprogramma's die ons in staat stellen om te zien wat er op een bepaald moment wordt uitgevoerd, een bepaald proces of een bepaalde gebruiker niet visualiseren.

Een Trojaans paard is analoog: het is een wijziging van de broncode van een specifieke dienst om bepaalde frauduleuze activiteiten te verbergen. In beide gevallen is het nodig om de broncode te verkrijgen van de exacte versie die op de Linux-machine is geïnstalleerd, de code te patchen, opnieuw te compileren, beheerdersrechten te verkrijgen, het gepatchte uitvoerbare bestand te installeren en de service - in het geval van de Trojan - of het besturingssysteem te initialiseren. compleet - in het geval van
rootkit–. Het proces is, zoals we zien, niet triviaal, en niemand kan dit allemaal "per ongeluk" doen. Beiden vereisen bij hun installatie dat iemand met beheerdersrechten bewust een reeks stappen uitvoert en beslissingen van technische aard neemt.

Dat is geen onbelangrijke semantische nuance: om een ​​virus zichzelf te laten installeren, hoeven we alleen maar een geïnfecteerd programma uit te voeren als een gewone gebruiker. Aan de andere kant is het voor de installatie van een rootkit of een Trojaans paard essentieel dat een kwaadwillende persoon persoonlijk de root-account van een machine binnendringt en op een niet-geautomatiseerde manier een reeks stappen uitvoert die mogelijk detecteerbaar zijn. een virus verspreidt zich snel en efficiënt; een rootkit of een trojan heeft ze nodig om ons specifiek achterna te gaan.

Virusoverdracht op Linux:

Het transmissiemechanisme van een virus is daarom wat het echt als zodanig definieert, en vormt de basis voor hun bestaan. een besturingssysteem is gevoeliger voor virussen naarmate het gemakkelijker is om een ​​efficiënt en geautomatiseerd transmissiemechanisme te ontwikkelen.

Stel dat we een virus hebben dat zichzelf wil verspreiden. Stel dat het is gestart door een normale gebruiker, onschuldig, bij het starten van een programma. Dit virus heeft uitsluitend twee transmissiemechanismen:

• Repliceert zichzelf door het geheugen van andere processen aan te raken, en zichzelf eraan te verankeren tijdens runtime.
• De uitvoerbare bestanden van het bestandssysteem openen en hun code –payload– toevoegen aan het uitvoerbare bestand.

Alle virussen die we als zodanig kunnen beschouwen, hebben ten minste één van deze twee transmissiemechanismen. O De twee. Er zijn geen mechanismen meer.
Laten we met betrekking tot het eerste mechanisme de virtuele geheugenarchitectuur van Linux onthouden en hoe Intel-processors werken. Deze hebben vier ringen, genummerd van 0 tot 3; hoe lager het nummer, hoe meer privileges de code heeft die in die ring wordt uitgevoerd. Deze ringen komen overeen met de status van de processor, en dus wat er kan worden gedaan met een systeem dat zich in een specifieke ring bevindt. Linux maakt gebruik van ring 0 voor de kernel en ring 3 voor processen. er is geen procescode die op ring 0 draait, en er is geen kernelcode die op ring 3 draait. Er is maar één toegangspunt tot de kernel vanaf ring 3: de 80-uurs interrupt, die het mogelijk maakt om uit het gebied te springen waar hij is de gebruikerscode naar het gebied waar de kernelcode zich bevindt.

De architectuur van Unix in het algemeen en Linux in het bijzonder maakt de verspreiding van virussen niet haalbaar.

De kernel door virtueel geheugen te gebruiken, laat elk proces geloven dat het al het geheugen voor zichzelf heeft. Een proces - dat werkt in ring 3 - kan alleen het virtuele geheugen zien dat ervoor is geconfigureerd, voor de ring waarin het werkt. Het is niet zo dat het geheugen van de andere processen wordt beschermd; is dat voor het ene proces het geheugen van de andere zich buiten de adresruimte bevindt. Als een proces alle geheugenadressen zou verslaan, zou het niet eens kunnen verwijzen naar een geheugenadres van een ander proces.

Waarom kan dit niet worden bedrogen?
Om de commentaren te wijzigen - bijvoorbeeld ingangspunten genereren in ring 0, interruptvectoren wijzigen, virtueel geheugen wijzigen, LGDT wijzigen ... - is dit alleen mogelijk vanaf ring 0.
Dat wil zeggen, om een ​​proces in staat te stellen het geheugen van andere processen of de kernel aan te raken, moet het de kernel zelf zijn. En het feit dat er een enkel punt van binnenkomst is en dat de parameters door registers worden doorgegeven, maakt de val gecompliceerd - in feite wordt het door het register geleid tot wat te doen, wat vervolgens als een geval in de aandachtsroutine wordt geïmplementeerd. 80 uur onderbreking.
Een ander scenario is het geval van besturingssystemen met honderden ongedocumenteerde oproepen om 0 te bellen, waar dit mogelijk is - er kan altijd een slecht geïmplementeerde vergeten oproep zijn waarop een val kan worden ontwikkeld - maar in het geval van een besturingssysteem met zo'n eenvoudig stappenmechanisme is het niet.

Om deze reden verhindert de virtuele geheugenarchitectuur dit transmissiemechanisme; geen enkel proces - zelfs niet degenen met rootprivileges - hebben een manier om toegang te krijgen tot het geheugen van anderen. We zouden kunnen zeggen dat een proces de kernel kan zien; het heeft het in kaart gebracht vanaf het logische geheugenadres 0xC0000000. Maar vanwege de processorring waarop hij draait, kun je deze niet wijzigen; zou een val genereren, aangezien het geheugengebieden zijn die tot een andere ring behoren.

De "oplossing" zou een programma zijn dat de kernelcode wijzigt als het een bestand is. Maar het feit dat deze opnieuw worden gecompileerd, maakt het onmogelijk. Het binaire bestand kan niet worden gepatcht, aangezien er miljoenen verschillende binaire kernels in de wereld zijn. Simpelweg dat ze bij het hercompileren iets uit het uitvoerbare bestand van de kernel hadden verwijderd of verwijderd, of dat ze de grootte van enkele labels die de compilatieversie identificeren - iets dat zelfs onbedoeld wordt gedaan - de binaire patch niet kon toepassen. Het alternatief zou zijn om de broncode van internet te downloaden, te patchen, te configureren voor de juiste hardware, te compileren, te installeren en de machine opnieuw op te starten. Dit alles moet automatisch door een programma worden gedaan. Een behoorlijke uitdaging op het gebied van kunstmatige intelligentie.
Zoals we kunnen zien, kan zelfs een virus als root deze barrière niet doorbreken. De enige oplossing die overblijft, is de overdracht tussen uitvoerbare bestanden. Wat ook niet werkt zoals we hieronder zullen zien.

Mijn ervaring als administrateur:

In meer dan tien jaar dat ik Linux beheer, met installaties op honderden machines in datacentra, studentenlaboratoria, bedrijven, etc.

• Ik heb nog nooit een virus "gekregen"
• Ik heb nog nooit iemand ontmoet die dat wel heeft gedaan
• Ik heb nog nooit iemand ontmoet die iemand heeft ontmoet die dat wel heeft gedaan

Ik ken meer mensen die het monster van Loch Ness hebben gezien dan Linux-virussen.
Persoonlijk geef ik toe dat ik roekeloos ben geweest, en ik heb verschillende programma's gelanceerd die de zelfbenoemde "specialisten" "virussen voor Linux" noemen - vanaf nu zal ik ze virussen noemen, niet om de tekst belerend te maken -, vanuit mijn gebruikelijke account tegen mijn computer, om te zien of een virus mogelijk is: zowel het bash-virus dat daar circuleert - en dat overigens geen bestanden infecteerde - als een virus dat erg beroemd werd en in de pers verscheen. Ik heb geprobeerd het te installeren; en na twintig minuten werk gaf ik het op toen ik zag dat een van zijn eisen was om de tmp-directory op een partitie van het MSDOS-type te hebben. Persoonlijk ken ik niemand die een specifieke partitie voor tmp maakt en deze naar FAT formatteert.
In feite vereisen sommige zogenaamde virussen die ik voor Linux heb getest een hoog kennisniveau en het root-wachtwoord om te worden geïnstalleerd. We zouden op zijn minst een virus als "waardeloos" kunnen kwalificeren als het onze actieve tussenkomst nodig heeft om de machine te infecteren. Bovendien vereisen ze in sommige gevallen uitgebreide kennis van UNIX en het root-wachtwoord; wat vrij ver verwijderd is van de automatische installatie die het hoort te zijn.

Uitvoerbare bestanden infecteren op Linux:

Onder Linux kan een proces eenvoudig doen wat de effectieve gebruiker en effectieve groep toestaan. Het is waar dat er mechanismen zijn om de echte gebruiker in contanten te wisselen, maar verder weinig. Als we kijken waar de uitvoerbare bestanden zijn, zullen we zien dat alleen root schrijfrechten heeft, zowel in deze mappen als in de daarin opgenomen bestanden. Met andere woorden, alleen root kan dergelijke bestanden wijzigen. Dit is het geval geweest in Unix sinds de jaren 70, in Linux sinds de oorsprong, en in een bestandssysteem dat privileges ondersteunt, is er nog geen fout verschenen die ander gedrag toelaat. De structuur van de uitvoerbare ELF-bestanden is bekend en goed gedocumenteerd, dus het is technisch mogelijk dat een bestand van dit type de payload in een ander ELF-bestand laadt ... zolang de effectieve gebruiker van de eerste of de effectieve groep van de eerste toegangsrechten heeft. lezen, schrijven en uitvoeren op het tweede bestand. Hoeveel uitvoerbare bestanden van het bestandssysteem kan het als een gewone gebruiker infecteren?
Deze vraag heeft een eenvoudig antwoord, als we willen weten hoeveel bestanden we kunnen "infecteren", starten we het commando:

$ find / -type f -perm -o=rwx -o \( -perm -g=rwx -group `id -g` \) -o \( -perm -u=rwx -user `id -u` \) -print 2> /dev/null | grep -v /proc

We sluiten de map / proc uit omdat het een virtueel bestandssysteem is dat informatie weergeeft over hoe het besturingssysteem werkt. De bestandstypebestanden met uitvoeringsrechten die we zullen vinden, vormen geen probleem, aangezien het vaak virtuele koppelingen zijn die lijken te worden gelezen, geschreven en uitgevoerd, en als een gebruiker het probeert, werkt het nooit. We verwijderen ook fouten, overvloedig - aangezien er, vooral in / proc en / home, veel mappen zijn waar een gewone gebruiker niet in kan - Dit script duurt erg lang. In ons specifieke geval, in een machine waar vier mensen werken, was het antwoord:

/tmp/.ICE-unix/dcop52651205225188
/tmp/.ICE-unix/5279
/home/irbis/kradview-1.2/src
/kradview

De uitvoer toont drie bestanden die kunnen worden geïnfecteerd als een hypothetisch virus wordt uitgevoerd. De eerste twee zijn bestanden van het Unix-sockettype die bij het opstarten worden verwijderd - en niet kunnen worden aangetast door een virus - en de derde is een bestand van een programma in ontwikkeling, dat elke keer dat het opnieuw wordt gecompileerd, wordt verwijderd. Het virus zou zich vanuit praktisch oogpunt niet verspreiden.
Van wat we zien, is de enige manier om de payload te spreiden door root te zijn. In dit geval moeten gebruikers altijd beheerdersrechten hebben om een ​​virus te laten werken. In dat geval kan het bestanden infecteren. Maar hier komt het addertje onder het gras: om de infectie te verzenden, moet u een ander uitvoerbaar bestand nemen, het naar een andere gebruiker mailen die de machine alleen als root gebruikt, en het proces herhalen.
In besturingssystemen waar het nodig is om een ​​beheerder te zijn voor algemene taken of om veel dagelijkse applicaties te draaien, kan dit het geval zijn. Maar in Unix is ​​het nodig om een ​​beheerder te zijn om de machine te configureren en de configuratiebestanden te wijzigen, dus het aantal gebruikers dat de root-account als een dagelijkse account gebruikt, is klein. Het is meer; bij sommige Linux-distributies is het root-account niet eens ingeschakeld. In bijna alle gevallen, als u de grafische omgeving als zodanig opent, verandert de achtergrond in intens rood en worden constante berichten herhaald die eraan herinneren dat dit account niet mag worden gebruikt.
Ten slotte kan alles wat als root moet worden gedaan, zonder risico worden gedaan met een sudo-commando.
Om deze reden kan in Linux een uitvoerbaar bestand anderen niet infecteren zolang we de root-account niet gebruiken als de algemene gebruikersaccount; En hoewel antivirusbedrijven erop staan ​​te zeggen dat er virussen voor Linux zijn, komt het meest in de buurt van een Trojaans paard in het gebruikersgedeelte dat in Linux kan worden gemaakt. De enige manier waarop deze Trojaanse paarden iets op het systeem kunnen beïnvloeden, is door het als root uit te voeren en met de nodige rechten. Als we de machine gewoonlijk als gewone gebruikers gebruiken, is het niet mogelijk dat een proces dat door een gewone gebruiker wordt gestart, het systeem infecteert.

Mythen en leugens:

We vinden veel mythes, hoaxes en gewoon leugens over virussen in Linux. Laten we er een lijst van maken op basis van een discussie die enige tijd geleden plaatsvond met een vertegenwoordiger van een fabrikant van antivirus voor Linux die erg beledigd was door een artikel dat in hetzelfde tijdschrift werd gepubliceerd.
Die discussie is een goed referentievoorbeeld, aangezien het alle aspecten van virussen in Linux raakt. We gaan al deze mythen een voor een bespreken zoals ze in die specifieke discussie werden besproken, maar die zo vaak in andere fora is herhaald.

Mythe 1:
"Niet alle kwaadaardige programma's, vooral virussen, hebben root-rechten nodig om te infecteren, vooral in het specifieke geval van uitvoerbare virussen (ELF-indeling) die andere uitvoerbare bestanden infecteren'.

antwoord:
Degene die zoiets claimt, weet niet hoe het Unix-privilegesysteem werkt. Om een ​​bestand te beïnvloeden, heeft een virus het voorrecht nodig om te lezen - het moet worden gelezen om het te wijzigen - en moet het schrijven - het moet worden geschreven om de wijziging geldig te maken - op het uitvoerbare bestand dat het wil uitvoeren.
Dit is altijd het geval, zonder uitzonderingen. En in elk van de distributies hebben niet-rootgebruikers deze privileges niet. Dan is de infectie simpelweg niet mogelijk zonder root te zijn. Empirische test: in het vorige gedeelte hebben we een eenvoudig script gezien om de reeks bestanden te controleren die door een infectie kunnen worden beïnvloed. Als we het op onze computer starten, zullen we zien hoe het verwaarloosbaar is, en met betrekking tot systeembestanden, null. Bovendien hebt u, in tegenstelling tot besturingssystemen zoals Windows, geen beheerdersrechten nodig om algemene taken uit te voeren met programma's die gewoonlijk door normale gebruikers worden gebruikt.

Mythe 2:
"Ze hoeven ook geen root te zijn om het systeem op afstand te betreden, in het geval van Slapper, een worm die, gebruikmakend van een kwetsbaarheid in Apache's SSL (de certificaten die beveiligde communicatie mogelijk maken), in september 2002 zijn eigen netwerk van zombiemachines creëerde.'.

antwoord:
Dit voorbeeld verwijst niet naar een virus, maar naar een worm. Het verschil is erg belangrijk: een worm is een programma dat een service voor internet exploiteert om zichzelf te verzenden. Het heeft geen invloed op lokale programma's. Daarom heeft het alleen invloed op servers; niet op bepaalde machines.
De wormen zijn er altijd erg weinig geweest en hebben een verwaarloosbare incidentie. De drie echt belangrijke zijn geboren in de jaren 80, een tijd waarin internet onschuldig was en iedereen iedereen vertrouwde. Laten we niet vergeten dat zij degenen waren die sendmail, fingerd en rexec beïnvloedden. Tegenwoordig zijn de zaken ingewikkelder. Hoewel we niet kunnen ontkennen dat ze nog steeds bestaan ​​en dat ze, als ze niet aangevinkt worden, buitengewoon gevaarlijk zijn. Maar nu zijn de reactietijden op wormen erg kort. Dit is het geval met de Slapper: een worm die is gemaakt op een kwetsbaarheid die twee maanden voor de verschijning van de worm zelf is ontdekt - en gepatcht -.
Zelfs als we aannemen dat iedereen die Linux gebruikt Apache had geïnstalleerd en de hele tijd actief was, zou het maandelijks bijwerken van de pakketten meer dan voldoende zijn geweest om nooit enig risico te lopen.
Het is waar dat de SSL-bug die Slapper veroorzaakte kritiek was - in feite de grootste bug in de hele geschiedenis van SSL2 en SSL3 - en als zodanig binnen enkele uren werd verholpen. Dat twee maanden nadat dit probleem was gevonden en opgelost, iemand een worm heeft gemaakt op een bug die al is verholpen, en dat dit het krachtigste voorbeeld is dat als kwetsbaarheid kan worden genoemd, stelt het in ieder geval gerust.
Als algemene regel geldt dat de oplossing voor wormen niet is om een ​​antivirusprogramma te kopen, het te installeren en de computertijd te verspillen door het resident te houden. De oplossing is om gebruik te maken van het beveiligingsupdatesysteem van onze distributie: als de distributie wordt bijgewerkt, zullen er geen problemen zijn. Alleen de services uitvoeren die we nodig hebben, is ook om twee redenen een goed idee: we verbeteren het gebruik van bronnen en we vermijden beveiligingsproblemen.

Mythe 3:
"Ik denk niet dat de kern onkwetsbaar is. In feite is er een groep kwaadaardige programma's genaamd LRK (Linux Rootkits Kernel), die precies zijn gebaseerd op het misbruiken van kwetsbaarheden in kernelmodules en het vervangen van de systeembinaire bestanden.'.

antwoord:
Een rootkit is in feite een kernelpatch waarmee je het bestaan ​​van bepaalde gebruikers en processen kunt verbergen voor de gebruikelijke tools, dankzij het feit dat ze niet in de directory / proc verschijnen. Het normale is dat ze het aan het einde van een aanval gebruiken, in de eerste plaats zullen ze een kwetsbaarheid op afstand misbruiken om toegang te krijgen tot onze machine. Vervolgens zullen ze een reeks aanvallen uitvoeren om de rechten te escaleren totdat ze het root-account hebben. Het probleem wanneer ze dat doen, is hoe ze een service op onze computer kunnen installeren zonder te worden gedetecteerd: dat is waar de rootkit binnenkomt. Er wordt een gebruiker gemaakt die de effectieve gebruiker zal zijn van de service die we willen verbergen, ze installeren de rootkit en ze verbergen zowel die gebruiker als alle processen die bij die gebruiker horen.
Hoe het bestaan ​​van een gebruiker te verbergen is nuttig voor een virus is iets dat we uitgebreid zouden kunnen bespreken, maar een virus dat een rootkit gebruikt om zichzelf te installeren, lijkt me leuk. Laten we ons de mechanica van het virus voorstellen (in pseudocode):
1) Het virus komt het systeem binnen.
2) Zoek de broncode van de kernel. Is dit niet het geval, dan installeert hij het zelf.
3) Configureer de kernel voor de hardware-opties die van toepassing zijn op de machine in kwestie.
4) Compileer de kernel.
5) Installeer de nieuwe kernel; het wijzigen van LILO of GRUB indien nodig.
6) Start de machine opnieuw op.

Stappen (5) en (6) vereisen root-privileges. Het is enigszins ingewikkeld dat de stappen (4) en (6) niet worden gedetecteerd door de geïnfecteerde. Maar het grappige is dat er iemand is die gelooft dat er een programma is dat stap (2) en (3) automatisch kan doen.
Als een hoogtepunt, als we iemand tegenkomen die ons vertelt "wanneer er meer Linux-machines zijn, zullen er meer virussen zijn", en aanbeveelt dat we "een antivirusprogramma hebben geïnstalleerd en dit constant bijwerken", kan dit verband houden met het bedrijf dat de antivirus en updates verkoopt. . Wees achterdochtig, mogelijk dezelfde eigenaar.

Antivirus voor Linux:

Het is waar dat er een goede antivirus voor Linux bestaat. Het probleem is dat ze niet doen wat voorstanders van antivirusprogramma's beweren. Zijn functie is om de e-mail te filteren die van malware en virussen naar Windows wordt gestuurd, en om het bestaan ​​van Windows-virussen te verifiëren in mappen die via SAMBA worden geëxporteerd; dus als we onze machine gebruiken als e-mailgateway of als een NAS voor Windows-machines, kunnen we ze beschermen.

Clam-AV:

We zullen ons rapport niet afmaken zonder te praten over de belangrijkste antivirus voor GNU / Linux: ClamAV.
ClamAV is een zeer krachtige GPL-antivirus die compileert voor de meeste Unix die op de markt verkrijgbaar is. Het is ontworpen om bijlagen van e-mailberichten die door het station gaan te analyseren en deze op virussen te filteren.
Deze applicatie integreert perfect met sendmail om het filteren van virussen mogelijk te maken die kunnen worden opgeslagen op de Linux-servers die mail naar bedrijven sturen; een virusdatabase hebben die dagelijks wordt bijgewerkt, met digitale ondersteuning. De database wordt meerdere keren per dag bijgewerkt en het is een levendig en zeer interessant project.
Dit krachtige programma is in staat om virussen te analyseren, zelfs in bijlagen in complexere formaten om te openen, zoals RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, MS Cabinet-bestanden, MS CHM (HTML COprinted) en MS SZDD.
ClamAV ondersteunt ook mbox-, Maildir- en mailbestanden in RAW-indeling en Portable Executable-bestanden gecomprimeerd met UPX, FSG en Petite. Clam AV en spamassassin-paar zijn het perfecte paar om onze Windows-clients te beschermen tegen Unix-mailservers.

GEVOLGTREKKING

Op de vraag Zijn er kwetsbaarheden in Linux-systemen? het antwoord is beslist ja.
Niemand bij zijn volle verstand twijfelt eraan; Linux is niet OpenBSD. Een ander ding is het kwetsbaarheidsvenster dat een Linux-systeem heeft dat correct is bijgewerkt. Als we ons afvragen: zijn er tools om van deze beveiligingslekken te profiteren en ze te exploiteren? Ja, maar dit zijn geen virussen, het zijn exploits.

Het virus moet nog een aantal moeilijkheden overwinnen die door Windows-verdedigers altijd als een Linux-fout / probleem zijn aangemerkt, en die het bestaan ​​van echte virussen bemoeilijken - kernels die opnieuw worden gecompileerd, veel versies van veel toepassingen, veel distributies, dingen die ze niet zijn automatisch transparant doorgegeven aan de gebruiker, enz. -. De huidige theoretische "virussen" moeten handmatig vanaf de root-account worden geïnstalleerd. Maar dat kan niet als een virus worden beschouwd.
Zoals ik altijd tegen mijn studenten zeg: geloof me alsjeblieft niet. Download en installeer een rootkit op de machine. En als je meer wilt, lees dan de broncode van de ‘virussen’ op de markt. De waarheid zit in de broncode. Het is moeilijk voor een "zelfverklaard" virus om het zo te blijven noemen na het lezen van de code. En als u niet weet hoe u code moet lezen, een enkele eenvoudige beveiligingsmaatregel die ik aanbeveel: gebruik het root-account alleen om de machine te beheren en houd beveiligingsupdates up-to-date.
Alleen daarmee is het onmogelijk dat virussen u binnendringen en het is zeer onwaarschijnlijk dat wormen of iemand uw machine met succes zullen aanvallen.