Hur man använder revisionssystemet i CentOS 7

När våra roller och funktioner innebär att hantera alla element i företagsinfrastrukturen, oavsett om det är på nätverks- eller systemnivå, måste vi ha användbara verktyg för att övervaka, spåra händelser och säkerställa optimal prestanda för alla dess komponenter.

Idag kommer vi att granska hur man implementerar och använder Linux -revisionssystemet, ett verktyg för många okända. Vi vet att det finns tredjepartsverktyg som gör att vi kan hantera olika parametrar i systemet, men det här verktyget går utöver vad vi behöver och vi kommer att granska varför.

För denna handledning kommer vi att analysera verktyget i en miljö CentOS 7.

1. Känner till Linux -revisionssystemet

Med revisionssystemet kan vi uppdateras om den väsentliga säkerhetsinformationen i vårt system.

Revisionssystemet ger oss rapporter om alla händelser som inträffar i systemet baserat på fördefinierade regler; Det är viktigt att förtydliga att vi med revisionssystemet inte lägger till säkerhet till CentOS 7 men det gör att vi kan analysera vilka brister systemet har för att vidta korrigerande åtgärder.

Information som kan analyseras

• Databasändringar, till exempel sökvägsändringar / etc / passwd.

• Revisionssystemet anger datum, tid och typ av händelse.

• Försök att importera eller exportera information inom systemet.

• Användarverifieringsmekanismer.

• Alla ändringar av granskningsändringar och försök att få tillgång till bland annat granskningsloggar.

2. Kontrollera installationen av revisionssystemet

Inom revisionssystemet har vi två viktiga system att ta hänsyn till:

1. Kärnan i revisionssystemet tar alla händelser som behandlas av användaren och skickar denna information till granskningsdemon.

2. Revisionsdemon tar denna information och skapar poster.

Revisionssystemet hanterar två paket: granska Y revisions-libsDessa är installerade som standard i CentOS 7, vi kan kontrollera deras installation med följande kommando:

 sudo yum list revision revisions-libs

Om vi ​​inte har dem kan vi installera revisionssystemet med följande kommando:

 sudo yum installera granskning

När de har installerats måste vi se följande text:

 Installerade paket audit.x86_64 audit-libs.x86_64

Låt oss gå vidare till systemkonfigurationen.

3. Konfigurera granskningssystemet i CentOS 7

När vi har bekräftat att vi har de nödvändiga paketen kommer vi att ändra konfigurationen av filen auditd.conf och det är i den här filen som vi har möjlighet att konfigurera registren, händelserna och andra. För att komma åt den här filen använder vi följande kommando:

 sudo nano /etc/audit/auditd.conf

Följande fönster visas:

De viktigaste parametrarna

• num_logs: Det gör det möjligt att definiera antalet loggar som ska registreras i utrustningen.

• max_log_file: Med denna parameter kan vi definiera maximal loggstorlek.

• mellanslag_vänster: Vi kan ange mängden ledigt diskutrymme.

• disk_full_action: Vi kan definiera en viss åtgärd för när disken är full.

Som vi kan se kan vi justera olika parametrar. Om vi ​​till exempel vill att antalet loggar ska vara 12 raderar vi helt enkelt standardvärdet (5) och lägger till det önskade (12). Om vi ​​vill ändra storleken på loggarna till 20 ändrar vi helt enkelt standardvärdet (6) till det som krävs (20).

Vi sparar ändringarna med hjälp av kombinationen Ctrl + O och vi lämnar redaktören med hjälp av kombinationen Ctrl + X. När ändringarna har bearbetats måste vi starta om granskningstjänsten med kommandot:

 sudo service auditd starta om

NoteraOm vi ​​vill redigera parametrarna för reglerna måste vi redigera filen audit.rules med följande kommando:

 /etc/audit/rules.d/audit.rules

4. Förstå systemgranskningsloggar i CentOS 7

Som standard lagrar revisionssystemet alla händelser som inträffade i CentOS i sökvägen /var/log/audit/audit.log och dessa filer innehåller mycket information och kod som kanske inte är så lätt för många av oss att förstå men Solvetic tar hand om att sammanfatta dessa filer lite.

För att demonstrera hur revisionssystemet fungerar har vi skapat en regel som heter sshconfigchange och den kan skapas med följande kommando:

 sudo auditctl -w / etc / ssh / sshd_config -p rwxa -k sshconfigchange

För att se regeln använder vi följande syntax:

 sudo cat / etc / ssh / sshd_config

Nu ska vi se loggen som skapats av systemgranskningsverktyget genom att ange följande:

 sudo nano /var/log/audit/audit.log

Vi kommer att förlita oss på tre (3) vitala poster:

• SYSCALL
• CWD
• VÄG

Dessa filer är sammansatta enligt följande:

• Nyckelord: Avser namnet på processen (PATH, CWD, etc)
• Tidsstämpel: Avser datum och tid (1469708505.235)
• Gå: Består av ID för händelsen i fråga (153)

SYSCALL -händelse
SYSCALL avser meddelandet som genereras av ett kärnsamtal från revisionssystemet, msg -fält = granskning (1469708505.235:153):

I tidsstämpel och ID -fält vi ser att dessa tre poster har samma värde (1469708505.235: 153) vilket indikerar att dessa tre poster lagrades med samma granskningshändelse.

De bågfält refererar till maskinens arkitektur, i det här fallet anger 40000003 att det är i386, om det vore värdet c000003e skulle det referera till en x86_64 -maskin.

De Syscall -fält den nämner vilken typ av samtal som skickades till systemet. Värdet kan variera, i det här fallet är det 5. Vi kan använda kommandot sudo ausyscall 5 för att se status för tjänsten (öppen).

Det finns mer än 300 värden, om vi vill se vad värdena betyder i allmänhet kan vi använda kommandot:

 sudo ausyscall -dump

Och vi kommer att se alla värden och deras betydelse:

De Framgångsfält Den berättar om evenemangssamtalet lyckades eller inte, ja eller nej. Vi kan hitta SYSCALL -händelsen och rulla åt vänster för att se andra rapporter som ingår.

De uid -fält avser användaren som startade granskningstjänsten, i det här fallet är det uid = 0.

De kommande fält det hänvisar till kommandot som användes för att visa meddelandet, så vi ser att det visas som comm = "cat".

De exe -fält Det indikerar sökvägen till kommandot som genererade granskningshändelsen, vi kan se i detta exempel att det är exe = " / usr / bin / cat".

CWD -evenemang
I CWD-händelsen kan vi märka att det inte finns samma information som i SYSCALL, här har vi katalogen som används för att spara händelserna, CWD- Current Working Directory, därför ser vi värdet cwd = ” / home / solvetic”.

PATH -evenemang
I den senaste händelsen, PATH, ser vi att namnfält som hänvisar till filen eller katalogen som användes för att skapa granskningen, i det här fallet ser vi följande: name = " / etc / ssh / sshd_config".

5. Sök efter revisionshändelser efter specifika händelser

Ett av de mest intressanta sätten att söka efter en händelse i CentOS 7 är genom att använda syntaxen:

 sudo ausearch -m Event_name -börja idag -i

Detta kommando låter oss filtrera en viss händelse och behöver inte söka i hela händelsesfilen eftersom den är omfattande. I det här fallet kommer vi att söka efter alla händelser som är associerade med inloggningen, därför kommer vi att ange följande:

 sudo ausearch -m LOGGA IN -börja idag -i

Resultatet blir följande:

Det är också möjligt att filtrera sökningen efter händelse -ID för detta kommer vi att använda följande syntax:

 sudo ausearch -a Event_ID

Därefter kommer vi att se hur vi genererar rapporter.

6. Skapa granskningsrapporter

Ett av sätten att bättre hantera händelser är med en detaljerad rapport om vad som händer i CentOS 7 och med revisionssystemet kan vi generera rapporter som är enkla och tydliga att förstå för att hjälpa oss i vår ledning. För detta kommer vi att använda kommandot:

 sudo aureport -x -summary

Och vi kommer att se resultatet erhållet:

Den första kolumnen som vi ser indikerar antalet gånger kommandot har körts och den andra kolumnen anger vilket kommando som utfördes. På samma sätt kan vi generera en rapport med de misslyckade händelserna med kommandot:

 sudo aureport -misslyckades

Om vi ​​vill generera en rapport med användarnamnen och systemanropen använder vi kommandot:

 sudo aureport -f -i

7. Hur man analyserar processer individuellt

Det är möjligt att vi ibland måste analysera processer individuellt och inte en hel katalog, för detta kommer vi att använda autrace, det här verktyget låter oss övervaka systemanrop till en viss process. Autrace -resultaten lagras i sökvägen:

 /var/log/audit/audit.log

Till exempel vi kommer att analysera sökvägen / bin / datum, för detta kommer vi att använda följande:

 sudo autrace / bin / date

Vi ser att händelsen med ID 16541 har skapats. Nu går vi in ​​på följande kommando för att se händelseöversikten:

 udo ausearch -p 16541 --raw | aureport -f -i

På så sätt kan vi analysera filer individuellt. I följande länk kan vi se alla typer av poster som kan granskas av revisionssystemet i CentOS 7.

På detta sätt ser vi hur revisionssystemet i CentOS 7 kan hjälpa oss att hantera och övervaka händelser som inträffar i våra datorer och på så sätt säkerställa att vi har ett säkert, stabilt och optimalt system.

Slutligen lämnar vi dig en handledning om det gratis WinAudit -verktyget för att utföra granskningar i Windows:

Granska med WinAudit