Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I see repeated requests like these in my Apache Access Logs and they have been eating up all my CPU.

I have a normal WordPress installation. All i changed in the Apache Configuration was changing the DocumentRoot from /var/www/html to /var/www for both ssl and the default configuration.

Also, the file referenced in the requests(updatedll.jpeg) does not exist on my server and also isn't referenced in the source code served by any page of the web application.

Could this be a security threat? What are these actually and what can i do to stop them.

I changed the ip address of my server. They still kept coming. Meaning that somebody is actually hitting the domain name and not the ip address.

Why does my server send a 301 for these requests? Shouldn't it be sending a 404? Is it because Wordpress is installed in my root directory and the .htaccess file present for Wordpress is sending a 301 redirect?

My disk access logs also seem to have high peaks intermittently. But nobody is actually accessing the site. I see no access logs except these below.

Also, i see that all the requests seem to be coming from one of the following 5 ip addresses.

201.4.132.43 - - [05/Jun/2014:07:35:08 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; BTRS103681; GTB7.5; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.2; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; AskTbATU3/5.15.29.67612; BRI/2)"

187.40.241.48 - - [05/Jun/2014:07:35:08 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; GTB7.5; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

186.56.134.132 - - [05/Jun/2014:07:35:10 -0400] "GET /updatedll.jpg HTTP/1.0" 301 428 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"

71.223.252.14 - - [05/Jun/2014:07:35:13 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; BTRS31756; GTB7.5; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; InfoPath.2)"

85.245.229.167 - - [05/Jun/2014:07:35:14 -0400] "GET /updatedll.jpg HTTP/1.1" 301 465 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; MAAU; .NET4.0C; BRI/2; .NET4.0E; MAAU)"

UPDATE

Appears to be 32 distinct IP Addresses which seem to be hitting my server now.

Also, the output of command "ngrep 'GET /updatedll.jpg' port 80" is given below:

T 75.172.162.70:1616 -> 162.243.34.213:80 [AP]
  GET /updatedll.jpg HTTP/1.1..Accept: */*..Accept-Encoding: gzip, deflate..U
  ser-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; 
  BTRS31756; GTB7.5; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506
  .2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; InfoPath.2)..Connection: Kee
  p-Alive..Host: www.reinventweb.com....                                     
###############
T 85.245.0.83:65166 -> 162.243.34.213:80 [AP]
  GET /updatedll.jpg HTTP/1.1..Accept: */*..UA-CPU: x86..Accept-Encoding: gzi
  p, deflate..User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; 
  GTB7.5; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; 
  .NET CLR 3.5.21022)..Host: reinventweb.com..Connection: Keep-Alive....     
######
share|improve this question
    
have you tried accessing /updteddll.jpg yourself to see what happens ? –  Iain Jun 6 '14 at 6:13
    
Yes i get a 404 response code if i access mywebsitename.com/updatedll.jpg. –  Kanishk Dudeja Jun 6 '14 at 6:17
1  
Their user-agent is kinda weird (IE6 and IE7 in 2014, really ?), I think it's a bot... anyway you can easily block the IPs with iptables if they cause too much CPU usage. –  André Daniel Jun 10 '14 at 15:17
1  
@user38480 yes, block them all. If the attacks continue with new bots you can use Fail2Ban and a custom regex that will match the attacked file path /updatedll.jpg and block them automatically. –  André Daniel Jun 11 '14 at 11:11
1  
@user38480 you can, but is it worth the hassle to set up Fail2Ban right now if it's just 32 IPs that you can block manually ? –  André Daniel Jun 11 '14 at 11:21

2 Answers 2

up vote 3 down vote accepted

A search on Google for the filename reveals a few copies of your logfile and just one other hit, which appears to be an upload log from some service. You should be able to tell if that log is related to your site, I am not.

None of those five IP addresses show up in that upload log, so that doesn't tell us much. The filenames in the upload log looks legit to me. Whether the content of those files matches their names is impossible to say, without knowing the contents.

What might originally have been in a file named updatedll.jpg? I am guessing somebody took a screenshot of how to update some dll and uploaded it to a service in order to share it with others. The sharing probably did not happen on a public webforum, because then I would have found more hits for it.

Why does somebody think the file resides on your host? I don't know. I find it useful to include \"%{Host}i\" in the Apache LogFormat.

As for the status code, you can first try to access the filename yourself to see how that looks in the logfile. If you get a different status code, something must be different between your own request for the file and theirs.

If you cannot figure out how to reproduce the exact same status code, then try to produce a packet dump of their traffic. You could use something like tcpdump -pni eth0 -s0 -Uw output.pcap 'host 201.4.132.43 || host 187.40.241.48 || host 186.56.134.132 || host 71.223.252.14 || host 85.245.229.167'

Later you can inspect the output using Wireshark to see exactly what the requests look like. Remember to use an updated version of Wireshark in case somebody is actually trying to exploit a vulnerability in Wireshark. Once you have seen the exact request, you should be able to reproduce the reply through a telnet command.

share|improve this answer
    
Thanks for your answer. I will inspect and get back to you! :). –  Kanishk Dudeja Jun 11 '14 at 6:02
    
@user38480 You are redirecting from reinventweb.com to www.reinventweb.com, requests to the first domain get a 301 response, and they should be followed by requests to the second domain, which will get a 404. –  kasperd Jun 11 '14 at 6:53
    
yes that looks like the case. but how do i now stop these requests? –  Kanishk Dudeja Jun 11 '14 at 7:00
1  
According to whois, the domain was registered November 2013. But archive.org indicates it has crawled the domain in April and May of 2013. This may in fact mean it is a recycled domain name. At the time it was redirecting to a URL under fw.dnslink.com. However archive.org has not seen the updatedll.jpg URL. My best suggestion on how to find out any more, would be to contact the owners of dnslink.com and ask if they know something. –  kasperd Jun 11 '14 at 7:55
1  
I wanted to award a bounty each to both of you. But after awarding the first bounty to him, i did not see an option to create another bounty for this question. So i've accepted your answer and given that user the bounty. In some time, when i get more reputation, i'l create another bounty for this question and award you too :). Thanks :). –  Kanishk Dudeja Jun 11 '14 at 17:02

Are you redirecting based on domain name? Eg from example.com to www.example.com? That might explain the 301 response.

If your server is responding with a 301, it's likely this isn't doing much harm. However some page somewhere probably has a broken image link on it. To track that down you should look at the Referer header in the incoming requests. You could log Referers from your web server, but it's probably easier to look at the traffic directly.

Rather than tcpdump, (Which kasperd suggested) I'd use ngrep:

ngrep 'GET /updatedll.jpg' port 80
share|improve this answer
    
I think wordpress internally generates a 301 redirect from example.com to www.example.com. –  Kanishk Dudeja Jun 11 '14 at 5:56
    
I will check the referer header and will get back to you. Thank you so much! :). –  Kanishk Dudeja Jun 11 '14 at 5:56
    
Have updated the output of the ngrep command in the edit. Please check. –  Kanishk Dudeja Jun 11 '14 at 6:06
1  
I wanted to award a bounty each to both of you. But after awarding the first bounty to you, i did not see an option to create another bounty for this question. So i've accepted his answer and given you the bounty. In some time, when i get more reputation, i'l create another bounty for this question and award it to him too :). Thanks :) –  Kanishk Dudeja Jun 11 '14 at 17:03
    
A bit late, but: Look through some more ngrep output for hits that include a Referer header. Some browsers may block it. MSIE used to do so for hits from a different domain, and I guess probably still does. At least some of the browsers out there will include the Referer header though. You could try ngrep -q '^GET /updatedll.jpg.*Referer' port 80 –  mc0e Jul 1 '14 at 11:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.