Log analysis follow up
I posted a story a little over a week ago asking for reader input on their favorite log analysis tools and followed up with some of my own. I promised that I'd post a summary of what you provided me. I was hoping to do that last week, but life got in the way. So in the spirit of "better late than never", here is my wrap-up.
The one open source tool that was mentioned most often was ossec and frankly, I'm not sure how that one slipped my mind when I did my own list. I started using it a few months ago and really like it. Daniel Cid, the maintainer, pointed out to me that there are quite a few rules for it that can be found at http://www.ossec.net/rules/ and they are updated/added to on a daily basis.
Beyond that, most of the folks who wrote in said that they wrote their own scripts to search/parse/summarize their logs because with experience they've learned what it is they want to look for. I guess this points out one of the problems in the area though. Folks with lots of experience, who have managed their machines/networks for a long time develop a feel for what is normal and what they need to watch for, but how much bad stuff happened on the way to developing all that experience? Also, is their intuition, correct? As I mentioned to fellow handler, Swa, when he wrote up his audit story last month, in some ways, automated summarization/reporting on logs based on experience is a lot like signature-based anti-virus or IDS, you'll catch the known stuff, but may miss the new stuff. That's why it is important to also look at the unusual stuff. Not just, the "top 10" reports, but also the "bottom 10".
I was kind of surprised that few of our readers wrote in about any of the commercial tools out there. I don't know if that is because our readers all are strong believers in open source, or don't have experience with the commercial tools, or if the commercial tools just don't do what they need. I personally have almost no experience with the commercial tools because in most of my paid jobs, there was no budget for log analysis, so we were stuck with open source, stuff I wrote, or doing without.
I'll wrap this up, by pointing you to a report that was released at the SANS Log Analysis Summit after SANSFIRE in DC in July. I was able to attend part of the summit, including the talk by Chris Brenton and Mike Poor where they discussed the Top 5 Essential Log Reports.
Update 1: (2006-09-18 19:00 UTC) Tor e-mailed me to point out that he has had a lot of success using Excel (and especially using it to create pivot tables) for log analysis. He also pointed to Microsoft's LogParser (see the unofficial site at http://www.logparser.com) as a favorite tool of his.
-------------------------------
Jim Clausing, jclausing --at-- isc dot sans dot org
0 comment(s)
The one open source tool that was mentioned most often was ossec and frankly, I'm not sure how that one slipped my mind when I did my own list. I started using it a few months ago and really like it. Daniel Cid, the maintainer, pointed out to me that there are quite a few rules for it that can be found at http://www.ossec.net/rules/ and they are updated/added to on a daily basis.
Beyond that, most of the folks who wrote in said that they wrote their own scripts to search/parse/summarize their logs because with experience they've learned what it is they want to look for. I guess this points out one of the problems in the area though. Folks with lots of experience, who have managed their machines/networks for a long time develop a feel for what is normal and what they need to watch for, but how much bad stuff happened on the way to developing all that experience? Also, is their intuition, correct? As I mentioned to fellow handler, Swa, when he wrote up his audit story last month, in some ways, automated summarization/reporting on logs based on experience is a lot like signature-based anti-virus or IDS, you'll catch the known stuff, but may miss the new stuff. That's why it is important to also look at the unusual stuff. Not just, the "top 10" reports, but also the "bottom 10".
I was kind of surprised that few of our readers wrote in about any of the commercial tools out there. I don't know if that is because our readers all are strong believers in open source, or don't have experience with the commercial tools, or if the commercial tools just don't do what they need. I personally have almost no experience with the commercial tools because in most of my paid jobs, there was no budget for log analysis, so we were stuck with open source, stuff I wrote, or doing without.
I'll wrap this up, by pointing you to a report that was released at the SANS Log Analysis Summit after SANSFIRE in DC in July. I was able to attend part of the summit, including the talk by Chris Brenton and Mike Poor where they discussed the Top 5 Essential Log Reports.
Update 1: (2006-09-18 19:00 UTC) Tor e-mailed me to point out that he has had a lot of success using Excel (and especially using it to create pivot tables) for log analysis. He also pointed to Microsoft's LogParser (see the unofficial site at http://www.logparser.com) as a favorite tool of his.
-------------------------------
Jim Clausing, jclausing --at-- isc dot sans dot org
Killbit apps for current IE exploit
Update: I posted this late on Friday (9/15) evening, so I wanted to pull it back onto the front page again. This looks to me like a perfect avenue for malware drive-bys, and with the likelihood being that this won't be addressed until the next MS monthly patch cycle (gee... who would EVER have thought that the bad guys would start timing THEIR releases to maximize exposure until the next patch-day?!?) we're probably going to be seeing a whole lot of this stuff:
To make life a little easier, I put together two small apps to set and unset the appropriate "kill bit" to block the actions of the current "daxctle.ocx" IE exploit. They can be found here:
http://handlers.sans.org/tliston/DAXCTLE.OCX_KillBit.exe - Standard Windows executable
(MD5: 599a2e48602f63a5330eea8259216584)
http://handlers.sans.org/tliston/DAXCTLE.OCX_KillBit_cmd.exe - Command line version
(MD5: 571a19cf51f713b81545ebd6a007d792)
The command line version, when run without any parameters, will set the "kill bit". When run with any parameter (i.e. something like "/r"), will remove the "kill bit."
The standard Windows executable, when run, will tell you the current status of the kill bit and offer you the option of changing it.
Hope these help...
--------------------------------------------------------------------------
Tom Liston
ISC Handler
Senior Security Analyst - Intelguardians (http://www.intelguardians.com)
To make life a little easier, I put together two small apps to set and unset the appropriate "kill bit" to block the actions of the current "daxctle.ocx" IE exploit. They can be found here:
http://handlers.sans.org/tliston/DAXCTLE.OCX_KillBit.exe - Standard Windows executable
(MD5: 599a2e48602f63a5330eea8259216584)
http://handlers.sans.org/tliston/DAXCTLE.OCX_KillBit_cmd.exe - Command line version
(MD5: 571a19cf51f713b81545ebd6a007d792)
The command line version, when run without any parameters, will set the "kill bit". When run with any parameter (i.e. something like "/r"), will remove the "kill bit."
The standard Windows executable, when run, will tell you the current status of the kill bit and offer you the option of changing it.
Hope these help...
--------------------------------------------------------------------------
Tom Liston
ISC Handler
Senior Security Analyst - Intelguardians (http://www.intelguardians.com)
Keywords:
0 comment(s)
×
Diary Archives
Comments
Anonymous
Dec 3rd 2022
9 months ago
Anonymous
Dec 3rd 2022
9 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
https://defineprogramming.com/
Dec 26th 2022
8 months ago
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
https://defineprogramming.com/
Dec 26th 2022
8 months ago
rthrth
Jan 2nd 2023
8 months ago