IP Filter 3.5alpha3 (fwd)

[Darren Reed <darrenr () reed wattle id au>]

There's a couple of new features to IP Filter below, which might pique
the interest of people here.  I'd welcome any suggestions/comments on
the direction here as it is early in the piece and things can go anyway.
This code is, currently, strictly alpha (so what's new you say ? :) so
don't start running production things using it and complain if it crashes
every 30 minuts and you can't patch it yourself O:_)

Cheers,
Darren

In some email I received from Darren Reed, sie wrote:
> From owner-ipfilter () cairo anu edu au Mon May  1  7:30:01 2000
> X-Authentication-Warning: cairo.anu.edu.au: majordomo set sender to owner-ipfilter () coombs anu edu au using -f
> From: Darren Reed <darrenr () reed wattle id au>
> Message-Id: <200004302119.HAA16928 () avalon reed wattle id au>
> Subject: IP Filter 3.5alpha3
> To: ipfilter () coombs anu edu au
> Date: Mon, 1 May 100 07:19:50 +1000 (EST)
> X-Mailer: ELM [version 2.4 PL23]
> Content-Type: text
> Sender: owner-ipfilter () coombs anu edu au
>
>
> There are a few people "waiting" for this email, so here it is...
>
> The next major version of IP Filter will have a few new features as
> well as another target OS - HP-UX 11.00.  At the moment, IP Filter
> for HP-UX 11.00 is only available as binary objects due to include
> files required for compiling not being public.  Before 3.5 is
> finalised, it will be a source code only port as it is with the
> others (well, excluding BSD/OS..).  There are two depot files
> available, one for 32bit systems and one for 64bit systems:
>
> http://coombs.anu.edu.au/~avalon/ip-filter/ip_fil3.5alpha3-hp11-32.tar.gz
> MD5: 458ceb8459f1bff1575be071b9588a2d
> http://coombs.anu.edu.au/~avalon/ip-filter/ip_fil3.5alpha3-hp11-64.tar.gz
> MD5: 255f1acda762cbc6d1dd4a7ba02dbdf7
>
> So what's new ?  Well bugs for one...;)
>
> First, for those who like redundancy in things, there is now a capability
> to keep the state & NAT tables in sync between two different boxes running
> IP Filter.  The protocol is network byte order and the code does what is
> required to allow big endian boxes to sync up with little endian boxes.
> This is very much experimental at present - the protocol used between
> the master & slave isn't encrypted or authenticated and neither have I
> spent a lot of time getting them to do fancy things in terms of connecting
> to each other, reading config files, etc.  If you build and install IP
> Filter, two new binares are built (ipsyncs/ipsyncm).  At the moment the
> master connections to the slave (ipsyncm <ip>) and neither really do much
> to recover if one goes away.  I'm really interested in hearing about how
> people go with playing around and how people think this should operate.
> Should the master make connections, the slaves, etc.  To not compile this
> code in, remove -DIPFILTER_SYNC.
>
> The next new feature is something which I hinted at earlier on the list
> as being "easy to do".  Well, the part I've done so far has been `easy'
> anyway :)  What I've done is added in some code to match data at the
> start of TCP connections and do something if a match is made.  Again, I'm
> interested to hear what people think this should provide iin terms of
> flexible configuration, etc.  The program "ipscan" manages the configuration
> of this.  An example config file would be this:
> #
> # * = match any character, . = exact match, ? = case insensitive
> #
> # Scan for anything that looks like HTTP and redirect it to the local
> # proxy.  One catch - this feature (redirect) is not yet implemented.
> #
> http : ("GET ", "???." ) = redirect(127.0.0.1)
> #
> # Track ssh connections (i.e do nothing)
> #
> ssh : (), ("SSH-") = track
> #
> # Things which look like smtp to be tracked else closed.
> # Client can start with EHLO (ESMTP) or HELO (SMTP).
> #
> smtp : ("HELO ", "**??."), ("220 ", "....") = track else close
> #
> # Evil napster
> #
> nap2 : ("*\0\2\0", "*...") = close
> nap4 : ("*\0\4\0", "*...") = close
> nap6 : ("*\0\6\0", "*...") = close
> nap7 : ("*\0\7\0", "*...") = close
>
> If you load that with "ipscan -f foo", it will complain about the first
> (http) line because "redirect" is not supported by the kernel code, only
> the parser :-)  Having done that, if you then loaded this rule:
>
> pass out proto tcp from any to any flags S keep state scan *
>
> it would attempt to match the start of all TCP connections against the
> strings configured above (this is where the configuration needs some
> work, I fear).  It attempts to work on longest match is best match.  So
> if it sees a connection get made and the first thing it seems back from
> the server is "SSH-", it will "track" it (i.e. do nothing :)  If the
> first 4 bytes sent matches any of nap2/nap4/nap6/nap7, then it would
> force the connection to close.  In the case of the "smtp" line, the
> "else close" is ignored with "scan *".  If however I had a rule like
> this:
>
> pass out proto tcp from any to any port = smtp flags S keep state scan smtp
>
> that would force the TCP connection to match "**LO " from the client
> (either EHLO or HELO) and "220 " from the server.  If it didn't match
> then it would close the connection.  To not compile this in, remove
> -DIPFILTER_SCAN.  The restriction here is that it only looks at the first
> 16 bytes in each direction.  There is potential here for capture of
> passwords in buffers if you're not using encryption and so long as those
> connections hang around (and state information kept), "ipfstat -sl" will
> show up the passwords. As far as I know, this is a completely new firewall
> feature (:-) and borders on what you'd get if you merged an IDS in some
> fashion.
>
> Anyway, source is available at:
>
> ftp://coombs.anu.edu.au/pub/net/ip-filter/ip_fil3.5alpha3.tar.gz
> MD5: bbb0ea0dd823848862b44e752ee75089
>
> Darren
> p.s. no man pages for the new features yet - they're far from finalised.