Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
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 would like to block brute force attacks. I've added the following iptables rules and yet, the attacks are not blocked. I've tried similar rules with the same results. The attacks persist for about 8 or so minutes. Why is this not working?
Walt
iptables -N SSH_KILLER
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_KILLER
iptables -A SSH_KILLER -m recent --set --name SSH
iptables -A SSH_KILLER -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
I opened 6 putty windows and then attempted to login with 6 bogus id's. When the 6th one was entered, I received a connection refused. So, I guess that tells me it is working. But then, why do I see this in /var/log/messages?
BTW, I'm running openSUSE 10.3 on this machine.
Walt
Feb 2 21:19:06 spock sshd[4803]: Did not receive identification string from 210.82.89.139
Feb 2 21:22:49 spock sshd[4807]: User root from 210.82.89.139 not allowed because listed in DenyUsers
Feb 2 21:22:51 spock sshd[4813]: Invalid user usuario from 210.82.89.139
Feb 2 21:22:53 spock sshd[4818]: Invalid user irina from 210.82.89.139
Feb 2 21:22:56 spock sshd[4823]: Invalid user karin from 210.82.89.139
Feb 2 21:22:58 spock sshd[4828]: Invalid user cvs from 210.82.89.139
Feb 2 21:23:01 spock sshd[4833]: Invalid user cvsroot from 210.82.89.139
Feb 2 21:23:03 spock sshd[4838]: Invalid user paper from 210.82.89.139
Feb 2 21:23:06 spock sshd[4843]: Invalid user a from 210.82.89.139
Feb 2 21:23:08 spock sshd[4848]: Invalid user carter from 210.82.89.139
Feb 2 21:23:11 spock sshd[4853]: Invalid user paul from 210.82.89.139
Feb 2 21:23:13 spock sshd[4858]: Invalid user julie from 210.82.89.139
Feb 2 21:23:16 spock sshd[4863]: Invalid user tomato from 210.82.89.139
Feb 2 21:23:18 spock sshd[4868]: Invalid user dev from 210.82.89.139
Feb 2 21:23:21 spock sshd[4873]: Invalid user eric from 210.82.89.139
Feb 2 21:23:23 spock sshd[4878]: Invalid user morgan from 210.82.89.139
Feb 2 21:23:25 spock sshd[4883]: Invalid user jackson from 210.82.89.139
Feb 2 21:31:13 spock sshd[5810]: Invalid user ftpuser from 210.82.89.139
Feb 2 21:31:16 spock sshd[5815]: Invalid user master from 210.82.89.139
Feb 2 21:31:18 spock sshd[5820]: Invalid user oleg from 210.82.89.139
Feb 2 21:31:20 spock sshd[5825]: Invalid user eugene from 210.82.89.139
Feb 2 21:31:23 spock sshd[5830]: Invalid user max from 210.82.89.139
Feb 2 21:31:25 spock sshd[5835]: Invalid user java from 210.82.89.139
Feb 2 21:31:28 spock sshd[5840]: Invalid user rick from 210.82.89.139
Feb 2 21:31:30 spock sshd[5845]: Invalid user ruth from 210.82.89.139
Feb 2 21:31:33 spock sshd[5850]: Invalid user resin from 210.82.89.139
Feb 2 21:31:35 spock sshd[5855]: Invalid user delgado from 210.82.89.139
Feb 2 21:31:38 spock sshd[5860]: Invalid user sara from 210.82.89.139
Feb 2 21:31:40 spock sshd[5865]: Invalid user amanda from 210.82.89.139
Feb 2 21:31:42 spock sshd[5870]: Invalid user stan from 210.82.89.139
Feb 2 21:31:45 spock sshd[5875]: Invalid user denis from 210.82.89.139
Feb 2 21:31:47 spock sshd[5880]: Invalid user dennis from 210.82.89.139
Feb 2 21:31:50 spock sshd[5885]: Invalid user vivian from 210.82.89.139
Feb 2 21:31:52 spock sshd[5890]: Invalid user viviane from 210.82.89.139
Feb 2 21:31:55 spock sshd[5895]: Invalid user jacob from 210.82.89.139
Last edited by LinuxIsGR8; 02-03-2009 at 09:39 AM.
I would like to block brute force attacks. I've added the following iptables rules and yet, the attacks are not blocked. I've tried similar rules with the same results. The attacks persist for about 8 or so minutes. Why is this not working?
Walt
iptables -N SSH_KILLER
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_KILLER
iptables -A SSH_KILLER -m recent --set --name SSH
iptables -A SSH_KILLER -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
I use a similar rule... and I know it does work.
Code:
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 360 --hitcount 3 --name SSHATTEMPTS --rsource -j DROP
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSHATTEMPTS --rsource
iptables -A INPUT -s 210.82.89.139 -j LOG #Optional if you want to log
iptables -A INPUT -s 210.82.89.139 -j DROP
Just so to make sure at least temporarily unless they then start using another IP, that they will get no-where with their brute attack. Then is there a specific reason your creating a new chain, it will work just as well:-
Code:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
Shouldn't be any problems with that, althought can't say i see an issue with what you've got either.
Last edited by helptonewbie; 02-03-2009 at 01:32 PM.
Ok,
I put the following rules in:
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 360 --hitcount 3 --name SSHATTEMPTS --rsource -j DROP
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSHATTEMPTS --rsource
I thought that since it specifically pointed to eth0 that maybe that would work. Not so, I had to shut down the ssh daemon in the middle of an attack.
Will try the one form the last posting.
Walt
Feb 4 13:12:41 spock sshd[21647]: Invalid user admin65 from 221.139.3.36
Feb 4 13:12:43 spock sshd[21652]: Invalid user admin from 221.139.3.36
Feb 4 13:12:44 spock sshd[21657]: Invalid user admin from 221.139.3.36
Feb 4 13:12:46 spock sshd[21662]: Invalid user admin from 221.139.3.36
Feb 4 13:12:48 spock sshd[21667]: Invalid user admin from 221.139.3.36
Feb 4 13:12:49 spock sshd[21672]: Invalid user admin from 221.139.3.36
Feb 4 13:12:51 spock sshd[21677]: Invalid user admin from 221.139.3.36
Feb 4 13:12:52 spock sshd[21682]: Invalid user admin from 221.139.3.36
Feb 4 13:12:54 spock sshd[21687]: Invalid user admin from 221.139.3.36
Feb 4 13:12:55 spock sshd[21692]: Invalid user admin from 221.139.3.36
Feb 4 13:12:57 spock sshd[21697]: Invalid user admin from 221.139.3.36
Feb 4 13:12:59 spock sshd[21702]: Invalid user admin from 221.139.3.36
Feb 4 13:13:00 spock sshd[21707]: Invalid user admin from 221.139.3.36
Feb 4 13:13:02 spock sshd[21712]: Invalid user admin from 221.139.3.36
Feb 4 13:13:03 spock sshd[21717]: Invalid user admin from 221.139.3.36
Feb 4 13:13:05 spock sshd[21722]: Invalid user admin from 221.139.3.36
Feb 4 13:13:06 spock sshd[21727]: Invalid user admin from 221.139.3.36
Feb 4 13:13:08 spock sshd[21733]: Invalid user admin from 221.139.3.36
Feb 4 13:13:10 spock sshd[21739]: Invalid user admin from 221.139.3.36
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Rep:
I'm curious how '--update --seconds N' works. Does it wake up every N seconds and check how many matches there have been since the last interval? If so, lowering the value of N should see improvement in how quickly an IP gets blocked.
Feb 4 13:12:41 spock sshd[21647]: Invalid user admin65 from 221.139.3.36
Feb 4 13:12:43 spock sshd[21652]: Invalid user admin from 221.139.3.36
Feb 4 13:12:44 spock sshd[21657]: Invalid user admin from 221.139.3.36
Feb 4 13:12:46 spock sshd[21662]: Invalid user admin from 221.139.3.36
Feb 4 13:12:48 spock sshd[21667]: Invalid user admin from 221.139.3.36
Feb 4 13:12:49 spock sshd[21672]: Invalid user admin from 221.139.3.36
Feb 4 13:12:51 spock sshd[21677]: Invalid user admin from 221.139.3.36
Feb 4 13:12:52 spock sshd[21682]: Invalid user admin from 221.139.3.36
Feb 4 13:12:54 spock sshd[21687]: Invalid user admin from 221.139.3.36
Feb 4 13:12:55 spock sshd[21692]: Invalid user admin from 221.139.3.36
Feb 4 13:12:57 spock sshd[21697]: Invalid user admin from 221.139.3.36
Feb 4 13:12:59 spock sshd[21702]: Invalid user admin from 221.139.3.36
Feb 4 13:13:00 spock sshd[21707]: Invalid user admin from 221.139.3.36
Feb 4 13:13:02 spock sshd[21712]: Invalid user admin from 221.139.3.36
Feb 4 13:13:03 spock sshd[21717]: Invalid user admin from 221.139.3.36
Feb 4 13:13:05 spock sshd[21722]: Invalid user admin from 221.139.3.36
Feb 4 13:13:06 spock sshd[21727]: Invalid user admin from 221.139.3.36
Feb 4 13:13:08 spock sshd[21733]: Invalid user admin from 221.139.3.36
Feb 4 13:13:10 spock sshd[21739]: Invalid user admin from 221.139.3.36
One thing to remember... it's not number of attempts. It's number of connects. If your sshd lets them take 20 attempts per connect... it'll take 60 attempts before it gets rid of them.
I think the sshd_config options you want to look at is strictmode (should be yes), maxauthtries (your call, mines 2), and logingracetime (I use 30s).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.