Netfilter development project

Netfilter development project

[Andy Loukes]

My company needs to develop two netfilter applications.

First a simple daemon which listens on a tcp socket for messages which
inform it to add or remove specific iptables rules. It needs to be
secure, very high performance and deal with multiple concurrent 
requests. We currently use iptables rules, but when I get time I'm going
to try out using IPSet as it seems more appropriate.

Second an accounting daemon, it needs to connect to another server using
a to-be-defined protocol to update the packet and byte counts, in and
out per source ip address.

I have proposed to my company that I send this out to the netfilter-dev 
list because we don't have the resource available at the moment and our 
dev team aren't particularly familiar with netfilter.

We are obviously prepared to pay!

The company is based in London although geography doesn't need to be 
particularly relevant.

Please contact me with a brief CV, any examples of code and why you 
think you should do it!

Clearly if these applications could be made useful to the wider 
community then it would be better for everyone.

I hope this is an appropriate list for this request, I did check the rules!

Regards

Andy

Re: Netfilter development project

[Pablo Neira Ayuso]

Andy Loukes wrote:
> My company needs to develop two netfilter applications.
> 
> First a simple daemon which listens on a tcp socket for messages which
> inform it to add or remove specific iptables rules. It needs to be
> secure, very high performance and deal with multiple concurrent
> requests. We currently use iptables rules, but when I get time I'm going
> to try out using IPSet as it seems more appropriate.

I don't know if there exists something similar so far, but it should not
be hard to implement this.

> Second an accounting daemon, it needs to connect to another server using
> a to-be-defined protocol to update the packet and byte counts, in and
> out per source ip address.

I can extend ulogd [1] or the conntrack-tools [2] to do this, it should
not be hard either. Probably your company can sponsor this extension. We
can discuss the details in private.

[1] http://www.netfilter.org/projects/ulogd/index.html
[2] http://conntrack-tools.netfilter.org

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: high number of rule changes per second (was Re: Netfilter development project)

[Pablo Neira Ayuso]

Andy Loukes wrote:
> I should clarify the problem we have a little more. I realised we shouldn't
> be to be too hasty in throwing away our current system, which is currently
> perl (not ideal but it does work and isn't a bottleneck) handling the
> network connection which then just calls iptables to add and remove rules.
> 
> The problem we have is two-fold. First the application that is controlling
> the firewall is load balanced, so often the daemon gets two concurrent
> requests and it appears that only one iptables command can be executed at
> once so one fails. We can fix that with locking but it would be interesting
> to understand what is happening. Is this a kernel thing?

Fails with EINTR? Anyway, it is sane to perform some kind of
serialization of the request from your application.

> Secondly it can take up to 0.5s to execute an iptables (1.3.8) add and this
> is causing a bottleneck and making the first problem more significant.

Use iptables-restore instead with -n. You can pipe iptables commands to
it. And upgrade to iptables >= 1.4, there was a major rewrite to resolve
scalability problems in iptables-restore.

> I can't reproduce this in test, I get more like 0.02s. I don't know if this is
> due to the throughput of the firewall in production (I only tried flood
> pinging when testing to generate packets). Is the slow execution likely to
> caused by throughput? It also appears to take longer with more rules already
> in the chain, which I would expect. 
> 
> I am considering IPSet for these rules, is that likely to suffer from the
> same problem?
> 
> If we were to develop a C app that directly manipulates the rules using
> libnetfilter would that help?

Unfortunately, there is no supported library for this but there will be
one in the near future. The safest interface by now is iptables-restore.

> Another option we've talked about is batching the changes and using
> iptables-restore to insert the rules as often as possible.

Indeed, that should be the way to go.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: high number of rule changes per second (was Re: Netfilter development project)

[Jesper Dangaard Brouer]

On Tue, 2 Sep 2008, Pablo Neira Ayuso wrote:

> Andy Loukes wrote:
>> I should clarify the problem we have a little more. I realised we shouldn't
>> be to be too hasty in throwing away our current system, which is currently
>> perl (not ideal but it does work and isn't a bottleneck) handling the
>> network connection which then just calls iptables to add and remove rules.

I have written a iptables system in Perl that scales to 5000 customers, 
and I can perform 77965 rule changes in 2.28 sec.

I have published my low-level iptables-to-perl library on CPAN called 
IPTables::libiptc.

  http://search.cpan.org/~hawk/IPTables-libiptc-0.11/

I have some extra modules that I have not published yet... but you can get 
them offlist if you like...


>> The problem we have is two-fold. First the application that is controlling
>> the firewall is load balanced, so often the daemon gets two concurrent
>> requests and it appears that only one iptables command can be executed at
>> once so one fails. We can fix that with locking but it would be interesting
>> to understand what is happening. Is this a kernel thing?

This is because iptables work by copying the entire ruleset to userspace 
and commiting it back... thus, there is a race-condition if two userspace 
iptables calls are performed at the same time.


>> Secondly it can take up to 0.5s to execute an iptables (1.3.8) add and this
>> is causing a bottleneck and making the first problem more significant.
>
> Use iptables-restore instead with -n. You can pipe iptables commands to
> it. And upgrade to iptables >= 1.4, there was a major rewrite to resolve
> scalability problems in iptables-restore.

Yep! -- my changes and experiences has gone into mainline ;-)

Hilsen
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------