Hello all, I''m new to the list. But have been using Shorewall on and off for over a year now. The one thing that got me hooked on staying with Shorewall, was the extensive and useful documentation. Great Job! I see also that over use of blacklisting is time consuming for restarts, refresh and it also means the kernel spends more time checking incoming packets. The following is from: http://shorewall.net/1.4/blacklisting_support.htm "Important Neither form of Shorewall blacklisting is appropriate for blacklisting 1,000s of different addresses.The blacklists will take forever to load and will have a very negative effect on firewall performance." What if you were to use either a database like BerkeleyDB or maybe something like the .cdb file used in Dan Bernstein''s tcpserver. I have several thousand addresses blocked for spamming in my smtp.cdb for qmail and the speed for look-ups is fast to say the least. I can see that the problem with using BerkeleyDB or other DB systems is the database would have to be up and running before the firewall starts. Not a big thing to change in Linux. I''m not a programmer. So please don''t shoot me. But it seems like a good way to go for blacklisting. My 2 cents. -jim
On Tue, 2004-12-21 at 13:36 -0800, James Burns wrote:> > What if you were to use either a database like BerkeleyDB or maybe > something like the .cdb file used in Dan Bernstein''s tcpserver. I > have several thousand addresses blocked for spamming in my smtp.cdb > for qmail and the speed for look-ups is fast to say the least.The problem is that the database needs to be available inside the kernel in an interrupt context. That lets out any conventional database like BerkeleyDB. There are a couple of patches in Patch-O-Matic-NG (ippool and ipset) -- should one of those make it into the standard kernels, then I will adopt it for blacklisting. Both of these patches implement an in-kernel database of address/proto/port tupples that can be accessed in Netfilter rules and that can be updated using a user-space utility. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Tue, 2004-12-21 at 14:34, Tom Eastep wrote:> On Tue, 2004-12-21 at 13:36 -0800, James Burns wrote:> The problem is that the database needs to be available inside the kernel > in an interrupt context. That lets out any conventional database like > BerkeleyDB. > > There are a couple of patches in Patch-O-Matic-NG (ippool and ipset) -- > should one of those make it into the standard kernels, then I will adopt > it for blacklisting. Both of these patches implement an in-kernel > database of address/proto/port tupples that can be accessed in Netfilter > rules and that can be updated using a user-space utility. > > -TomThank you for clearing that up for me. I read the man pages for ippool and ipset. Both look usable for blacklisting. But to be honest. I think ipset would be a good choice as far as flexibility is concerned. A tool like that would have many uses in the Shorewall project I would think. As before. My 2 cents. -jim
On Tue, 2004-12-21 at 14:34, Tom Eastep wrote:> The problem is that the database needs to be available inside the kernel > in an interrupt context. That lets out any conventional database like > BerkeleyDB. > > There are a couple of patches in Patch-O-Matic-NG (ippool and ipset) -- > should one of those make it into the standard kernels, then I will adopt > it for blacklisting. Both of these patches implement an in-kernel > database of address/proto/port tupples that can be accessed in Netfilter > rules and that can be updated using a user-space utility. > > -TomThank you for clearing that up for me. I read the man pages for ippool and ipset. Both look usable for blacklisting. But to be honest. I think ipset would be a good choice as far as flexibility is concerned. A tool like that would have many uses in the Shorewall project I would think. As before. My 2 cents. -jim
On Tue, 2004-12-21 at 15:54 -0800, James Burns wrote:> But to be honest. > I think ipset would be a good choice as far as flexibility is concerned. > A tool like that would have many uses in the Shorewall project I would > think.I agree -- but I believe it needs a save/restore facility before it will be really usable. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Tue, 2004-12-21 at 19:43 -0800, Tom Eastep wrote:> On Tue, 2004-12-21 at 15:54 -0800, James Burns wrote: > > > But to be honest. > > I think ipset would be a good choice as far as flexibility is concerned. > > A tool like that would have many uses in the Shorewall project I would > > think. > > I agree -- but I believe it needs a save/restore facility before it will > be really usable.Duh -- it has such a facility; I should read twice and post once... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
--On Tuesday, December 21, 2004 20:07 -0800 Tom Eastep <teastep@shorewall.net> wrote:> Duh -- it has such a facility; I should read twice and post once...Yanno to be honest though, for such a critical package and all, the netfilter documentation that I''ve been able to find is...well, depressingly sparse.