Collecting Event logs–The Builtin way. Part 3.
In exemplele de pana acum probabil ca ati observat ca am exemplificat numai pe logurile din Application si System log.
Asta deoarece pentru a colecta logul Security e nevoie de un pas aditional. By default acesta este restrictionat si nu oricine poate citi logurile de aici. Prin documentatia de specialitate este specificat grupul Event Log Readers (Windows 2008 si mai sus) insa din experienta proprie nu am reusit sa citesc niciodata logul folosindu-ma de apartenenta la acest grup (din domeniu sau local).
Metoda pe care o sa o recomand poate fi folosita si pentru servere membre si pentru domain controllere.
Security Descriptor-ul pentru fiecare log este specificat in SDDL (Security Descriptior Definition Language) iar cei mai experimentati in AD probabil s-au mai lovit de SDDL si in alte cazuri. Cum sa folositi SDDL pentru a modifica permisiunile pe log-uri este specificat in detaliu aici:
http://support.microsoft.com/kb/323076
Cu mentiunea ca in Windows 2008 optiunea din GPO se regaseste in Computer Configuration/Policies/Administrative Templates/Windows Components/Event Log Service/Security/Log Access.
By default pe un server cu Windows 2008, permisiunile arata cam asa in SDDL (linia channelAccess):
Si folosind comanda wevtutil sl security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20) putem modifica permisiunile in asa fel incat Network Service sa aiba permisiuni de read.
Imediat dupa rularea comenzii si dupa un restart al serviciului Windows Remote Management, evenimentele din log-ul security vor fi trimise catre collector:
Acum trebuie sa fiti foarte atenti la cum setati collectorul, pentru ca daca este setat pe “All Event IDs” atunci va colecta tot ce se afla in security log de pe sistemele abonate.
Iar clientii trimit din urma tot ce s-a strans in log-uri pana la data actuala, deci mare atentie la cum dimensionati logurile. Un domain controller abonat, poate creste logul de pe collector instant cu 100Mb.
Si cam atat pe astazi. Daca intampinati probleme in configurare, va astept cu intrebari.
Collecting Event logs–The Builtin way. Part 1
Collecting Event logs–The Builtin way. Part 2
Another interesting hack
Vremurile in care discutam numai de sisteme Windows compromise (de multe ori din cauza admin-ilor) sunt de mult apuse. Acum totul are un interes financiar in spate.
Check this out:
Acum cateva zile pe linux.com se povestea despre hackul de pe kernel.org. Acum se pare ca si-au inchis si ei portile.
E interesanta ideea de a “sparge” kernel.org si cu toate ca nu prea vad posibila alterarea surselor, numai gandul ca cineva incearca asa ceva ma sperie.
New malware–RIGHT TO LEFT OVERRIDE–RLO
Mi-a ajuns la urechi o chestie foarte interesanta, despre cum poti pacali end user-ul, si chiar si pe cei bine pregatiti.
Nu este ceva foarte nou insa in ultimele luni metoda a inceput sa fie folosita intens.
Pe scurt, folosind un caracter de control (U+202E) poti face ca de la un anumit loc in denumirea fisierului sa inversezi sirul de caractere si sa faci ca de exemplu “doc.exe” sa arate ca “exe.doc”.
Detalii complete la http://blog.commtouch.com/cafe/malware/exe-read-backwards-spells-malware/
Un alt mesaj de la ComodoHacker
PS: tot el e responsabil si pentru cazul DigiNotar.
Nici SSL-ul nu mai e ce-a fost
http://www.microsoft.com/technet/security/advisory/2607712.mspx
http://support.microsoft.com/kb/2607712
Interesanta e cererea guvernului Olandez de a nu instala update-ul ce scoate root-urile DigiNotar in Olanda. Ma intreb cum o sa restrictioneze asta – neprezentand update-ul sistemelor localizate sau altfel?
Probabil ca au vandut o gramada de certificate si sunt destul de folosite.
Cum se face un audit de securitate (funny)
De la un membru winadmin am primit urmatoarea discutie de pe serverfault:
Am ramas uimit, dar dupa mi-am adus aminte ca m-am confruntat si eu la randul meu cu probleme asemanatoare (stiti bancul ala cu prostia, universul si infinitul).
Collecting Event logs–The Builtin way. Part2.
Prima parte o gasiti aici.
In postul de astazi o sa vedem cum putem seta Event Forwarding si WinRM via Group Policies.
Inainte de toate este nevoie sa setam collectorul si este de preferat ca acesta sa nu fie un domain controller (din experienta am observat numai probleme de configurare cu collectorul pus pe domain controller).
Incepem setand winrm-ul si pentru mai multa siguranta si wecutil qc pentru a seta starea serviciului collector.
winrm qc
wecutil qc
Acum diferenta intre ce am facut in primul articol este ca acum vom seta Source computer initiated in setarea subscriptiei.
Acum e nevoie sa rulati urmatoarea comanda pentru a vedea portul pe care asculta collectorul:
winrm enumerate winrm/config/listener
Notati portul, pentru ca va fi nevoie de el putin mai tarziu.
In exemplul meu o sa fac un GPO nou pe care o sa-l asignez containerului Domain Controllers si in felul acesta voi reusi sa consolidez/colectez evenimentele de pe domain controllere fara a fi nevoie sa configurez de mana ceva pe fiecare DC.
Nota: GPO-ul odata facut, poate fi link-at si la alte organizational unit-uri din domeniu.
In GPO e nevoie sa ne uitam in Computer configuration/Policies/Administrative templates/Windows components – Event Forwarding si Windows Remote Management (WinRM).
Prima data vom seta auto config-ul pentru WinRM. Atentie ca in scenariul meu consider ca infrastructura mea e trusted si permit accesul de la orice IP.
Nota: asta este cumva echivalentul lui winrm quickconfig.
Mai departe setam adresa collectorului.
Portul de mai jos este portul pe care l-am notat mai devreme.
Si daca totul a fost facut corect si nu v-a scapat nici un pas (sau nu am uitat eu sa va zic ceva) colectarea evenimentelor ar trebui sa mearga. Iar daca nu merge din prima, aveti putina rabdare sau rulati gpupdate /force si restartati serviciul winrm.
Rezultatul il puteti vedea mai jos:
Collecting Event logs–The builtin way. Part 1.
Imi aduc aminte ca am discutat despre asa ceva pe vremea cand de abia se lansase Windows Vista (sau era inca beta) insa in continuare e un subiect nu foarte dezvoltat si zic ca merita un articol aici.
Tehnologia e builtin in Windows-urile actuale si e agentless. Nu putem compara cu System Center Operation Manager sau alte produse de colectare a logurilor insa e util atunci cand nu avem altceva.
Sistemul ce va colecta/consolida logurile il vom numi Collector. Collector-ul poate fi orice windows de la Vista in sus (diferentele intre OS client sau server tin de scalabilitate) iar client cam orice de la XP/2003 in sus – cu mentiunea ca pe XP si 2003 e nevoie sa mai instalam ceva.
Incepem de la collector si cream o subscriptie noua:
Pentru a ne putea conecta la sistemele remote e nevoie sa rulam WINRM QUICKCONFIG.
Iar in query filter putem selecta evenimentele colectate. Exista si posibilitatea de a edita filtrul manual si e posibil sa aveti nevoie pentru ca interfata default e putin limitata.
Aici o sa vreti sa setati un cont cu drept de a citi logurile de pe masina remote. Mai multe detalii in alt articol. Pentru test puteti folosi un cont de admin.
Optiunea Minimize Latency ii va spune sistemului remote sa trimita evenimentele imediat ce apar. Normal le trimite la 15 minute, iar Minimize Bandwidth la 6 ore.
Mai jos puteti observa cum arata logurile colectate de pe doua servere (DC1 & DC2). Folosind filtrul de mai sus am putut colecta evenimentele ce informau despre restart-ul serviciilor.
In articolele urmatoare o sa detaliez mai multe despre colectarea logurilor folosind Event Logs Subscription.
Partea a doua – http://www.winadmin.ro/2011/09/06/collecting-event-logsthe-builtin-way-part2/
Searching files on the local disks using Powershell
Asta era un task de care m-am ferit de fiecare data folosind Vbscript. Nu ca ar fi imposibil, dar la cat de complicat e fata de Powershell parca nu se merita.
Mai jos aveti un exemplu de script care cauta fisierul definit in variabila $searchFile pe discurile locale:
$searchFile=”numefisier.extensie”
$Cdisks = get-wmiobject Win32_LogicalDisk -Filter “DriveType = 3”
foreach($Cdisk in $Cdisks)
{
$CdeviceID = $Cdisk.DeviceID
$files = Get-ChildItem -LiteralPath $CdeviceID -Force -Recurse
foreach($f in $files)
{
if($f.Name.toLower() -eq $searchFile){ Write-Host $f.FullName }
}
}
Get-ChildItem suporta parametrul –Force, care il face sa caute si in locatiile marcate ca Hidden. Totusi, folosirea acestui parametru va face ca scriptul sa incerce sa caute in unele locatii system neaccesibile si sa produca erori in output. Dar modificand scriptul sa afiseze rezultatul intr-un fisier de raspuns, se poate rezolva aceasta problema.
Recurse, presupun ca nu mai are rost sa-l explic. Dar puteti testa si voi.
Si probabil ca ar merge adaptat si pentru a rula pe un sistem remote.
Pentru cei ce nu au renuntat la tastatura in favoarea tabletei
Ultrabook is coming:
http://www.youtube.com/watch?v=zeoecAAkUFQ
Sper sa vad cat mai curand asa ceva prin magazine. Cu i7 si SSD :).