LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (http://www.linuxquestions.org/questions/linux-server-73/)
-   -   iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set (http://www.linuxquestions.org/questions/linux-server-73/iptables-i-input-p-tcp-dport-22-i-eth0-m-state-state-new-m-recent-set-742801/)

deadeyes 07-25-2009 07:03 PM

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
 
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 (Post 3621146)
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 (Post 3620289)
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 (Post 3622553)
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 (Post 3622616)
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 :p)
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 (Post 3622814)
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. :scratch:

deadeyes 07-28-2009 05:44 PM

Quote:

Originally Posted by blackhole54 (Post 3623454)
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. :scratch:

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

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 (Post 3623546)
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


All times are GMT -5. The time now is 09:04 AM.