OpenBSD Journal

Remote pf control daemon

Contributed by jose on from the remote-control-management dept.

Srebrenko Sehic writes :
"Couple of weeks ago, I started implementation of rpfcd, remote OpenBSD packet filter control daemon.

rpfcd goal is to provide a common framework for pf control and monitoring. Instead of running pfctl/tcpdump/pflog, writing ad-hoc parsing scripts, sending the results by mail, rpfcd provides the same and much more via a transparent server-client interface. Together with a decent CLI/GUI client, pf firewall monitoring becomes rather easy. This is especially interesting if you have several firewalls to control and monitor.

Since I don't know GUI programming, I'm looking for a brave soul that could implement a GUI client.

Anyways, more details, including source snapshots, are available at http://www.insecure.dk/rpfcd/.

Any input is appreciated. Thanks. "

This type of thing could prove to be very useful and an interesting protocol. Worth having a look at.

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    It seems to me that for a long time, the emphasis of OpenBSD was auditing and code correctness. Now it seems that we are getting a lot more security architecture and new security tools, in addition to the existing base of great code. This is excellent! I'm looking forward to 3.2 which is coming soon, right?

    Comments

    1. By Anonymous Coward () on

      It depends what your definition of "soon" is.

      Let's see. Every six months. 3.1 was released in May. It's now August. Probably another 3 months...

      Comments

      1. By Cowardly poster () on

        They've released at least one version ahead of schedule. I wouldn't put money on it happening again, but it has happened in the past.

  2. By invaderzim () on

    Having not really looked at the code(I don't run -current anywhere at the moment), what is being done to keep the client/server setup secure?

    Comments

    1. By Srebrenko Sehic () haver@insecure.dk on mailto:haver@insecure.dk

      Well, besides trying to produce correct code (avoid buffer owerflows, race conditions etc), using SSL for communication, rpfcd runs also with minimal privileges.

      Children (serving clients), after chorooting to /var/empty and opening the neccesary device handles, drop all privileges after that.

      I still need to implement username/passwd + client/server certificates authentication.

      Apxm. 50 lines of code runs as UID 0. Rest is unpriviliged.

      Comments

      1. By invaderzim () on

        Excellent, this looks like a promising tool.

    2. By Banonymous Wizard () on

      over SSL

      Comments

      1. By invaderzim () on

        You are correct it's on the web page, I beg a thousand pardons from you.....

  3. By Anonymous Coward () on

    Looks promising... If this could be used with some type of Snort implementation acting like a packet scrubber like http://hogwash.sourceforge.net talking to or on a transparent filtering bridge0 firewall as a first line kiddie gate before traffic hit the main firewall, it might make a nice blended solution. Interior IDS' could trigger other events. Lot's of possibilities.

    Comments

    1. By Anonymous Coward () on

      Unless you can convince script kiddies to authenticate via authpf before scanning your network, this is a pretty stupid idea. :)

      Comments

      1. By Anonymous Coward () on

        ummm... who said put authpf on _any_ interface they can touch. bridge0 is invisible. third interface/third network... :)

    2. By Srebrenko Sehic () haver@insecure.dk on mailto:haver@insecure.dk

      Possibilities are there. However, rpfcd follows KISS and will probably only allow monitoring and _perhaps_ some light pf control.

      Hybrid 'let's stop kiddies automagically by inserting deny rules in pf' solutions won't fly.

      Comments

      1. By francisco () on http://www.blackant.net/

        Hybrid 'let's stop kiddies automagically by inserting deny rules in pf' solutions won't fly.

        glad you agree. every now and then this comes up on the mailing lists. a couple problems i remember: 1) what order do new rules go in? 2) it's a great way for someone to DoS your firewall, like scan from forged ip's and block large quantities of hosts from your sites.

        Comments

        1. By Daniel () daniel a kladdkaka d nu on mailto:daniel a kladdkaka d nu

          For personal use this kind of ip-blocking isn't a problem. To comment your 2 problems:

          1. Add a deny rule without the "quick" statement at the end of pf.conf. Then when you want to unblock an ip you just add an allow (pass) statement. Appending at the end all the time. This will be quite messy in the pf.conf after some time but it's probably the easiest. A Perlprogram that clean up the ip's that have been allowed again after being denied could be put in a cronjob to keep the pf.conf file quite clean.
          2. For personal internet-use there really isn't a problem with the possibility of DoS. It's simply would (next to) never happen and if you cant access one of your favourite sites, your DNS seems broken or similar you know where to check. You could also specify IP's that always should be able to talk to the firewall. Just add an allow rule for these in the top of the pf.conf file and include a "quick" statement and the rest of the rules will be ignored. Ofcourse you would never ever want an automatic IP-blocker on a firewall/gateway connected to a commercial/official site/network, but that is a completely different story and hopefully obvious.

          I see the minimal "risk" of being DoS:ed as a good tradeoff compared to not having automatic IP-blocking.

  4. By elrako harkonnen () sect@datacrypt.org on mailto:sect@datacrypt.org

    it could also be the focus of attacks...

Latest Articles

Credits

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 deadly.org 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.]