I am working on a PHP sandbox for a Web Application Honeypot. The PHP sandbox will analyze a PHP file that may have been injected as part of an RFI attack. It should run the file in a safe environment and return the result, embedding the output of the PHP script. We hope to fool the attacker into believing that this is a genuine response and thus continue with the next step of his attack.

In order to build the sandbox, we used the Advance PHP Debugger (ADP). Using the rename_function and override_function, vulnerable PHP functions have been rewritten. Some functions such as exec,disk_free_space have been rewritten to send out fake replies. All the others function just return nothing. Here's a complete list of the functions that have been considered.

Also, the input script is run only for a maximum of 10 seconds in the sandbox. After that, the entire sandbox process gets killed.

  1. Is this list good enough? Does this make the sandbox secure enough to be made part of the web app honeypot?

  2. Beside blocking function calls like this, are there anymore security measures that should be taken?

  3. In the end, this is a honeypot. So, we would like our reply to be as close as possible to a real reply. So, by blocking DNS function calls like dns_check_record and gethostbyname are we restricting the scope of execution for the script unnecessarily. (I am not sure why they are present in the first place)

    In short, I would like to know what elements I should add/delete from the list.

  4. Any other suggestions/advice on how to go about this will be highly appreciated.

  • Hi Phani, welcome to Information Security! This sounds very interesting, thanks for bringing this here. Don't forget to check out the FAQ at some point...
    – AviD
    Mar 25, 2012 at 19:16

2 Answers 2


I'm far from being a PHP expert, so my comments are more general rather than specific.

  1. Probably not entirely, but it depends. I don't think that any whitelist/blacklist approach can ever be 100% accurate. There will always be a case of false positives or false negatives. So you're always balancing between hits (of a script being able to still penetrate through your defences) and misses (i.e. successfully blocking the script, but in such a way that doesn't allow you further analysis). PHP must have thousands of different calls and permutations, so building a waterproof list is very difficult. That said, the list on a very quick glance looks ok as a starting point. Again, my php experience is limited.

  2. I'm not sure what you meant when you said "to be made part of the web app", but I would rather strongly advise against embedding this with anything that is even remotely connected or in proximity to real data or any real production application. If this is a honeypot, it should probably be kept in as much isolation as possible. You should consider things like:

    • Running this on a dedicated hardware machine which gets regularly 'refreshed' (re-imaged, built from scratch)
    • Don't let it connect to anything other than the outside world
    • Don't store any sensitive (or even not so sensitive) data on it
    • Log all access and use an external firewall with verbose logging
    • Use internal OS system logging
    • Monitor anything even remotely strange on any of your logs
    • Consider throttling the speed of the external connection

    If the system is isolated well enough, then the main remaining risk besides to itself, is to other systems. Assuming the attackers went through your php protection layer successfully, your honeypot can be used to launch external attacks onto other systems - spam, denial of service, act as part of a botnet etc. This is why keeping it in isolation, keeping a close eye on it, as well as trashing and starting from scratch is a good idea.

  3. Unfortunately I cannot answer that more than I already covered on 1.

  4. See 2.
  • +1 I like the trashing and starting from scratch part. Can you suggest a suitable VM for this purpose? I am looking at KVM and OpenVZ, but do you have any suggestions. This software is going to be distributed, so I would like the VM to be lightweight and set up friendly.
    – Phani
    Mar 29, 2012 at 18:27
  • I believe most virtualization platforms support some kind of images where you can clone/refresh from. From what I hear KVM and Xen have good reputation. Perhaps you can also consider a cloud hosting provider (Linode, AWS, Rackspace etc). I normally prefer using one of those guys than having to manage my own virtual platform and they all have easy-enough web (+API) access to manage pretty much everything online.
    – Yoav Aner
    Mar 29, 2012 at 20:08

Your approach doesn't make a lot of sense to me.

You say you want to create a honeypot (i.e. a system which appears to be insecure) by disabling common attack vectors.

We hope to fool the attacker into believing that this is a genuine response

That implies you will only be able to substitute responses for attacks you have already characterized. And you'll be running a very different software stack to the system you are trying to model the behaviour of.

At best, this is going to be a huge amount of effort. More likely that you'll have something which is far from representative, which doesn't expose the vulnerabilities of the system you are modelling and which exposes this to any attacker. Your list is very far from being a complete list of things to disable/wrap for a secure PHP installation - but that's not the point.

I'd recommend that you revert to a standard PHP build and think about how you encapsulate and monitor the honeypot as a whole. You certainly want to implement the honeypot in a virtual machine (which you can copy elsewhere to study / take offline quickly / modify the build) and proxy and log all the server traffic to/from, with remote logging and (near) continuous integrity checking. By all means wrap key PHP functions / constructs with logging - but don't disable them.

  • Can you please elaborate on "Your list is very far from being a complete list of things to disable/wrap for a secure PHP installation" Can you state some example functions?
    – Phani
    Mar 29, 2012 at 18:20
  • Also, I don't understand where we are "disabling common attack vectors"? The Python based honeypot serves all the HTTP requests that it receives. In this process, if it happens to receive a PHP file, it will execute it on another sandbox.
    – Phani
    Mar 29, 2012 at 18:27

You must log in to answer this question.

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