Virus i GNU / Linux: Fakta eller myte?

Hver gang debatten er slut virus y GNU / Linux det tager ikke lang tid, før brugeren vises (normalt Windows) hvad står der:

«I Linux er der ingen vira, fordi skaberne af disse ondsindede programmer ikke spilder tid på at gøre noget til et operativsystem, som næsten ingen bruger »

Som jeg altid har svaret:

"Problemet er ikke det, men skaberne af disse ondsindede programmer spilder ikke tid på at skabe noget, der vil blive rettet med den første opdatering af systemet, selv på mindre end 24 timer"

Og jeg tog ikke fejl, da denne fremragende artikel blev offentliggjort i 90 nummer (År 2008) fra Todo Linux Magazine. Hans skuespiller david santo orcero giver os en teknisk måde (men let at forstå) forklaringen hvorfor GNU / Linux mangler denne type ondsindet software.

100% anbefales. Nu vil de have mere end overbevisende materiale til at tavse enhver, der taler uden et solidt grundlag om dette emne.

Download artikel (PDF): Myter og fakta: Linux og vira

REDIGERET:

Her er den transskriberede artikel, da vi mener, at det er meget mere behageligt at læse på denne måde:

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

Linux- og virusdebatten er ikke noget nyt. Hvert så ofte ser vi en e-mail på en liste, der spørger, om der er vira til Linux; og automatisk svarer nogen bekræftende og hævder, at hvis de ikke er mere populære, er det fordi Linux ikke er så udbredt som Windows. Der er også hyppige pressemeddelelser fra antivirusudviklere, der siger, at de frigiver versioner af Linux-vira.

Personligt har jeg lejlighedsvis haft diskussioner med forskellige mennesker via mail eller distributionsliste vedrørende spørgsmålet om, hvorvidt der findes vira i Linux. Det er en myte, men det er komplekst at nedbryde en myte eller rettere en svindel, især hvis den er forårsaget af økonomisk interesse. Nogen er interesseret i at formidle ideen om, at hvis Linux ikke har denne slags problemer, er det fordi meget få mennesker bruger den.

På tidspunktet for offentliggørelsen af ​​denne rapport ville jeg gerne have skrevet en endelig tekst om virussen i Linux. Desværre er det vanskeligt at bygge noget definitivt, når overtro og økonomisk interesse løber ud.
Vi vil dog forsøge at fremsætte et rimeligt komplet argument her for at afvæbne angrebene fra enhver, der ønsker at argumentere.

Hvad er en virus?

Først og fremmest skal vi starte med at definere, hvad en virus er. Det er et program, der kopierer og kører automatisk, og som har til formål at ændre en computers normale funktion uden brugerens tilladelse eller viden. For at gøre dette erstatter vira eksekverbare filer med andre, der er inficeret med deres kode. Definitionen er standard og er et resumé af en linje over Wikipedia-posten om vira.
Den vigtigste del af denne definition og den der adskiller virussen fra anden malware er, at en virus installerer sig selv uden brugerens tilladelse eller viden. hvis det ikke installerer sig selv, er det ikke en virus: det kan være et rootkit eller en trojan.

En rootkit er en kernepatch, der giver dig mulighed for at skjule bestemte processer fra brugerområdet. Med andre ord er det en ændring af kernekildekoden, hvis formål er, at de hjælpeprogrammer, der giver os mulighed for at se, hvad der kører til enhver tid, ikke visualiserer en bestemt proces eller en bestemt bruger.

En trojan er analog: det er en ændring af kildekoden til en bestemt tjeneste for at skjule visse falske aktiviteter. I begge tilfælde er det nødvendigt at hente kildekoden til den nøjagtige version, der er installeret på Linux-maskinen, lappe koden, kompilere den igen, få administratorrettigheder, installere den patchede eksekverbare og initialisere tjenesten - i tilfælde af Trojan– eller operativsystemet. komplet - i tilfælde af
rootkit–. Processen, som vi ser, er ikke triviel, og ingen kan gøre alt dette "ved en fejltagelse". Begge kræver i deres installation, at nogen med administratorrettigheder bevidst udfører en række trin, der tager beslutninger af teknisk karakter.

Hvilket ikke er en ubetydelig semantisk nuance: for at en virus kan installere sig selv, er alt, hvad vi skal gøre, at køre et inficeret program som en almindelig bruger. På den anden side er det vigtigt for installation af et rootkit eller en trojan, at et ondsindet menneske personligt kommer ind på maskinens rodkonto og på en ikke-automatiseret måde udfører en række trin, der potentielt kan detekteres. en virus spreder sig hurtigt og effektivt en rootkit eller en trojan har brug for dem til specifikt at målrette mod os.

Overførsel af vira i Linux:

Transmissionsmekanismen for en virus er derfor, hvad der virkelig definerer den som sådan, og er grundlaget for deres eksistens. et operativsystem er mere følsomt over for vira, jo lettere er det at udvikle en effektiv og automatiseret transmissionsmekanisme.

Antag, at vi har en virus, der ønsker at sprede sig. Antag, at det er blevet lanceret af en normal bruger, uskyldigt, når der startes et program. Denne virus har udelukkende to transmissionsmekanismer:

• Repliker sig selv ved at røre ved andre processers hukommelse og forankre sig selv til dem ved kørsel.
• Åbning af filsystemets eksekverbare filer og tilføjelse af deres kode –payload– til den eksekverbare.

Alle vira, som vi kan overveje som sådan, har mindst en af ​​disse to transmissionsmekanismer. O De to. Der er ikke flere mekanismer.
Med hensyn til den første mekanisme, lad os huske den virtuelle hukommelsesarkitektur i Linux, og hvordan Intel-processorer fungerer. Disse har fire ringe, nummereret fra 0 til 3; jo lavere tal, jo større privilegier har koden, der kører i den ring. Disse ringe svarer til processortilstande, og derfor hvad der kan gøres med, at et system er i en bestemt ring. Linux bruger ring 0 til kernen og ring 3 til processer. der er ingen proceskode, der kører på ring 0, og der er ingen kernekode, der kører på ring 3. Der er kun et enkelt indgangspunkt til kernen fra ring 3: 80-timers afbrydelse, som gør det muligt at hoppe fra det område, hvor det er brugerkoden til det område, hvor kernekoden er.

Unix-arkitekturen generelt og Linux i særdeleshed gør ikke spredning af vira mulig.

Kernen ved hjælp af virtuel hukommelse får hver proces til at tro, at den har al hukommelsen til sig selv. En proces - som fungerer i ring 3 - kan kun se den virtuelle hukommelse, der er konfigureret til den, for den ring, den fungerer i. Det er ikke, at hukommelsen til de andre processer er beskyttet; er, at for en proces er hukommelsen for de andre uden for adresseområdet. Hvis en proces skulle slå alle hukommelsesadresser, ville den ikke engang være i stand til at henvise til en hukommelsesadresse for en anden proces.

Hvorfor kan dette ikke snydes?
For at ændre kommentarerne - for eksempel generere indgangspunkter i ring 0, ændre afbrydelsesvektorer, ændre virtuel hukommelse, ændre LGDT ... - det er kun muligt fra ring 0.
For at en proces skal kunne røre ved hukommelsen i andre processer eller kernen, skal den være selve kernen. Og det faktum, at der er et enkelt indgangspunkt, og at parametrene sendes gennem registre, komplicerer fælden - faktisk sendes den gennem registret, indtil hvad man skal gøre, som derefter implementeres som en sag i opmærksomhedsrutinen. 80-timers afbrydelse.
Et andet scenarie er tilfældet med operativsystemer med hundredvis af udokumenterede opkald til ring 0, hvor dette er muligt - der kan altid være et dårligt implementeret glemt opkald, hvor en fælde kan udvikles - men i tilfælde af et operativsystem med en sådan enkle trin mekanisme, det er det ikke.

Af denne grund forhindrer den virtuelle hukommelsesarkitektur denne transmissionsmekanisme; ingen processer - ikke engang dem med root-privilegier - har en måde at få adgang til andres hukommelse. Vi kunne argumentere for, at en proces kan se kernen; det har det kortlagt fra sin logiske hukommelsesadresse 0xC0000000. Men på grund af processorringen, den kører på, kan du ikke ændre den; ville generere en fælde, da de er hukommelsesområder, der hører til en anden ring.

"Løsningen" ville være et program, der ændrer kernekoden, når det er en fil. Men det faktum, at disse er kompileret, gør det umuligt. Binæren kan ikke lappes, da der er millioner af forskellige binære kerner i verden. Simpelthen, at når de kompilerede det igen, havde de sat eller fjernet noget fra kernekørbarheden, eller de havde ændret størrelsen på en af ​​etiketterne, der identificerer kompileringsversionen - noget der udføres selv ufrivilligt - den binære patch kunne ikke anvendes. Alternativet ville være at downloade kildekoden fra Internettet, lappe den, konfigurere den til den relevante hardware, kompilere den, installere den og genstarte maskinen. Alt dette skal udføres automatisk af et program. Helt en udfordring inden for kunstig intelligens.
Som vi kan se, kan ikke engang en virus som rod springe denne barriere. Den eneste løsning, der er tilbage, er transmission mellem eksekverbare filer. Hvilket heller ikke fungerer som vi vil se nedenfor.

Min erfaring som administrator:

I mere end ti år har jeg styret Linux med installationer på hundredvis af maskiner i datacentre, studielaboratorier, virksomheder osv.

• Jeg har aldrig fået en virus
• Jeg har aldrig mødt nogen, der har
• Jeg har aldrig mødt nogen, der har mødt nogen, der har

Jeg kender flere mennesker, der har set Loch Ness-monsteret, end der har set Linux-vira.
Personligt indrømmer jeg, at jeg har været hensynsløs, og jeg har lanceret adskillige programmer, som de selvudråbte "specialister" kalder "vira til Linux" - fra nu af vil jeg kalde dem vira, ikke for at gøre teksten pedantisk, fra min sædvanlige konto mod min maskine for at se, om en virus er mulig: både den bash-virus, der cirkulerer rundt der - og som forresten ikke inficerede nogen filer - og en virus, der blev meget berømt og dukkede op i pressen . Jeg prøvede at installere det; og efter tyve minutters arbejde gav jeg op, da jeg så, at et af dets krav var at have tmp-biblioteket på en partition af MSDOS-typen. Personligt kender jeg ikke nogen, der opretter en bestemt partition til tmp og formaterer den til FAT.
Faktisk kræver nogle såkaldte vira, som jeg har testet for Linux, et højt niveau af viden og root-adgangskoden, der skal installeres. Vi kunne i det mindste kvalificere os som "skøre" en virus, hvis den har brug for vores aktive intervention for at inficere maskinen. Desuden kræver de i nogle tilfælde omfattende viden om UNIX og rodadgangskoden; hvilket er ret langt fra den automatiske installation, som det skal være.

Infektion af eksekverbare filer på Linux:

På Linux kan en proces simpelthen gøre, hvad dens effektive bruger og effektive gruppe tillader. Det er rigtigt, at der er mekanismer til at udveksle den rigtige bruger med kontanter, men lidt andet. Hvis vi ser på, hvor eksekverbare filer er, vil vi se, at kun root har skriverettigheder både i disse mapper og i de indeholdte filer. Med andre ord, kun root kan ændre sådanne filer. Dette er tilfældet i Unix siden 70'erne, i Linux siden dets oprindelse og i et filsystem, der understøtter privilegier, er der endnu ikke opstået nogen fejl, der tillader anden adfærd. ELF-eksekverbare filers struktur er kendt og veldokumenteret, så det er teknisk muligt for en fil af denne type at indlæse nyttelasten i en anden ELF-fil ... så længe den effektive bruger af den tidligere eller den effektive gruppe af tidligere har adgangsrettigheder. læsning, skrivning og udførelse på den anden fil. Hvor mange eksekverbare filsystemer kunne den inficere som en almindelig bruger?
Dette spørgsmål har et simpelt svar, hvis vi vil vide, hvor mange filer vi kunne "inficere", starter vi kommandoen:

$ 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

Vi ekskluderer / proc-biblioteket, fordi det er et virtuelt filsystem, der viser oplysninger om, hvordan operativsystemet fungerer. De filtypefiler med eksekveringsrettigheder, som vi finder, udgør ikke et problem, da de ofte er virtuelle links, der ser ud til at blive læst, skrevet og udført, og hvis en bruger prøver, fungerer det aldrig. Vi udelukker også rigelige fejl - da der især i / proc og / home er mange kataloger, hvor en fælles bruger ikke kan komme ind. Dette script tager lang tid. I vores særlige tilfælde var svaret på en maskine, hvor fire personer arbejder:

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

Outputtet viser tre filer, der kunne inficeres, hvis der blev kørt en hypotetisk virus. De to første er Unix-sokkeltypefiler, der slettes ved opstart - og kan ikke påvirkes af en virus - og den tredje er en fil i et udviklingsprogram, som slettes hver gang det kompileres igen. Virussen spredte sig fra et praktisk synspunkt ikke.
Fra det, vi ser, er den eneste måde at sprede nyttelasten på at være root. I dette tilfælde skal brugere altid have administratorrettigheder for at en virus kan fungere. I så fald kan det inficere filer. Men her er fangsten: for at sprede infektionen skal du tage en anden eksekverbar, sende den til en anden bruger, der kun bruger maskinen som rod, og gentage processen.
I operativsystemer, hvor det er nødvendigt at være administrator for almindelige opgaver eller køre mange daglige applikationer, kan dette være tilfældet. Men i Unix er det nødvendigt at være administrator for at konfigurere maskinen og ændre konfigurationsfilerne, så antallet af brugere, som rodkontoen bruger som en daglig konto, er lille. Det er mere; nogle Linux-distributioner har ikke engang rodkontoen aktiveret. I næsten alle af dem skifter baggrunden til intens rødt, hvis du får adgang til det grafiske miljø som sådan, og konstante meddelelser gentages, der minder om, at denne konto ikke skal bruges.
Endelig kan alt, hvad der skal gøres som root, gøres med en sudo-kommando uden risiko.
Af denne grund kan en eksekverbar fil i Linux ikke inficere andre, så længe vi ikke bruger rodkontoen som den almindelige brugskonto; Og selvom antivirusfirmaer insisterer på at sige, at der er vira til Linux, er den nærmeste ting, der kan oprettes i Linux, virkelig en trojan i brugerområdet. Den eneste måde, hvorpå disse trojanske heste kan påvirke noget på systemet, er at køre det som root og med de nødvendige privilegier. Hvis vi normalt bruger maskinen som almindelige brugere, er det ikke muligt for en proces, der startes af en almindelig bruger, at inficere systemet.

Myter og løgne:

Vi finder mange myter, hoaxes og bare løgne om vira i Linux. Lad os lave en liste over dem baseret på en diskussion, der fandt sted for nogen tid siden med en repræsentant for en producent af antivirus til Linux, der blev meget fornærmet af en artikel, der blev offentliggjort i det samme magasin.
Denne diskussion er et godt referenceeksempel, da det berører alle aspekter af vira i Linux. Vi vil gennemgå alle disse myter en efter en, som de blev diskuteret i den specifikke diskussion, men som er blevet gentaget så mange gange i andre fora.

Myte 1:
"Ikke alle ondsindede programmer, især vira, har brug for rodprivilegier for at inficere, især i det særlige tilfælde af eksekverbare vira (ELF-format), der inficerer andre eksekverbare filer".

Svar:
Den, der fremsætter et sådant krav, ved ikke, hvordan Unix-privilegiesystemet fungerer. For at påvirke en fil har en virus brug for privilegiet at læse –den skal læses for at ændre den–, og skrivning –den skal skrives for at modifikationen skal være gyldig– på den eksekverbare fil, den ønsker at udføre.
Dette er altid tilfældet uden undtagelser. Og i hver eneste distribution har ikke-root-brugere ikke disse privilegier. Så simpelthen uden at være rod, er infektionen ikke mulig. Empirisk test: I det forrige afsnit så vi et simpelt script til at kontrollere rækkevidden af ​​filer, der kan blive påvirket af en infektion. Hvis vi starter det på vores maskine, vil vi se, hvordan det er ubetydeligt, og med hensyn til systemfiler, null. I modsætning til operativsystemer som Windows behøver du heller ikke have administratorrettigheder til at udføre almindelige opgaver med programmer, der normalt bruges af normale brugere.

Myte 2:
"De behøver heller ikke være rod for at komme ind i systemet eksternt, i tilfælde af Slapper, en orm, der udnyttede en sårbarhed i Apache's SSL (certifikaterne, der tillader sikker kommunikation), skabte sit eget netværk af zombiemaskiner i september 2002".

Svar:
Dette eksempel refererer ikke til en virus, men en orm. Forskellen er meget vigtig: en orm er et program, der udnytter en tjeneste, som Internettet kan transmittere sig selv. Det påvirker ikke lokale programmer. Derfor påvirker det kun servere; ikke til bestemte maskiner.
Ormene har altid været meget få og af ubetydelig forekomst. De tre virkelig vigtige blev født i 80'erne, en tid hvor Internettet var uskyldigt, og alle stolede på alle. Lad os huske, at det var dem, der påvirkede sendmail, fingerd og rexec. I dag er tingene mere komplicerede. Selvom vi ikke kan benægte, at de stadig eksisterer, og at hvis de ikke kontrolleres, er de ekstremt farlige. Men nu er reaktionstiderne på orme meget korte. Dette er tilfældet med Slapper: en orm oprettet på grund af en sårbarhed opdaget - og patched - to måneder før selve ormen optrådte.
Selv under antagelse af, at alle, der bruger Linux, havde Apache installeret og kørt hele tiden, ville det bare have været mere end nok at opdatere pakkerne månedligt til aldrig at løbe nogen risiko.
Det er rigtigt, at den SSL-fejl, som Slapper forårsagede, var kritisk - faktisk den største fejl, der blev fundet i hele SSL2- og SSL3-historikken - og som sådan blev rettet inden for få timer. At der to måneder efter dette problem blev fundet og løst, lavede nogen en orm på en fejl, der allerede er blevet rettet, og at dette er det mest kraftfulde eksempel, der kan gives som en sårbarhed, i det mindste beroliger det.
Som en generel regel er løsningen på orme ikke at købe et antivirusprogram, installere det og spilde computertid, så det forbliver hjemmehørende. Løsningen er at gøre brug af sikkerhedsopdateringssystemet til vores distribution: Når distributionen opdateres, vil der ikke være nogen problemer. At køre kun de tjenester, vi har brug for, er også en god idé af to grunde: Vi forbedrer ressourceforbruget, og vi undgår sikkerhedsproblemer.

Myte 3:
"Jeg tror ikke, at kernen er usårlig. Faktisk er der en gruppe ondsindede programmer kaldet LRK (Linux Rootkits Kernel), der er baseret netop på at udnytte sårbarheder i kernemoduler og erstatte systembinarier.".

Svar:
En rootkit er grundlæggende en kernepatch, der giver dig mulighed for at skjule eksistensen af ​​bestemte brugere og processer fra de sædvanlige værktøjer takket være det faktum, at de ikke vises i / proc-biblioteket. Den normale ting er, at de bruger det i slutningen af ​​et angreb, for det første vil de udnytte en fjern sårbarhed for at få adgang til vores maskine. Derefter foretager de en række angreb for at eskalere privilegier, indtil de har rodkontoen. Problemet, når de gør det, er, hvordan man installerer en tjeneste på vores maskine uden at blive opdaget: det er her rootkit kommer ind. Der oprettes en bruger, der vil være den effektive bruger af den tjeneste, vi vil skjule, de installerer rootkit, og de skjuler både den bruger og alle de processer, der tilhører den bruger.
Hvordan man skjuler en brugers eksistens er nyttigt for en virus, er noget, vi kan diskutere udførligt, men en virus, der bruger et rootkit til at installere sig selv, virker sjovt. Lad os forestille os virusets mekanik (i pseudokode):
1) Virussen kommer ind i systemet.
2) Find kernekildekoden. Hvis det ikke er det, installerer han det selv.
3) Konfigurer kernen til de hardwareindstillinger, der gælder for den pågældende maskine.
4) Kompilér kernen.
5) Installer den nye kerne; ændre LILO eller GRUB, hvis det er nødvendigt.
6) Genstart maskinen.

Trin (5) og (6) kræver rodrettigheder. Det er noget kompliceret, at trin (4) og (6) ikke detekteres af den inficerede. Men det sjove er, at der er nogen, der mener, at der er et program, der kan udføre trin (2) og (3) automatisk.
Som kulmination, hvis vi møder nogen, der fortæller os "når der er flere Linux-maskiner, vil der være flere vira" og anbefaler "at have et antivirusprogram installeret og opdaterer det konstant", muligvis er det relateret til det firma, der markedsfører antivirusprogrammet og opdateringer. Vær mistænksom, muligvis den samme ejer.

Antivirus til Linux:

Det er rigtigt, at der er godt antivirus til Linux. Problemet er, at de ikke gør, hvad antivirus-fortalere hævder. Dens funktion er at filtrere e-mails, der overføres fra malware og vira til Windows, samt at kontrollere eksistensen af ​​Windows-vira i mapper, der eksporteres via SAMBA; så hvis vi bruger vores maskine som en mail-gateway eller som en NAS til Windows-maskiner, kan vi beskytte dem.

Clam-AV:

Vi afslutter ikke vores rapport uden at tale om det vigtigste antivirusprogram til GNU / Linux: ClamAV.
ClamAV er et meget kraftigt GPL-antivirusprogram, der kompilerer for det meste af Unix, der er tilgængeligt på markedet. Det er designet til at analysere vedhæftede filer til mailbeskeder, der passerer gennem stationen, og filtrere dem for vira.
Denne applikation integreres perfekt med sendmail for at tillade filtrering af vira, der kan lagres på Linux-serverne, der leverer mail til virksomheder; have en viradatabase, der opdateres dagligt med digital support. Databasen opdateres flere gange om dagen, og det er et livligt og meget interessant projekt.
Dette kraftfulde program er i stand til at analysere vira, selv i vedhæftede filer i mere komplekse formater, der skal åbnes, såsom RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, MS Cabinet-filer, MS CHM (HTML COprinted) og MS SZDD .
ClamAV understøtter også mbox-, Maildir- og RAW-mailfiler og bærbare eksekverbare filer komprimeret med UPX, FSG og Petite. Clam AV og spamassassin-par er det perfekte par til at beskytte vores Windows-klienter fra Unix-mailservere.

KONKLUSION

Til spørgsmålet Er der sårbarheder i Linux-systemer? svaret er bestemt ja.
Ingen i deres rette sind tvivler på det; Linux er ikke OpenBSD. En anden ting er sårbarhedsvinduet, som et Linux-system har, og som opdateres korrekt. Hvis vi spørger os selv, er der værktøjer til at udnytte disse sikkerhedshuller og udnytte dem? Nå ja, men disse er ikke vira, de er udnyttelser.

Virussen skal overvinde flere flere vanskeligheder, der altid er blevet brugt som en Linux-fejl / problem af Windows-forsvarere, og som komplicerer eksistensen af ​​virkelige vira - kerner, der kompileres igen, mange versioner af mange applikationer, mange distributioner, ting, som de ikke er videregives automatisk gennemsigtigt til brugeren osv .–. De nuværende teoretiske "vira" skal installeres manuelt fra rodkontoen. Men det kan ikke betragtes som en virus.
Som jeg altid siger til mine elever: Tro mig ikke, tak. Download og installer et rootkit på maskinen. Og hvis du vil have mere, skal du læse kildekoden til "vira" på markedet. Sandheden er i kildekoden. Det er vanskeligt for en "selvudråbt" virus at fortsætte med at navngive den på den måde efter at have læst dens kode. Og hvis du ikke ved, hvordan du læser kode, en enkelt sikkerhedsforanstaltning, som jeg anbefaler: Brug kun rodkontoen til at administrere maskinen og hold sikkerhedsopdateringer opdaterede.
Kun med det er det umuligt for vira at komme ind i dig, og det er meget usandsynligt, at orme eller nogen vil angribe din maskine med succes.