iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set

deadeyes · 07-25-2009, 07:03 PM

I have been giving someone the following link to help him:
http://www.debian-administration.org/articles/187

However, this command gives the following error (for him, for me on my Gentoo system)
iptables: No chain/target/match by that name.

Strange thing for me is that my CentOS5.3 system does this correctly.

The functionality is enabled in the kernel. However it is build in, so not as a module.
Could this be causing the problem?

Thanks in advance

blackhole54 · 07-26-2009, 07:57 PM

It is possible that iptables needs to be compiled for the kernel being used. As I understand it, iptables should always be compiled for a given kernel, although frequently you can make changes to the kernel w/o recompiling iptables and things will still work. But I have encountered a situation where using a new kernel was giving some kind of error and (re)compiling iptables solved the problem.

deadeyes · 07-27-2009, 05:48 AM

Quote:

Originally Posted by blackhole54

It is possible that iptables needs to be compiled for the kernel being used. As I understand it, iptables should always be compiled for a given kernel, although frequently you can make changes to the kernel w/o recompiling iptables and things will still work. But I have encountered a situation where using a new kernel was giving some kind of error and (re)compiling iptables solved the problem.

TO be certainly I recompiled iptables. However this does not solve it.
So I think it will be a version compatibility issue.

fotoguy · 07-27-2009, 05:59 AM

Quote:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set

Are you sure this rule is correct, are there any other rules, it may be a good idea to post your whole script so we can check the order and what other rules maybe there that could be causing issues.

Quote:

iptables: No chain/target/match by that name.

This error messages usually happens when there is a rule pointing to a chain or target that doesn't exist, or the rules are not in the right order. Created chains or targets need to be at the top of the script and loaded before you can have a rule point to it.

deadeyes · 07-27-2009, 12:03 PM

yes this is totally correct and can be executed as a single rule.
On my CentOS: ok, on my gentoo, the error mentioned above

blackhole54 · 07-28-2009, 01:19 AM

Quote:

Originally Posted by deadeyes

The functionality is enabled in the kernel. However it is build in, so not as a module.
Could this be causing the problem?

I am making a wild guess here, but I wonder if perhaps when extended functionality is compiled directly into the kernel as you indicate, if maybe the corresponding -m <module> options should be omitted from the iptables command.

deadeyes · 07-28-2009, 02:09 AM

Quote:

Originally Posted by blackhole54

I am making a wild guess here, but I wonder if perhaps when extended functionality is compiled directly into the kernel as you indicate, if maybe the corresponding -m <module> options should be omitted from the iptables command.

Thanks for your effort. But this will not work as you have to associate the iptables options with a certain module. To be 100% certain I tried it

But I will try to compile them as modules. As I know that iptables normally automatically loads those modules (ipt_ with uppercase characters for targets and ipt_ small characters for matches)

zhjim · 07-28-2009, 02:23 AM

Guess it's my turn to guess

Maybe you don't have a networkcard with the name of eth0? Cause I can't believe you don't have a "chain" with the name INPUT. That would take care of the chain/target part of the error message. I can't figure one out for the match side.

I just polled the /proc dir on a debian installation.

/proc/net/ipt_recent/ holds the targets for the recent module. If this dir exists you for sure have the recent module installed.

Code:

 for i in $(cat /proc/net/ip_tables_names); do echo $i; iptables -L -v -t $i; done

shows all the chains you got.

deadeyes · 07-28-2009, 06:33 AM

Quote:

Originally Posted by zhjim

Guess it's my turn to guess

Maybe you don't have a networkcard with the name of eth0? Cause I can't believe you don't have a "chain" with the name INPUT. That would take care of the chain/target part of the error message. I can't figure one out for the match side.

I just polled the /proc dir on a debian installation.

/proc/net/ipt_recent/ holds the targets for the recent module. If this dir exists you for sure have the recent module installed.

Code:

 for i in $(cat /proc/net/ip_tables_names); do echo $i; iptables -L -v -t $i; done

shows all the chains you got.

There is certainly an eth0. The error does say chain/match/target...
so one of these is wrong. INPUT definitely not

Could you try to execute this one line on your firewall and tell me what version of iptables you have installed?

Code:

laptop ~ # cat /proc/net/ip_tables_matches 
mark
mark
conntrack
icmp
state
policy
conntrack
udplite
udp
tcp
tmrk-laptop ~ # cat /proc/net/ip_tables_targets 
SECMARK
NFLOG
MARK
MARK
MARK
CONNSECMARK
ULOG
REJECT
MASQUERADE
LOG
DNAT
SNAT
ERROR
TCPMSS
tmrk-laptop ~ # cat /proc/net/ip_tables_names   
nat
mangle
filter

I didn't know the existence of these

(I learned something today

)
As you can see the wanted parts ar available(or am I missing something?).

I don't have a /proc/net/ipt_recent/

blackhole54 · 07-28-2009, 03:59 PM

Quote:

Originally Posted by deadeyes

I don't have a /proc/net/ipt_recent/

I'm learning things from this thread too!

I just checked on an old Ubuntu system where ipt_recent is compiled as a module. /proc/net/ipt_recent is created by simply loading the module with modprobe. Unloading the module removes the directory. When I give a rule similar to the "set" rule listed earlier on this thread , then /proc/net/ip_recent gets populated with DEFAULT. DEFAULT goes away when I remove the rule. Since you don't have /proc/net/ipt_recent, I'm wondering if that is actually compiled into your kernel.

deadeyes · 07-28-2009, 05:44 PM

Quote:

Originally Posted by blackhole54

I'm learning things from this thread too!

I just checked on an old Ubuntu system where ipt_recent is compiled as a module. /proc/net/ipt_recent is created by simply loading the module with modprobe. Unloading the module removes the directory. When I give a rule similar to the "set" rule listed earlier on this thread , then /proc/net/ip_recent gets populated with DEFAULT. DEFAULT goes away when I remove the rule. Since you don't have /proc/net/ipt_recent, I'm wondering if that is actually compiled into your kernel.

Quickly checked with a grep on the .config.
There is not an option with "recent" in it. So this is maybe outdated and not in the current kernels anymore.

On my gentoo system I run 2.6.29 and on Centos it is 2.6.18, which is quite a difference

As I really wouldn't be able to sleep if I didn't did some research, these are my findings:
I did a grep on the kernel config of my CentOS system and it returned:

Code:

[root@localhost 2.6.18-128.1.10.el5xen-x86_64]# cat .config | grep -i recent
CONFIG_IP_NF_MATCH_RECENT=m

So I think that this functionality is not build in my kernel and also is not in the kernel config anymore (Deprecated?).
Are all options always in the config(also the disabled)? As for netfilter in the kernel config there is an option to be able to select all iptables modules.

blackhole54 · 07-28-2009, 07:57 PM

Quote:

Originally Posted by deadeyes

So I think that this functionality is not build in my kernel and also is not in the kernel config anymore (Deprecated?).

Well, here is the listing for xt_recent.c in the netfilter directory for version 2.6.29-1, so I guess it is still there (as of 2.6.29). I don't know what the significance of the name change from ipt_* to xt_* is but I think all of those names were changed.

Quote:

Are all options always in the config(also the disabled)? As for netfilter in the kernel config there is an option to be able to select all iptables modules.

I wouldn't be comfortable trying to answer that w/o looking through one in some detail.

fotoguy · 07-29-2009, 03:09 AM

Quote:

Quickly checked with a grep on the .config.
There is not an option with "recent" in it. So this is maybe outdated and not in the current kernels anymore.

Yeah its still part of the kernels, I have it in then 2.6.30.1

deadeyes · 07-29-2009, 03:57 AM

Found it:
NETFILTER_XT_MATCH_RECENT_PROC_COMPAT and NETFILTER_XT_MATCH_RECENT

will try to compile it this evening.

zhjim · 07-29-2009, 04:30 AM

Quote:

Originally Posted by deadeyes

I don't have a /proc/net/ipt_recent/

This leads to believe that the modules isn't here. ( Which is confirmed by your grepping the config). But what I wonder than is why iptables does not complain about not finding the module?
I recall that it normaly does/did. Hm We'll see when you compile the module