1

Just got a new VPS with two IPs. I'm getting a tonne of requests from multiple different client IPs for a single path on one of the IPs, almost one per second. The path is "/lzb/gz.php". Any ideas what this is? And should I be concerned? Should I request a new IP from my VPS provider, or just hope the volume dies down over time?

FYI I'm running nginx as a reverse proxy to apache2. The VPS came with apache2 running, and the requests for "/lzb/gz.php" started immediately after purchase according to the apache2 logs. When I turned on nginx, the requests started to appear in the nginx logs. I'm pretty sure the requests are confined to one of the two IP's because I have unique access and error logs set up for a vhost that I've tried on both IPs, and the requests only show up in those logs when the vhost listens on the IP address in question. Both apache2 and now nginx return 404's, but I'm still concerned about the volume of requests for the same path and potential security implications.

2 Answers 2

1

/lzb/gz.php doesn't jump out as anything nefarious. It appears to be a file in the xwall firewall package, so perhaps the former owner of that IP was running that application.

You have three options that I see:

  1. You can most certainly request a new IP from your provider if this behavior bothers you, but one request per second isn't a troubling volume.
  2. Drop the traffic with your server's firewall. This is, I think, the quickest and most effective option unless the bandwidth used by the errant incoming connections starts to eat your allowance up.
  3. What I think would be the better long-term solution is to track the source IP address(es) and see if there is any network operator that you can speak to about the requests. Perhaps it's just a few other systems that formerly relied on the services supplied at your IP address. In that case, you have a decent shot at tracing things back to the originators.
  4. Okay, I lied, there's a fourth possibility, but it's not very good. You could tarpit the incoming requests using iptables rate limiting and perhaps throw off the systems sending the traffic. Of course, if you're using another OS, then research the rate limiting capabilities of its firewall. If the sending system's communication to your IP address isn't responded to immediately, or you send alternate responses back you might timeout whatever is making the communication and cause enough consternation in the sending system's logs to notify a human. It's an outside shot, and not your best option by far.
1
  • Thanks. For now I think I'll go with option #2 and prevent these requests from hitting the server using iptables. Hopefully the requests will die down over time, but if not I can try my hand at #3 if/when I find the time.
    – user101570
    Apr 19, 2012 at 20:47
0

The requests are probably made from a broken client. You probably don't need to worry, and can use @WesleyDavid's tips to remove this annoyance.

The VPS came with apache2 running, and the requests for "/lzb/gz.php" started immediately after purchase according to the apache2 logs.

The requests probably appeared after purchase because your vendor allocated the IPs to you and configured the firewall to allow access to those IPs.

Someone probably owned these IPs before you, and the requests /lzb/gz.php are likely intended for the website which existed before yours. I'm reaching here, but note that lzb and gz are both common shorthand for two compression methods, so it's possible that the previous owner served compressed content. Googling around shows that gz.php is not an unusual name for a file, and is sometimes used to compress data on the fly using PHP.

A google for site:your.ip.address/lzw/gz.php might reveal who the previous owner was and shed some light on the issue.

2
  • Thank you, that is reassuring, and good tip re: the google site search. I think your hypothesis re: prior owner serving compressed content is likely correct; hopefully the request volume will die down quickly when the client(s) realize there is nothing there (though it hasn't so far 3 days in... )
    – user101570
    Apr 19, 2012 at 20:54
  • If it is a dumb client, it was likely hitting the firewall (With no response) before you became the owner of this IP, and it still kept on sending requests. Check with Tech Support, they should be able to give you more information. Apr 19, 2012 at 21:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .