[SOLVED] iptables recent match . What am I doing wrong ?
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
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.
I want to stop brute-force attacks in ssh port.
I tried to google and found working examples but here in this question I am trying to learn how to write the rule by myself.
This is what I wrote. It does not work. It keeps logging all the packets which comes even after 5 seconds whereas it is supposed to log it only if the packets come within 5 seconds.
iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --name SSH --set
Whereas it is supposed to log _only_ if there are >=2 connections of ssh coming to this server within an interval of 5 seconds, it logs and gives me a lot of packets (atleast 11 packets per try to ssh).
I suspect that means that you are getting re-tries (and logging all of those). I don't see any sign of a drop or reject target (or policy, for that matter), and to quote http://www.linuxtopia.org/Linux_Fire...les/x4164.html
Quote:
The DROP target does just what it says, it drops packets dead... Note that this action might in certain cases have an unwanted effect, since it could leave dead sockets around on either host. A better solution in cases where this is likely would be to use the REJECT target, especially when you want to block port scanners from getting too much information, such as on filtered ports and so on.
This may be a case in which you want to reject, because, although it does give away the info that there is a 'sentient' box there and listening, it does give the other end an opportunity to give up early, when it knows it isn't going to get anywhere. Possibly.
Quote:
I want to stop brute-force attacks in ssh port.
And while that sounds like a worthwhile intention, the 'best' solution surely depends on whether you still need ssh to work. If you don't just block the port AND don't have anything to listen (belt 'n braces). Beyond that, whether to log anything is an interesting question. If no one is ever going to look at the logs, there may not be any point.
If you do there are a number of measures that you can take, of various degrees of 'paranoic-ness' and difficulty.
Move ssh to a non-standard port
Use port knocking
Use something like fail2ban
Can't say which, or which combination, you would like best, but the simplicity of the first does have an appeal.
I dont think there is any retry. I moved the port to http and tried wget from some other server too. That is also logging too many inputs. The main issue is that I cannot achieve a DROP if log does not work. Also, after some 2hrs why is the packet in the
/proc/net/ipt_recent/SSH entries not cleared ? I am just trying to understand this. I can circumvent this issue with other methods (like I use hosts.allow/deny). But I want to learn this method too.
I'm not precisely sure about what is wrong with your ruleset; but, if it helps any, here's the iptables invocation for working rules (which I use):
Code:
-A INPUT -m state --state NEW -p tcp --dport 22 -m recent --set --name BRUTE
-A INPUT -m recent --rcheck --name BRUTE --hitcount 6 --seconds 60 -j DROP
There is also some good feedback on said rules in this thread.
Finally, using the LOG target instead of DROP may be having some unintended consequences. (i.e. I wouldn't assume that you will see the same behavior when using DROP -- try it out if you have a testing environment.)
Finally, using the LOG target instead of DROP may be having some unintended consequences. (i.e. I wouldn't assume that you will see the same behavior when using DROP -- try it out if you have a testing environment.)
That was the answer. The LOG target does not work with this 'kind-of' filtering using iptables. The DROP target if used however works fine. So there was nothing wrong
with the rules, but using the right TARGET.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.