Olivier <olivierwarez@netscape.net> writes:

[snip]
>>>I'd call it impractical. The accept/reject decision is made in
>>>the kernal for each packet. There isn't time to run user code.
>> There's the whole user-mode queueing module whose existence suggests there
>> may be time to do something with some of the packets in code... :)
>
> Thanks for all your answers.
> Actually I was thinking of making something like "rblsmtpd" but at the
> iptables level ( typically do a dns request for each new incoming
> connection to check if client is blacklisted ), but I understand now this
> does not exist in iptables, but I might be able to write it myself with
> POM. I've seed a "condition patch" which may need few tweaking for doing
> what I need

You want to trust a third-party site to tell you what to do with a
third-party packet?

You want to do some kind of lookup on the incoming packet in realtime and
use that to determine whether to permit it or not? Whatever backend
database system you use (text lookup, sql, dns, ldap), please let me help
DoS it remotely for you ;)

To be honest, I don't see a major need or use for this sort of thing at the
iptables level. I don't believe in dynamic firewalls that much at the best
of times; if you're going to consider biassing your rules by source-IP,
then (a) I back impersonate you whilst doing something naughty, and (b)
there are only a finite number of cases to consider - rfcwhatever private
addresses (10/8, 172.16/12, 192.168/16) and other unroutable things (0,
127), obvious invalid packets and valid stuff. Go with the majority -
filter all ports and IP#s except where you're providing a service, and if
it's basically for the world to access, put some rudimentary invalid-packet
checks on for everything and open the port up wide. Of course, you'll be
securing the service behind that, anyway...

So. Tell us more about your plans for world-domination :)

~Tim
--
You take your message to the waters, |piglet@stirfried.vegetable.org.uk
And you watch the ripples flow |http://pig.sty.nu/