Plug command in iptables

Hi,

I have a very basic knowledge of iptables, does somebody know if there
is something for using user-space commands in the rules?
For example:
instead of:
iptables -A INPUT -m state --state NEW -j ACCEPT
do
iptables -A INPUT -m state --state NEW -j do-some-script

with the scripting returning "ACCEPT" or "REJECT" according to some
parameters ( src ip / dest ip / src port / dest port / protocol etc )

Or is my question just stupid?

>I have a very basic knowledge of iptables, does somebody know if there
>is something for using user-space commands in the rules?
>For example:
>instead of:
>iptables -A INPUT -m state --state NEW -j ACCEPT
>do
>iptables -A INPUT -m state --state NEW -j do-some-script
>
>with the scripting returning "ACCEPT" or "REJECT" according to some
>parameters ( src ip / dest ip / src port / dest port / protocol etc )
>
>Or is my question just stupid?

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.

Can you turn things inside out and make a script that generates
the appropriate commands? Perhaps running it from a cron job
to keep things up to date.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

Hal Murray wrote:

> Can you turn things inside out and make a script that generates
> the appropriate commands? Perhaps running it from a cron job
> to keep things up to date.
>

Or a script that waits for new input to a file (like tail does) and
reacts accordingly.

But i agreee, this is something that should be done in userspace.

It may be possible to whip something up with the ULOG target, if you
create your own daemon instead of ulogd (using libipulog which is part
of the ulogd package).

hth,
Nils

hmurray@suespammers.org (Hal Murray) writes:

[snip]
>>with the scripting returning "ACCEPT" or "REJECT" according to some
>>parameters ( src ip / dest ip / src port / dest port / protocol etc )
>>
>>Or is my question just stupid?
>
> 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... :)

~Tim
--
So lead me to the river |piglet@stirfried.vegetable.org.uk
Blood runs thicker than the water |http://pig.sty.nu/Pictures/

As the other posts suggest, it is not(?) possible to add a user-space
command to a rule. But some work may have been already done for you: The
NetFilter project has an option to add modules to iptables: Patch-o-Matic
(or just POM). Some handy modules allow you to create "tar pits", define
multiple ports in one rule, and so on. When I scanned through the modules
I didn't see any module that allowed you to alter the standard -jump
target specifications though.

Jisse

On Sun, 16 May 2004 21:37:37 +0200, Olivier wrote:
> Hi,
>
> I have a very basic knowledge of iptables, does somebody know if there
> is something for using user-space commands in the rules?
> For example:
> instead of:
> iptables -A INPUT -m state --state NEW -j ACCEPT
> do
> iptables -A INPUT -m state --state NEW -j do-some-script
>
> with the scripting returning "ACCEPT" or "REJECT" according to some
> parameters ( src ip / dest ip / src port / dest port / protocol etc )
>
> Or is my question just stupid?

Tim Haynes wrote:
> hmurray@suespammers.org (Hal Murray) writes:
>
> [snip]
>
>>>with the scripting returning "ACCEPT" or "REJECT" according to some
>>>parameters ( src ip / dest ip / src port / dest port / protocol etc )
>>>
>>>Or is my question just stupid?
>>
>>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... :)
>
> ~Tim
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
Thanks again
Olivier

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/

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

Yes, as I said, the same way it's done with dnsbls. The trick with
dnsbls is that we need to have the compliance at the application-level.
Putting it directly in the firewall would allow to by-pass this
application-level requirement.
I do not pretend to improve security by any way...

> 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 ;)

Once again I do not pretend to improve security ( maybe I did not post
in the right newsgroup ? ), but application functionnality.

> 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 :)

What do you think of devices such as load-balancers for example? I am
using an Alteon switch, and I think this is just a great and powerful
device. It can dynamically take decision from a cookie inside an http
request for example. Cookie can be set by the switch or by the web
server. So this is an example of dynamic NAT. Pretty successfull I think!

I am routinely using dnsbls for qmail. I have to run rblsmtpd on each
one of my smtp server. If it was possible to run it ( or an equivalent )
directly on my load balancer or on the firewall or on a dedicated device
I think it would be more efficient and easier to administrate.I could do
proxies etc, but the idea is not have to setup an application. I just
want to block IPs using the service.

For world-domination on these things I'll need to raise some money and
get some experts think on the problem. I still do not have the money but
sometimes experts come on forums :)) !