Should I suspicious of this behaviour?

Question

My website users have perceived that sometimes the server performance is not as it used to be (basically they say that a page that normally loads immediately, could take more than 3 seconds now). This happens for 15-30 minutes and then the server becomes responsive again.

Today a user warned me just when this was happening. I had time to run a couple of commands as root and this is what I found:

root@[redacted]:~# netstat -ntu | grep ESTAB | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr
    22 185.25.18.43
     4 79.153.178.230
     3 83.45.74.248
     2 83.59.9.137
     1 77.89.254.178
     1 77.89.252.156
     1 77.89.252.149
     1 209.85.160.41
root@[redacted]:~# netstat -n -p | grep SYN_REC | awk '{print $5}' | awk -F: '{print $1}'
root@[redacted]@~# netstat -plan|grep :80|awk {'print $5'}|cut -d: -f 1|sort|uniq -c|sort -nk 1
     1 142.166.98.36
     1 180.76.5.194
     1 79.151.200.177
     1 83.59.9.137
     1 91.121.82.227
    22 185.25.48.43
    29
root@[redacted]:~# uptime
    10:53:26 up 133 days, 11 min,   1 user,   load average: 28.82, 29.89, 20.97

After 5 minutes the uptime is: 3.07 13.60 19.44 and now all values are below 4 and there are no connections from 185.25.48.43.

The whois for the suspicious IP 185.25.48.43 is:

 [Querying whois.arin.net] [Redirected to whois.ripe.net:43] [Querying
 whois.ripe.net] [whois.ripe.net] % This is the RIPE Database query
 service. % The objects are in RPSL format. % % The RIPE Database is
 subject to Terms and Conditions. % See
 http://www.ripe.net/db/support/db-terms-conditions.pdf

 % Note: this output has been filtered. %       To receive output for a
 database update, use the "-B" flag.

 % Information related to '185.25.48.0 - 185.25.48.63'

 % Abuse contact for '185.25.48.0 - 185.25.48.63' is
 'abuse@bacloud.com'

 inetnum:        185.25.48.0 - 185.25.48.63 netname:        IST-NET
 descr:          Informacines sistemos ir technologijos, UAB country:  
 LT admin-c:        BAC2006-RIPE tech-c:         BAC2006-RIPE status:  
 ASSIGNED PA mnt-by:         BACLOUD-MNT source:         RIPE #
 Filtered

 role:           BACLOUD NOC address:        Informacines sistemos ir
 technologijos, UAB address:        Pramones 15 address:       
 LT-78137 Siauliai address:        Lithuania phone:          +370 41
 210000 phone:          +370 52 044044 fax-no:         +370 65 002611
 admin-c:        NB5547-RIPE tech-c:         TM9791-RIPE nic-hdl:      
 BAC2006-RIPE abuse-mailbox:  abuse@bacloud.com mnt-by:        
 BACLOUD-MNT source:         RIPE # Filtered

 % Information related to '185.25.48.0/22AS61272'

 route:          185.25.48.0/22 descr:          BACLOUD-COM origin:    
 AS61272 mnt-by:         AS61272-MNT source:         RIPE # Filtered

 % This query was served by the RIPE Database Query Service version
 1.70.1 (WHOIS3)

It's a cloud service from Lithuania, which makes it more suspicious as all my users speak Spanish (it's a Spanish website).

The question is: is 185.25.48.43 attacking my server? And what can I do about it?

EDIT: After reviewing my access.log, this IP was trying to access to all my sites with these kind of requests:

site1.es:80 185.25.48.43 - - [27/Jan/2014:10:38:11 +0100] "GET /?author=2 HTTP/1.1" 200 16569 "http://site1.es/?author=2" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"
inusion.es:80 185.25.48.43 - - [27/Jan/2014:10:38:03 +0100] "GET /wp-login.php HTTP/1.1" 200 2551 "http://inusion.es/wp-login.php" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"
site1.es:80 185.25.48.43 - - [27/Jan/2014:10:38:12 +0100] "GET /?author=3 HTTP/1.1" 200 16569 "http://site1.es/?author=3" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"
site2.com:80 185.25.48.43 - - [27/Jan/2014:10:38:03 +0100] "GET /wp-login.php HTTP/1.1" 200 2811 "http://site2.com/wp-login.php" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"
site3.com:80 185.25.48.43 - - [27/Jan/2014:10:38:03 +0100] "GET /wp-login.php HTTP/1.1" 200 2811 "http://site3.com/wp-login.php" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"

It seems it's looking for Wordpress blogs.

This data is not that interesting, 22 connections from 1 IP is not really special. Can you post the access.log lines matching this IP plus a top/htop output (made when the server is reacting slow). — Jeroen, Jan 27 '14 at 10:43
Check your access.log to see if 185.25.48.43 has tried to access "strange" urls on your website. In doubt, use a firewall to block this ip. — krisFR, Jan 27 '14 at 10:45
I've updated with the access.log information. Sorry, I couldn't take a top capture, it was just a minute. — Ivan, Jan 27 '14 at 11:44
What kind of server is this? That little traffic shouldn't even bog down a Raspberry Pi. — Michael Hampton, Jan 27 '14 at 14:39
Little traffic? `access.log|grep '185.25.48.43'|wc -l` gives 50000 request in less than a 5 minutes — Ivan, Jan 28 '14 at 08:33

score 5 · Answer 1 · answered Jan 27 '14 at 12:40

My guess is that a script kiddie in Lithuania is looking for WordPress on a wide range of IPs. Not having found it on your site, he'll probably move on. This kind of thing happens all the time, and probably isn't the cause of your high load.

Also, what symcbean said.

score 4 · Answer 2 · edited Jan 27 '14 at 11:49

There's not nearly enough information provided to determine if this IP address is causing the problem nor to identify what the problem is (hence voting to close). That's not an invitation to provide more info - it's too complex a problem to answer here.

If we assume that the IP address is the cause of the high load (assuming it is high - you didn't say what the hardware config is) then it would probably be a good idea to block the network range.

Fail2ban is very useful for automating this kind of response but you still need to implement the detection part yourself.

Should I suspicious of this behaviour?

2 Answers2