We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


Persisant attacks logged on a Linux server

sheepfarmer asked
Medium Priority
Last Modified: 2010-04-22
Our logs indicate persistant attempts to log into our box as root and admin from foreign IP addresses (every few seconds)
Apart from ensuring a strong password and setting up firewall access to ssh from specific fixed IP addresses only, its there anything else we can practically do to either stop the attacks and/or secure the box.

Do most admin ignore this sort of attack as background 'noise'.

Watch Question

If you have port 22 open and visible to the internet then it's going to get substantial traffic from ssh version checkers.  There's not much you can do about it other than setting up port knocking, which is setting up an obscure port like 8426 to listen for a "knock" and then it opens port 22 for some period of time to let the person log in.   I've never set it up I just live with the scans.

My Linux server receives around 40000 such ssh probes per day. In addition to being a potential security risk, it causes much unnecessary load on the system. Worst of all the probes often tend to come in closely-spaced batches, causing extra load due to the thrashing from a large number of processes being created all at once. My solution to the problem is to throttle the connection rate down to a level that easily exceeds what "normal" usage is but drastically reduces the number of accepted attack packets. I have the following in /etc/sysconfig/iptables (with real addresses, of course, not the example ones here):


:filt-icmp -
:per_src_limit -
-A INPUT -i eth0 -p icmp --icmp-type echo-request -j filt-icmp
-A INPUT -i eth0 -p tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j per_src_limit

-A filt-icmp -s -j ACCEPT
-A filt-icmp -s -j ACCEPT
-A filt-icmp -j DROP

-A per_src_limit -s -j ACCEPT
-A per_src_limit -s -j ACCEPT
-A per_src_limit -m hashlimit --hashlimit 2/min --hashlimit-burst 10 --hashlimit-mode srcip,dstport --hashlimit-name per_src --hashlimit-htable-gcinterval 60000 --hashlimit-htable-expire 300000 -j ACCEPT
-A per_src_limit -j REJECT --reject-with icmp-admin-prohibited


This set of filters does two things. First, it drops ICMP echo-request (ping) packets from all but a couple ranges of trusted source IPs. I've found many types of attacks will ignore you if you don't reply to a ping. Of course there's many other ways to discover whether something exists at an IP, but this simple filter does help a lot.

The second filter limits incoming SSH connection initiations to a maximum of 2 per minute, PER SOURCE ADDRESS, with a bucket of 10, which allows a small burst to exceed the 2/min rate. These rates are relatively low because they are per source, and are above what a normal interactive user would ever do. If you have automatic processes that initiate multiple successive ssh sessions (such as scp's in a script), then you may want to increase the rate. Better yet, if your high-rate initiators are from fixed addresses, you can simply exempt some trusted addresses from the rate limiting as I have done.

Note that I send REJECT packets to offending sources. I have found that this works better to quell attacks than simply starting to drop packets. You might have different results and may want to try both.

Here's a statistics dump using "iptables -vL" after my server has been up for 108 days:


Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 35M packets, 8152M bytes)
 pkts bytes target     prot opt in     out     source               destination
81921 7732K filt-icmp  icmp --  eth0   any     anywhere             anywhere            icmp echo-request
4587K  266M per_src_limit  tcp  --  eth0   any     anywhere             anywhere            tcp dpt:ssh flags:SYN,RST,ACK/SYN

Chain OUTPUT (policy ACCEPT 36M packets, 18G bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain filt-icmp (1 references)
 pkts bytes target     prot opt in     out     source               destination
   42  3552 ACCEPT     all  --  any    any  anywhere
    0     0 ACCEPT     all  --  any    any  anywhere
81879 7729K DROP       all  --  any    any     anywhere             anywhere

Chain per_src_limit (1 references)
 pkts bytes target     prot opt in     out     source               destination
  163  9416 ACCEPT     all  --  any    any  anywhere
    0     0 ACCEPT     all  --  any    any  anywhere
38458 2234K ACCEPT     all  --  any    any     anywhere             anywhere            limit: avg 2/min burst 10 mode srcip-dstport htable-gcinterval 60000 htable-expire 300000
4548K  264M REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-admin-prohibited


This technique lessens load from SSH probes, and lowers the statistical risk due to fewer probes, but you still need to have a secure box with good passwords and software that is kept up-to-date.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
Top Expert 2005

I ,personally, setted up the ssh on different port from default 22. Works...

Knocking is even better alternative, but running different port is so simple...
I have been in enough situations where the only SSH client available could not easily be changed to use a port other than 22 that it's been worth the extra trouble of having the server on 22.

Knocking is also a hassle unless your client can do it automatically (you'd have to do the knock manually with a Web browser of something).

So in my experience the rate-limiting solution has been the best tradeoff for the sake of convenience.


First of all, disable root login directly from ssh. If you need root access, login as normal user and then su to it later. This can be done by setting "PermitRootLogin" to "no" in /etc/ssh/sshd_config.

Secondly, relocate the listening port of ssh, if possible. This can be done by adding the "-p portnum" parameter to sshd. If you use xinetd, set it under the "server_args" setting of sshd config.

Thirdly, limit the access to ssh port, if accesses are always come from fixed range of known IP addresses.

Fourthly, use IDS/IPS to slow down or block the traffic of port scanning or brute force guessing. Take a look at Snort and related software.

Of course, a secured and hard to guess password is always a must.


I would strongly recommend you use pam_abl, pam_abl provides:

Auto blacklisting of hosts and users responsible for repeated failed authentication attempts. Generally configured so that blacklisted users still see normal login prompts but are guaranteed to fail to authenticate.

Brute force password discovery attacks involve repeated attempts to authenticate against a service using a dictionary of common passwords. While it is desirable to enforce strong passwords for users this is not always possible and in cases where a weak password has been used brute force attacks can be effective.

You can check this out more at: http://www.hexten.net/pam_abl/
Top Expert 2005

pam_abl is cute, but note, that such attacks are usually distributed(from various IPs) and from dynamic IPs. The list will grow huge. There are simpler sollutions I guess.

pam_abl will add that extra security which is required. Also implementation of iptales and no allowing root
remote login is secure.
I'd vote for iptables --limit option 'cause it is independent of the clients allowed to connect and it manages any IP without having a black- or whitelist up-to-date.
The only drawback is that clever stealth scans are still possible, but who cares if your system is secured:)


Yes, I'm inclinded to agree with the iptables - at least the connection throttle will reduce the number of dictionary password attempts in a given period.

Thanks for all the responses.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.