Symanec Protection Suites

Unfortunately, I discovered this little "event" when I needed records most desperately.We have some strange things going on, and I had SEP set up to watch for contact or attempted contact with a specific IP address. It's just a very simple firewall rule that if client IP matching these ranges tries to contact a remote IP address, log it. No block, nothing fancy - log it. We needed to find out what computers were performing this action, when, how often, and just as important, WHAT application or file!

No malware involved, no risk or threat, but there is an application attempting contact with a server it has no need to, plus, the response it gets back is causing a router to send our router/ASA the type of packet that appears to be DoS. It's not, but it's wreaking havoc on some systems and a certain office.

I believe it's a bug in DNS or something similar, but SEP has been helping in GREAT ways, in fact, indespensible ways, to help track this down. I was using the logs to prove it was happening in some places, prove it was NOT happening in others, in short - I was blowing away some bad info and incorrect theories thanks to SEP traffic logs. That was last week.... today, some big questions came up about this happening in other offices. I knew it wasn't happening in a specific office and was just about to prove it, when I found to my surprise, the SEPM console showed NOTHING at all in the traffic log! It was empty - especially days worth of information about this particular case - all totally gone. I rebooted the SEPMs, and relaunched the console on my computer, tried pointing it to each SEPM in turn, same result - empty traffic logs regarding these particular IP addresses - it was as if all that information never even existed, and I was looking rather foolish (at least to me, as I now had no proof, but I do know what I saw)

So, I started checking the SEPM system logs (love SEPM logging, just wish there were a few more details on a couple really small areas) and I found this

Ouch, if I'd only gotten up a few hour earlier and come into work before 3:30 am, I might still have some logs...... Ah, but I think back to Windows OS logs, and it operates on the FIFO principal - it's never purged, just that old events roll out so new ones can roll in! Love it.

But it appears to me, and this is perhaps the largest question - does that mean what I think it means? Swept, swept out the door with the trash, gone, forever, unrecoverable, doesn't exist any more? Are all those log entries related to this very complex and mysterious case actually out in the Ether somewhere? That great bitbucket in the sky?

I'd seen an empty log just one other time, and never really thought about it again as it wasn't any big deal at the time - so I suspect the answer to the above is yes, Bill, it's gone, swept means deleted, cleaned out, ready for new info.

If that is the case - is there a way to tell SEPM to sweep the old logs into a file somewhere? A SPECIFIC somewhere? I'd like to keep the logs if they get swept, as the problem is, you never know when that 60 or 90 days to keep the logs is going to come! It might come as you are attempting to troubleshoot something important, and then right in the middle of things, they are gone....   Either allow an archive, or a WARNING, like "hey, admin, these logs will disappear forever at 3:41 CDT on August 13th, 2012 unless you click here to dump the log to a file (choose location)

I can understand the housekeeping - SQL would grow so huge it would slow down terribly after a couple of years, but the total sweeping and full loss of a whole log, ouch. Or, can SEPM be made to use FIFO, like Windows does?

Oh - it did the same with the packet logs, too - and I was needing that packet info today as well as I told another person who is helping to trouble shoot this "yeah, I can actually furnish you packets for these events, I'll get them to you on Monday". Then I come in, and they are ALL GONE. No warning! Wish I had known that this was day 61!

I know - it's really something I should have been prepaired for, but then again, it just sort of happens, boom, day 61 us here, logs are empty, so I'm looking for some good tips from smart folks.

Well, as I understand the logging, traffic logs are saved in two tables. That is, when table 1 is "full", SEP changes to table 2. If table 2 is "full", table 1 is swept (deleted, gone forever etc. ), and SEP is logging in table 1 again. So the stuff in table 2 should still exist, and it's a bit strange what happened to you.

The "Full" event means either the time threshold (e.g., 60/90 days) or the maximum number of rows (50,000 by default for traffic log). AFAIK the data sweeping happens as soons as the first of the two thresholds is reached. So perhaps the number of rows is the culprit, and you have to increase it. That's particularly true if you have a lot of logging firewall rules for many clients.

To check if there is still traffic log data, you could make SQL queries like these:

SELECT COUNT(*) FROM AGENT_TRAFFIC_LOG_1

SELECT COUNT(*) FROM AGENT_TRAFFIC_LOG_2

or even more convenient (both tables in one view):

SELECT COUNT(*) FROM V_AGENT_TRAFFIC_LOG

BTW, if you are using the SEP Content Distribution Monitor for SEP 12.1, there is a nice new feature showing the number of rows of every single database table.

If that is the case - is there a way to tell SEPM to sweep the old logs into a file somewhere?

AFAIK, there is no way to do so. However, it's possible to save the traffic logs in a file (Admin > Local Site > Configure External Logging). But that does not seem that what you want.

Hmmm, can I use that tool even though we don't use GUPs?

Maybe I need to somehow come up with a script that would export the logs every 60 days.....

I don't know SQL at all, just enough to know not to type anything in while I'm looking at the SQL management.
With this little issue we have, I have had the firewall log everything coming out of one office going to specific addresses, and the other logging I do - filles logs REALLY fast.

But the forensics abilities SEP allows me are fantastic.

Hmmm, can I use that tool even though we don't use GUPs?

Yes. Here is a screenshot of the database part of SEPCDM:

It's easy to configure and run.