I have these rules in effect:
]# iptables --list --line-numbers Chain INPUT (policy ACCEPT) num target prot opt source destination 1 RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT) num target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references) num target prot opt source destination 1 DROP all -- 202.14.0.0/24 anywhere 2 DROP all -- 220.232.0.0/24 anywhere 3 ACCEPT all -- anywhere anywhere 4 ACCEPT icmp -- anywhere anywhere icmp any 5 ACCEPT esp -- anywhere anywhere 6 ACCEPT ah -- anywhere anywhere 7 ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns 8 ACCEPT udp -- anywhere anywhere udp dpt:ipp 9 ACCEPT tcp -- anywhere anywhere tcp dpt:ipp 10 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED 11 ACCEPT tcp -- 216.185.71.0/24 anywhere tcp dpts:ftp-data:ftp 12 ACCEPT tcp -- 216.185.71.0/25 anywhere tcp dpt:ssh state NEW 13 DROP tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: CHECK seconds: 10 name: THROTTLE side: source 14 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: SET name: THROTTLE side: source 15 ACCEPT tcp -- 209.47.176.0/25 anywhere tcp dpt:ssh state NEW 16 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NEW
...
Note particularly line 2.
Now, notwithstanding the above, I see this in my /var/log/secure file:
Jan 12 13:36:02 inet01 sshd[16056]: Received disconnect from 220.232.152.137: 11: Bye Bye Jan 12 13:36:13 inet01 sshd[16062]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=avalon.aty-group.com user=root Jan 12 13:36:15 inet01 sshd[16062]: Failed password for root from 220.232.152.137 port 38722 ssh2 Jan 12 13:36:15 inet01 sshd[16063]: Received disconnect from 220.232.152.137: 11: Bye Bye Jan 12 13:36:26 inet01 sshd[16070]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=avalon.aty-group.com user=root Jan 12 13:36:27 inet01 sshd[16070]: Failed password for root from 220.232.152.137 port 39287 ssh2 Jan 12 13:36:28 inet01 sshd[16071]: Received disconnect from 220.232.152.137: 11: Bye Bye Jan 12 13:36:38 inet01 sshd[16078]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=avalon.aty-group.com user=root Jan 12 13:36:40 inet01 sshd[16078]: Failed password for root from 220.232.152.137 port 39863 ssh2 Jan 12 13:36:40 inet01 sshd[16079]: Received disconnect from 220.232.152.137: 11: Bye Bye
What is wrong with my IPTABLES rules that this connection is permitted?
On Mon, January 12, 2009 1:37 pm, James B. Byrne wrote:
I have these rules in effect:
<snip>
1 DROP all -- 202.14.0.0/24 anywhere 2 DROP all -- 220.232.0.0/24 anywhere
<sniP>
Note particularly line 2.
Now, notwithstanding the above, I see this in my /var/log/secure file:
Jan 12 13:36:02 inet01 sshd[16056]: Received disconnect from 220.232.152.137: 11: Bye Bye Jan 12 13:36:13 inet01 sshd[16062]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=avalon.aty-group.com user=root Jan 12 13:36:15 inet01 sshd[16062]: Failed password for root from 220.232.152.137 port 38722 ssh2
<snip>
What is wrong with my IPTABLES rules that this connection is permitted?
Your netmask. You might want to consider changing it to /16.
Marko
James B. Byrne wrote:
Chain RH-Firewall-1-INPUT (2 references) num target prot opt source destination 1 DROP all -- 202.14.0.0/24 anywhere 2 DROP all -- 220.232.0.0/24 anywhere
Jan 12 13:36:02 inet01 sshd[16056]: Received disconnect from 220.232.152.137: 11: Bye Bye
What is wrong with my IPTABLES rules that this connection is permitted?
Seems that your subnet masks are not correct
Try /16 instead of /24 if you really want to block the last two octets.
nate
Thanks for the help. I completely missed that error.
This guy is persistent. After I cut off 220.232.152.137 we had intrusion attempts from 216.107.171.10. After I cut off that one then we had attempts from 69.80.235.135. Since blocking that network we have had no more attempts recorded.
When I first detected this attempt I thought that my iptable ssh throttle rules were somehow defective:
15 DROP tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: CHECK seconds: 15 name: THROTTLE side: source 16 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: SET name: THROTTLE side: source
however, more careful consideration of the log entries showed that the intruder was connecting every 23-24 seconds, which is outside the throttle threshold of 15 seconds. I am still concerned about any brute force attempt to discover the root password but, given no more than four connections per minute is possible, just how concerned should I be?
It is evident that this attacker had more than one netblock available. It is conceivable that, instead of serially attacking us, they could just have easily attempted multiple simultaneous connections from all of their available IP addresses. This would completely defeat the current throttle rules. Should I also throttle the total number of new connections from all IPs?
New to the list, so please forgive unintentional netiquette transgressions...
On Mon, 12 Jan 2009 14:24:54 -0600 "James B. Byrne" byrnejb@harte-lyne.ca wrote:
Thanks for the help. I completely missed that error.
<snip>
throttle threshold of 15 seconds. I am still concerned about any brute force attempt to discover the root password but, given no more than four connections per minute is possible, just how concerned should I be?
<snip> completely defeat the current throttle rules. Should I also throttle the total number of new connections from all IPs?
James,
Throttling all connection attempts to SSH is probably a good idea.
Discounting DoS or DDoS attacks, my solution to nefarious SSH attempts is threefold: 1) run sshd on a port other than 22 (I know, obscurity is not security...), 2) disable the root account (e.g., set the root password to '*' in /etc/shadow), and allow only sudo(1) access to privileged commands (this is the default on Ubuntu systems), and 3) disable password authentication in sshd_config and require all ssh users to log in using public key authentication.
Probably other things one can do, but I think this is a good first step.
Best,
-David Klann
David Klann wrote:
New to the list, so please forgive unintentional netiquette transgressions...
Welcome :-)
<snip>
Discounting DoS or DDoS attacks, my solution to nefarious SSH attempts is threefold: 1) run sshd on a port other than 22 (I know, obscurity is not security...), 2) disable the root account (e.g., set the root password to '*' in /etc/shadow), and allow only sudo(1) access to privileged commands (this is the default on Ubuntu systems), and 3) disable password authentication in sshd_config and require all ssh users to log in using public key authentication.
Probably other things one can do, but I think this is a good first step.
On Mon, 12 Jan 2009 17:47:08 -0600 Ned Slider ned@unixmail.co.uk wrote:
Welcome :-)
Thanks!
<snip>
Good guide -- thanks for pointing it out. I also like the idea of implementing denyhosts that Steve Huff pointed out. I use that on a public (virtual) server I rent from vpslink.com.
Thanks for the great input.
-David
On Jan 12, 2009, at 3:24 PM, James B. Byrne wrote:
It is evident that this attacker had more than one netblock available. It is conceivable that, instead of serially attacking us, they could just have easily attempted multiple simultaneous connections from all of their available IP addresses. This would completely defeat the current throttle rules. Should I also throttle the total number of new connections from all IPs?
you might be better served by adding an additional layer of defense e.g. denyhosts (which you can get from Dag). it's pretty good at deflecting brute-force attacks, especially if you enable synchronization mode in order to learn about hostile IPs before they hit you. initial setup should be a matter of minutes, i'd expect.
a useful trick to keep your hosts.deny file from growing to massive size is to use the hosts.evil include mechanism:
Can I use a non-standard hosts.deny file? (http://denyhosts.sourceforge.net/faq.html#2_6 )
-steve
-- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
-
David Klann -
James B. Byrne -
Marko A. Jennings -
nate -
Ned Slider -
Steve Huff