Using the tool shown here, I was able to convert the latest snort rules into Modsecurity rules!
Previous to this, I'd created my own (crude) rules that blocked most of the traffic I had concerns about, but I wanted something more. I converted the latest Snort rules to Modsecurity rules, ending up with 852 new Modsecurity rules (12 of which I created).
This is already paying off. I'm seeing a good bit of rejected or warning-type (but passing) traffic. Also, the web rejections are actually triggering Snort alerts (attack responses), which is great, as it gives me more data to investigate when perusing my Snort logs.
I also had issues with maybe 7 of the converted rules. I've yet to look at why they wouldn't work without Apache erroring out, but I've disabled them. I'll take a look at them sometime soon.
`
Monday, October 08, 2007
Snort/BASE and Analytics
This post is not related to Slackware, but will cover a method of utilizing BASE to conduct analysis. I'm including screenshots of my BASE setup when conducting analysis to describe how I utilize BASE and correlate logged activity. The below is NOT the only methods of conducting analytics with BASE. This method works for me and offers me quick results. In fact, if you've other methods, please post or e-mail me so that I can know different ways of using this SEM.
If you're not familiar with BASE, please visit the project's site. BASE is a browser-based console that presents intrusion detection logs in various readable formats.
Here is a screenshot of the root page:
Within the upper left-hand corner (within the blue field), there are what I call "canned queries", that will allow you to see certain subsets of data. The ones that I focus on the most are
- Today's alerts
- Last 24 Hours alerts
- Last 72 Hours alerts
- Most recent 15 Alerts
- Most recent 15 Unique Alerts
- Most frequent 5 Unique Alerts
Out of those, I focus on "Last 72 Hours alerts" most frequently.
Let us delve into the last 72 hours' events. Note in the image that I've circled this link. Please either follow along if you've BASE installed, or follow this diatribe and its image links. Either click the circled link or open it in a new tab or browser. I tend to open BASE links in a new browser instance, as it gives me a separate area to dig into a new investigation. This way, if I've several concerns, I've a browser window for each.
After clicking the 72-hour link, you should see something similar to below:
I've split the browser window into two pages, since the alerts scroll down the page. For this exercise, we're going to focus on the second image, specifically the "WEB-PHP remote include path" events (toward the bottom). I chose these events because I wanted a good example of how to correlate events per IP. Click on this link (circled in RED) or open the link in a new browser/tab. You may see something similar to the following browser window:
In this example, 37 alerts are showing, with various source IPs (or what I call SIPs) and, in this case, one destination IP (what I call a DIP). Note that there could be more than one DIP, such as when you've two web servers or two IPs that are sharing a NIC. In the above browser window, I've a few IPs apparently attacking my web server. How do I make it so I see one line per SIP yet get enough situational awareness that I have an idea of which SIP generated what number of alerts on a DIP? The "Unique IP Links" in the upper right corner (circled in RED). Click on that link and you should see something similar to the following:
What's changed? The traffic is now matched based on unique traffic. Let's focus on "90-179-94.adsl.cust.tie.cl/200.90.179.94". This IP shows as a source and destination IP. Why? Because the IDS sensor logged both the web server's sending and receiving traffic (bi-directional). Note that this only happens when a response signature triggers (we'll see this in the next screenshot). If the web server response does not trigger a signature, the IDS won't log an alert. This is where signature tuning comes in handy...you really don't want to see legitimate HTTP 202 (OK) traffic being logged unless absolutely necessary. You only want concerning traffic to be logged. Now, note the brackets (sloppy) in RED in the above right screenshot. I'm going to click the 200.90.179.94 IP because I want to know what's going on there. I also observed this IP in the lower half of the screen (not screenshotted for brevity) alerting on my other IP (the NIC is dual-homed). Click on the IP and you'll see something similar:
You can study this page for a moment, but its just a page to gain a further understanding of who owns the IP. The real resources on this page are circled in RED. We'll click on both, starting with "Source/Destination", then "Unique Alerts". Open them in separate windows so you can compare. While both may show similar alerts, each is valuable:
The view on the left shows every unique attack and attack response regarding the attacking IP. The view on the right shows a summary of the attacks, with a description of "4 unique alerts detected among 16 alerts on 200.90.179.94/32". The right view also shows that you can dig down into each category of alert, if you chose.
Which view do I rely on? For a quick view, I usually use the right screenshot, but I also use the left screenshot method for when I want to see everything the attacking IP did (and how my server responded). Note that I didn't obfuscate the whole of my server's IP. I wanted to show an example of this method of analysis showing EVERYTHING the attacker did, including reaching out to both of my IPs.
I'm not going to go further. I just wanted to highlight how BASE can be used efficiently. Anything further would get into payload analysis, which is beyond the scope of today's post.
Stay tuned for a possible swf2vnc movie capture of using BASE. This will happen as soon as I can figure out how to mask my public IPs. This task may get me to delve into using my Macs to edit the SWF movies (we'll see if that is possible, with free- or shareware).
If you're not familiar with BASE, please visit the project's site. BASE is a browser-based console that presents intrusion detection logs in various readable formats.
Here is a screenshot of the root page:
Within the upper left-hand corner (within the blue field), there are what I call "canned queries", that will allow you to see certain subsets of data. The ones that I focus on the most are
- Today's alerts
- Last 24 Hours alerts
- Last 72 Hours alerts
- Most recent 15 Alerts
- Most recent 15 Unique Alerts
- Most frequent 5 Unique Alerts
Out of those, I focus on "Last 72 Hours alerts" most frequently.
Let us delve into the last 72 hours' events. Note in the image that I've circled this link. Please either follow along if you've BASE installed, or follow this diatribe and its image links. Either click the circled link or open it in a new tab or browser. I tend to open BASE links in a new browser instance, as it gives me a separate area to dig into a new investigation. This way, if I've several concerns, I've a browser window for each.
After clicking the 72-hour link, you should see something similar to below:
I've split the browser window into two pages, since the alerts scroll down the page. For this exercise, we're going to focus on the second image, specifically the "WEB-PHP remote include path" events (toward the bottom). I chose these events because I wanted a good example of how to correlate events per IP. Click on this link (circled in RED) or open the link in a new browser/tab. You may see something similar to the following browser window:
In this example, 37 alerts are showing, with various source IPs (or what I call SIPs) and, in this case, one destination IP (what I call a DIP). Note that there could be more than one DIP, such as when you've two web servers or two IPs that are sharing a NIC. In the above browser window, I've a few IPs apparently attacking my web server. How do I make it so I see one line per SIP yet get enough situational awareness that I have an idea of which SIP generated what number of alerts on a DIP? The "Unique IP Links" in the upper right corner (circled in RED). Click on that link and you should see something similar to the following:
What's changed? The traffic is now matched based on unique traffic. Let's focus on "90-179-94.adsl.cust.tie.cl/200.90.179.94". This IP shows as a source and destination IP. Why? Because the IDS sensor logged both the web server's sending and receiving traffic (bi-directional). Note that this only happens when a response signature triggers (we'll see this in the next screenshot). If the web server response does not trigger a signature, the IDS won't log an alert. This is where signature tuning comes in handy...you really don't want to see legitimate HTTP 202 (OK) traffic being logged unless absolutely necessary. You only want concerning traffic to be logged. Now, note the brackets (sloppy) in RED in the above right screenshot. I'm going to click the 200.90.179.94 IP because I want to know what's going on there. I also observed this IP in the lower half of the screen (not screenshotted for brevity) alerting on my other IP (the NIC is dual-homed). Click on the IP and you'll see something similar:
You can study this page for a moment, but its just a page to gain a further understanding of who owns the IP. The real resources on this page are circled in RED. We'll click on both, starting with "Source/Destination", then "Unique Alerts". Open them in separate windows so you can compare. While both may show similar alerts, each is valuable:
The view on the left shows every unique attack and attack response regarding the attacking IP. The view on the right shows a summary of the attacks, with a description of "4 unique alerts detected among 16 alerts on 200.90.179.94/32". The right view also shows that you can dig down into each category of alert, if you chose.
Which view do I rely on? For a quick view, I usually use the right screenshot, but I also use the left screenshot method for when I want to see everything the attacking IP did (and how my server responded). Note that I didn't obfuscate the whole of my server's IP. I wanted to show an example of this method of analysis showing EVERYTHING the attacker did, including reaching out to both of my IPs.
I'm not going to go further. I just wanted to highlight how BASE can be used efficiently. Anything further would get into payload analysis, which is beyond the scope of today's post.
Stay tuned for a possible swf2vnc movie capture of using BASE. This will happen as soon as I can figure out how to mask my public IPs. This task may get me to delve into using my Macs to edit the SWF movies (we'll see if that is possible, with free- or shareware).
Subscribe to:
Posts (Atom)