Re: New Target: ipt_ACCOUNT

[Rolf Wuerdemann <rowue@crew-kg.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 6. Januar 2003 14:24 schrieb Harald Welte:
> On Mon, Dec 16, 2002 at 06:36:22PM +0100, Rolf Wuerdemann wrote:
> > Hi there ...
>
> Hi, sorry for my late reply.

Hi Harald (hope first name is o.k. ;) - no prob ;)
>
> > we've developed a new target for iptables: ipt_ACCOUNT.
> > This Target accounts Traffik on a packet-base on source and
> > target ip using netfilter (similar to nacctd - but using iptables).
> >
> > It's in use on our routers (app. 60MBit/s Bandwitdh) since three month
> > (app.) without any trouble and was tested with some DDoS-Tools before
> > use ;)
>
> great news.  A couple of comments:

Thank you ;)
>
>  I think this is the wrong approach, there are way too much data
> strucctures in non-swappable kernel momory allocated.  And kernel-OOM is
> not something we should provoke.  A better architecture from my point of
> view was: - use ULOG to copy the IP+TCP header of all packets to
> userspace [it is very efficient in doing so!!!] and then do all the
> accounting in userspace

I was aware of the OOM-Problem (so DDoS can kill your Router!), and thought
about something like acctrack_max (simmilar to contrack_max) so you can
set an maximum of tracked connections. This is not an solve for the root 
of the problem (to much data structures) - but an solve if you're afraid of
running OOM from this side. - Perhaps I'll do some tests using ULOG, but
from work with nacctd I know that copying packets from Kernel to User-Space
takes much time (and time/speed was something I want to save ;)
>
> Leaving this personal view aside, I still dislike a couple of issues
> with your patch
>
> - It doesn't adhere to the kernel CodingStyle
> 	- german variables
> 	- C++ style comments
> 	- more than 80chars per line

*G* - no problem to fix (like some debug-messages, etc ;) - I've posted
the source before "cleanup" - so I can work in suggestions/comments with
the cleanup ;) 

> - the kernel/userspace interface using a socket option

Yes - thinking about using /dev/accouning (fs i/o) to get the
data from kernel-space - /proc-fs seems to be unlikely (approx 2M
filesize) - any opinions?
>
> So if you want to contribute it into patch-o-matic, you will have to
> at least conform to the coding style, sorry.

Nothing to sorry ;) - Hwo should I post the changed version? Complete,
diff, link to ftp/cvs?

>
> > PS: We've developed it 'cause nacctd was
> > 	a) to much use of cpu
> > 	b) looses packets during kernel-problems with PF_PACKET
>
> I am (as a long time nacctd user and hacker) aware of those issues.  But
> this doesn't mean that moving everything into the kernel is the right
> thing..

Hmmm ... If you want to gain speed it's one of the best solutions - account 
the packets at the lowest possible level ;)

Regard's

	Rolf Würdemann
	Wieske's Crew KG
- -- 
               Security is an illusion - Datasecurity twice
  Rolf Wuerdemann  - Privat: rowue@digitalis.org - Office: rowue@crew-kg.de
  GnuPG-Key fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F
    RSA-Key fingerprint:      CEBB 5086 9154 E8D8 7D0E CC4F 0F5E B9CC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+GbtphqMxtmfw0C8RAsOHAJ9FNK1xJ6NLuSJkCYJwEh+cMJ0dLgCgqcPK
ehEfBQq8aavZ5KoyTMciqUk=
=TLx/
-----END PGP SIGNATURE-----