A few days ago i wrote about some challenges that my Snort_inline presented. Especially the full content logging wasn’t working quite as i would have liked. Logging on pseudo device ‘any’ didn’t work right because then the traffic that was NAT-ted was both recorded before NAT and after NAT. The solution I (with help of #snort-gui) came up with was using ‘-i any’ anyway, but exclude my public ip using a BPF filter. Later i saw Joel Esler write the solution in a unrelated problem to someone else. Sometimes solutions can be so simple!
Solution: passing -i eth0:eth1 to snort… Duh! Thanks Joel!
Today I installed a new sensor for Sguil. It went much better than before, but still i needed #snort-gui’s help again. The issue was that Sancp stats were not picked up by the sensor.
It turns out that the default initscript for sancp uses an old and depreciated setting that tells sancp to log into the /snort_data/sensorname/sancp/today directory. The sensor expects it in /snort_data/sensorname/sancp. After changing that in the /etc/default/sancp file it worked like a charm.
Just spend some time trying to get the transcripts part of Sguil working with my Snort_inline sensor. Without an obvious clue it returned no data for every alert that was received. After much trial and error, and especially much help by Bamm Visscher on IRC, i noticed that i recorded the full packet data from my ppp0 device. Then i remembered issues i had before with that, namely that the logging occurs after NAT. Snort_inline however, gets the packets from the system before NAT. That results in a mismatch causing the sensor not to be able to provide the transcript requested. Changing the interface to record the full packets from to eth0 solved the problem!
Partially, that is. Because i have multiple ethernet adapters in the firewall serving multiple network segments, the problem is not entirely solved yet. Eth0 is covered, but what about eth1? Running log_packets.sh twice won’t work, because it can only run once per sensor (not to confuse with once per box), and the snort_inline process is one sensor for all nics. Using -i any will work, but is messy, because all natted connections will be recorded twice, once from before nat and once from after. On #snort-gui it was suggested to checkout adapter bonding. This, it turns out, only works from adapters on the same segment. In some forum i found by google it was suggested to do use -i any, but filter on the mac address of the ethernet adapters. When i brought that up on #snort-gui, Bamm Visscher suggested just filtering on the external ipaddress. That seems to work fine…
I have been using ModSecurity for quite some time now to protect a webserver, but i never felt the need to write my own rules. Recently though, my site got quite a lot of spam in the comments of my TikiWiki based site. Since i was not willing to disable the anonymous comment posting i decided to see if i could use Mod_Security to block the spam.
The spam all looked alike with the following characteristics. It all contained a list uri’s with a pipe | before them. So decided to try the most easy way, by blocking all posts with this characteristic.
SecFilterSelective REQUEST_URI “.php” chain
SecFilterSelective POST_PAYLOAD ” | http:”
And it works fine:
[Sat Jul 01 12:37:32 2006] [error] [client 188.8.131.52] mod_security: Access denied with code 404. Pattern match ” \\| http\\:” at POST_PAYLOAD …
Surely the rule can be much refined, but as long as it works as it does, and i see no bad side effects, i’m happy 😉
William Metcalf recently wrote a bait-and-switch plugin for Snort_inline. The idea is that when a rule matches on certain traffic this plugin loads an iptables rule into the system that redirects the offending host to another server. This can present the user an error message such as “Access Denied” for example, but this server can also have al kinds of sniffing tools, or even be a honeypot.
As the plugin currently creates an iptables rule it only works with linux. Also, it has some difficulty with existing iptables rulesets that might be maintained by other programs, such as my own Vuurmuur. My idea is to investigate whether or not it is possible to simply do the redirection in Snort_inline itself. By rewriting the ipaddress in the IP header, it might work as well. Naturally, this would need to be done for every packet, but with a connection to either the flow engine or the stream engine, this should be able to work… just a thought…
I just finished Preventing Webattacks with Apache by Ryan C. Barnett. Even though the title says it is about Apache it is really mostly about Mod_Security, and this is why i really love the book.
Especially cool is the part of the book where the author challenges the user to setup his ‘Buggy Bank’ example application to play with the vulnarebilities and with the possible counter measures.
This book got me even more exited about Mod_Security, which I use already to protect one webserver. I plan to check out setting up a reverse filtering web proxy soon.
Currently I am rewriting a modification of the TCP reassembler in Snort_inline. Snort’s TCP reassembler is called Stream4 and it works fairly well in IDS mode, however it has some serious issues in inline mode. The biggest and most important issue is that Snort_inline cannot block an attack if it is detected in the reassembled stream. In Snort_inline 2.4 we made our first attempt to fix this with the stream4inline modification.
Stream4 was never designed to be used inline. It was designed to help the detection capabilities of Snort in IDS mode. This had a large consequence for the design. In Stream4, incoming packets are stored in a per-stream list of packets, before the packet is handled normally. After a number of packets have been piled up this way, the stream is flushed. This flush builds a pseudo packet containing the payloads of all the ack’d packets in the list. This pseudo packet is than ran through the detection engine, to see if it contains an attack. This works fine for IDS mode, since this way the attacks can be detected in the reassembled stream.
When running in inline this concept has a big flaw. In inline mode we can use the action drop. This action makes sure that the underlying subsystem (netfilter or ipfilter) discards the packet, making sure it will not reach the destination. The problem with Stream4 is that at the time the pseudo packet is inspected, its content is already accepted and ack’d by the end-host. This situation is of course very unsatisfying.
To deal with this problem in Snort_inline 2.4 we created the stream4inline option. This option is a modification to Stream4 that simply reassembles the stream for every packet received. Then instead of the normal packet, the reassembled stream is scanned every time. There are two performance problems with this approach. The first is that we call the functions to build the pseudo packet for every packet we receive. Since this function walks the packet list every time, this is expensive.
The second problem is harder to solve. Because we scan a sliding window, we end up scanning the same data multiple times. I have not really thought of an (easy) solution for this. The rewrite of the stream4inline option is mostly focused on two improvements. First the performance of the reassembly itself will be improved by keeping a cached version of the reassembled stream. Second, the implementation will be much better and robust. I will discuss it on a more technical level later.