Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : This article was first published in EventTracker s EventSource Newsletter http www.eventtracker.com newsletters auditing-file-shares-windows-security-log open Over the years, security admins have repeatedly ask me how to audit file shares in Windows. Until Windows Server 2008, there were no specific events for file shares. About the best we could do was enable auditing of the registry key where shares are defined. But in Windows Server 2008 and later there are 2 new subcategories for share related events File Share Detailed File Share File Share Events The good news is that this subcategory allows you to track the creation, modification and deletion of shared folders see table below . You have a different event ID for each of those 3 operations. The events indicate who made the change in the Subject fields and provides the name of the share users see when browsing the network and the patch to the file system folder made available by the share. See the example of event ID 5142 below. A network share object was added. Subject Security ID W8R2 wsmith Account Name wsmith Account Domain W8R2 Logon ID 0x475b7 Share Information Share Name AcmeAccounting Share Path C AcmeAccounting The bad news is the subcategory also produces event ID 5140 each and every time a user connects to a share. The data logged, which includes who accessed it and their client IP address, is nice but the event is logged much too frequently. Since Windows doesn t keep network logon sessions active if no files are held open you will tend to see this event a lot if you enable File Share audit subcategory. There is no way to configure Windows to produce just the share change events and not this access event as well. Of course that s the point of a log management solution like EventTracker which can be configured to filter out the noise. 5140 A network share object was accessed 5142 A network share object was added. 5143 A network share object was modified 5144 A network share object was deleted. Detailed File Share Events Event ID 5140, as discussed above, is intended to document each connection to a network share and as such it does not log the names of the files accessed through that share connection. The Detailed File Share audit subcategory provides this lower level of information with just one event ID 5145 which is shown below. A network share object was checked to see whether client can be granted desired access. Subject Security ID SYSTEM Account Name WIN-KOSWZXC03L0 Account Domain W8R2 Logon ID 0x86d584 Network Information Object Type File Source Address fe80 507a 5bf7 2a72 c046 Source Port 55490 Share Information Share Name SYSVOL Share Path C Windows SYSVOL sysvol Relative Target Name w8r2.com Policies 6AC1786C-016F-11D2-945F-00C04fB984F9 Machine Microsoft Windows NT Audit audit.csv Access Request Information Access Mask 0x120089 Accesses READ_CONTROL SYNCHRONIZE ReadData or ListDirectory ReadEA ReadAttributes Access Check Results READ_CONTROL Granted by Ownership SYNCHRONIZE Granted by D A 0x1200a9 WD ReadData or ListDirectory Granted by D A 0x1200a9 WD ReadEA Granted by D A 0x1200a9 WD ReadAttributes Granted by D A 0x1200a9 WD This event tells identifies the user Subject fields , the user s IP address Network Information , the share itself and the actual file accessed via the share Share Information and then provides the permissions requested and the results of the access request. As you can see this event actually logs the access attempt and therefore you will see failure versions of the event as well as success events. But be careful about enabling this audit subcategory because you will get an event for each and every file accessed through network shares every time the application opens the file. That can be much more frequent than you d imagine for some applications like Microsoft Office. Conversely, remember that this category won t catch access attempts on the same files if a locally executing application accesses the file via the local patch e.g. c docs file.txt instead of via a patch. Instead you might want to consider enabling auditing on individual folders containing critical files and using the File System subcategory. This method allows you to be much more selective about who, which files and what types of access are audited. For most organizations I suggest enabling the File Share subcategory if it s important to you to know when new folders are shared. But you will probably want to filter out all those occurrences of 5140. Then if you have file level audit needs, turn on the File Access subcategory, identify the exact folders containing the relevant files and then enable auditing on those folders for the specific operations e.g. Read, Write, Delete necessary to meet your audit requirements. Don t enable the Detailed File Share audit subcategory unless you really want events for every access to every file via network shares.

Les mots clés de la revue de presse pour cet article : windows security
Les videos sur SecuObs pour les mots clés : windows security
Les mots clés pour les articles publiés sur SecuObs : windows security
Les éléments de la revue Twitter pour les mots clé : windows security





Les derniers articles du site "Security et al" :

- Vulnerability Scanning Done Right
- Seven Steps to Designating Owners of Unstructured Data
- Comparison SQL Server Audit vs. SQL Trace Audit for security analysts
- SolarWinds Makes It Easy to Detect SharePoint Breaches with Integration to LOGbinder SP
- Monitoring File Permission Changes with the Windows Security Log
- Cool Stuff at RSA
- Elephants and Irony at RSAC
- In search of great technology at RSAC among all the noise filtering
- Auditing File Shares with the Windows Security Log
- Pay Attention to System Security Access Events

---

S'abonner au fil RSS global de la revue de presse

---