iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
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.
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)
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
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 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.
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:
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.
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.
Last edited by blackhole54; 07-29-2009 at 04:20 AM.
Reason: removed extra tag
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
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.