I set up a home web server in February on a Raspberry Pi running Arch Linux and Apache. I enabled port forwarding on my router and the server worked as expected. I get the standard attempts to access phpmyadmin from IPs that trace back to China, but there was nothing unusual until 22nd of April when I started getting these:

$ grep '' 'access_log.1' - - [22/Apr/2013:07:33:29 +0100] "GET / HTTP/1.1" 200 264 - - [22/Apr/2013:11:33:12 +0100] "GET / HTTP/1.1" 200 264 - - [22/Apr/2013:15:33:13 +0100] "GET / HTTP/1.1" 200 264 - - [22/Apr/2013:20:14:03 +0100] "GET / HTTP/1.1" 200 264 - - [23/Apr/2013:06:40:03 +0100] "GET / HTTP/1.1" 200 264 - - [23/Apr/2013:08:52:22 +0100] "GET / HTTP/1.1" 200 264 - - [23/Apr/2013:10:14:51 +0100] "GET / HTTP/1.1" 200 264 - - [23/Apr/2013:10:18:49 +0100] "GET / HTTP/1.1" 200 264 - - [23/Apr/2013:10:38:12 +0100] "GET / HTTP/1.1" 200 264 - - [23/Apr/2013:14:38:11 +0100] "GET / HTTP/1.1" 200 264 - - [23/Apr/2013:18:38:11 +0100] "GET / HTTP/1.1" 200 264 - - [24/Apr/2013:07:00:44 +0100] "GET / HTTP/1.1" 200 264 - - [24/Apr/2013:11:00:42 +0100] "GET / HTTP/1.1" 200 264 - - [24/Apr/2013:12:25:52 +0100] "GET / HTTP/1.1" 200 264 - - [24/Apr/2013:16:25:48 +0100] "GET / HTTP/1.1" 200 264 - - [25/Apr/2013:06:47:46 +0100] "GET / HTTP/1.1" 200 264 - - [25/Apr/2013:10:47:30 +0100] "GET / HTTP/1.1" 200 264

The router is a Sky Broadband branded Sagecom with branded firmware; remote management is disabled and the admin password was changed months ago to a 20 character string that only my password manager knows. There's no corresponding pattern between the router logs and the server logs. There were no changes to the server or my network on the 22nd that I can remember. These entries have been appearing five or six times a day since.

Is this anything to worry about? Is there a way to stop these requests? Having Apache blacklist the router's IP seems like it'd cause problems.


  • There is nothing to worry about. Traffic sent by cannot be seen outside of your network. This is likely your attempts to view your website within your own network because of the port forwading. – Ramhound May 7 '13 at 13:49

These requests are not immediately worrisome. If anyone is allowed to access your public web server, surely machines within your local area network are, especially devices the majority of the traffic is passing through anyway. If your router is not trustworthy, you are completely at an end. I see no sign of a security issue in the partial log you've posted.

Although it is often possible to run an actual browser on a router, I believe the most common cause of a router's internal IP showing up as source addresses in access logs is hairpin NAT. If a machine inside your LAN tries to connect to your web server on an external IP address (or a domain name that resolves to one), the connection would fail because the client does not expect to receive a reply from the server's LAN IP. That is, unless the router supports the hairpin NAT feature and rewrites the packet headers, replacing their source IPs with its own. On the server, it appears as if the requests originated from the router.

It is very well possible 'something' on your LAN is polling the web server using your external IP address. Adding to Apache's blacklist 'works', if you want to kill this feature. The server would still be accessible from outside. Nevertheless, there's little harm in ignoring these log entries altogether.

  • I hadn't heard of hairpin NAT before, thanks for the info. What sort of program could be polling the server like that? Is it worth trying to track down? There is no information or service available on the /index.htm page - it contains one image and no links, so I know that no-one's accessing the page normally because the image URL would be in the log. Is there any legitimate reason software I have would be making GET requests to other devices on the LAN? And so frequently? I see other log entries requesting "GET /" and nothing else, and I always assumed those to be rogue spiders. – user222609 May 7 '13 at 17:13

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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