Hærdning af Linux med SELinux: en komplet og praktisk guide

Informatic Digital » Recursos » Hærdning af Linux med SELinux: en komplet og praktisk guide

Når du konfigurerer en Linux-server til produktion, er standardkonfigurationen normalt ret åben. Den er designet til at fungere perfekt direkte fra starten, ikke til at være en fæstning . Det er her, SELinux kommer ind i billedet som en vigtig, hærdende komponent: den tilføjer et kontrollag, der fortsætter med at fungere, selv når typiske forsvarsmekanismer (filtilladelser, firewall, opdateringer ) fejler.

SELinux kan virke skræmmende i starten, men når du først har forstået dets grundlæggende elementer, bliver det et utroligt kraftfuldt værktøj til at inddæmme angreb, begrænse skade og opfylde sikkerhedsstandarder som CIS, PCI DSS eller andre højkritiske standarder. I stedet for at stole på, at applikationer opfører sig normalt, tvinger systemet hver proces til at fungere inden for meget specifikke grænser.

Hvad er SELinux, og hvorfor er det vigtigt i Linux-hærdning?

Security-Enhanced Linux er en sikkerhedsudvidelse til Linux-kernen baseret på Mandatory Access Control (MAC). I modsætning til klassisk Unix DAC (discretionary access control), hvor filejeren bestemmer, hvem der kan få adgang til en fil, dikteres reglerne i SELinux af en central politik, som selv root-brugere ikke kan tilsidesætte uden eksplicit at ændre den.

Denne model sikrer, at adgangsbeslutninger er baseret på sikkerhedsetiketter (kontekster) og foruddefinerede regler , ikke kun rwx-tilladelser. Selv hvis en tjeneste er blevet kompromitteret eller har for mange tilladelser, kan SELinux forhindre den i at tilgå følsomme filer, udløse andre processer eller bevæge sig på tværs af netværket ud over dens autoriserede grænser.

SELinux erstatter ikke traditionel DAC; den supplerer den. Først kontrolleres standard Unix-tilladelser, og kun hvis DAC tillader handlingen, træder SELinux til for at validere sin politik . Hvis DAC allerede blokerer adgang, hverken griber eller logger SELinux noget, hvilket hjælper med at reducere støj i loggene og opretholder ydeevnen.

Denne lagdelte tilgang er især mærkbar i virksomhedsmiljøer som Red Hat Enterprise Linux, Fedora, SUSE Linux Enterprise eller openSUSE Leap , hvor SELinux er integreret med resten af ​​systemets sikkerhedsmekanismer og med moderne teknologier som containere og virtuelle maskiner.

Nøglebegreber: SELinux-politikker, kontekster og domæner

Fundamentet for SELinux er sikkerhedspolitikker, der beskriver, hvem der kan gøre hvad, imod hvad og hvordan . I dette sprog betragtes processer som subjekter, og systemressourcer (filer, mapper, sockets, porte, enheder osv.) som objekter.

I stedet for at tænke på brugere som "root" eller "www-data", fungerer SELinux med domæner og typerEn Apache webserverproces kører for eksempel i domænet httpd_t, mens filerne, der serveres til klienten, har en type som httpd_sys_content_tPolitikken definerer, hvilke domæner der kan tilgå hvilke typer, for hvilke klasser af objekter (fil, mappe, socket, port…) og med hvilke specifikke tilladelser (læse, skrive, udføre, getattr, tilføje osv.).

Hvert objekt har en tilknyttet SELinux-kontekst , en etiket af formen:

usuario:rol:tipo:nivel

For eksempel kunne en fil mærkes som system_u:object_r:httpd_sys_content_t:s0Hvor Det vigtigste felt til daglig administration er normalt typen (httpd_sys_content_t), som bestemmer hvilke procesdomæner der får adgang.

I praksis arbejder SELinux med tusindvis af regler. For at forhindre, at dette bliver uhåndterligt, er politikker opdelt i uafhængige moduler, der kan aktiveres, deaktiveres eller opdateres uden at skulle rekompilere en kæmpe monolitisk blok. Dette er afgørende i RHEL, SUSE og openSUSE, hvor hver relevant tjeneste typisk har sit eget politikmodul.

SELinux-driftstilstande: håndhævende, tilladt og deaktiveret

SELinux kan fungere i tre forskellige tilstande, som bestemmer, i hvilket omfang dets regler anvendes på systemet i realtid :

I håndhævelsestilstand håndhæver kernen strengt politikken. Enhver handling, der overtræder reglerne, blokeres og logges . Dette er den anbefalede tilstand til produktion, når politikken er velafstemt, fordi det er her, SELinux virkelig yder beskyttelse.

I permissiv tilstand fortsætter SELinux med at evaluere politikken, men blokerer ikke noget . Alle overtrædelser logges som advarsler. Denne tilstand er ideel til test, implementering af nye applikationer eller finjustering af regler, fordi den giver dig mulighed for at opdage, hvad der ville bryde håndhævelsen, uden at afbryde tjenesterne.

I deaktiveret tilstand er SELinux fuldstændig deaktiveret. Ingen politikker håndhæves, og ingen SELinux-relaterede logfiler genereres. Skift mellem deaktiveret og aktiv tilstand (tilladende eller håndhævende) kræver en genstart, fordi kernen skal starte med initialiseret SELinux-understøttelse for at tagge filsystemet.

En meget fornuftig praksis i enhver distribution er i første omgang at starte med tilladte indstillinger , gennemgå og rette tagging- og politikproblemer og kun skifte til håndhævelse af indstillinger, når alt er stabilt . Hvis du lader det være permanent deaktiveret, fjernes et af de mest kraftfulde beskyttelseslag, der er tilgængelige for dig.

Integrering af SELinux i RHEL, Fedora, SUSE og openSUSE

Distributioner som Red Hat Enterprise Linux, Fedora og derivater aktiverer SELinux som standard , normalt ved hjælp af en målrettet politik, der primært begrænser systemtjenester startet af systemd og nogle brugere.

I RHEL tilbydes der, udover den forudkonfigurerede politik, en række værktøjer for at forhindre administratoren i konstant at skulle kæmpe med lavniveauregler. SELinux Troubleshooter skiller sig ud ved at analysere afvisningshændelser og foreslå specifikke ændringer (såsom aktivering af en boolsk værdi, rettelse af en kontekst eller generering af et ekstra modul).

Derudover udvides SELinux til containere (for eksempel med Podman) og virtualiserede miljøer. Med passende tags isoleres hver container eller VM fra de andre på kerneniveau, selvom en sårbarhed i runtime eller hypervisor kompromitteres.

I SUSE-økosystemet inkluderer SUSE Linux Enterprise Server SELinux-frameworket i sin kerne og værktøjer , men ikke en omfattende officiel politik. Den anbefalede tilgang er at opbygge en brugerdefineret politik, der er skræddersyet til dit miljø, eller bruge løsninger som slemicro, når du ønsker en minimalistisk vært til containere eller virtualisering med fuld SELinux-understøttelse.

I openSUSE Leap er det almindeligt at bruge politikker, der er tilgængelige i repositories, såsom security:/SELinux_legacy, til test, vel vidende at det ideelle for et kritisk miljø stadig er en politik, der er gennemgået og justeret specifikt til implementeringen.

SELinux-politikmodeller: målrettet, MLS og minimum

SELinux kan arbejde med forskellige policymodeller, som bestemmer bredden og dybden af ​​kontrol. De tre mest almindelige er:

Den målrettede politik er designet til generelle miljøer. Den fokuserer på at begrænse specifikke tjenester (især netværksdæmoner) og efterlader andre processer i mere permissive domæner eller endda uafgrænsede. Det er standardindstillingen i de fleste distributioner, fordi den finder en god balance mellem sikkerhed og kompatibilitet.

La Politik for sikkerhed på flere niveauer (MLS) Tilføj feltet for følsomhedsniveau til konteksten (s0, s1, s2, kategorier osv.) og tillader klassificer information og processer i niveauerDet er designet til organisationer med meget strenge krav (forsvar, efterretningstjenester, klassificerede miljøer), hvor det er vigtigt, hvem der kan se eller ændre hvilket niveau af data.

Minimumspolitikken er en reduceret variant med færre regler og kontroller. Den bruges i systemer med begrænsede sikkerhedskrav, eller hvor minimal påvirkning af kompatibilitet ønskes , hvilket ofrer nogle af SELinux's inddæmningsfunktioner.

I implementeringer i den virkelige verden er det normalt at foretrække at arbejde med målrettede modulære politikker og justere modul for modul, hvad der beskyttes, og hvordan, i stedet for at forsøge at administrere en enkelt enorm monolitisk fil, som er meget sværere at vedligeholde.

Konteksthåndtering: visning, ændring og gendannelse af SELinux-tags

En af nøgleopgaverne i SELinux-administration er at sikre, at filer, mapper, processer og porte har den korrekte kontekst i henhold til politikken. En forkert tildelt kontekst kan forårsage, at en tjeneste holder op med at virke eller efterlade en ressource for eksponeret.

For at inspicere SELinux-konteksten for filer og mapper accepterer mange standardkommandoer indstillingen -Z. For eksempel med ls -Z /ruta kan du se bruger, rolle, type og niveau for hver post, og med ps Zaux Du får konteksten for de aktive processer.

Når en politik er installeret, og filsystemet er mærket (for eksempel ved hjælp af setfiles o fixfiles med filerne file_contexts), modtager hver rute en standardtype i henhold til politikHvis du opretter en ny fil i en allerede navngivet mappe, vil den arve mappens type, men hvis du flytter den fra en anden placering, vil den beholde sin oprindelige navn, hvilket kan forårsage uoverensstemmelser.

Hvis et fil- eller mappetræ har forkerte etiketter, kan du rette dem med restoreconDet gendanner kontekster til de værdier, der er defineret i politikken. Med muligheder som -R (rekursiv) og -v (udførlig) Det er nemt at se, hvad der ændrer sig. Det er et næsten obligatorisk trin, før man skifter fra permissiv til håndhævende tilstand på systemer, der har været under test i et stykke tid.

For at deklarere nye mærkningsmønstre bruger du semanage fcontextMed dette værktøj skriver du i politikken, hvad SELinux-typen skal tildeles bestemte stier eller regulære udtrykog derefter anvender du disse ændringer på filsystemet med restoreconFor eksempel kan du mærke en ny DocumentRoot fra Apache med httpd_sys_content_t så webserveren kan læse den under sit begrænsede domæne.

Grundlæggende konfiguration: aktiver SELinux og vælg tilstand

SELinux' opførsel på globalt niveau styres fra /etc/selinux/config, hvor tilstanden er defineret (enforcing, permissive o disabled) og den politik, der skal anvendes (målrettet, MLS, minimum…).

I systemer som RHEL eller Fedora kommer den målrettede politik normalt aktiveret som standard og i tvungen tilstandHvorimod i SUSE eller openSUSE skal kerneparametre i GRUB2 justeres for at indlæse SELinux i stedet for AppArmor. Dette involverer tilføjelse af muligheder som f.eks. security=selinux y selinux=1 til bootlinjen og regenerer GRUB-konfigurationen.

Efter aktivering af SELinux ved opstart og valg af politikken, er det vigtigt at udføre en indledende fuld filsystemtag ved hjælp af setfiles eller tilsvarende værktøj. Dette trin Det kan tage tid, og det er bedst at gøre det i en periode med lav efterspørgsel.Men det er grundlaget for, at systemet kan starte uden overraskelser i tvangstilstand.

I miljøer, hvor du migrerer fra AppArmor, er det afgørende gennemgå filerne meget omhyggeligt file_contexts og deres lokale varianterfordi enhver alvorlig uoverensstemmelse kan forhindre systemet i at starte. Lav en sikkerhedskopi på forhånd og arbejd med semanage fcontext Det er næsten obligatorisk at tilpasse politikken til systemets virkelighed.

SELinux og CVE'er: hvordan de hjælper med at afbøde sårbarheder

Leverandører som Red Hat inkluderer SELinux som en faktor i deres konsekvensvurdering af CVE'er . Deres alvorlighedsmodel (kritisk, vigtig, moderat, lav) tager højde for, om en sårbarhed kan afbødes eller i det mindste inddæmmes af velkonfigurerede SELinux-begrænsninger.

I en kritisk sårbarhed over for fjernudførelse af kode, skriv Log4Shell (CVE-2021-44228)En angriber kunne indsprøjte kode i en tjeneste, der er tilgængelig fra internettet. Hvis den pågældende tjeneste kører under et meget begrænset SELinux-domæne, reduceres potentialet for skade, fordi vil ikke have tilladelse til at læse /etc/shadowmanipulere følsomme databaser eller dreje gennem systemet ud over, hvad der er strengt nødvendigt for dens funktion.

I sårbarheder med eskalering af rettigheder, som f.eks. CVE-2023-4911 (Looney Tunables) , kan politikken stadig forhindre vigtige handlinger såsom indlæsning af kernemoduler, skrivning til systemmapper eller åbning af bestemte netværkssockets , selvom det lykkes at give en bruger adgang med højere rettigheder på DAC-niveau . Resultatet er en begrænsning af, hvad der kan gøres med den nyligt opnåede adgang.

I tilfælde af moderate sårbarheder (for eksempel visse problemer i Grafana), der kræver usædvanlige konfigurationer eller er vanskelige at udnytte, fungerer SELinux som en yderligere barriere, der forhindrer en mindre fejl i at eskalere til en alvorlig hændelse. Ofte blokerer politikken direkte den adgang, som angrebet ville have brug for for at kompromittere systemet.

I sårbarheder med lav effekt, såsom fejl, der forårsager nedbrud i brugerapplikationer (for eksempel i editorer som vim) , er SELinux normalt ikke afgørende for at forhindre selve problemet, men det opretholder stadig sin indeslutningsrolle og sikrer, at en fejlbehæftet proces ikke forlader sin konceptuelle sandkasse.

SELinux i aktion: et eksempel på webserverindespærring i den virkelige verden

Forestil dig en webserver, der kører RHEL eller Fedora, som eksponerer adskillige applikationer, og på trods af at være beskyttet med patches, ender med at være sårbar over for et fjernudførelsesangreb i en af ​​dens komponenter. Uden SELinux kunne en angriber, der udfører kode som webserverbruger, installere bagdøre, læse legitimationsoplysninger eller pivotere til andre systemer.

Med SELinux i håndhævelsestilstand og en velafstemt målrettet politik kører Apache, Nginx eller lignende processer under domænet. httpd_t, som har tilladelser begrænset til filer mærket med typer som httpd_sys_content_t o httpd_sys_rw_content_tog kontrolleret adgang til definerede porte, også med passende kontekst.

Det betyder, at selvom udnyttelsen tillader, at kommandoer udføres, er den kompromitterede proces Den kan ikke læse filer som f.eks. /etc/shadow nor touch-databasemapper mærket med specifikke typer (f.eks. mysqld_db_t), og heller ikke åbne vilkårlige forbindelser til andre interne tjenester, hvis netværkspolitikken begrænser det.

I stedet for en fuldstændig systemkompromittering er indtrængen begrænset til webstedets domæne . Ja, det vil stadig være en hændelse, der skal undersøges, men den potentielle påvirkning er meget lavere, og angriberen har meget sværere ved at operere.

Booleaner, moduler og værktøjer til justering af politikker

Udover korrekt mærkning drejer det daglige arbejde med SELinux sig normalt om at justere basispolitikken for mindre justeringer uden at skulle omskrive den helt . Det er her, booleske værdier og brugerdefinerede moduler kommer i spil.

masse booleske værdier SELinux Disse er tænd/sluk-knapper, der ændrer dele af den allerede kompilerede politiks funktionsmåde. For eksempel kan en boolsk værdi tillade eller forbyde FTP-serveren at skrive til bestemte mapper (i tilfælde af allow_ftpd_anon_write), eller at webserveren initierer udgående forbindelser til netværket.

med getsebool -a o semanage boolean -l Du kan liste disse kontakter og se deres beskrivelser. For at ændre dem permanent skal du bruge setsebool -P nombre_booleano on|offhvor muligheden -P sikrer, at ændringen gemmes på disken og overlever genstartDet er en meget bekvem måde at tilpasse den "officielle" politik til din servers specifikke behov.

På den anden side er brugen af politikmoduler Det giver dig mulighed for at udvide eller ændre regler uden at røre ved basispolitikken. Du kan se de aktive moduler med semodule -lat deaktivere en med semodule -d nombre eller genaktiver den med semodule -e nombreI SUSE/openSUSE er dette især nyttigt til finjustering af, hvilke dele af systemet du ønsker at have under SELinux' fokus, mens du stabiliserer din implementering.

Når du har brug for at give meget specifikke yderligere tilladelser, kan kombinationen af audit2allow y semodule Det gør livet meget lettere. Baseret på optegnelserne fra /var/log/audit/audit.log, audit2allow viser dig, hvilken regel der blev blokeret, og genererer et modul som, hvis du installerer det, tillader præcis det, der tidligere blev nægtet.

Logfiler, revision og fejlfinding med SELinux

Hver gang SELinux forhindrer en handling, som politikken ikke autoriserer, vil en AVC-afslag (Access Vector Cache-afvisning), der normalt registreres i /var/log/audit/audit.logforudsat at tjenesten auditd arbejder.

Disse poster indeholder en masse information: hvad der er blevet forsøgt at gøre (avc: denied { append }, write, getattrosv.), hvilken proces har anmodet om det (pid, comm=), på hvilken fil eller ressource (name=, dev=, ino=), hvilken kontekst havde den oprindelige proces (scontext) og hvilken kontekst destinationen (tcontext)I starten virker de som kryptiske linjer, men med lidt øvelse er de rent guld til at forstå, hvad der sker.

For at undgå at blive helt vanvittig med at læse loggen manuelt, kan værktøjer som ausearch tillad filtrering efter beskedtype (f.eks. -m AVC) eller via et midlertidigt vindue (-ts recent). Og frem for alt, audit2allow og forsyningsvirksomheder som f.eks. sealert hjælp til at oversætte disse begivenheder til næsten menneskeligt sprog og vis forslag.

En typisk fejlfindingsproces ville være at bruge audit2allow -w -a For at se forklaringer på de seneste meddelelser, så audit2allow -a o -i fichero at inspicere specifikke regler, og endelig beslutte, om det er umagen værd at oprette et modul, der låser op for den tilladelse Eller hvis blokken derimod er på den sikre side, og det er bedst ikke at røre ved den.

Når moduler genereres med audit2allow -M nombre og er installeret med semodule -iDet er værd at gennemgå disse indstillinger, fordi værktøjet har en tendens til at være generøst og kan give mere adgang end strengt nødvendigt. SELinux tilbyder en masse fleksibilitet til at begrænse adgang, men uforsigtig brug kan ende med at skabe smuthuller i selve politikken.

SELinux inden for en Linux-hærdningsstrategi

SELinux eksisterer ikke i et vakuum: det er integreret i en bredere hærdningsstrategi, der inkluderer brugere med begrænsede privilegier, firewalls, SSH-hærdning, anti-brute-force-mekanismer og konfigurationsautomatisering.

Et meget almindeligt mønster efter installation af en server er at oprette en bruger med begrænsede sudo-rettigheder for aldrig at fungere som direkte root, aktivere en netværksfirewall (såsom ufw eller iptables/nftables) , installere værktøjer som Fail2ban for at blokere gentagne adgangsforsøg og konfigurere SSH med god praksis (ikke-standard port, deaktivering af root-adgang, nøglegodkendelse, forsøgsgrænser, robust kryptering osv.).

Med udgangspunkt i dette fundament tilføjer SELinux MAC-laget: selvom en angriber får adgang til en bruger med forkert konfigurerede sudo-rettigheder eller en SSH-adgangskode, kan politikken stadig begrænse, hvilke processer og filer brugeren tilgår . Det er ikke idiotsikkert, men det lukker mange af de sårbarheder, der typisk udnyttes af automatiserede angreb beskrevet i matricer som MITRE ATT&CK.

Efterhånden som antallet af servere vokser, bliver det upraktisk at anvende alle disse hærdningsforanstaltninger manuelt. Det er her, automatiserings- og orkestreringsværktøjer (Ansible, Puppet, Chef, kommercielle automatiserede hærdningsløsninger osv.) kommer i spil, hvilket muliggør implementering af ensartede SELinux-politikker, justering af booleske værdier, sti-tagging og vedligeholdelse af ønskede tilstande uden at bruge timer pr. maskine.

I organisationer med hundredvis af noder kan denne automatisering være forskellen mellem at have et rimeligt homogent og sikkert miljø eller en jungle af inkonsistente konfigurationer, hvor SELinux er deaktiveret på halvdelen af ​​serverne, "så det ikke generer nogen".

I sidste ende, når SELinux er velimplementeret – med håndhævelsestilstand, konsistente kontekster, reviderede politikker, finjusterede moduler og overvågede logfiler – bliver det en slags sikkerhedsnet, der holder mærkelig adfærd på afstand, begrænser indtrængen og hjælper med at demonstrere, at der anvendes robuste adgangskontroller til revisioner, reguleringer og bedste praksis inden for sikkerhed.