OpenBSD Journal

snort2c: feeding pf with snort

Contributed by phessler on from the oink-oink dept.

Pablo Méndez Hernández writes in to tell us: "Antonio Benojar of Hazent Technologies has improved snort2pf rewriting it in C instead of perl, speeding it up and adding it a few advantages like:
- 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)

  1. By Benjamin Schweizer ( on

    When you rewrite a piece of stupid designed software, you get another piece of stupid designed software. That's fact. The problem whith snort2pf (and all other approaches in this direction in the past) is that you can easily use this functionality for a denial-of-service attack. All you need is to spoof some packets and the intrusion-detection-system will advice the packet-filter to block the wrong hosts; or maybe the right ones:-) This problematic was discussed years ago elsewhere and as a result the idea was dropped. Don't say you haven't been warned

    1. By Jose Ramon Palanco ( on will see it comes with white list support ;)

      enjoy it!

      1. By Anonymous Coward ( on

        So, you were planning to whitelist the entire internet? If you do that then there's no point in running this to begin with, and if you don't then people can still make whatever you haven't whitelisted inaccessable to you.

    2. By Stephan Schmieder ( on

      Hi gopher!

      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)

      1. By Benjamin Schweizer ( on

        Hey ssc! Whitelisting is not the way. Even if you unblock every n seconds, the only result is that I've to restart my attack after n seconds. I admit that spoofing tcp is harder than udp; however even if only your upstream nameserver is blocked, you are mostly dead. In my opinion this is a design failure and whitlisting as an approach to reduce the negative effects.

        1. By Stephan Schmieder ( on

          come're latest statements are so utopistic...
          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.

          1. By Stephan Schmieder ( on

            whitelisting (in pf.conf or inside the program) is a key part of the design

            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.

    3. By scrooge ( on

      hey pal, you can spoof port scans, but not 3way handshake. so...

    4. By Anonymous Coward ( on

      How do you spoof multiple ssh login attempts as root with only a couple of spoofed packets? If someone is trying to brute force passwords, couldn't something like this be used to slow them down?

      1. By Benjamin Schweizer ( on

        Sure, blocking slows attacks down. That's the benefit. But it makes you vulnerable for a massive denial-of-service attack. Thats the disadvantage and in my opinion this overweighs. Spoofing tcp is another lection and there are much more creative people than me. I think of guessing the sequence number (this was imho done in the bgp affair some months ago) or taking over a whole subnet (breaking into another host on the same wire, owning a router, phreaking around with autonomous systems). In any case this can be done.

        1. By Anonymous Coward ( on

          Right, you go ahead and try to guess the ISNs generated by open or by pf's modulate state... Good luck.

          1. By Anonymous Coward ( on

            Who says pf has anything to do with this? Its just snort you have to fool, not openbsd or pf or anything else. Making snort believe an attack is happening isn't as hard as some people here want to pretend it is, and whitelisting isn't going to help. It just means an attacker has to be more creative with who he spoofs attacks from.

    5. By Anonymous Coward ( on

      you raise a valid point, but what about those of us who correctly prevent spoofed packets at the network edge? this functionality is still useful to a number of people.

      1. By Anonymous Coward ( on

        You clearly lack a basic understanding of the issue here. Blocking spoofed packets at the edge of your network simply stops people from sending packets with a source address that should only be coming from in your network, and preventing people in your network from sending packets with addresses not in your address space. People can still spoof packets from say, google to your network. And if those spoofed packets also match a snort rule then snort2pf will add google to your pf blacklist and nobody on your network will be able to go to google.

        1. By JC ( on

          Yeah, but obviously, you don't want to have your snort listening on your outside interface; if you have snort listening on an interface behind pf, and use the right homenet and a ruleset that will only alert on attacks over fully established (handshake) connections, then the threat of self inflicted DoS from spoofed attacks is, IMHO, down to an acceptable level.

          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...


      2. By Benjamin Schweizer ( gopher at h07 dot org on

        I admit that snort2pf or snort2c might be of use, but that was never the topic. The problem is the principal design weakness of automated blocking that can be triggered by a remote attacker. Of course you must evaluate the advantages and disadvantages and may be it's a solution for you. However, this doesn't make it a generic solution for everyone. (I'm just thinking of the FUSSP)

  2. By Anthony Roberts ( on

    I don't use Perl, but doesn't it have bindings for things like kqueue, and can't it be extended to support things like the PF calls?

    1. By j ( on

      Of course one could extend perl with a module to support pf calls (i.e. ioctl calls with the correct parameters). But it seems nobody has done that so far.

      1. By Anonymous Coward ( on

        Benjamin Schweizer is a stupid gay!! Fuck you Benjamin!! Go out here, do you have a girl? I think no!!


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]