Logwatch: "Connection attempts using mod_proxy" for Apache

I run a tool called logwatch daily on my webserver (Ubuntu 12.04) to let me know if there's anything in my webserver's log files that is worth noting. Over the past week or two, I started seeing a new section under the main "httpd" header for Apache in the logwatch report that I receive each morning, The new section was entitled "Connection attempts using mod_proxy," and it would list a string of IP addresses, the mail server it was trying to connect to via port 25, and the number of connection attempts.

At first, I wasn't too concerned because I was almost certain that I had mod_proxy disabled, and there were also one or two connection attempts per day. Other servers will often probe my server, looking for any holes in the firewall that they can exploit, so I was used to seeing a lot of failed attempts at manipulating my server.

Each day, however, the number of connection attempts increased. Here are the relevant entries from today's report:

Since I had zero attempts a few weeks ago and the number was increasing so quickly, I decided to check to dive in to see if there were any problems. At first, I searched "Connection attempts using mod_proxy" with various other search terms to see if this was even issue. An attempt doesn't necessarily indicate any amount of success, after all. I encountered a number of threads that seemed to indicate that seeing this at all was a problem, and the solutions always seemed to be to disable mod_proxy.

Since this was the case, I decided that it was time to make sure that mod_proxy was really disabled, so I I ran the following commands:

sudo apache2ctl -M

I ran through the list, and then to make sure that there were no proxy-enabled mods enabled, I also grepped through the list for any instances of the word "proxy":

sudo apache2ctl -M | grep "proxy"

This turned up no results. I thought it might also be a good idea to search through my config files. From within /etc/apache2, I recursively grepped for the word "proxy" again:

sudo grep -R "proxy" *

The only instances that I was able to find in the mods-enabled directory were in status.conf (a conditional to check if mod_proxy is enabled) and rpaf.conf ("RPAFproxy_ips 127.0.0.1 ::1"), neither of which made me think that mod_proxy was actually enabled.

I tried searching for any instances in which people were encountering these reported attempts at connecting via mod_proxy in logwatch reports, but I was unable to turn up much. Finally, I decided to take a look at the logs to see what the attempts actually were and if they were successful.

Within /var/log/apache2 I grepped through the access logs for the IP address that I had seen in today's logwatch report (I just selected the first one:

sudo grep "111.241.24.96" *

Here are the results that I received:

This concerned me in the first instance, because the 200 response code (appearing just after the quoted request itself) is standard for successful Apache requests. I felt a little bit better about the second line, which is the one that logwatch had flagged in my report. This is because it received a 405 response code, which stands for "Method Not Allowed," since the resource does not support the method of the request.

I decided that the best thing that I could do at this point would be to actually telnet to the server and see the results of the requests myself.

To do this, I just ran a telnet command to port 80 to my website, and then I issued the commands that I found in the log file. The only trick to this is that you have to hit an extra return to actually get your command to go through when connecting via telnet.

telnet www.rklawson.com 80

After connecting I issued the following command and then hit enter/return twice:

GET http://www.google.com.tw HTTP/1.1

Here is the response I got back after issuing the command:

This was actually a relief, because this is the index file of my default virtual host for Apache. The 200 response code indicates that the request was successful, but the result is the headers and HTML from my default apache index file. I surmised that this was because the request did not match the ServerName or any of my ServerAlias values in any of my virtual hosts.

I used telnet (as per above) again to run the second request, making sure to hit enter/return twice again:

This showed me that even though someone was trying to use my server as a proxy to connect to that mail server, the request was not successful, just as the Apache access log had indicated.

At this point, I feel comfortable that with mod_proxy disabled, these attempts to use my server as a proxy have been unsuccessful. I could probably reconfigure logwatch to ignore these attempts, but I'd rather receive some false positives from logwatch than to potentially miss something that turns out to be important, so I will probably just leave the configuration alone.