Linux

Linux härdning är enklast när du behandlar systemet som en samling av små, komponerbara behörigheter. Kärnidén är enkel: minska det som är tillgängligt, minska det som är tillåtet och minska det man litar på.

En användbar mental modell är exponeringstider tillstånd är lika med risk. Exponering är öppna tjänster och nåbara gränssnitt. Behörighet är vad koden kan göra efter att den startar. Trust är vilka paket och konfigurationer du accepterar som giltiga.

Linux ger dig många kontroller, men det svåra är konsekvens. Små skillnader mellan värdar, distributioner och team kan skapa luckor som angripare utnyttjar eftersom miljön blir oförutsägbar.

• Minimera tjänster och lyssningsuttag eftersom de definierar fjärringång.

• Minimera privilegier och funktioner eftersom de definierar lokal påverkan.

• Minimera förtroendegränser genom att separera roller, användare och arbetsbelastningar.

Verkliga Linux incidenter börjar ofta med ett av tre mönster: en exponerad tjänst, en svag referensväg eller en överraskning i leveranskedjan. En bra baslinje prioriterar kontroller som blockerar dessa mönster över många arbetsbelastningar.

Serviceexponering handlar inte bara om hamnar. Det handlar också om vem som kan nå dem, vilket gränssnitt de binder till och om de kör med onödiga behörigheter. Standard för att bara binda till det du behöver.

Autentiseringssökvägar inkluderar SSH, lokala konton, API tokens i filer och programhemligheter. Härdning handlar dels om att minska var hemligheter bor och dels om att begränsa vad en angripare kan göra om en läcker.

Försörjningskedjans risk är operativ. Om du installerar från många källor, kör okända skript som root eller hoppar över uppdateringar är din baslinje ömtålig. Föredrar färre förråd, signerade paket och en repeterbar installationshistoria.

Avvägning att förvänta sig: härdning kan kosta bekvämlighet. Snäva behörigheter och strikta tjänster kan bryta automatisering och utvecklarverktyg. Det säkra förhållningssättet är att separera miljöer eller roller istället för att försvaga allt för alla.

När du behöver kompatibilitet, sikta på snävare ändringar, som att tillåta en tjänstfunktion, snarare än breda ändringar som att inaktivera en kontroll globalt.

En ofta förekommande fälla är att härda värden men att glömma appen. Om programmet körs som root, skriver hemligheter till världsläsbara filer eller inte har någon patch-kadens, tvingas värdhärdning att kompensera och misslyckas ofta.

En annan fälla är att lita för mycket på nätverksgränser. Många Linux-servrar kan nås från platser som folk inte hade tänkt sig på grund av VPNs, molnsäkerhetsgrupper, containernätverk eller platta interna nätverk.

Privilegekrypning är också vanligt. Med tiden får fler användare sudo åtkomst, fler tjänster körs som privilegierade och fler undantag läggs till. Baslinjen blir långsamt ett förslag snarare än en regel.

Överhärdning kan också vara en fälla. Om du gör ändringar som är svåra att felsöka, kommer operatörerna att kringgå dem under press. Det skapar en splittrad hjärnmiljö med odokumenterat beteende.

• Tysta fel: en kontroll konfigureras men tillämpas inte, till exempel en policy i tillåtande läge eller en tjänst som startas med en annan enhetsfil.

• Inkonsekvent konfiguration: samma roll beter sig olika mellan värdarna, vilket gör både övervakning och incidentrespons svårare.

Inneslutning är där Linux lyser när den används avsiktligt. Tänk i termer av att minska vad en process kan se, röra och anropa. Även om kodexekvering sker, kan inneslutning förhindra privilegieskalering och datastöld.

Använd obligatorisk åtkomstkontroll när det är lämpligt. SELinux eller AppArmor kan vara frustrerande i början, men de ger en stark gräns som är svår att replikera med enbart filbehörigheter. Avvägningen är policyunderhåll och felsökningsförmåga.

Isoleringsverktyg spelar också roll. Namnutrymmen, cgroups och containerkörningstider kan vara en del av en hårdnande historia, men bara om du behandlar dem som säkerhetsgränser med tydliga antaganden.

Systemd kan också minska risken genom att begränsa en tjänst under körning, som att begränsa filsystemåtkomst och systemanrop. Detta är kraftfullt eftersom det hårdnar tjänsten utan att kräva kodändringar.

När ska man koppla av inneslutningen: ofta för äldre programvara, leverantörsagenter eller felsökning. Det säkra mönstret är att bara koppla av för den specifika tjänsten och hålla resten strikt, sedan dokumentera orsaken och en plan för att återbesöka.

Dokumentera undantag med ett test: vad ska du kontrollera senare för att bekräfta att du kan dra åt igen utan att avbryta produktionen.

Verifiering på Linux bör fokusera på effektivt tillstånd, inte avsett tillstånd. Många system ser härdade ut på papper men körs med olika körtidsinställningar, anpassade enhetsöverstyrningar eller föråldrade paket.

Börja med exponeringskontroller: lista lyssningsportar, tjänster och gränssnitt. Det ser bra ut som att bara förväntade tjänster lyssnar, och administrationstjänster är endast tillgängliga från kontrollerade nätverk.

Verifiera sedan behörighet och integritet: kontrollera vilka konton som har sudo, vilka tjänster som körs som root och om viktiga filer är skyddade från modifiering. Om du använder integritetsverktyg, bekräfta att det faktiskt rapporterar ändringar.

Så här verifierar du och hur det ser ut:

• Exponering: inga oväntade lyssningsuttag, och brandväggar eller säkerhetsgrupper matchar dokumenterad avsikt

• Konton: minimala sudo användare, inga inaktuella konton och tydligt ägande för tjänstekonton

• Policy: SELinux tillämpar eller AppArmor-profiler tillämpas där det är avsett, inte tyst inaktiverat

• Drift: konfigurationshanteringsrapporter konvergerar och manuella redigeringar är sällsynta och granskas

När du ska koppla av detta: för kortlivade labbvärdar eller isolerade byggmaskiner. Redan då, skriv ner vad som är avslappnat, och håll åtminstone grundläggande lappning och kontohygien eftersom dessa misslyckanden lätt går mellan miljöer.