Project

General

Profile

Actions

Support #297

closed

IPFW divert based on suricata/snort rules?

Added by Jason Gerfen over 13 years ago. Updated over 13 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Affected Versions:
Label:

Description

I have been looking around trying to find some good documentation regarding using IPFW, suricata to divert traffic caught to a honeypot environment. Thanks.

Actions #1

Updated by Victor Julien over 13 years ago

Our IPFW support is limited to "just" forwarding traffic using divert. There is no support for doing conditional divert based on signature matches. You may want to have a look at using Snortsam for this. The newly released Barnyard2 1.10 beta 1 can instruct Snortsam to act based on signature matches.

Actions #2

Updated by Jason Gerfen over 13 years ago

After reading documentation about this project, including support forum threads, I am under the impression that diverting traffic based on attack signatures is exactly the type of functionality the securita software performs.

I am just trying to ensure there is not an avenue of approach using the dpi functionality to forward any packet matching a configured rule to another server. Logging only?

This is one article that has led me to the securita software: http://freebsd.rogness.net/snort_inline/. I realize this is regarding the use of snort_inline. However the link at the bottom of the page led me here. My natural assumption is that securita extends this functionality with additional rules in combination with the existing rules provided by snort.

I suppose I will have to bind snort_inline, add the securita rule sets and divert using ipfw? Seems like a bigger hassle then just using securita with ipfw.

Actions #3

Updated by Victor Julien over 13 years ago

What both Snort_inline and Suricata do in it's so called inline mode, is decide based on the rules if a packet needs to be dropped or that it can be forwarded. In the IPFW case, if it's dropped it's not send to the divert socket, if it's forwarded it is. The IPFW rule configuration then controls where in the IPFW ruleset the packet continues it journey. More fine grained control, like sending traffic to a honeypot if a certain Suricata rule fires, is not available. It would be nice to have though.

Actions #4

Updated by Jason Gerfen over 13 years ago

After looking at the source I am assuming something like this could be as respond-forward.c? Since I am new, any good resources besides the obvious documentation in terms of contributing?

Actions #5

Updated by Victor Julien over 13 years ago

I think the proper way would to have a detection keyword like "ipfw_divert_to:<rulenum>;" (much like nfq_set_mark: detect-mark.c) . If the rule matches, set the divert port in the packet (and/or flow if you want all following packets of that flow to be diverted to this rulenum as well), and then adapt the reinjection code (in source-ipfw.c) to make sure this newly set value has preference over the global reinject rulenum.

I suggest you join the oisf-devel list, makes discussing it easier.

Actions #6

Updated by Victor Julien over 13 years ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF