Snort mailing list archives
Extending Snort to other protocols?
From: <Joshua.Kinard () us-cert gov>
Date: Mon, 14 Feb 2011 21:47:51 -0600
Hi snort-devel, Forgive me if this question/thought process has been asked before, but what's the relative amount of work needed to extend Snort to other protocols? Right now, Snort does TCP, UDP, and ICMP. It allows 'ip' to be used for anything else, but at that point, you're slowing it down by operating on raw network traffic, as ip rules are very expensive. I'm not much of a coder, but I was looking through the parser.c and decoder.c files, and what stands out to me is that the support of these four core protocols is deeply ingrained in the code. Adding one or more new protocols would involve tweaking things like various conditional blocks, adding new #define macros, new structs, etc. I.e., a lot of plumbing. In contrast, adding new rule options looks a lot easier. While I've not found any documented API, there is a notable amount of commonality in the Snort detection plugins. Each rule option handles its own specific bits, and links into the higher-level code through a few aptly-named functions that correspond to a higher-level API. Has something like this been considered for things like the protocols? Consider the SCTP protocol. It supports the same format of ports alongside TCP and UDP, but pretty much everything else differs from that point onwards. Adding the logic into the existing codebase to support scanning SCTP packets looks like it'd be a bit complicated, but not entirely difficult, assuming one fully understands SCTP (I don't). But it could easily leverage the existing rule syntax. I.e., alert sctp 203.0.113.57 :1024 -> 198.51.100.134 $HTTP_PORTS ( ... ), which would make adoption by rule writers fairly straight-forward. Then consider a protocol like IPX, which is a completely different animal. Adding support for a protocol like that would be much more difficult than SCTP. For IPX to leverage the existing rule syntax, you'd have to do things like redefine the nature of the address/port fields. I.e., src/dst address becomes the src/dst network & node, and src/dst port becomes the src/dst IPX socket. And that's not even getting into the sub-protocols, like SPX or NCP. I.e., alert ipx 00000001.001731e0d9f2 0x4004 -> 00000004.00015c24a371 0x0452 ( ... ). No idea if that's even valid IPX routing...finding PCAPs of it is really difficult since it's an obsolete protocol. But it gets the idea across. Assuming a modular framework kind-of-thing, the parser could check the protocol first, then offload the remaining fields to a protocol module to handle the implementation-specific bits, and that can hand back to allow other rule processing logic to follow. There already appears to be very high-level detection of various protocols in decoder.c in the form of the Decode*() functions. But those just count the occurrence of such a protocol for statistics (as far as I can tell). These could make for decent starting points for stub modules, at minimum allowing someone to easily write modules to report back the occurrence of different protocols on the network being monitored. This is all just late-night brainstorming...I'm uncertain of the actual feasibility of things, but seeing some of the more modular aspects of the Linux kernel internals got me wondering. Thoughts? --J ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Snort-devel mailing list Snort-devel () lists sourceforge net https://lists.sourceforge.net/lists/listinfo/snort-devel
Current thread:
- Extending Snort to other protocols? Joshua.Kinard (Feb 14)
- Re: Extending Snort to other protocols? Steven Sturges (Feb 15)