?
Solved

Persisant attacks logged on a Linux server

Posted on 2006-04-06
10
Medium Priority
?
454 Views
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'.

Thanks
SF
0
Comment
Question by:sheepfarmer
  • 2
  • 2
  • 2
  • +4
10 Comments
 
LVL 3

Expert Comment

by:sheetbird
ID: 16395835
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.

0
 
LVL 3

Accepted Solution

by:
TimEliseo earned 2000 total points
ID: 16397617
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):

---

*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
: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 192.168.3.64/255.255.255.248 -j ACCEPT
-A filt-icmp -s 192.168.5.0/255.255.255.0 -j ACCEPT
-A filt-icmp -j DROP

-A per_src_limit -s 192.168.3.64/255.255.255.248 -j ACCEPT
-A per_src_limit -s 192.168.5.0/255.255.255.0 -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
COMMIT

---

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     192.168.3.64/29  anywhere
    0     0 ACCEPT     all  --  any    any     192.168.5.0/24  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     192.168.3.64/29  anywhere
    0     0 ACCEPT     all  --  any    any     192.168.5.0/24  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.
0
 
LVL 43

Expert Comment

by:ravenpl
ID: 16398337
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...
0
Get quick recovery of individual SharePoint items

Free tool – Veeam Explorer for Microsoft SharePoint, enables fast, easy restores of SharePoint sites, documents, libraries and lists — all with no agents to manage and no additional licenses to buy.

 
LVL 3

Expert Comment

by:TimEliseo
ID: 16398421
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.
0
 
LVL 14

Expert Comment

by:ppfoong
ID: 16398526

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.







0
 
LVL 16

Expert Comment

by:xDamox
ID: 16398664
Hi,

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/
0
 
LVL 43

Expert Comment

by:ravenpl
ID: 16398698
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.
0
 
LVL 16

Expert Comment

by:xDamox
ID: 16398772
pam_abl will add that extra security which is required. Also implementation of iptales and no allowing root
remote login is secure.
0
 
LVL 51

Expert Comment

by:ahoffmann
ID: 16399743
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:)
0
 

Author Comment

by:sheepfarmer
ID: 16402521
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.
SF
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

​Being a Managed Services Provider (MSP) has presented you  with challenges in the past— and by meeting those challenges you’ve reaped the rewards of success.  In 2014, challenges and rewards remain; but as the Internet and business environment evol…
BIND is the most widely used Name Server. A Name Server is the one that translates a site name to it's IP address. There is a new bug in BIND (https://kb.isc.org/article/AA-01272), affecting all versions of BIND 9 from BIND 9.1.0 (inclusive) thro…
We’ve all felt that sense of false security before—locking down external access to a database or component and feeling like we’ve done all we need to do to secure company data. But that feeling is fleeting. Attacks these days can happen in many w…
Despite its rising prevalence in the business world, "the cloud" is still misunderstood. Some companies still believe common misconceptions about lack of security in cloud solutions and many misuses of cloud storage options still occur every day. …

840 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question