Hur man begränsar antalet lösenordsförsök i Linux

Kontrollera hur många gånger ett lösenord kan misslyckas i Linux Det är en av de säkerhetsåtgärderna som nästan alltid skjuts upp till "senare"... tills du en dag ser tusentals misslyckade inloggningsförsök i loggarna eller en användare som är utelåst utan någon uppenbar anledning. Att korrekt konfigurera dessa gränser skyddar inte bara mot brute-force-attacker, utan hjälper dig också att undvika absurda utelåsningar eller problem med kritiska tjänster.

I Linux har vi flera lager där autentiseringsförsök kan begränsasspecifika PAM-moduler som t.ex. pam_faillock y pam_tally2, SSH-serverdirektiv som t.ex. MaxAuthTriesparametrar i /etc/login.defs och lösenordspolicyverktyg som till exempel pam_cracklib o pam_pwqualityAtt förstå hur de alla hänger ihop är nyckeln till att bygga en sammanhängande politik och undvika överraskningar.

Blockera konton för misslyckade inloggningsförsök i Linux: en översikt

Grundidén är enkel: begränsa misslyckade försök och blockera kontot tillfälligt eller permanent när den tröskeln överskrids. Praktiken blir mer komplicerad eftersom flera komponenter är inblandade: PAM, SSH, systemkonfiguration och, beroende på distributionen, olika moduler.

I Red Hat-liknande distributioner (RHEL, CentOS, Rocky, Alma…) Det moderna tillvägagångssättet är att använda modulen pam_faillock, som registrerar autentiseringsfel och tillämpar automatiserade lås med konfigurerbara upplåsningstider.

I Debian- och Ubuntu-baserade miljöer har traditionellt använts pam_tally2 att räkna misslyckade inloggningsförsök och neka inloggningar över en viss tröskel. Även om nyare versioner migrerar mot fellåsI många produktionsservrar är pam_tally2 fortfarande det som verkligen styr.

Förutom PAM har SSH-daemonen ett eget MaxAuthTries-direktiv.Detta begränsar antalet autentiseringsförsök som tillåts per anslutning. Det blockerar inte konton i sig, men det minskar en angripares möjlighet att testa autentiseringsuppgifter på en enda SSH-kanal.

Slutligen, filer som /etc/login.defs och moduler för lösenordskvalitet De kontrollerar aspekter som antalet försök vid lösenordsändring, minsta komplexitet, utgångsdatum eller längd, samt hur väl kontosäkerhetspaketet slutförs.

Kontoutlåsning på grund av misslyckade inloggningsförsök på Red Hat, CentOS och derivator (pam_faillock)

I Red Hat-ekosystemet hanteras blockering av autentiseringsfel med modulen pam_faillock.Denna modul är centraliserad integrerad i PAM-stacken. Den konfigureras vanligtvis i följande filer: /etc/pam.d/system-auth och, i vissa versioner, även i /etc/pam.d/lösenordsautentisering.

För att aktivera ett lås efter flera misslyckade försök Rader som dessa läggs till i blocken av auth y konto av dessa PAM-filer (de exakta detaljerna kan variera beroende på version, men idén är denna):

auth required pam_faillock.so preauth silent audit deny=2 unlock_time=120
auth pam_faillock.so authfail audit deny=2 unlock_time=120
account required pam_faillock.so

Dessa parametrar definierar blockets grundläggande beteende.:

• revisionregistrerar misslyckade försök och krascher i systemloggarna, vanligtvis i / Var / log / säkra eller tidskriften.
• neka=2: blockerar kontot efter 2 misslyckade försök.
• upplåsningstid=120Kontot låses upp automatiskt efter 120 sekunder (2 minuter).
• tyst: döljer för användaren att kontot är låst, vilket gör det svårare för en angripare att blint testa lösenord.

En viktig punkt: som standard är root vanligtvis uteslutet från detta block.Om du vill att begränsningar även ska gälla för administratörskontot måste du lägga till parametern even_deny_root på linjerna av auth, med risken att ett konfigurationsfel kan lämna dig utan åtkomst om du glömmer ditt lösenord eller bryter SSH.

När ett konto är låst på grund av pam_faillock får användaren ett specifikt meddelande när hen försöker autentisera sig. om vi inte använder alternativet tystDetta hjälper supporten att snabbt identifiera att det inte är ett ändrat lösenord, utan en tillfällig utlåsning på grund av för många felaktiga försök.

För att granska misslyckade försök och en användares låsstatus verktyget används fellås i administratörsläge:

# faillock --user lionel

Kommandot visar hur många försök som har samlats och från vilken IP-adress eller TTY-adressunderlättar utredningen av misstänkta försök. Och om du behöver frigöra en användare utan att vänta på upplåsningstidNollställ bara din räknare:

# faillock --user lionel --reset

Det finns också konfigurationsfilen /etc/security/faillock.confdär globala parametrar kan definieras utan att direkt beröra PAM-filerna, till exempel:

deny = 3
fail_interval = 600
unlock_time = 900

I den här filen kan du justera antalet försök, beräkningsfönstret och låstiden. på ett mer ordnat sätt, centralisera politiken utan att PAM-linjerna blir så mycket grumliga.

Kontoutlåsning i Debian och Ubuntu med pam_tally2

I klassiska Debian- och Ubuntu-system är modulen som ansvarar för att räkna misslyckade försök pam_tally2.Den här modulen hanterar en räknefil (som standard). /var/log/tallylog) där den lagrar autentiseringsfelen per användare.

För att aktivera en blockeringspolicy baserad på antalet fel filen redigeras vanligtvis /etc/pam.d/common-auth och lägg till en rad som denna:

auth required pam_tally2.so onerr=fail deny=3 unlock_time=120 audit even_deny_root root_unlock_time=600

Kombinationen av alternativ möjliggör mycket finare kontroll över beteendet:

• onerr=misslyckasOm ett fel uppstår i modulen (till exempel ett problem med tallylog) nekas åtkomst av säkerhetsskäl.
• neka=3: blockerar kontot efter 3 misslyckade försök.
• upplåsningstid=120Kontot låses upp automatiskt efter 120 sekunder.
• revision: registrerar händelser i /var/log/auth.log.
• even_deny_rootinkluderar användaren rot i blockeringspolicyn.
• root_unlock_time=600: ställer in en annan låstid för root (till exempel 600 sekunder) fastän upplåsningstid vara någon annan.

När ett konto är låst visar systemet ett specifikt meddelande. vilket indikerar att det maximala antalet försök har överskridits; användaren fortsätter därmed inte att försöka och administratören vet att incidenten inte är ett enkelt "Jag har glömt lösenordet".

Så här kontrollerar du försöksräknaren för en specifik användare programmet används pam_tally2 (utan .so) med parametern -u:

# pam_tally2 -u lionel

Kommandot visar antalet fel, om kontot är låst och sedan när.Dessutom kan vi från samma verktyg återställa räknaren genom att lägga till alternativet -återställavilket frigör användaren utan att behöva vänta på att låstiden ska gå.

Händelser associerade med pam_tally2 loggas normalt i /var/log/auth.logså det är enkelt att integrera dem i övervakningssystem eller SIEM för att utlösa varningar när avvikande mönster av misslyckade försök upptäcks.

Begränsa SSH-försök: MaxAuthTries och andra åtgärder

SSH-tjänsten är en av de viktigaste gatewayerna till en Linux-serverDärför är det lämpligt att installera flera lås. Ett av de enklaste är direktivlåset. MaxAuthTries från själva SSH-daemonen, specifikt utformad för att begränsa misslyckade försök på samma anslutning.

MaxAuthTries definierar hur många autentiseringsförsök som kan göras innan servern stänger SSH-sessionen.Det blockerar inte kontot, men det avbryter anslutningen och tvingar dig att öppna den igen, vilket avsevärt saktar ner brute-force-attacker.

För att konfigurera det måste du redigera SSH-konfigurationsfilen. (vanligtvis / Etc / ssh / sshd_config) och justera direktivet:

MaxAuthTries 3

I många system är standardvärdet vanligtvis 6, vilket är ganska generöst för en server som är exponerad för internet.Att minska det till 3 eller till och med 2 innebär att varje anslutning tillåter väldigt få försök innan den tvingas stängas.

Det är viktigt att förstå att MaxAuthTries inte ersätter pam_faillock eller pam_tally2.Den sätter helt enkelt en gräns per anslutning, medan PAM bibehåller global kontroll per användare och kan blockera konton under en tidsperiod.

Förutom att modifiera MaxAuthTries finns det andra grundläggande rekommendationer för SSH-härdning.:

• Ändra standardporten (22) till en mindre uppenbar.minska bruset från botar som skannar internet.
• Använd autentisering med offentlig nyckel istället för lösenord, eller åtminstone kräva lösenord för administratörsanvändare.
• Kombinera SSH med brandväggar och vitlistorendast tillåta åtkomst från betrodda IP-adresser eller intervall.
• Inaktivera direkt root-inloggning via SSH och tvinga fram användningen av sudo från personliga konton.

Om du använder Ubuntu och vill minska antalet gånger du blir ombedd att ange ditt lösenord när du loggar in i det grafiska gränssnittetAtt experimentera med MaxAuthTries i SSH kommer inte att lösa någonting: de är helt separata problem. I så fall är det PAM-stacken som används av inloggningshanteraren (LightDM, GDM, etc.) som spelar roll, så du måste kontrollera dess konfigurationsfiler. /etc/pam.d, ingen sshd_config.

Lösenordspolicyer: komplexitet, utgångsdatum och antal försök

Att begränsa misslyckade försök är bra, men om lösenorden är "123456" eller "qwerty" kommer du inte att komma särskilt långt.En viktig del av härdning i Linux är att definiera en riktig lösenordspolicy som kräver användning av starka lösenord och, när det är rimligt, att de förnyas regelbundet.

Målet med en bra policy är att förhindra att användare väljer förutsägbara eller återanvända lösenord.Detta kräver en minimikombination av längd, komplexitet och rimliga periodiska ändringar. Detta gäller både vanliga användare och privilegierade eller kritiska tjänstkonton.

De viktigaste punkterna i en anständig lösenordspolicy i Linux de är vanligtvis:

• Skapa starka lösenordminsta längd (minst 12 tecken), en blandning av stora bokstäver, små bokstäver, siffror och symboler, och undvik ord i ordboken.
• Undvik att återanvända lösenord: förhindrar att en användare återgår till ett tidigare använt lösenord.
• Fastställ ett rimligt utgångsdatum: tvinga fram förändringen med några dagars mellanrum, utan att bli besatt av absurt täta rotationer.
• Begränsa antalet försök när du ändrar ditt lösenord.förhindra att en användare spenderar en halvtimme på att prova svaga lösenord tills ett fungerar.
• Komplettera med multifaktorautentisering där det är möjligtsärskilt i externa åtkomstpunkter eller administrationspaneler.

I företagsmiljöer är dessa policyer viktiga. För att följa regler, revisioner och säkerhetsstandarder. På personliga servrar kan detta verka överdrivet, men när du är värd för tjänster som är tillgängliga från internet är skillnaden mellan en robust säkerhetspolicy och att inte ha någon alls enorm.

Konfigurera lösenordspolicyer med pam_cracklib och pam_pwquality

PAM-moduler som specialiserar sig på lösenordskvalitet möjliggör detaljerad kontroll över lösenordens egenskaper.Historiskt sett har det använts pam_cracklibMen det blir allt vanligare. pam_pwquality, vilket lägger till förbättringar och ytterligare alternativ.

I Debian och Ubuntu är det första steget att installera motsvarande bibliotek om den inte redan finns:

sudo apt install libpam-cracklib libpam-pwquality libpwquality-tools

pam_cracklib konfigureras vanligtvis från /etc/pam.d/common-passwordDet är vanligt att ha en rad som denna:

password requisite pam_cracklib.so retry=3 minlen=12 difok=3 ucredit=-3 lcredit=-3 dcredit=-3 ocredit=-3

Varje parameter styr en aspekt av det obligatoriska lösenordet.:

• Försök igenantal försök som användaren har angett ett giltigt lösenord innan kommandot misslyckas.
• minlenminsta lösenordslängd.
• difokminsta antal olika tecken jämfört med det föregående lösenordet.
• ukredit: med ett negativt värde krävs det att man har minst den mängden stora bokstäver.
• lkredit: med ett negativt värde krävs minst gemener.
• dkredit: med ett negativt värde krävs minst siffriga.
• okkredit: med ett negativt värde innebär minst symboler eller andra specialtecken.

Positiva krediter fungerar som ett "bonussystem"Ett lösenord kan vara något kortare om det kompenserar med större komplexitet i andra teckenklasser. Negationer, å andra sidan, anger obligatoriska krav: "minst X versaler", etc.

pam_pwquality lägger till ännu fler alternativ, konfigurerade i /etc/security/pwquality.confdär parametrar som följande kan justeras:

• difokantal olika tecken jämfört med det föregående lösenordet.
• minlenminsta längd.
• dcredit, ucredit, lcredit, ocreditkrediter per karaktärstyp, precis som i cracklib.
• minklassMinsta antal olika klasser (gemener, versaler, siffror, symboler) som krävs.
• maxrepeat: maximalt antal tecken som upprepas i följd.
• maxclassrepeatmaximalt antal på varandra följande tecken av samma klass.
• gecocheckavvisar lösenord som innehåller data från användarens GECOS-fält (fullständigt namn, etc.).
• diktväg: väg till ordböcker för att blockera alltför uppenbara ord.
• badwords: specifik lista över förbjudna ord.

Modulen kan till och med upptäcka palindromer, triviala ändringar i stora/små bokstäver eller lösenord som är nästan identiska med tidigare lösenord.och undvika de typiska fällorna med "Jag lägger bara till en 1:a i slutet och det är allt".

Ett mycket användbart verktyg som följer med pwquality är pwscore.vilket låter dig mäta kvaliteten på ett lösenord baserat på den aktuella konfigurationen:

# echo 123 | pwscore
Falló la comprobación de calidad de la contraseña:
La contraseña tiene menos de 8 caracteres

Med ett riktigt komplext lösenord returnerar pwscore en hög poäng, vanligtvis upp till 100, vilket tjänar till att bekräfta att den policy du har definierat varken är för slapp eller omöjlig att följa.

Hantera lösenordsutgång och ålder: change, /etc/shadow och login.defs

Förutom komplexiteten är det vanligt att övervaka hur länge ett lösenord kan hålla innan det behöver ändras.I Linux lagras denna information i filen / Etc / shadow och hanteras enkelt med kommandot jage och direktiven från /etc/login.defs.

Filen /etc/shadow lagrar, för varje användare, det krypterade lösenordet och utgångsdatumetLösenordsfältet är strukturerat enligt följande $id$salt$hashDär id indikerar vilken algoritm som använts (till exempel $ 6 $ för SHA-512). Andra fält anger den senaste lösenordsändringen, giltighetsdagar, varningsdagar före utgångsdatum, inaktivitetsdagar efter utgångsdatum etc.

Med kommandot "ändra" kan du visa och ändra dessa värden på enskild användarnivå.Några viktiga alternativ:

• -l: visar information om kontots utgångsdatum.
• -mminsta antal dagar mellan lösenordsändringar.
• -M: maximalt antal dagar lösenordet är giltigt.
• -W: dagars uppsägningstid före utgången.
• -E: kontots utgångsdatum.
• -I: dagar av inaktivitet efter utgångsdatum innan kontot deaktiveras.

Ett typiskt exempel på en fråga skulle vara:

# chage -l pepe
Last password change : Apr 18, 2020
Password expires : never
Password inactive : never
Account expires : never
Minimum number of days between password change : 0
Maximum number of days between password change : 90
Number of days of warning before password expires : 5

För att definiera standardvärden för nya användare, använd /etc/login.defs, där globala direktiv upprättas, såsom:

• PASS_MAX_DAYSmaximalt antal dagar ett lösenord kan användas (t.ex. 90).
• PASS_MIN_DAYSminsta antal dagar mellan lösenordsändringar.
• PASS_WARN_AGE: dagars uppsägningstid före utgången.
• PASS_MIN_LEN och PASS_MAX_LEN: minsta och största längd, även om detta i praktiken vanligtvis delegeras till PAM.
• PASS_CHANGE_TRIESmaximalt antal försök att ändra lösenord om nyckeln avvisas som svag.
• KRYPTERINGSMETOD: hashalgoritm som används (till exempel, SHA512).
• LOGIN_REFREESÅterförsök tillåts vid inloggning innan avbrott.
• LOGIN_TIMEOUT: maximal tid i sekunder för att ange inloggningsuppgifter.

En viktig detalj: login.defs-direktiv påverkar användare som skapas efter att de har ändrats.Befintliga konton behåller sina värden och måste justeras därefter. jage om vi vill att de ska följa den nya policyn.

Integrera försöksgränser med företagets policyer och bästa praxis

I professionella miljöer räcker det inte att sätta ett par parametrar och hålla tummarna.Lösenordspolicyer och policyer för misslyckade inloggningsförsök måste vara i linje med organisationens verklighet och med identitetsplattformar som nyckelmantel och med effekten av att blockera tjänstkonton eller nyckelanvändare.

Till exempel att aggressivt blockera ett tjänstkonto som kör en kritisk process Ett helt system kan bli obrukbart om ett skript fastnar i en loop och försöker använda felaktiga inloggningsuppgifter. I dessa fall är det nödvändigt att bedöma om man ska undanta det kontot från blockering eller implementera alternativa skyddsmekanismer.

Det är också viktigt att ta hänsyn till aktuella rekommendationer från organisationer som NISTDessa system prioriterar lösenordslängd och komplexitet framför alltför frekvent tvångsmässig lösenordsrotation. Att tvinga fram ändringar var 90:e dag är i allmänhet rimligt, men att göra det var 30:e dag kan leda till förutsägbara lösenord som "Lösenord01", "Lösenord02" etc.

Användarutbildning är en ofta förbisedd aspekt.Oavsett hur bra din PAM-konfiguration är, om folk fortsätter att skriva sina lösenord på post-it-lappar som sitter på sina skärmar, är all din ansträngning bortkastad. Att förklara orsakerna bakom policyerna hjälper folk att följa dem lättare.

Slutligen, kombinationen av alla dessa åtgärder med tvåfaktorsautentisering Där det är möjligt (VPN, paneler, SSH med OTP, etc.) mångfaldigar det säkerheten utan att förlita sig så mycket på att ha ett perfekt lösenord.

Genom att kombinera gränser för lösenordsförsök, tillfälliga lås och rimliga komplexitets- och utgångspolicyerGenom att stärka SSH-åtkomsten uppnås ett mycket mer motståndskraftigt ekosystem mot brute-force-attacker och mänskliga fel, utan att användarnas vardag förvandlas till en omöjlig mardröm.