Contributed by phessler on from the oink-oink dept.
- kqueue.
- pf table support (more flexible than anchors).
- pf ioctl's calls.
- modular design.
- daemon mode support.
- whitelist support.
- syslog logging support.
The program is BSD licensed and waiting for suggestions/improvements. You can find all the information in the program homepage."
(Comments are closed)
By Benjamin Schweizer (193.29.186.1) on http://www.redsheep.de/
Comments
By Jose Ramon Palanco (80.58.1.107) jose.palanco@hazent.com on http://people.hazent.com/~jrp
...you will see it comes with white list support ;)
enjoy it!
Comments
By Anonymous Coward (69.197.92.181) on
By Stephan Schmieder (217.231.25.208) ssc@h07.org on http://unix-geek.info
The idea wasn't dropped at any time.
Snort2pf has an "unblock after X seconds" feature to fight such DoS attacks.
And the proper way of whitelisting is to do it inside pf.conf:
pass quick <TableTrustedHosts>
anchor snort2pf
Although I think it's great to have a c fork of snort2pf,
I had liked to be informed earlier about it.
(e.g. for discussing the need of this whitelisting feature)
Comments
By Benjamin Schweizer (84.164.214.78) on http://www.redsheep.de/
Comments
By Stephan Schmieder (217.231.25.208) ssc@h07.org on http://unix-geek.info
I mean, when you are able to gain control of an internet core router,
you are probably able to bypass intrusion detection and get root on that box. no need to hack such a router and only dos non-whitelisted requestes from the outside.
And, perhabs you don't know, but some admins might notice their whole net is down after a couple of minutes. and those admins could just block packets from the hacked router or disable snort2* and restart their firewalls.
Comments
By Stephan Schmieder (217.231.25.208) ssc@h07.org on http://unix-geek.info
it enables you to create filters,
for example, you could allow all subnets but a few to pass through the firewall regardless of the idps filtering.
Or just a couple of hosts with specific source/dest ports and tcp flags....
It's basically the same as with you're AntiExploit (Aexpl) toolsuite...
You're signatures have to be good and the range of you're filter actions have to be choosen carefully.
By scrooge (195.122.29.101) on
By Anonymous Coward (207.54.125.136) on
Comments
By Benjamin Schweizer (84.164.214.78) schweizer@dsb.net on http://www.redsheep.de/
Comments
By Anonymous Coward (24.203.161.144) on
Comments
By Anonymous Coward (69.197.92.181) on
By Anonymous Coward (64.235.239.2) on
Comments
By Anonymous Coward (69.197.92.181) on
Comments
By JC (24.203.161.144) on
One other thing that bothered me before with snort2pf is that it didn't seem (from the code I read) to kill an established state over which an attack is detected. Does snort2c issu pfctl -k (or equivalents) to kill conections from an IP that should now be blocked? Otherwise, as long as the attacker keeps his original (block provoking) connection open, he's free to keep hacking away...
JC
By Benjamin Schweizer (84.164.205.81) gopher at h07 dot org on http://www.redsheep.de/
By Anthony Roberts (68.145.103.21) on
Comments
By j (80.108.115.184) on
Comments
By Anonymous Coward (200.140.7.162) on