Controlling an iptables-match from userspace

Controlling an iptables-match from userspace

[Manfred Stock]

Hi,

I'm looking for a way to control an iptables-match from a
c/c++-program. My goal is to
have a simple match-module which can be told from userspace to either
return 0 or 1
in it's match-function (this would be useful for dynamically turning
on/off several more
complicated rules without inserting/removing them from the ip tables,
i.e. without
using libiptc (for which I haven't found an easy way on how to use it
anyways...) or
iptables itself).

The netfilter Hacking HOWTO mentions nf_register_sockopt for such
tasks (receiving
commands from userspace) - is this still the way to go, or is it going
to be removed
in the (not so far) future (eg. in favor of netlink)? Another way
would be the use of
sysfs, but it seems to be more for device drivers than this; configfs
is still relatively
new and probably not available for older kernels... Or is there even a
simpler way to do
such a thing? Any ideas/hints?



Best regards,

Manfred.

Re: Controlling an iptables-match from userspace

[Sven-Haegar Koch]

On Tue, 23 May 2006, Manfred Stock wrote:

> I'm looking for a way to control an iptables-match from a
> c/c++-program. My goal is to
> have a simple match-module which can be told from userspace to either
> return 0 or 1
> in it's match-function (this would be useful for dynamically turning
> on/off several more
> complicated rules without inserting/removing them from the ip tables,
> i.e. without
> using libiptc (for which I haven't found an easy way on how to use it
> anyways...) or
> iptables itself).

Have a look at the "condition" patch-o-matic-ng extension. Some time ago 
is was in the pom-ng subversion repository, but I don't know where it is 
kept now.

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

Re: Controlling an iptables-match from userspace

[Manfred Stock]

On 5/23/06, Sven-Haegar Koch <haegar@sdinet.de> wrote:
> On Tue, 23 May 2006, Manfred Stock wrote:
> > I'm looking for a way to control an iptables-match from a
> > c/c++-program. My goal is to
> > have a simple match-module which can be told from userspace to either
> > return 0 or 1
> > in it's match-function (this would be useful for dynamically turning
> > on/off several more
> > complicated rules without inserting/removing them from the ip tables,
> > i.e. without
> > using libiptc (for which I haven't found an easy way on how to use it
> > anyways...) or
> > iptables itself).
> Have a look at the "condition" patch-o-matic-ng extension. Some time ago
> is was in the pom-ng subversion repository, but I don't know where it is
> kept now.

Thanks. That's close to what I'm looking for. Unfortunately, it does
not seem to be maintained anymore - I could find the sources in
netfilter's svn using google, but the last change was it's import into
the new trunk directory 19 months ago... At least it compiles against
2.6.8 with only one warning, and seems to work. But I would very much
prefer a solution which does not rely on /proc because I don't believe
in it's future for this kind of stuff ;). Any ideas?


Best regards,

Manfred.

Re: Controlling an iptables-match from userspace

[Massimiliano Hofer]

On Tuesday 23 May 2006 5:00 pm, Manfred Stock wrote:

> Thanks. That's close to what I'm looking for. Unfortunately, it does
> not seem to be maintained anymore - I could find the sources in
> netfilter's svn using google, but the last change was it's import into
> the new trunk directory 19 months ago... At least it compiles against
> 2.6.8 with only one warning, and seems to work. But I would very much
> prefer a solution which does not rely on /proc because I don't believe
> in it's future for this kind of stuff ;). Any ideas?

I recently became maintainer of the condition patch.
You can find a new version at 
"http://www.nucleus.it/pom-repo/condition.tar.gz". From now on it will be 
handled as an external repository.

I'm working on some other changes that should make it more acceptable, 
althought I've been busy in the last couple of weeks.

Some considerations:
- adding a new system call or ioctl is more intrusive than a proc interface;
- a file interface doesn't require a special app.

You could argue about putting it in /sys or in the brand new configfs.
I'd like feedback about the best way to handle this.

-- 
Saluti,
   Massimiliano Hofer
        Nucleus

STRING agrument

[Allan Parreno]

Hello,

Good Day.

Anyone could help me out with this error using the string argument.

[root@ja Desktop]# iptables -o eth0 -A FORWARD -p tcp -m string --string
"X-Kazaa-Username:" -j REJECT --reject-with tcp-reset
iptables v1.3.4: STRING match: You must specify `--algo'
Try `iptables -h' or 'iptables --help' for more information.
[root@ja Desktop]#

However, if I specify the --algo if have this error

[root@ja Desktop]# iptables -o eth0 -A FORWARD -p tcp -m string --string --algo
"X-Kazaa-Username:" -j REJECT --reject-with tcp-reset
Bad argument `X-Kazaa-Username:'
Try `iptables -h' or 'iptables --help' for more information.
[root@ja Desktop]#

Thanks in advance



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: STRING agrument

[Eric Benton]

Allan Parreno wrote:

>Hello,
>
>Good Day.
>
>Anyone could help me out with this error using the string argument.
>
>[root@ja Desktop]# iptables -o eth0 -A FORWARD -p tcp -m string --string
>"X-Kazaa-Username:" -j REJECT --reject-with tcp-reset
>iptables v1.3.4: STRING match: You must specify `--algo'
>Try `iptables -h' or 'iptables --help' for more information.
>[root@ja Desktop]#
>
>However, if I specify the --algo if have this error
>
>[root@ja Desktop]# iptables -o eth0 -A FORWARD -p tcp -m string --string --algo
>"X-Kazaa-Username:" -j REJECT --reject-with tcp-reset
>Bad argument `X-Kazaa-Username:'
>Try `iptables -h' or 'iptables --help' for more information.
>[root@ja Desktop]#
>
>Thanks in advance
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>
>
>  
>
--algo bm

algo needs to a method but you left out the method
in this case the mthod is "bm"
Eric

Re: Controlling an iptables-match from userspace

[Manfred Stock]

On 5/26/06, Massimiliano Hofer <max@nucleus.it> wrote:
> I recently became maintainer of the condition patch.
> You can find a new version at
> "http://www.nucleus.it/pom-repo/condition.tar.gz". From now on it will be
> handled as an external repository.
>
> I'm working on some other changes that should make it more acceptable,
> althought I've been busy in the last couple of weeks.

Sounds good :) Btw. is there somewhere some more recent
Netfilter-Hacking-Howto-like documentation besides the kernel sources?
The Howto was not even for 2.6, and at least 2.6.16 had some larger
netfilter-related changes...


> Some considerations:
> - adding a new system call or ioctl is more intrusive than a proc interface;

Definitely. Adding a new setsockopt option as mentioned in the Howto
would be another possibility, but it at least feels a little weird if
you can create a socket, set a special option on it and as a result
you have influenced the behaviour of netfilter... Nevertheless it's
fairly easy to use on the kernel side. Probably netlink/nfnetlink
would be another (not file based) alternative.


> - a file interface doesn't require a special app.

It also fits nicely into the "everything is a file" paradigm, and it's
easy to use if you do write a special app to use that functionality.


> You could argue about putting it in /sys or in the brand new configfs.
> I'd like feedback about the best way to handle this.

/sys seems to be intended for devices and their drivers and
configuration, so I'd rather not use it for the configuration of a
netfilter match. But after a short look at
Documentation/filesystems/configfs/configfs.txt I would say that
configfs was intended for this kind of stuff. As for /proc, I don't
really know what to say, but my feelings are that it should rather not
be used for new non process related things - they have duplicated some
hardware related things in /sys which were in /proc already (e.g. the
information in /proc/scsi/scsi), and even moved things out of /proc
into /sys (iirc, this happened to some i2c/sensors-related stuff).
Similar things might happen with configfs. This is why I would prefer
a solution not involving /proc. But as I'm not really into kernel
programming, I might be completely wrong ;).


Best regards
Manfred

Re: Controlling an iptables-match from userspace

[Massimiliano Hofer]

On Sunday 28 May 2006 8:19 pm, Manfred Stock wrote:

> > I'm working on some other changes that should make it more acceptable,
> > althought I've been busy in the last couple of weeks.
>
> Sounds good :) Btw. is there somewhere some more recent
> Netfilter-Hacking-Howto-like documentation besides the kernel sources?
> The Howto was not even for 2.6, and at least 2.6.16 had some larger
> netfilter-related changes...

If there is, I would like it too. Most of the documentation I found dated from 
the 2.4.x era and cantained obsolete information. I cross examined other 
netfilter code and specific documentation for other parts of the kernel.
:(

> Definitely. Adding a new setsockopt option as mentioned in the Howto
> would be another possibility, but it at least feels a little weird if
> you can create a socket, set a special option on it and as a result
> you have influenced the behaviour of netfilter... Nevertheless it's
> fairly easy to use on the kernel side. Probably netlink/nfnetlink
> would be another (not file based) alternative.

Feasible, but I wouldn't like to implement it this way.
If you find a compelling reason not to go for the current multiple files 
approach I can create a single file that receives batches of commands.
The only reason this would be necessary would be in order to have transations 
of multiple simultaneous changes, but I think we would be solving the wrong 
problem.

> > - a file interface doesn't require a special app.
>
> It also fits nicely into the "everything is a file" paradigm, and it's
> easy to use if you do write a special app to use that functionality.

OK.

> netfilter match. But after a short look at
> Documentation/filesystems/configfs/configfs.txt I would say that
> configfs was intended for this kind of stuff. As for /proc, I don't
> really know what to say, but my feelings are that it should rather not
> be used for new non process related things - they have duplicated some

Many people think that /proc is in a sorry state. The current trend is not to 
accept patches that use /proc for anything new that is not process related.
I'm still using /proc in order to maintain backward compatibility, but I was 
already considering a transition to /config. Another thing holding me back 
was the lack of other modules already using it. There is no accepted naming 
convention and I wouldn't like to keep moving my files.

Anyway I'll soon release a new version of condition that uses configfs.

I'll put the directory name to popular vote:
- /config/xt_condition (this seem the preferred one by the configfs 
documentation);
- /config/netfilter/xt_condition (this would be more clear if other netfilter 
modules ever wanted to use configfs);
- ... (fill in the blanks);

-- 
Bye,
   Massimiliano Hofer

Re: Controlling an iptables-match from userspace

[Manfred Stock]

On 5/29/06, Massimiliano Hofer <max@nucleus.it> wrote:
> On Sunday 28 May 2006 8:19 pm, Manfred Stock wrote:
> > Definitely. Adding a new setsockopt option as mentioned in the Howto
> > would be another possibility, but it at least feels a little weird if
> > you can create a socket, set a special option on it and as a result
> > you have influenced the behaviour of netfilter... Nevertheless it's
> > fairly easy to use on the kernel side. Probably netlink/nfnetlink
> > would be another (not file based) alternative.
>
> Feasible, but I wouldn't like to implement it this way.
> If you find a compelling reason not to go for the current multiple files
> approach I can create a single file that receives batches of commands.
> The only reason this would be necessary would be in order to have transations
> of multiple simultaneous changes, but I think we would be solving the wrong
> problem.

Other than that, I currently don't see a reason to do it with one
file. To some degree such a transaction is already possible as one
could define the same condition in several rules - probably not that
flexible, but possible. Having several files is imho also easier to
use from user space, as one does not need to parse them for writing to
the right place.


> > netfilter match. But after a short look at
> > Documentation/filesystems/configfs/configfs.txt I would say that
> > configfs was intended for this kind of stuff. As for /proc, I don't
> > really know what to say, but my feelings are that it should rather not
> > be used for new non process related things - they have duplicated some
>
> Many people think that /proc is in a sorry state. The current trend is not to
> accept patches that use /proc for anything new that is not process related.
> I'm still using /proc in order to maintain backward compatibility, but I was
> already considering a transition to /config. Another thing holding me back
> was the lack of other modules already using it. There is no accepted naming
> convention and I wouldn't like to keep moving my files.
>
> Anyway I'll soon release a new version of condition that uses configfs.
>
> I'll put the directory name to popular vote:
> - /config/xt_condition (this seem the preferred one by the configfs
> documentation);
> - /config/netfilter/xt_condition (this would be more clear if other netfilter
> modules ever wanted to use configfs);
> - ... (fill in the blanks);

Maybe one could do it similar to /sys, which would imho result in
something like /config/net/netfilter/matches/xt_condition/.
Personally, I would prefer the first variant (/config/<modulename>).
The problem might be that if others really start using configfs,
/config could become quite cluttered. But as most of the modules
loaded on e.g. my system are device drivers, which imho will/should
rather use /sys for most of their configuration, this probably won't
happen.

Best regards
Manfred