Information Overload!

[Gump]

I may be out ofmy league here, but I can't pass this up. I am not a computer security guy (yet), but i do analysis on lots and lots (Gigs) of logs. Not sytem logs but huge text files that come inmany diferent delimited and fixed width formats. When it comes to doing things your own way with data manipulation you can't beat a data base. Once you have all of the tables, Import/export scripts(orMacros), and queries done itisa snap. You can suck all the data in and once it is neatly in place you can make the Db tell you anythng you want to know based on the criteria of any variablecontainedin the original logs.

It can look for anomoloies, links, patterns, Etc.... Anything you want. And once you get the info your looking for you can turn it intoa chart, a graph, a spreadsheet Etc... Again, anything you want.

MySql is an enterprise level open source database that can do CL stuff and has an available GUI. Maybe this will help maybe not but it sounded like a pretty goodsolution to your problem.

[Tiger Shark]

Gump: Technically you are right. I went down the database route a year or so ago and found it to be unweildy, (too many different file formats to import and too many line formats and fields within a single file to make importing easy without dropping any info, not everything can be brought in in a delimited format - at least not in this shop). I did the best I could to automate everything but my morning still consisted of an hour or more of tweaking and importing. What makes the text particularly attractive to me is the relatively small size, and the speed with which I can search it with that LineStrip program, (a 40M file dumps it's results on my 1G/256M system in under 15 seconds as you can see from my report printout it makes some twenty passes on the data on no more than 2 minutes on a 40M file - thats equivalent to 8G).

I also found that the database can sometimes be a tad too literal and there were occasions when queries would dump exactly what I asked for, (which is fair I guess..... ), but if I went to the appropriate area of the log there was something else that would have peeked my interest a whole lot more had I been able to see it. This knowledge then began to make me distrust my results a little - I was always niggled by the fact that there may have been a little more info in one of those results. With linestrip I don't have to be worried that I'm searching the correct fields for the word "deny" for example..... If that word is in a log entry, (a line of text), then the entire line gets dumped for me to examine.

Another thing I hated was the lack of accurate chronology sometimes. Even if you synch the clocks by an atomic clock hourly it would seem that things could get a little off quite quickly so when I see and IIS entry come in before the firewall entry it peeved me a little. The combination of the additional work and the slight lack of trust in my system led me to believe that there had to be a better way.

Using the current system I have yet to see a failure in chronology. Where a packet is logged by all systems I see entries in order from external IDS, internal IDS, IIS for example.... Well, I just like that and linestrip does such good job of being "vague", (and I mean that in the best possible way), that I feel I get a better picture overall.

Of course this is a personal thing that is also derived from the ability of _all_ your logging system to be able to dump their data in the same format. I was, unfortunately, unable to do that so text is better for me. If your situation is different then go for it.

As a final thought - you say you examine Gigs of data per day.... I would hazard a guess that you know what it is you are looking for...... That makes it a bit easier. Imagine searching for something that you don't know what it is you are searching for or the format it might present itself in....... I believe it helps at that point to not be so precise and to have some leeway either side to be able to look at something and think "whoa.... that looks a tad odd..."

[Tiger Shark]

As is usual just before I take my vacation everything has hit the proverbial fan..... A new office to open within a week, (yeah, that's gonna happen), the complete replacement of a 40 computer lab, (yeah that's gonna happen), the pump failed on my pond/stream requiring replacement... and on, and on..... So I have to back down on the Tutorial right now though I have started it - it's a bit more involved than I thought if I am to make a good job of it. I may play with it on vacation but for right now I'll just drop you all the scripts I use to move and split up my logs.

There are two files in the zip file. They are both renamed from .vbs to .txt. You need to rename them back to .vbs before they will do a darned thing for you.... ;)

The first one, (sanitmovelog.txt), can be renamed back to simply movelog.vbs sits in the log directory itself and moves yesterday's log, (the schedule runs it at 12:05am and it selects the appropriate file by the fact it will be bigger than 5M while the new one will still be less than 5M.... You may need to adjust the 5000000 parameter higher in a really busy shop or lower if your logs don't exceed 5M _every_ day), first to an archive subdirectory and then to the log analysis machine, (security administrators in this case).

The second file, (sanitloganalysis.txt), can be renamed back to loganalysis.vbs and is the beastie that does the work. It relies heavily on the LineStrip program mentioned in my original post and for this script to work as is you need a copy of LineStrip in %system root%\system32 or somewhere else if you have custom paths as well.

You will need to change the parameters that you do the extractions with depending upon the syntax of your log entries. The portions that pull server events, (note that it is only pulling login failures) will work if you place your server's name where mine are. Account lockouts should work just fine. A kind of side benefit here with using Snare to dump the events to syslog is that a skiddie will look at the auditing and the event log retenion to see how much "danger" he is in..... He may miss or mis-undertand the snare service, (don't forget you can rename it.... <WEG>) and if you leave your event logs parameters at say max size .5M/overwrite as needed then you may look like a lax admin at first glance...... Lulled into a false sense of security..... I love it.....


Snort logs and portscans should work fine but things like IPv6 pulls are done by having a snort rule set up to capture them in the first place:-

alert tcp any any -> any any (msg: "IPv6 Syn Connection"; Flags: S; ip_proto: 41; Classtype: bad-unknown;)

.... then the pull will work for that.
Blocked sites, deny in and out's may work depending on the syntax of your firewall logs, (many probably will), but you might need to tweak these.

IIS logs will work if you send the syslog entry from BackLog IIS as "daemon.info" entries.... Pulling the 404's and the 403's will work but be aware that it does pull some falses 'cos those numbers may appear in other log lines.

VPN, SSL and Term Server stuff comes from my firewall and will probably not work with yours..... Run the syslog.... dump the log and see what you can pick up on.

The loganalysis script needs to be scheduled, (on the security admin's PC), for an appropriate amount of time after the "movelog" takes place bearing in mind the size of the log file and the fact that it is copied once internall on the log server and once across your network to the security administrators PC at the slower speeds.

You will need to put in an appropriate email address for the report to be sent to you.

Oh, and note near the top of the script it copies the log to a sub-folder before it begins work on it and near the end it moves it to another server to yet again hide it.... by the time you are done you have 3 copies on three different machines and if you are set up right the login password combinations are unique to each machine - so skiddie has to hack the log server and then skip from box to box or he has to hack all three boxes individually to get to the logs..... In my shop he has 10 days to achieve this without me noticing because at that point the logs just about fill a CD-ROM and they get written there too......

I think that's about all...... Most of you have enough talent to work out what I have missed and those of you that still have questions just post them here..... I'll certainly be around for the next week, albeit from my hotel room.....

[Maestr0]

Thanks Tiger,
Maybe I'll crack these open this weekend ,Keep us posted on your write up progress, and good luck with your pond!

-Maestr0

[RoadClosed]

Very nice, I burned it all to a cd and I am off to my new syslog server placed in a nice location. Nice scripts, here ya go man!

[RoadClosed]

Hey all, I am extremely interested in snort after doing some more research. I have a cisco IDS now but snort is so much cheaper and more flexible at first look. I am designing my deployment in the same fashion as Tiger_Shark. Meaning, using Kiwi. I am guessing you just set snort to syslog to the kiwi box versus dumping it in mysql or some other database first? I could use a little clarity on that issue. I was also wondering if anyone is using a single box to monitor 3 sensors. For example, if I place 3 nics in a single Linux box can I monitor all 3 sensors with snort. Hmm would I even want to? That would make a single compromise point for the IDS system? How did you all handle multiple sensors with snort? I have some more questions but it's time to pull all the snort references from AO and go through that bit first.

EDIT/ I was looking at OLD documentation of Snort. Current version supports Syslog it seems.