I haven't seen that, but we also don't use the SIEM collector. For whatever it's worth, I have an at job that runs at intervals to type out the active dnslog off to a new file, and use a CIFS pull to get the copy of the file. 2008 and I assume 2012 Windows don't update the file timestamps as the log is filling up so the CIFS retriever skips the active log file otherwise. With this approach you can keep a few generations of the active log file for whatever it's worth.
Does the SIEM collector have a notion of "delete after collection" perhaps?
Thank You for the apply. Unless that pulling of the debug dns log files via CIFS is putting them into the ESM, it would not be very useful to us. We generate quite a bit of DNS activity and getting them into the SIEM is our priority.
The SIEM collector does not delete the log by design. I have already spoken with McAfee Support and got the "It ain't us" answer.
Thanks for the input!
Hi gpelowski, that's exactly what we're doing, and we share the same priority (DNS logs are important after all). Here's the job I run every 10 minutes on a 2008r2 server to deal with the peskiness of 2008R2 not updating file timestamps on dnslog.log while it grows (which consequently makes Receiver ignore it and not pull new events in until the timestamp changes).
Point the CIFS retriever at share name c$ path /dnslogs and wildcard dnslogforpickup.tx* and it works. If your logs are huge and disk space tight, you can decrease the depth of the rolling. I just have those to give something to grab if we have an issue, so there is some history to grab by changing the wildcard if need be.
if exist c:\dnslogs\dnslogforpickup4.txt del c:\dnslogs\dnslogforpickup4.txt
if exist c:\dnslogs\dnslogforpickup3.txt move /y c:\dnslogs\dnslogforpickup3.txt c:\dnslogs\dnslogforpickup4.txt
if exist c:\dnslogs\dnslogforpickup2.txt move /y c:\dnslogs\dnslogforpickup2.txt c:\dnslogs\dnslogforpickup3.txt
if exist c:\dnslogs\dnslogforpickup1.txt move /y c:\dnslogs\dnslogforpickup1.txt c:\dnslogs\dnslogforpickup2.txt
if exist c:\dnslogs\dnslogforpickup.txt move /y c:\dnslogs\dnslogforpickup.txt c:\dnslogs\dnslogforpickup1.txt
if exist c:\dnslogs\dnslog.log type c:\dnslogs\dnslog.log > c:\dnslogs\dnslogforpickup.txt
Note that this batch file intentionally uses type with a redirection to a new file in order to force a new timestamp to be made. Windows' copy or move function does not change the relevant timestamp. With this approach, you get a brand new file with minty timestamps every 10 minutes that Receiver will cheerfully pull and parse via CIFS. I have an open PER on a native, agentless way to get DNS logs off a Microsoft server without these gymnastics (e.g. to have an override to tell the CIFS retriever on the receiver to grab a file anyway, and do bookmarking of it even if the time stamp isn't updated). Please file a PER if you agree that this should be built in functionality.
More to your direct issue, If you ran procmon from microsoft sysinternals and watched dnslog.log I wonder if it'd tell ya which process is eating your log file. Process Monitor
Thank You for your advice and offering a different method to collect the DNS debug log file. Overall, it does not help answer my initial question.
I never promised you a rose garden. :-) Just another way to take a whack at the problem.
Did you try my suggestion about using procmon to follow the file?
No, I have not. That falls under the responsibility of another team, but I would be more than happy to forward on any instructions you may have. This happens randomly at some point during the day. What would be the proper settings to configure procmon to watch for and log this activity?
Get procmon from Microsoft sysinternals Process Monitor
Find an entry with PATH has the debug log file you care about (you might restart the dns daemon to manually force it to create the file or open it while you're watching)
Right click on that PATH entry and tell procmon to include only that file. This'll cut down the list of events dramatically.,
Wait until you notice that the file disappeared.
And you'll see which process was responsible at least.
Iterate with a wider set of filters as needed to isolate the incident.