Older blog entries for scaramanga (starting at number 1)

So far with my forrays in to netfilter I have produced two things related to network intrusion detection.

PROMISC Chain. netfilter and iptables patches that add a new chain to the filter table called PROMISC. Packets that get picked up in promiscuous mode and arent destined for our host traverse this chain. This is useful so we can monitor all taffic on our LAN segment. You can use the REJECT target to send out RSTs to stop TCP streams between other machines.

NETLINK target. A patch that adds a NETLINK target to netfilter/iptables. This sends packets to userspace via a netlink socket so tyhat you can use my FWMON tool to monitor the data. Althugh you can do anythjing with this data, for example send the encrypted data out over the network push style.

Now this is the thing I wonder about. Is it best to send the data to userspace, then back to the kernel (through the TCP/IP stack) then on to the network. Or should the kernel send the data out directly? I mean, the data should be sent at regular intervals (eg: every 30 seconds), whether there actually is data or not, or attackers could find out what triggers an intrusion by monitoring when it sends data. Is the userspace overhead acceptable, or would it be too easy to snowblind the system, by flooding it, to the point where the data doesnt get sent to userspace? I will have to code both approaches and test them, maybe I am being too paranoid, if such a thing exists.

Kernel Space vs User space, kernel is:

• More secure, we can make sure the system can NEVER be snowblinded.
• Less flexible
• Bulks the kernel out
• Low latency

(userspace, this is all the opposite)

I've spent most of my day today with "Network Intrusion Detection, An analysts handbook" and "TCP/IP Illustrated" - trying to map out my new project, kNIDS. A kernel level network intrusion detection system. I think all NIDSes currently available are flawed in two places.

Sensor. The sensors are usually inplemented in userspace, so all the functionality like IP defragmentation, TCP stream reassembly etc.. are re-implemented on top of the kernels (and often badly implemented). Another problem is snow blinding, when the kernel recieves so much data, it decides not to send it to the sensor. A kernel level NIDS could never be fooled this way.

Analyst Console. User interfaces are usually badly designed, implemented in a proprietary fashion, ie: it doesn't interoperate with other systems. Eeach vendor has its own set of "standards" for sharing intrusion information. This is where I think UNIX can win out, with its srong standards, such as libpcap format for packet capture.

I think netfilter (part of linux 2.4) is an ideal playground to implement a kernel level NIDS sensor, it's simple and extensible. Anything implemented at this level should be fast, and kept as simple as possible. Make the detect, report the detect, nothing more.

The analyst console should contain the complexity. I love evolutions ability to manage objects (mail) - its all indexed, so manipulation is fast. You can define what objects (mails) you want to see, and how you see them. Replace "mails" with "packets" or "intrusions" and you have an idea of what an interface should be like. Don't impose order. Give the user as many tools as she needs to create her own order. Intrusion analysis is all about creating order from the jumble. The analyst should have all the tools she needs in one place, see the intrusion, view the full data to verify it, make the report, print it, send it to the CIRT/FIRST, mark it analysed, whatever.