After everything what I did in order to protect my server, i have uploaded webshell (WSO 2.1 Web Shell) , to see how far can hacker go and gues what, I was shocked, because I was able to read very sensitive information.

I can run number of commands and read a lot of private data.

enter image description here

As you can see from source code of webshell... and that's not all you can do, but there is more...

If permissions are not as it should be, then it's possible to read the content of those files.

So question is simple, what can I do in order to protect my server, how can I limit/restrict shell command execution via PHP.

What are recommended permissions for:


I'm running Apache/2.4.7 (Ubuntu)

I also did all of this. (Hardening PHP from php.ini)

EDIT: I'v missed popen from disabled PHP functions. That solved my problem!

  • 1
    Did you try to actually run the commands the shell offers? Because from what I can tell, WSO uses only these functions to try to execute system commands: exec, passthru, system, shell_exec, popen. These are all disabled if you followed the tutorial you linked. How to prevent system command execution in PHP still seems like a valid question, but you might want to edit your question a bit, so it's not closed as too broad or unclear what you are asking.
    – tim
    Feb 23, 2016 at 19:03
  • popen was missing, i can not belive that is missed that one. I'v focused on bigger things and ignored smaller, unexpected mistakes. Thank you!
    – Mirsad
    Feb 23, 2016 at 19:30

1 Answer 1


i have uploaded webshell (WSO 2.1 Web Shell)

Hmmm. If you leave your car keys in the ignition and park your car in a bad area, would you be surprised if it was not there when you get back? Certainly security in depth is a good idea, but what is exposed to code running on your server is not the starting point for hardening your server. Sadly the boilerplate recommendations you followed were, like most of the articles I've seen, a simple checklist of instructions with little explanation or justification.

If you really have taken adequate precautions against code injection (I note that eval and preg_replace() are not disabled in this howto, but things like posix_setuid() are!!!) and have applied all the best practice in securing the platform (which, based on the screenshots, you clearly have not done) and deployment process, then yes, you might then consider restricting what code which bypasses all these controls might do.

To that end, there are some very simple things which will have a big impact;

  • work out a proper permissions model and apply it
  • configure apparmor or grsecurity to further constrain the behaviour (selinux sucks)
  • or run the php in a chroot environment / container if appropriate
  • use suhosin
  • find out what extensions and functions your code needs to run and remove extensions / disable functions which are not needed

The single, most valuable thing you can do is learn about what the facilities you have available actually do and hence how they affect your risk.

  • preg_replace() is a commonly used function in a lot of PHP applications. For example, in WordPress it is used 115 times. It isn't a dangerous function. I wouldn't recommend blocking it.
    – Bacon Brad
    Nov 12, 2016 at 4:08
  • Notice how it says the deprecation has been implemented. It is no longer in 7 and up. And if your code does not accept user supplied code for that argument it is no danger. It is optional argument and not used often with that function. If a hacker gets to the point they can implement it themselves they already have compromised you to the point where exploiting this function or eval is moot. I still recommend against blocking it.
    – Bacon Brad
    Nov 14, 2016 at 5:11
  • "If a hacker gets to the point they can implement it themselves...." - then what is the point of disable_functions? " It is no longer in 7 and up" - what version is mirsad running?
    – symcbean
    Nov 14, 2016 at 13:26

You must log in to answer this question.

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