[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-pf
Subject:    Re: Featuritis: overload on transferred volumes, auto-expiring tables?
From:       "Travis H." <travis+ml-pf () subspacefield ! org>
Date:       2007-01-10 22:34:22
Message-ID: 20070110223422.GA16069 () subspacefield ! org
[Download RAW message or body]


On Mon, Jan 08, 2007 at 12:03:30AM +0100, Peter N. M. Hansteen wrote:
> The OTHER feature I thought of, since we're dealing with tables, is to
> have a way to declare tables with expire time for its entries.  We
> have expiretable for that, but I for one would find it convenient to
> be able to declare a table such as
> 
>  table <bruteforce> persist expire 24h
>
> meaning that table entries are removed when they have not been
> referenced during the last 24 hours.


I feel like I'm always repeating myself (or advertising) when I bring
this up, but this can more or less be done with pf and my tool,
dfd_keeper.

Since before macros existed (meaning, I think, ipfilter), I've been
generating my firewall with a simple shell script.

Basically you do something like:

pfctl -f /dev/stdin <<EOM
...
EOM

In this case, any occurence of the form $foo is expanded as the content
of shell envar $foo as normal for shell scripts.

I don't recall the location of my old ipfilter scripts, but it was
pretty easy to do the equivalent of "antispoof" as well, as long as
you knew how to use eval to access the contents of a variable whose
name is computed.

So anyway, I eventually wanted a firewall with rules that changed in
response to the environment; this is handy for all kinds of reasons.
So I created DFD, specifically dfd_tbk (The Black Knight), which works
with iptables (at the time I didn't have room for a seperate firewall
box, and so was stuck with an inferior rule language).  Anyway, I long
ago replaced it (and now the Linux port needs a maintainer, if anyone
knows any candidate).  So now I have dfd_keeper (The Bridge Keeper),
which uses pf.

Since then, pf has matured, I've learned about authpf, and a lot of
what dfd_keeper could do has become possible in pf, but not all.
For example, you can have "rule queues", where you can insert a rule
into the fixed-size queue, and when it fills up they purge the oldest
one.  This is handy for blocking problem hosts without creating too
many rules.  Also, you can set rules up to expire at a certain time.

This all happens without requiring tables or anchors or any of that.

Furthermore, the way you talk to DFD makes it super-easy to integrate
with other programs.  It's netcat, or even telnet.  It accepts lines
of input of the form "command argument1 argument2 ..."; does this
sound familiar to anyone?  Yes, it's like a shell for the firewall.

If you have any experience with programming languages, you should
be able to follow the python code.  DFD itself is a module, and
you implement a set of rules and commands that modify them in a
script, and then you invoke that script at boot time.  A sample
firewall script suitable for a natting firewall is provided.
It should be trivial to write a small script triggered by, say,
snort, and have that block an IP (or rdr them to a honeypot).

Right now there is no crypto or authentication in the application
code, but there's nothing stopping you from using the firewall
rules themselves to require it when connecting to that port.

Currently I have a prototype sniffer that listens for p2p file
sharing traffic and sets up port-forwarding (rdr) back to that
host.  I'm also working on making the persistence and updating
a bit more sensible.  Yes, it saves the state of the firewall
in /var/dfd and restores it when run later.

I'm not exactly sure how to get rule usage stats into dfd_keeper,
but I think I should be able to parse pfctl -s rules -v -v and
extract that information.

I certainly have similar functionality, including the ability
to show the ruleset provided to pfctl with line numbers, so that
you know exactly what rule threw it...

Not everyone uses all the features of DFD, so I am trying to keep
it a collection of small tools where that makes sense.  I don't
see it being very sensible to have a lot of small sniffers,
though, so I'm investigating a way to have a sniffer that can be
configured to listen to different events, and yet be able to create
the narrowest BPF filter that will catch all of those events.
Perhaps that work will be more widely applicable.

Note that DFD is one process.  The only time it forks is when it
executes pfctl.  It is also single-threaded.  Everything is based
around Twisted's asynchronous I/O framework.  From what I understand,
they even have a ssh client implemented, so adding crypto shouldn't
necessarily be hard... imagine multiple clients sshing to a
single-threaded pure python script... how cool is that?

Eventually, when I get some more auxillary scripts, I plan on making
a port or something like that out of it, so that people can just
"make install" and have a very featureful firewall.  Right now it
takes a bit of effort to install things... if you're familiar with
how to install python modules in the ports system, please get in
touch with me.
-- 
``Unthinking respect for authority is the greatest enemy of truth.''
-- Albert Einstein -><- <URL:http://www.subspacefield.org/~travis/>

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]