Virus i GNU / Linux: Fakta eller myte?

Når debatten er over virus y GNU / Linux det tar ikke lang tid før brukeren vises (vanligvis Windows) hva står det:

«I Linux er det ingen virus fordi skaperne av disse ondsinnede programmene ikke kaster bort tid på å gjøre noe for et operativsystem som nesten ingen bruker »

Som jeg alltid har svart:

"Problemet er ikke det, men skaperne av disse ondsinnede programmene vil ikke kaste bort tid på å lage noe som vil bli rettet med den første oppdateringen av systemet, selv på mindre enn 24 timer."

Og jeg tok ikke feil, da denne utmerkede artikkelen ble publisert i Antall 90 (År 2008) fra Todo Linux Magazine. Hans skuespiller david santo orcero gir oss på en teknisk måte (men lett å forstå) forklaringen hvorfor GNU / Linux mangler denne typen skadelig programvare.

100% anbefalt. Nå vil de ha mer enn overbevisende materiale for å stille alle som snakker uten et solid grunnlag om dette emnet.

Last ned artikkel (PDF): Myter og fakta: Linux og virus

REDIGERT:

Her er den transkriberte artikkelen, ettersom vi anser at det er mye mer behagelig å lese på denne måten:

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

Linux- og virusdebatten er ikke noe nytt. Hvert så ofte ser vi en e-post på en liste som spør om det er virus for Linux; og automatisk svarer noen bekreftende og hevder at hvis de ikke er mer populære, er det fordi Linux ikke er så utbredt som Windows. Det er også hyppige pressemeldinger fra antivirusutviklere som sier at de slipper versjoner av Linux-virus.

Personlig har jeg hatt en og annen diskusjon med forskjellige personer via post eller via distribusjonsliste angående spørsmålet om virus eksisterer i Linux eller ikke. det er en myte, men det er komplekst å rive en myte eller rettere en lur, spesielt hvis den er forårsaket av økonomisk interesse. Noen er interessert i å formidle ideen om at hvis Linux ikke har slike problemer, er det fordi de færreste bruker den.

På tidspunktet for publiseringen av denne rapporten hadde jeg ønsket å skrive en endelig tekst om eksistensen av virus i Linux. Dessverre, når overtro og økonomisk interesse lønner seg, er det vanskelig å bygge noe definitivt.
Vi vil imidlertid prøve å gjøre et rimelig komplett argument her for å avvæpne angrepene til alle som vil krangle.

Hva er et virus?

Først og fremst skal vi begynne med å definere hva et virus er. Det er et program som kopierer seg selv og kjører automatisk, og som tar sikte på å endre en datamaskins normale funksjon uten brukerens tillatelse eller kunnskap. For å gjøre dette erstatter virus kjørbare filer med andre som er infisert med koden. Definisjonen er standard, og er et sammendrag av en linje av Wikipedia-oppføringen om virus.
Den viktigste delen av denne definisjonen, og den som skiller viruset fra annen skadelig programvare, er at et virus installerer seg selv, uten brukerens tillatelse eller kunnskap. hvis den ikke installerer seg selv, er det ikke et virus: det kan være et rootkit eller en trojan.

En rootkit er en kjerneoppdatering som lar deg skjule visse prosesser fra brukerområdet. Med andre ord er det en modifisering av kjernekildekoden hvis formål er at verktøyene som lar oss se hva som kjører til enhver tid ikke viser en bestemt prosess eller en bestemt bruker.

En trojan er analog: det er en modifikasjon av kildekoden til en bestemt tjeneste for å skjule visse falske aktiviteter. I begge tilfeller er det nødvendig å skaffe kildekoden til den eksakte versjonen som er installert på Linux-maskinen, lappe koden, kompilere den på nytt, få administratorrettigheter, installere den oppdaterte kjørbare filen og initialisere tjenesten - når det gjelder trojaneren - eller operativsystemet. fullført - i tilfelle
rootkit–. Prosessen er, som vi ser, ikke triviell, og ingen kan gjøre alt dette "ved en feiltakelse". Begge krever i installasjonen at noen med administratorrettigheter bevisst utfører en rekke trinn som tar beslutninger av teknisk art.

Noe som ikke er en ubetydelig semantisk nyanse: for et virus å installere seg selv, er det nok for oss å kjøre et infisert program som en vanlig bruker. På den annen side, for installasjon av et rootkit eller en trojan, er det viktig at et ondsinnet menneske personlig kommer inn på rotkontoen til en maskin, og på en ikke-automatisert måte utfører en rekke trinn som potensielt kan oppdages. et virus sprer seg raskt og effektivt; et rootkit eller en trojan trenger at de spesifikt retter seg mot oss.

Overføring av virus i Linux:

Overføringsmekanismen til et virus er derfor det som virkelig definerer det som sådan, og er grunnlaget for deres eksistens. et operativsystem er mer følsomt overfor virus, jo lettere er det å utvikle en effektiv og automatisert overføringsmekanisme.

Anta at vi har et virus som vil spre seg. Anta at den har blitt lansert av en normal bruker, uskyldig, når den lanserer et program. Dette viruset har utelukkende to overføringsmekanismer:

Repliker seg selv ved å berøre minnet til andre prosesser, forankre seg selv til dem ved kjøretid.
Åpne filsystemets kjørbare filer og legge til koden –payload– i den kjørbare filen.

Alle virus som vi kan vurdere som sådan har minst en av disse to overføringsmekanismene. O De to. Det er ingen flere mekanismer.
Når det gjelder den første mekanismen, skal vi huske den virtuelle minnearkitekturen til Linux og hvordan Intel-prosessorer fungerer. Disse har fire ringer, nummerert fra 0 til 3; jo lavere tall, jo større privilegier har koden som kjører i den ringen. Disse ringene tilsvarer tilstandene til prosessoren, og derfor med det som kan gjøres med at et system er i en spesifikk ring. Linux bruker ring 0 for kjernen, og ring 3 for prosesser. det er ingen proseskode som kjører på ring 0, og det er ingen kjernekode som kjører på ring 3. Det er bare et enkelt inngangspunkt til kjernen fra ring 3: 80-timers avbrudd, som gjør det mulig å hoppe fra området der den er brukerkoden til området der kjernekoden er.

Arkitekturen til Unix generelt og Linux spesielt gjør ikke spredning av virus mulig.

Kjernen ved å bruke virtuelt minne får hver prosess til å tro at den har alt minne for seg selv. En prosess - som fungerer i ring 3 - kan bare se det virtuelle minnet som er konfigurert for den, for ringen den opererer i. Det er ikke det at minnet til de andre prosessene er beskyttet; er at for en prosess er minnet til de andre utenfor adresseområdet. Hvis en prosess skulle slå alle minneadressene, ville den ikke engang kunne referere til en minneadresse til en annen prosess.

Hvorfor kan ikke dette bli snytt?
For å modifisere det som er kommentert, for eksempel generere inngangspunkter i ring 0, endre avbruddsvektorer, modifisere virtuelt minne, modifisere LGDT ... - det er bare mulig fra ring 0.
Det vil si at for at en prosess skal kunne berøre minnet til andre prosesser eller kjernen, bør den være selve kjernen. Og det faktum at det er ett enkelt inngangspunkt og at parametrene sendes gjennom registre kompliserer fellen - faktisk, det som skal gjøres passeres av register, som deretter implementeres som et tilfelle i oppmerksomhetsrutinen 80-timers avbrudd.
Et annet scenario er tilfellet med operativsystemer med hundrevis av udokumenterte anrop til ring 0, hvor dette er mulig - det kan alltid være en dårlig implementert glemt samtale som en felle kan utvikles på - men når det gjelder et operativsystem med en så enkel trinnmekanisme, det er den ikke.

Av denne grunn forhindrer den virtuelle minnearkitekturen denne overføringsmekanismen; ingen prosesser - ikke engang de med rotprivilegier - har en måte å få tilgang til andres minne. Vi kan hevde at en prosess kan se kjernen; den har den kartlagt fra sin logiske minneadresse 0xC0000000. Men på grunn av prosessorringen som den kjører på, kan du ikke endre den; ville generere en felle, siden de er minneområder som tilhører en annen ring.

"Løsningen" vil være et program som endrer kjernekoden når det er en fil. Men det at disse blir kompilert, gjør det umulig. Binæren kan ikke lappes, da det er millioner av forskjellige binære kjerner i verden. Rett og slett at når de kompilerte den på nytt, hadde de satt eller fjernet noe fra kjernekjørbarheten, eller de hadde endret størrelsen på en av etikettene som identifiserer kompileringsversjonen - noe som gjøres selv ufrivillig - den binære oppdateringen kunne ikke brukes. Alternativet ville være å laste ned kildekoden fra Internett, lappe den, konfigurere den for riktig maskinvare, kompilere den, installere den og starte maskinen på nytt. Alt dette skal gjøres av et program, automatisk. Ganske en utfordring for kunstig intelligens.
Som vi kan se, ikke engang et virus som rot kan hoppe over denne barrieren. Den eneste løsningen som er igjen er overføring mellom kjørbare filer. Noe som ikke fungerer som vi vil se nedenfor.

Min erfaring som administrator:

I mer enn ti år har jeg ledet Linux, med installasjoner på hundrevis av maskiner i datasentre, studentlaboratorier, selskaper osv.

Jeg har aldri "fått" et virus
Jeg har aldri møtt noen som har
Jeg har aldri møtt noen som har møtt noen som har skjedd med ham

Jeg kjenner flere mennesker som har sett Loch Ness-monsteret enn har sett Linux-virus.
Personlig innrømmer jeg at jeg har vært hensynsløs, og jeg har lansert flere programmer som de selvutnevnte "spesialistene" kaller "virus for Linux" - fra nå av vil jeg kalle dem virus, ikke for å gjøre teksten pedantisk - fra min vanlige konto mot maskinen min, for å se om et virus er mulig: både bash-viruset som sirkulerer rundt der - og som for øvrig ikke infiserte noen filer - og et virus som ble veldig kjent, og dukket opp i pressen. Jeg prøvde å installere den; og etter tjue minutters arbeid ga jeg opp da jeg så at et av hans krav var å ha tmp-katalogen på en partisjon av MSDOS-typen. Personlig vet jeg ikke om noen som lager en bestemt partisjon for tmp og formaterer den til FAT.
Faktisk krever noen såkalte virus som jeg har testet for Linux et høyt kunnskapsnivå og rotpassordet som skal installeres. Vi kan i det minste kvalifisere som "crappy" et virus hvis det trenger vårt aktive inngrep for å infisere maskinen. Videre krever de i noen tilfeller omfattende kunnskap om UNIX og root-passordet; som er ganske langt fra den automatiske installasjonen som den skal være.

Infisere kjørbare filer på Linux:

På Linux kan en prosess ganske enkelt gjøre hva den effektive brukeren og den effektive gruppen tillater. Det er sant at det er mekanismer for å bytte den virkelige brukeren med kontanter, men lite annet. Hvis vi ser på hvor kjørbare filer er, vil vi se at bare root har skriverettigheter både i disse katalogene og i filene. Med andre ord, bare root kan endre slike filer. Dette er tilfelle i Unix siden 70-tallet, i Linux siden opprinnelsen, og i et filsystem som støtter privilegier, har det ennå ikke dukket opp noen feil som tillater annen oppførsel. Strukturen til ELF-kjørbare filer er kjent og godt dokumentert, så det er teknisk mulig for en fil av denne typen å laste nyttelasten i en annen ELF-fil ... så lenge den effektive brukeren av den tidligere eller den effektive gruppen av den tidligere har tilgangsrettigheter. lese, skrive og utføre på den andre filen. Hvor mange kjørbare filer kan det infisere som en vanlig bruker?
Dette spørsmålet har et enkelt svar, hvis vi vil vite hvor mange filer vi kan "infisere", 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-katalogen fordi det er et virtuelt filsystem som viser informasjon om hvordan operativsystemet fungerer. Filtypefilene med kjøringsrettigheter som vi finner utgjør ikke noe problem, siden de ofte er virtuelle lenker som ser ut til å bli lest, skrevet og utført, og hvis en bruker prøver, fungerer det aldri. Vi utelukker også mange feil - siden det er mange kataloger der en vanlig bruker ikke kan komme inn, spesielt i / proc og / home. Dette skriptet tar lang tid. I vårt spesielle tilfelle, på en maskin der fire personer jobber, var svaret:

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

Utgangen viser tre filer som kan infiseres hvis et hypotetisk virus ble kjørt. De to første er Unix-sokkelfiler som slettes ved oppstart - og kan ikke påvirkes av et virus - og den tredje er en fil av et program under utvikling, som slettes hver gang det kompileres på nytt. Fra et praktisk synspunkt ville viruset ikke spre seg.
Fra det vi ser, er den eneste måten å spre nyttelasten på å være rot. I dette tilfellet, for at et virus skal fungere, må brukerne alltid ha administratorrettigheter. I så fall kan det infisere filer. Men her kommer fangsten: for å overføre infeksjonen, må du ta en annen kjørbar, sende den til en annen bruker som bare bruker maskinen som rot, og gjenta prosessen.
I operativsystemer der det er nødvendig å være administrator for vanlige oppgaver eller å kjøre mange daglige applikasjoner, kan dette være tilfelle. Men i Unix er det nødvendig å være administrator for å konfigurere maskinen og endre konfigurasjonsfilene, slik at antall brukere som rotkontoen bruker som daglig konto, er lite. Det er mer; noen Linux-distribusjoner har ikke engang rotkontoen aktivert. I nesten alle, hvis du får tilgang til det grafiske miljøet som sådan, endres bakgrunnen til intens rød, og konstante meldinger gjentas som minner deg om at denne kontoen ikke skal brukes.
Til slutt kan alt som må gjøres som root gjøres med en sudo-kommando uten risiko.
Av denne grunn kan ikke en kjørbar i Linux infisere andre så lenge vi ikke bruker rotkontoen som vanlig brukskonto; Og selv om antivirusselskaper insisterer på å si at det er virus for Linux, er det nærmeste som kan opprettes i Linux, en trojan i brukerområdet. Den eneste måten disse trojanerne kan påvirke noe på systemet er å kjøre det som root og med de nødvendige privilegiene. Hvis vi vanligvis bruker maskinen som vanlige brukere, er det ikke mulig for en prosess lansert av en vanlig bruker å infisere systemet.

Myter og løgner:

Vi finner mange myter, hoaxes og rett og slett løgner om virus i Linux. La oss lage en liste over dem basert på en diskusjon som fant sted for en tid tilbake med en representant for en produsent av antivirus for Linux som ble veldig fornærmet av en artikkel publisert i samme magasin.
Diskusjonen er et godt referanseeksempel, da den berører alle aspekter av virus i Linux. Vi skal gjennomgå alle disse mytene en etter en slik de ble diskutert i den spesifikke diskusjonen, men som har blitt gjentatt så mange ganger i andre fora.

Myte 1:
"Ikke alle ondsinnede programmer, spesielt virus, trenger root-privilegier for å infisere, spesielt i tilfelle kjørbare virus (ELF-format) som infiserer andre kjørbare filer".

Svar:
Den som fremsetter et slikt krav, vet ikke hvordan Unix privilegiesystem fungerer. For å påvirke en fil, trenger et virus privilegiet å lese –det må leses for å modifisere det–, og skriving –det må skrives for at modifikasjonen skal være gyldig– på den kjørbare filen den vil utføre.
Dette er alltid tilfelle, uten unntak. Og i hver og en av distribusjonene har ikke ikke-root-brukere disse rettighetene. Så rett og slett uten å være rot, er ikke infeksjonen mulig. Empirisk test: I forrige avsnitt så vi et enkelt skript for å sjekke rekkevidden av filer som kan påvirkes av en infeksjon. Hvis vi starter den på maskinen vår, vil vi se hvordan den er ubetydelig, og med hensyn til systemfiler, null. I motsetning til operativsystemer som Windows trenger du heller ikke administratorrettigheter for å utføre vanlige oppgaver med programmer som ofte brukes av vanlige brukere.

Myte 2:
"De trenger heller ikke være rot for å komme inn i systemet eksternt, i tilfelle Slapper, en orm som, ved å utnytte et sårbarhet i Apache's SSL (sertifikatene som tillater sikker kommunikasjon), opprettet sitt eget nettverk av zombiemaskiner i september 2002".

Svar:
Dette eksemplet refererer ikke til et virus, men en orm. Forskjellen er veldig viktig: en orm er et program som utnytter en tjeneste for internett for å overføre seg selv. Det påvirker ikke lokale programmer. Derfor påvirker det bare servere; ikke til bestemte maskiner.
Ormene har alltid vært svært få og av ubetydelig forekomst. De tre virkelig viktige ble født på 80-tallet, en tid da Internett var uskyldig, og alle stolte på alle. La oss huske at det var de som påvirket sendmail, fingerd og rexec. I dag er ting mer kompliserte. Selv om vi ikke kan benekte at de fremdeles eksisterer, og hvis de ikke er merket av, er de ekstremt farlige. Men nå er reaksjonstidene på ormer veldig korte. Dette er tilfellet med Slapper: en orm opprettet på grunn av en sårbarhet oppdaget - og lappet - to måneder før selve ormen dukket opp.
Selv om vi antar at alle som bruker Linux hadde Apache installert og kjører hele tiden, ville det bare være mer enn nok å oppdatere pakkene månedlig for å aldri risikere.
Det er sant at SSL-feilen som Slapper forårsaket var kritisk - faktisk den største feilen som ble funnet i hele historien til SSL2 og SSL3 - og som sådan ble den løst innen få timer. At to måneder etter at dette problemet ble funnet og løst, laget noen en orm på en feil som allerede er rettet, og at dette er det kraftigste eksemplet som kan gis som et sårbarhet, i det minste beroliger det.
Som en generell regel er løsningen på ormer ikke å kjøpe et antivirusprogram, installere det og kaste bort datatid som holder det hjemme. Løsningen er å benytte sikkerhetsoppdateringssystemet for distribusjonen vår: å ha distribusjonen oppdatert, vil det ikke være noen problemer. Å kjøre bare tjenestene vi trenger er også en god ide av to grunner: vi forbedrer ressursbruken, og vi unngår sikkerhetsproblemer.

Myte 3:
"Jeg tror ikke kjernen er usårbar. Faktisk er det en gruppe ondsinnede programmer som heter LRK (Linux Rootkits Kernel), som er basert nettopp på å utnytte sårbarheter i kjernemoduler og erstatte systembinariene.".

Svar:
En rootkit er i utgangspunktet en kjerneoppdatering som lar deg skjule eksistensen av visse brukere og prosesser fra de vanlige verktøyene, takket være at de ikke vises i / proc-katalogen. Det normale er at de bruker det på slutten av et angrep, for det første skal de utnytte en ekstern sårbarhet for å få tilgang til maskinen vår. Deretter vil de foreta en rekke angrep for å eskalere privilegier til de har rotkontoen. Problemet når de gjør det er hvordan du installerer en tjeneste på maskinen vår uten å bli oppdaget: det er der rootkit kommer inn. Det opprettes en bruker som vil være den effektive brukeren av tjenesten vi ønsker å skjule, de installerer rootkit, og de skjuler både den brukeren og alle prosessene som tilhører den brukeren.
Hvordan vi kan skjule eksistensen av en bruker, er nyttig for et virus, er noe vi kan diskutere lenge, men et virus som bruker et rootkit for å installere seg selv, virker morsomt. La oss forestille oss virusets mekanikk (i pseudokode):
1) Viruset kommer inn i systemet.
2) Finn kjernekildekoden. Hvis det ikke er det, installerer han det selv.
3) Konfigurer kjernen for maskinvarealternativene som gjelder den aktuelle maskinen.
4) Kompiler kjernen.
5) Installer den nye kjernen; endre LILO eller GRUB om nødvendig.
6) Start maskinen på nytt.

Trinn (5) og (6) krever rotprivilegier. Det er noe komplisert at trinn (4) og (6) ikke blir oppdaget av den infiserte. Men det morsomme er at det er noen som tror at det er et program som kan gjøre trinn (2) og (3) automatisk.
Hvis vi kommer over noen som forteller oss "når det er flere Linux-maskiner, vil det være flere virus", og anbefaler at vi "har et antivirusprogram installert og kontinuerlig oppdaterer det", kan det være relatert til selskapet som selger antivirusprogrammet og oppdateringene. . Vær mistenksom, muligens samme eier.

Antivirus for Linux:

Det er sant at det er bra antivirus for Linux. Problemet er at de ikke gjør det antivirus-talsmenn hevder. Dens funksjon er å filtrere e-posten som går fra skadelig programvare og virus til Windows, samt å verifisere eksistensen av Windows-virus i mapper som eksporteres via SAMBA; så hvis vi bruker maskinen vår som en postportal eller som en NAS for Windows-maskiner, kan vi beskytte dem.

Clam-AV:

Vi vil ikke fullføre rapporten uten å snakke om hovedantivirusprogrammet for GNU / Linux: ClamAV.
ClamAV er et veldig kraftig GPL-antivirusprogram som kompilerer for det meste av Unix som er tilgjengelig på markedet. Den er designet for å analysere vedlegg til e-postmeldinger som går gjennom stasjonen og filtrere dem for virus.
Denne applikasjonen integreres perfekt med sendmail for å tillate filtrering av virus som kan lagres på Linux-serverne som gir e-post til selskaper; ha en virusdatabase som oppdateres daglig, med digital støtte. Databasen oppdateres flere ganger om dagen, og det er et livlig og veldig interessant prosjekt.
Dette kraftige programmet er i stand til å analysere virus selv i vedlegg i mer komplekse formater som kan åpnes, for eksempel RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, MS Cabinet-filer, MS CHM (HTML COprinted) og MS SZDD.
ClamAV støtter også mbox-, Maildir- og RAW-formatfiler og bærbare kjørbare filer komprimert med UPX, FSG og Petite. Clam AV-paret og spamassassin er det perfekte paret for å beskytte Windows-klientene våre fra Unix-postservere.

KONKLUSJON

Til spørsmålet Er det sårbarheter i Linux-systemer? svaret er absolutt ja.
Ingen med rett sinn tviler på det; Linux er ikke OpenBSD. En annen ting er sårbarhetsvinduet som et Linux-system har som er riktig oppdatert. Hvis vi spør oss selv, er det verktøy for å utnytte disse sikkerhetshullene og utnytte dem? Vel, ja, men dette er ikke virus, de er utnyttelser.

Viruset må overvinne flere vanskeligheter som alltid har blitt satt som en Linux-feil / problem av Windows-forsvarere, og som kompliserer eksistensen av virkelige virus - kjerner som er kompilert på nytt, mange versjoner av mange applikasjoner, mange distribusjoner, ting som de ikke er automatisk overført transparent til brukeren, etc.–. De gjeldende teoretiske "virusene" må installeres manuelt fra rotkontoen. Men det kan ikke betraktes som et virus.
Som jeg alltid sier til elevene mine: Ikke tro meg, vær så snill. Last ned og installer et rootkit på maskinen. Og hvis du vil ha mer, kan du lese kildekoden til "virusene" på markedet. Sannheten er i kildekoden. Det er vanskelig for et "selvutnevnt" virus å fortsette å navngi det slik etter å ha lest koden. Og hvis du ikke vet hvordan du leser kode, et enkelt sikkerhetsmål som jeg anbefaler: bruk bare rotkontoen for å administrere maskinen, og hold sikkerhetsoppdateringer oppdatert.
Bare med det er det umulig for virus å komme inn i deg, og det er svært lite sannsynlig at ormer vil gjøre det, eller at noen vil angripe maskinen din.