GET /HNAP1/ HTTP/1.1 with my outgoing IP address in /httpd/access_log 1

[jdavenport]

Hello,
I'm looking for some advice on some odd entries I'm seeing in the /var/log/httpd_access_log on one of my servers. The server is running Red Hat Enterprise Linux Server release 5.10 (Tikanga), kernel 2.6.18-371.3.1.el5, with Apache/2.2.3. The main applications we are running on the server are ColdFusion 8 and Postgresql 8.4. The entries in access_log all look something like this:

216.138.24.68 - - [29/Dec/2013:11:26:31 -0600] "GET /HNAP1/ HTTP/1.1" 404 266 "

http://<outgoing

IP address of my server>/" "Opera/6.x (Linux 2.4.8-26mdk i686; U) [en]"
76.14.92.23 - - [29/Dec/2013:10:15:55 -0600] "GET /HNAP1/ HTTP/1.1" 404 266 "

http://<outgoing

IP address of my server>/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (FM Scene 4.6.1)"
68.43.22.227 - - [31/Dec/2013:11:46:33 -0600] "GET /HNAP1/ HTTP/1.1" 404 266 "

http://<outgoing

IP address of my server>/" "Opera/9.60 (Windows NT 5.1; U; de) Presto/2.1.1"
67.51.128.82 - - [31/Dec/2013:12:41:14 -0600] "GET /HNAP1/ HTTP/1.1" 404 266 "

http://<outgoing

IP address of my server>/" "Mozilla/2.0 (compatible; MSIE 3.0B; Win32)"

and they reference the outgoing IP address of my server where I indicated. The IP addresses on these entries are always from within the U.S. but are not legitimate servers that should be accessing my server. There are usually 2-3 of them per day. Can anyone tell me what this is? I can block the IP's but I'd like to understand what is going on.
Thanks!
Julie

 

[jdavenport]

Another strange set of entries we are also seeing in the access_log on this server and a couple others is similar to the following:

189.126.117.74 - - [15/Dec/2013:08:36:03 -0600] "HEAD / HTTP/1.0" 200 - "-" "-"
189.126.117.74 - - [15/Dec/2013:08:36:03 -0600] "POST /cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2
D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%6
2%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65
%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%6
4+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 271 "-" "Mozilla/5.0 (iPad; CPU OS 6_0
like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25"

This is only part of the entry. It always starts with the "HEAD..." line, then it follows with 5 of the "POST /cgi-bin/php?..." lines, all 6 lines coming from the same IP address. Then it will stop and another set of these same 6 rows will show from a different IP address. This happens over and over again, and only started about 6 weeks ago. It seems to increase at times when the server is busier. A few weeks ago there were 68 such sets of rows in one week. Can anyone tell me what these entries are and what we can do to stop them?

thanks!
Julie

 

[ChrisHirst]

A HEAD request is one that returns only the server headers, often employed in identifying the sever signature.

And the URL encoded request is an attack vector that attempts to bypass PHP security.

http://www.url-encode-decode.com/

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum

 

[jpadie]

the GET HNAP1 is a test to see whether the server supports the HNAP protocol (which has been the subject of some security issues recently).

as Chris points out, the POST request is an attempt to spawn a php cgi thread. the url encoded information is a bunch of configuration commands for php cgi that reduce (somewhat) the security of the binary. assumedly if that is successful either some other commands can be pushed through or a pre-existing trojan can then use the spawned thread for whatever purpose.

in terms of stopping them, it's unlikely that you will want to lock out all HEAD, POST, GET etc requests, as that somewhat negates the purpose of the server. So don't look so much to stop the probes occurring, but to make sure that they are unsuccessful. Ensure your server apps are fully patched. use rewrites to push all naughty looking traffic to some process that will just sit there delaying things (that will cost the miscreants some pain). If you are not a security guru, consider having one check out your servers from time to time.

 

[jdavenport]

Chris and jpadie,
Thank you both for your replies. Those were very helpful explanations. You are right, I don't want to lock out all HEAD, POST, GET. We do apply the Redhat patches on all our servers once a month. We have no security gurus on hand, just programmers and database folks who inherited the Linux and Apache duties and are doing our best to wing it. Would love to find a security guru to check them out, not sure how to find one. I'm also interested in your suggestion "use rewrites to push all naughty looking traffic to some process that will just sit there delaying things (that will cost the miscreants some pain)". I will do some research on that, sounds like fun. Do you have any references to suggest on that topic?
Thanks!
Julie

 

[jpadie]

Hi Julie

actually you can do it even more easily than using rewrites.
if you think about an httpd.conf file, you can specify what is allowed on a per host per directory basis. some directories will, for example, never need to be POSTed to. so you can exclude POST on those. etc etc. others will only hold images, so you can restrict the service to the relevant mime types.

if you do this diligently you are left with a scenario that all other requests will be:

1. permitted (and secured through the application scripts)
2. for resources that are not present (and thus apache will 404)
3. for resources that are not permitted (403 error).

sos then you can specify handlers for 404 and 403 errors that drip content down the pipe every few seconds for, say, 30 seconds or whatever. And also shove an arbitrarily large value for content-length as a header (if you can dummy this). Unless the miscreant has coded some proper smarts into its spider, that thread will sit there and listen for a long time to detect whether it is receiving useful data. Yes, it ties up a thread at your end too. This is called a zombie and is a form of honey-trap.

If you are concerned about the processors at your servers becoming overloaded by this (this is how ddos attacks are successful), you could create a cheap cloud instance and redirect all 404/403s to that. Probably the client will realise and drop the connection, but who knows; it's only a few bucks a month with some providers (e.g. DigitalOcean) and you can analyse the traffic after a couple of months to see whether the honey trap is working. Keeping the actual traffic to a minimum keeps your bandwidth charges low. If you are not bandwidth constrained, you could consider dropping war & peace (if out of copyright) on each 405.

the negative aspect of all of this is that you won't have nice 404s for real world visitors.

other potentials might be logging requests and submitting them to real time analysis to determine whether the time between requests is congruent with human clicks and whether cookies are maintained between clicks (potential issues with IP gateways here; so you'd also need to factor in other pieces of information like browser strings).

There are bound to be hundreds of resources on the net for how to plot honey traps. I'm glad to say (touch wood) that none of my operational sites are targets so I have not had to build a honey trap myself for some years.