LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 03-15-2014, 11:06 AM   #1
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,473

Rep: Reputation: 122Reputation: 122
Unhappy iptables not blocking ssh attacks


I have a pretty big problem. A couple of my Linux servers are experiencing ssh hack attempts:

Mar 15 08:41:32 bu6500 sshd[17942]: Invalid user darryl from 211.70.144.13
Mar 15 08:41:32 bu6500 sshd[17942]: Failed password for invalid user darryl from 211.70.144.13 port 20844 ssh2
Mar 15 08:41:35 bu6500 sshd[17944]: Invalid user brian from 211.70.144.13
Mar 15 08:41:35 bu6500 sshd[17944]: Failed password for invalid user brian from 211.70.144.13 port 21093 ssh2

The problem is, I've added this to iptables, but it's not blocking:

$ iptables -L -v | grep 211.70
0 0 DROP all -- any any 211.70.0.0/16 anywhere

I've had 3 such attack in the past 12 hours with up to 12000 attempts each. All of these are in iptables. Why isn't it blocking these attacks?

iptables v1.4.10
 
Old 03-15-2014, 11:13 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,393
Blog Entries: 55

Rep: Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565
Quote:
Originally Posted by mfoley View Post
Why isn't it blocking these attacks?
First of all please ensure you're adhering to SSH best practices (no root allowed, protocol version 2 only, only pubkey auth).
Secondly please post output of 'iptables-save' instead since your output doesn't show rule ordering.
Third you may find management easier using fail2ban or equivalent.
 
Old 03-16-2014, 01:54 AM   #3
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,473

Original Poster
Rep: Reputation: 122Reputation: 122
Yes, I do prohibit root login, I do not require public key since I need to be able to log in from anywhere.

Requested output below: I have lots of DROP restrictions, so I've deleted most. I'd rather stick with iptables if possible rather than go to another program like fail2ban. But if iptables is broken, I'll try an alternative.

To recap, the two questions I have are: 1) why is the IP 211.70.144.13 not getting blocked (see 2nd DROP line, below), and 2) Why is it letting someone try on ports 20844 and 21093 since I do not believe I have those enabled?

Thanks,

# Generated by iptables-save v1.4.10 on Sun Mar 16 01:46:18 2014
*raw
:PREROUTING ACCEPT [31918855:84594468322]
:OUTPUT ACCEPT [20730898:1682626222]
COMMIT
# Completed on Sun Mar 16 01:46:18 2014
# Generated by iptables-save v1.4.10 on Sun Mar 16 01:46:18 2014
*mangle
:PREROUTING ACCEPT [31918855:84594468322]
:INPUT ACCEPT [31906724:84593754097]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [20730898:1682626222]
:POSTROUTING ACCEPT [20731524:1682735350]
COMMIT
# Completed on Sun Mar 16 01:46:18 2014
# Generated by iptables-save v1.4.10 on Sun Mar 16 01:46:18 2014
*nat
:PREROUTING ACCEPT [37241:4531455]
:INPUT ACCEPT [7954:1046631]
:OUTPUT ACCEPT [23461:1552141]
:POSTROUTING ACCEPT [23461:1552141]
COMMIT
# Completed on Sun Mar 16 01:46:18 2014
# Generated by iptables-save v1.4.10 on Sun Mar 16 01:46:18 2014
*filter
:INPUT DROP [1252:179201]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -s 64.129.23.99/32 -p tcp -m tcp --dport 37 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth1 -m state --state NEW -j ACCEPT
-A INPUT -i eth0 -p tcp -m multiport --dports 22,25,53,80,443 -m state --state NEW -j ACCEPT
-A INPUT -i eth0 -p udp -m multiport --dports 53 -m state --state NEW -j ACCEPT
-A INPUT -s 1.179.0.0/16 -j DROP
[some entries deleted]
-A INPUT -s 211.70.0.0/16 -j DROP
-A INPUT -s 191.234.0.0/16 -j DROP
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -m state --state NEW -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth1 -m state --state NEW -j ACCEPT
COMMIT
# Completed on Sun Mar 16 01:46:18 2014

Last edited by mfoley; 03-16-2014 at 01:55 AM.
 
Old 03-16-2014, 02:58 AM   #4
descendant_command
Senior Member
 
Registered: Mar 2012
Posts: 1,638

Rep: Reputation: 434Reputation: 434Reputation: 434Reputation: 434Reputation: 434
Quote:
Code:
-A INPUT -i eth0 -p tcp -m multiport --dports 22,25,53,80,443 -m state --state NEW -j ACCEPT
You are ACCEPTing new traffic on port 22 before the packets reach your DROPs
 
Old 03-16-2014, 08:02 PM   #5
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,473

Original Poster
Rep: Reputation: 122Reputation: 122
So, how do I fix that? Physically move the DROPs above the ACCEPT?
 
Old 03-16-2014, 10:20 PM   #6
descendant_command
Senior Member
 
Registered: Mar 2012
Posts: 1,638

Rep: Reputation: 434Reputation: 434Reputation: 434Reputation: 434Reputation: 434
Yes.
 
Old 03-17-2014, 10:15 AM   #7
Rawcous
Member
 
Registered: Jan 2014
Location: Farnborough, Hampshire - UK
Distribution: 2 * CentOS 6.9 Self-Hosted Domain Servers (Mail & Web Server / FTP Server)
Posts: 98

Rep: Reputation: Disabled
Hello,

Forgive me if I have missed no.1 below in someone else's reply to this thread but:

1. I have found the single biggest way to reduce attacks is to move SSH to another port - in fact since doing this I have not had a single attack...

2. Without giving too much information away here - I have a single ssh account for connecting remotely to my domain server(s). Upon logging in using that particular account, I have a script running that will kill the session if a particular function is not activated with x no .of seconds. Thus if someone did someone get hold of the ssh account including the auth. keys upon connection, within x seconds the session will automatically be terminated without them even realising why - nice and simple.....

Regards,

Rawcous
 
Old 03-17-2014, 10:35 AM   #8
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,473

Original Poster
Rep: Reputation: 122Reputation: 122
Unfortunately, I cannot move the ssh port on this host (though I do on others), but I do have it restricted to few user ids. That's a great idea about the booby trap script!
 
Old 03-17-2014, 05:33 PM   #9
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,393
Blog Entries: 55

Rep: Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565
Quote:
Originally Posted by Rawcous View Post
(..) I have found the single biggest way to reduce attacks is to move SSH to another port - in fact since doing this I have not had a single attack.. (..) if someone did someone get hold of the ssh account including the auth. keys upon connection, within x seconds the session will automatically be terminated (..)
Maybe I'm missing something crucial here but A) if somebody got hold of your private key and pass phrase then you've got problems of a whole different order (and no sniper script is going to mitigate that), B) moving ports is simple obfuscation: it doesn't strengthen security posture one bit (get the right port and they're in business again) and C) no matter how you try and mitigate things the idea of allowing a perp to gain a foothold is simply wrong in the first place.

Adhering to SSH best practices is a "must have" and whatever you add to that is a "nice to have".
 
Old 03-17-2014, 05:54 PM   #10
Rawcous
Member
 
Registered: Jan 2014
Location: Farnborough, Hampshire - UK
Distribution: 2 * CentOS 6.9 Self-Hosted Domain Servers (Mail & Web Server / FTP Server)
Posts: 98

Rep: Reputation: Disabled
Quote:
Originally Posted by unSpawn View Post
Maybe I'm missing something crucial here but A) if somebody got hold of your private key and pass phrase then you've got problems of a whole different order (and no sniper script is going to mitigate that), B) moving ports is simple obfuscation: it doesn't strengthen security posture one bit (get the right port and they're in business again) and C) no matter how you try and mitigate things the idea of allowing a perp to gain a foothold is simply wrong in the first place.

Adhering to SSH best practices is a "must have" and whatever you add to that is a "nice to have".

Yes unSpawn - I agree, I have adhered to standard best practices - the only reason I didn't mention them was because others already had. The point I was trying to make was that by adopting the various recommended practices no matter how small adds an extra layer- changing the port, key authentication, background script execution upon logging in with a key, implementation of fail2ban, etc. I was simply stating that in my case changing the port has eradicated all attacks, i did not indicate that in itself it is a one step fits all solution.

Regards,

Rawcous!
 
Old 03-17-2014, 06:43 PM   #11
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,393
Blog Entries: 55

Rep: Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565Reputation: 3565
One of the problems with web log and forum posts in general (or rather: a readers perception of what are "official" guidelines and what not) is that people will take whatever advice given by whomever and regard it as Truth w/o questioning it, so thanks for that:
Quote:
Originally Posted by Rawcous View Post
I was simply stating that in my case changing the port has eradicated all attacks, i did not indicate that in itself it is a one step fits all solution.
 
Old 03-19-2014, 12:18 PM   #12
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,473

Original Poster
Rep: Reputation: 122Reputation: 122
I've moved the DROPs ahead of the accepts, and that appears to have solved the problem. Thanks.
 
Old 04-20-2014, 01:58 PM   #13
mfoley
Senior Member
 
Registered: Oct 2008
Location: Columbus, Ohio USA
Distribution: Slackware
Posts: 1,473

Original Poster
Rep: Reputation: 122Reputation: 122
This issue is still giving me problems. 1st question, referring to the script below, I believe I have set port 22 on eth0 to limit attempts to 10 per minute. This is not working. I have attempts that try hundreds of times in a minute. Why?

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -m state --state NEW -j ACCEPT

iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 \
--hitcount 10 --rsource -j LOG --log-prefix "SSH Break-in attempt" --log-level 6

iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 \
--hitcount 10 --rsource -j DROP

iptables -A INPUT -p tcp --syn -m limit --limit 1/s -i eth0 --dport 22 -j ACCEPT
iptables -A INPUT -p TCP -i eth0 -m multiport --dports 22,25,53,80,443 -m state --state NEW -j ACCEPT
iptables -A INPUT -p UDP -i eth0 -m multiport --dports 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I INPUT -p tcp -m tcp -s 64.129.23.99 --dport 37 -j ACCEPT
iptables -A OUTPUT -o eth0 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -o eth1 -m state --state NEW -j ACCEPT
 
  


Reply

Tags
iptables


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] iptables not blocking ssh attempts padeen Linux - Networking 1 04-18-2013 12:46 AM
iptables ssh auto blocking, centos 5.3 (upgrd to 5.5 krnl from updates) tedeansiii Linux - Security 3 06-07-2011 12:39 PM
Blocking outgoing ssh using iptables PMP Linux - Newbie 13 08-22-2009 09:49 AM
iptables not blocking brut force attacks (something simple?) MikeOfAustin Linux - Security 6 11-20-2008 12:51 AM
SSH attacks, a new approach david1941 Linux - Security 10 09-13-2008 02:16 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 07:06 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration