Is there Deep Packet analyzing plugins for PF?

[Denis Lapshin]

Hi there!

Interesting in how to make Deep Packet analyzing engine for my OpenBSD
box. I'm currently using PF to perform IP headers manipulation. But
sometimes I need analyze packets data while packet traversal.

Please give some recommendations.

Thanks.

--
Denis

[sadegh solati]

hi,

you can use divert with snort or suricata. 

you can make an inline IPS using them.

[Denis Lapshin]

Just have read about Snort and Suricata engines. The second one looks more productive in DPI task because of utilizing multi-thread algorithms.

Coult you explain a bit more about "divert" with Suricata to make an inline DPI engine.

Thanks

-- 
Denis

[sadegh solati]

Hi 

Google is your best friend to obtain info about every thing.

anyway .i will give some info about how to use divert.

pf is a part of kernel and the kernel has it's own memory space which cannot be acessed by users applications.

suricata and snort are user level applications. for doing inspection they need data , thus you need a tool to copy data from kernel memory space to user memory space. this tool is divert.

using divert has some limitations. 

for example:

1-copying data takes a lot of time.
2-you can pass or drop the packet. altering the packets will cause tcp desyncronization

3- for saving resources you might want to do NAT after the packets were inspected. this is not possible because the pf will ignore reinjected packet from divert for preventing loops(be diverted again).

there is a guide on suricata redmine for how to use divert in freebsd and ipfw,it also works on openBSD and pf. you canuse some thing like this in you pf.conf

pass in quick from any to any port 80 divert-packet 8080 keep state

for more info Google is your friend

regards

Sadegh

[Laurent Cheylus]

Hi,

On Wed, Mar 04, 2015 at 10:41:57PM +0300, Denis Lapshin wrote:
> Just have read about Snort and Suricata engines. The second one looks more
> productive in DPI task because of utilizing multi-thread algorithms.

Yes, Suricata is now a better solution than Snort to do packet filtering
/ packet inspection.

> Coult you explain a bit more about "divert" with Suricata to make an inline DPI
> engine.

You could read this blog post about OpenBSD divert to do Packet
Inspection / DPI :
http://blog.rootshell.be/2010/07/12/packet-inspection-using-divert-sockets/

++ Foxy

[Denis Lapshin]

Hi

Built Suricata from sources with "ipfw divert-sockets" support on OpenBSD 5.4. After that I did some efforts to make suricata working with "divert-packet" directive for divert sockets PF.conf.
I've added  the rule below into pf.conf  as man dirvert(4) recommend (I tried this PF rule on 80 port and on all ports as listed below):

pass out on $ext_if inet proto tcp divert-packet port 8000

afterwards I ran Suricata to listen with "-d 8000" directive.

Waiting for some foreground output from suricata was redirected from PF divert, but it seems to be nothing provided from DPI engine because of difference in divert algorithms from PF and IPFW which has been supported by suricata.

I don't know what the difference with PF and IPFW divert rules in nature. Does IPFW divert-sockets completely different than PF divert-packet realization?

Has somebody successful experiment with Suricata and PF on OpenBSD by using divert(4)?

But suricata successful listening on any OpenBSD system interface with "-i interface-name" directive. So I can see full output of packet processing while suricata foreground running but not from PF.

Thanks.

Denis

-- 
Denis

[Stuart Henderson]

On 2015/03/07 10:43, Denis Lapshin wrote:
> Hi
>
> Built Suricata from sources with "ipfw divert-sockets" support on
> OpenBSD 5.4. After that I did some efforts to make suricata working
> with "divert-packet" directive for divert sockets PF.conf.
> I've added the rule below into pf.conf as man dirvert(4) recommend (I
> tried this PF rule on 80 port and on all ports as listed below):
>
> pass out on $ext_if inet proto tcp divert-packet port 8000
>
> afterwards I ran Suricata to listen with "-d 8000" directive.

First thing to check is probably that the packets really are matching
on this rule. Add "log" to the rule and monitor pflog (something like
"tcpdump -neipflog0 -vvs500"). Or add "match log(matches) to $ip port $port"
to the top of the ruleset and it will show a line of tcpdump output for
every ruleset line that matches the packet.

You can also use the simple code from the divert(4) manual, it is a
working example and prints the packet addresses, so it's easy to test.

Basically: break the job into different steps, so you can test each one
individually. If packets aren't hitting the rule with "divert-packet" at
all, look at your PF rules. If they are matching the right rule and the
simple test works, you know to look in the direction of Suricata.

> Waiting for some foreground output from suricata was redirected from PF
> divert, but it seems to be nothing provided from DPI engine because of
> difference in divert algorithms from PF and IPFW which has been
> supported by suricata.
>
> I don't know what the difference with PF and IPFW divert rules in
> nature. Does IPFW divert-sockets completely different than PF
> divert-packet realization?

The mechanism is different but is explicitly intended to be compatible
with IPFW divert-sockets..