Archiv pro štítek: audit

Konfigurace a kontrola Audit Policy

Randy Smith shrnuje ve svém článku Security Log Step-by-Step: Avoiding Audit Policy Configuration Pitfalls zásady správného nastavení bezpečnostního auditu ve Windows a upozorňuje na problémy, které způsobuje nekompatibilita starších nástrojů (rsop.msc, gpresult) – nezobrazují správně nastavení auditu zavedená ve verzi Windows Vista a Server 2008. Viz také článek Getting the Effective Audit Policy in Windows 7 and 2008 R2 na webu Technet.

To make things interesting, all of this can be configured through domain policy, local policy, multiple-local policy, per-user, or using command-line tools. Like most security policy that has evolved through 20 years of Windows, it’s a bit of a Frankenstein’s monster. Making sense of what settings are actually in place in Win7 and 2008 R2 can be a real pain in the neck.

Doporučení podle Randyho pro konfiguraci Audit Policy ve Win2008R2/Win7 :

  1. Nepoužívej Local Security Policy
  2. Nepoužívej auditpol /set
  3. Ke konfiguraci Audit Policy použij objekty group policy v Active Directory
  4. Vždy povol „Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings a pro novější systémy Win2008R2+  ignoruj 9 původních kategorií auditu.
  5. Konfiguruj všechny subkategorie – aby bylo jasně definováno, zda je výslovně povolená nebo zakázaná.
  6. K ověření nastaveného stavu nepožívej Local Security Policy, Group Policy Results Wizard, RSOP ani gpresults
  7. Místo toho vypiš aktuální nastavení příkazem „auditpol /get /category:*
  8. Monitoruj výskyt událostí 4719, ve kterých není jako uživatel uveden samotný systém. Taková událost indikuje, že se někdo pokouší dočasně změnit tvoje předepsaná nastavení auditu z GPO. To je vážný problém, indikuje něco zlého.

SCOM: jak monitorovat vazbu GPO na OU v Active Directory

V systému, ve kterém používáme zásady skupiny (group policy) k nastavení konfigurace serverů a koncových počítačů uživatelů k vynucení důležitých položek (např. z bezpečnostních důvodů), může změna vazby (link) na organizační jednotku (OU) v Active Directory indikovat bezpečnostní problém. Jak nám SCOM 2007 může pomoci a co je třeba sledovat?

Nejprve musíme zajistit na doménových řadičích zapnutí Audit Policy: Directory Service Changes, nejlépe v Default Domain Controllers Policy (Computer Configuration / Policies / Windows Settings / Security Settings / Advanced Audit Policy Configuration / Audit Policies)

Vytvoříme výstrahu (alert), reagující na událost v bezpečnostním logu 5136: A directory service object was modified, přičemž nás zajímá změna atributu gPLink. Událost 5136 a její parametry (%n) podle dokumentace Microsoftu (Windows 7 and Windows Server 2008 R2 Security Event Descriptions.xls) vypadá takto

A directory service object was modified.

Subject:
Security ID: %3
Account Name: %4
Account Domain: %5
Logon ID: %6

Directory Service:
Name: %7
Type: %8

Object:
DN: %9
GUID: %10
Class: %11

Attribute:
LDAP Display Name: %12   <--- gPLink
Syntax (OID): %13
Value: %14

Operation:
Type: %15                <--- (Value Added, Value Deleted) 
Correlation ID: %1
Application Correlation ID: %2

Podmínka tedy bude vypadat takto pro výstrahu při odebrání vazby GP na OU:

(Event ID Equals 5136) And (Parameter 15  Equals Value Deleted) And (Parameter 12 Equals gPLink)

nebo pro přidání vazby:

(Event ID Equals 5136) And (Parameter 15  Equals Value Added) And (Parameter 12 Equals gPLink)

 

Windows: global object access auditing policy

Jak nastavit systém, aby vytvářel auditní záznamy týkající se všech objektů na počítači?

SACL (system access control lists) jsou seznamy, které řídí audit na úrovni jednotlivých objektů. Pokud potřebujeme mít jistotu, že je audit nastaven, museli jsme postupně všechny (alespoň ty důležité) objekty kontrolovat, jeden po druhém.

V nejnovějších verzích Windows Server 2008 R2 a Windows 7 lze definovat globální politiku pro celý počítač (global object access auditing policy), pro celý souborový systém nebo registry. Zvolený SACL je pak automaticky přiřazen každému objektu vybraného typu. Ve výsledku je záznam generován, pokud vyhoví kombinaci globálního nastavení a lokálního nastavení SACL.

V konfiguraci (global object access auditing policy) lze uvést jednotlivý účet nebo skupinu, jejichž aktivitu sledujeme. Z toho je zřejmé použití v různých scénářích: sledování aktivity vybrané skupiny uživatelů nebo správců či diagnostika – když hledáme konkrétní objekty pro jednotlivého uživatele, ke kterým nemá přístup (hlášení „access denied“), což znemožňuje uživateli zamýšlenou činnost.

Technet: Global Object Access Auditing

Struktura EventSchema.xml

Soubor EventSchema.xml definuje transformační pravidla pro sběr událostí z bezpečnostního logu Windows v systému SCOM 2007 – Audit Collection Services. Ze struktury je patrné rozdělení podle verzí  Windows (MinBuild) a Source Name. Windows 2000 – 2003 R2 používají „klasický“ formát zápisu událostí, Source Name = Security. Windows od verze Vista / 2008 mají nový formát zápisu a Source Name = Microsoft-Windows-Security-Auditing.

Verze Windows podle MinBuild pro Source Name = Security odpovídají:

2195 - Windows 2000
2600 - Windows XP
3790 - Windows 2003
3791 - Windows 2003 R2

Verze Windows podle MinBuild pro Source Name = Microsoft-Windows-Security-Auditing odpovídají:

5384 - Windows Vista / 2008
7000 - Windows 7 / 2008 R2

Sekce Source Name = CrossPlatformSecurity obsahuje události sbírané ze systémů Unix a Linux.

Způsob použití a popis transformačních funkcí uvedl Eric Fitzgerald před časem: ACS Event Transformation Demystified

Audit Collection Services: korelace událostí Logon / Logoff

Jednoduchá úloha: k události zaznamenávající přihlášení uživatele najít odpovídající událost odhlášení a zjistit, jakým způsobem identifikovat události uživatele po dobu, kdy byl přihlášen. Průzkum možností existujících záznamů událostí v prostředí serverů Windows 2008 a podobné příklady pro Windows 2003 (viz Audit Collection Services Deep-Drive – Part 2) vedly k následujícímu. Na uvedené adrese jsem nalezl jednoduchý příklad pro relaci přihlášení ze sítě terminálem RDP, typ přihlášení 10:

SELECT
'RDP' AS LogonType,
Logon.CreationTime AS LogOnTime,
LogOff.CreationTime AS LogOffTime,
Logon.String04 AS Computer,
Logon.String02 AS IP,
Logon.PrimaryDomain AS LogonDomain,
Logon.PrimaryUser AS LogonUser
FROM
(SELECT * FROM AdtServer.dvAll WHERE EventId=528) AS Logon LEFT OUTER JOIN
(SELECT * FROM AdtServer.dvAll WHERE EventId=538) AS LogOff ON
Logon.PrimaryLogonId = LogOff.ClientLogonId
WHERE
Logon.String01 = '10'
ORDER BY LogOnTime

Odpovídající události na serveru Windows 2008 jsou 4624 a 4634, a místo dvojice PrimaryLogonID = ClientLogonID použijeme String01. Také cílový počítač, informace o adrese IP a typ přihlášení jsou uvedené v jiných sloupcích tabulky v databázi. Uživatel je uveden v poli TargetUser:

SELECT
'RDP' AS LogonType,
Logon.CreationTime AS LogOnTime,
LogOff.CreationTime AS LogOffTime,
Logon.String05 AS Computer,
Logon.String03 AS IP,
Logon.PrimaryDomain AS LogonDomain,
Logon.TargetUser AS LogonUser
FROM
(SELECT * FROM AdtServer.dvAll5 WHERE EventId=4624) AS Logon LEFT OUTER JOIN
(SELECT * FROM AdtServer.dvAll5 WHERE EventId=4634) AS LogOff ON
Logon.String01 = LogOff.String01
WHERE
Logon.String02 = '10'
ORDER BY LogOnTime

korelace

Sloupec Computer označuje cílový počítač, IP je adresa, odkud došlo k přihlášení uživatele – Logon User. Pokud budeme chtít vyhledat další události vázané na stejné LogonID, budeme hledat shodu mezi zjištěným LogonID v poli String01 události 4624 a LogonID u dalších událostí. Bude to vyžadovat pátrání, protože LogonID se vyskytuje ve Windows 2008 u 163 událostí v různých parametrech. Pokud je při transformaci v databázi ACS (OperationManagersAC) LogonID zaznamenáno v poli PrimaryLogonID, je zde uvedeno v desítkovém tvaru. V poli String01 je však v šestnáctkovém, takže je musíme pro porovnání převést na shodný základ. Pro třetí řádku z předchozího výpisu jde o LoginID = 0x332321, v desítkovém zápisu ‚3351329‚. Toto číslo tedy hledáme v záznamech událostí v poli PrimaryLogonId:

SELECT EventId, Category, CreationTime, PrimaryUser as UserName, PrimaryDomain as Domain, PrimaryLogonId,String01, String02
FROM AdtServer.dvAll
WHERE PrimaryLogonId = '3351329'

nextEvents

Vybrané události skutečně následují časově po přihlášení uvedeném v předchozím výpisu na třetím řádku.

Monitoring: Group Policy Changes

Zdá se, že by bylo možné pomocí auditních záznamů zachytit změny v objektech skupinové politiky (GPO) povolením auditu v adresářové službě a v přístupu k souborům:

  • z auditních záznamů událostí v bezpečnostním logu jsme schopni zjistit okamžik změny a původce, změnu verze, zápis do objektu nebo smazání objektu GP v AD (Directory Service Audit Access). Žádné detaily.
  • z auditních záznamů přístupů k souborům (File Access Audit) jsme schopni odlišit změny nebo zápisy na úrovni souborů v \\domain\sysvol\fqdn.domain\policies\{policy-guid}\, tj. v souborech a složkách
    • GPT.INI (verze)
    • \Machine\Registry.pol (HKLM)
    • \Machine\Scripts (startup, shutdown)
    • \Machine\Applications (MS Installer)
    • \Machine\Microsoft\Windows NT\Secedit (Gpttmpl.inf – security)
    • \Machine\Adm (šablony pro editor)
    • \User\Applications (MS Installer)
    • \User\Documents and Settings (Fdeploy.ini – redirections)
    • \User\Microsoft\RemoteInstall (OSCfilter.ini)
    • \User\Microsoft\IEAK (Internet Explorer)
    • \User\Scripts (logon, logoff)

Detailní informace o změněných položkách takto ovšem nezískáme. (zdroj)
Existují produkty určené ke správě AD nebo přímo pro Group Policy které mohou tento úkol splnit. Nezkoušel jsem je, takže jen vyjmenuji, co jsem objevil:

Textový záznam o činnosti pro Windows Firewall

Nejprve nastavíme požadované parametry pomocí nástroje wf.msc (neboli Start | Administrative Tools | Windows Firewall with Advanced Security) Zobrazíme vlastnosti firewallu Properties (1,2)

winFw1

Pro každý profil, který přichází v úvahu a je v něm Firewall zapnutý (Domain, Private, Public) (3) upravíme co a kam se bude zaznamenávat, tlačítko Customize . . . (4)

image

Name: určuje umístění souboru, není problém změnit cestu i pojmenování, výchozí je – C:\Windows\system32\LogFiles\Firewall\pfirewall.log. Dále můžeme určit maximální velikost (Size limit (KB)) a vybrat, co se bude zaznamenávat:

  • zahozené pakety (dropped packets)
  • úspěšná připojení (successfull connections)

Ukončíme a uložíme zvolené nastavení – OK |OK.

Služba okamžitě začne soubor používat. Přesvědčíme se o tom – můžeme zobrazit obsah textového souboru se záznamy přímo z adresy, kterou jsme si zvolili: C:\Windows\system32\LogFiles\Firewall\pfirewall.log, nebo z prostředí výše uvedeného nástroje pro správu Firewalu, když ve stromové struktuře v levé části vybereme Monitoring:

wFmonitoring 

Formát uložených informací a příklad záznamů:

#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
2010-10-06 18:19:02 ALLOW TCP 10.0.0.51 10.0.0.51 56247 1433 0 - 0 0 0 - - - SEND
2010-10-06 18:19:02 ALLOW TCP 10.0.0.51 10.0.0.51 56247 1433 0 - 0 0 0 - - - RECEIVE
. . .
2010-10-06 18:22:15 ALLOW TCP 10.0.0.51 10.0.0.50 56395 88 0 - 0 0 0 - - - SEND
. . .
2010-10-06 18:22:26 DROP UDP 10.0.0.1 10.0.0.255 137 137 78 - - - - - - - RECEIVE

Audit a monitorování firewallu ve Windows 2008

Podmínkou monitorování je zapnutí auditní služby pro příslušné kategorie/podkategorie. Kontrolní výpis nastavení pro kategorii Object Access, podkategorie Filtering Platform Connection příkazem auditpol /get /category:”object access” mi ukazuje, že audit není aktivní:

filteringPC

Příkazem auditpol /set /subcategory:“Filtering Platform Connection“ /success:enable /failure:enable nastavení změníme. Názvy kategorií a podkategorií jsou závislé na jazyce lokalizace serveru, proto je možné používat místo jmen jazykově nezávislý  GUID: auditpol /set /subcategory:“{0CCE9226-69AE-11D9-BED3-505054503030}“ /success:enable /failure:enable

Kontrolní výpis pak potvrdí, že změna byla provedena:

filteringPC1

V logu nás potom budou zajímat následující události:

Allowed and blocked connections:

  • 5154—Listen permitted
  • 5155—Listen blocked
  • 5156—Connection permitted
  • 5157—Connection blocked
  • 5158—Bind permitted
  • 5159—Bind blocked

Note Permitted connections do not always audit the ID of the associated filter. The FilterID for TCP will be 0 unless a subset of these filtering conditions are used: UserID, AppID, Protocol, Remote Port.

Čerpal jsem ze stránek MSDN: http://msdn.microsoft.com/en-us/library/bb309058(VS.85).aspx, které uvádějí GUID pro další kategorie a podkategorie a seznam generovaných událostí, které přicházejí pro tyto účely v úvahu.

K zobrazení událostí používám filtry v bezpečnostním logu, viz zde.

Důležitá poznámka: zapnutí auditu firewallu může způsobit generování vysokého počtu záznamů, takže je důležité po změně nastavení sledovat provoz nebo povolit audit pouze na nezbytně dlouhou dobu, např. při vyšetřování problémů.