I was wondering if it is safe to have exec() enabled on my server. I would like to use it to execute a ping command inside a script to check to see if my servers are running. The ip's that are being passed into the exec() function are all hard coded into an array so it should be safe to run.
My worry is exec() could be injected somewhere else on my site via a self referencing form or into the database. Is this possible?
As long as you are the only one with access to the server, it is secure. The problem however occurs when somebody manages to get access to your server. This can be for several reasons, like stupid mistakes in coding, unknowningly creating holes, you lose your password, etc.
If you have exec enabled and somebody does manage to gain access, he can do almost anything with your server. Thats why its disabled in most environments. And i advise you to keep it that way.
If ping is what you want to do, check out how-to-ping-a-server-with-php
Yes. You'll definitely want to disable exec. This is more a debug function than something actually needed in scripts.
If you really need it, you can limit its capabilities, but I would discourage this approach.
Use this to ping a server from PHP.
Related
I'm hosting a couple of sites for my friends, which they can edit using SFTP. But I recently stumbled upon something quite alarming.
Using: <? echo $realIP = file_get_contents("http://ipecho.net/plain"); ?>
They are able to get the real IP of the server. I'm using CloudFlare to "mask" the IP from the outside, so that's quite safe. I know that I can use a VPN for this, but that a quite expensive option. Is there any way to avoid, them using this certain methodes to gain the real server IP?
I would just generally secure the server in a way that is similar to typical shared hosting accounts.
While this is on the edge of what I know, I am by no means an expert on server security I do know a few things I have ran into over the years.
disable using stream file wrappers for remote files. This is controlled by the allow_url_fopen setting in PHP, and disables opening remote files using fopen, file_get_contents and their like.
disable some of the more dangerous PHP functions these include but are not limited to shell_exec, exec, eval, popen. These likewise can be disabled in the PHP ini file by adding them to the disabled_functions list.
remove shell access for the users. They will still be able to authenticate for sFTP, for file transfers. But they will not be able to login via SSH through something like putty you can modify the users like this usermod -s /sbin/nologin myuser for more details see this post on Unix.StackExchange
setup a test account with the same access your clients (people you provide hosting for) have and test what works and what doesn't. This will give you a bit of an idea what they can and cant do, and it gives you a place to test some configuration changes before applying them globally.
I am sure there are many more things you can do, and I can't really go into a whole article on server security. As I said I am by no means an authority on the subject. So the last thing I would say is do as much research as you can and see what others are doing for shared hosting servers as this is basically what you have.
I did find this Post on 14 best practices on server security.
http://www.hostingadvice.com/how-to/web-hosting-security-best-practices/
This just gives a high level overview of some of the concerns and doesn't really get to overly technical.
This is a pretty big topic, with many pitfalls, but I hope my limited knowledge at least gets you started down the road of securing your server. And remember, it's your server you get to say what the policies are on it.
That said it is very important to communicate with your users about any policy changes. They have pretty much had free reign up to this point. But if you explain to them that it's in their interest because it not only protects the server but also protects their data, it may go over a bit easier. They do have a right to know, and you do have an obligation to tell them. This way they can make any necessary changes to their code. But again, it is your server ultimately and it's your responsibility to make it as secure as you can.
Good Luck!
I am in the middle of creating a game server control panel and i have a few issues.
The control panel needs to basically issue commands to a remote Linux server, starting and stopping processes, i have the commands written for this, however the problem is.
I am not sure whether to just SSH in using a PHP library and then issue the commands OR have remote files on the server to deal with this. Which would be most efficient?
Is it even safe running SSH commands from PHP, using the root account? Even if commands that will be sent are hard coded.
If the remote Linux servers would need remote files, what language would this be written in and what functions are best?
If you have any other ideas of the best way around this, please share, i will be very grateful.
Thanks!
that is possible but only done in special occasions. Usually the simpler way is to use some form of reqeust protocol, like for example http and thus evoke predefined routines (scripts) on the servers side. What protocols does the server speak?
NEVER DO THAT ! Usually that would mean to grant root access inside ssh which is unsafe. you could also use something like sudo or suid bits, unsafe again. And you would even top that by send the commands, since that would mean your setup would ahve to acceppt any command it is given and execute it under root rights. Not a good idea...
Use any language that is available on the server and that you feel comfortable with. Does it really matter what language you use to express what you want to say? No, the content matters. Maybe the coice also depends on what type of access you chose. Some languages offer themselves more easily in certain situations.
In short: without more detailed informations only a vague answer is possible.
I have an Amazon ec2 instance (linux).
I'd like you (yes, you) to be able to upload a PHP file and then serve it live on www.mydomain.com/yourname. I'd also like to be able to do this for numerous other people (www.mydomain.com/theirname).
I'm worried that you (or they, let's not point fingers) could do malicious things (purposefully or accidentally). For example, an infinite loop, reading/writing outside of one's root directory, taking the server down, running system commands, etc. This is what I would try if I wanted to be malicious.
Is there any way to set up PHP/apache/user permissions, or maybe search through their code before serving it, so that being malicious would at least be much, much harder?
Among other things, you'll definitely want to adjust your PHP.ini to include this:
disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
This will prevent the execution of those functions within any PHP files that utilize this .ini
I would also enable open_basedir support to lock down users to within their own directories so they can't use something like:
require_once '../../another_user/index.php';
or
$notMyFile = file_get_contents('../../another_user/config.php');
There's no bulletproof way of doing this.
First of all, no syscalls.
Secondly, timeout for each script.
And, you'll probably also want to keep a outside "quit button" in your hands so you can pull the plug if you see something going wrong.
PHP is a very large language, and having others run code on your server is a very difficult thing to do safely.
Have a look at Runkit Sandbox
Instantiating the Runkit_Sandbox class creates a new thread with its own scope and program stack. Using a set of options passed to the constructor, this environment may be restricted to a subset of what the primary interpreter can do and provide a safer environment for executing user supplied code.
http://php.net/manual/en/runkit.sandbox.php
Keep in mind that any resources you provide to a sandboxed environment can and eventually will be abused. If users should not be able to affect each other's results, for example, and you do provide users with a database, give each a different database in their sandbox with different credentials.
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.
Is this list good enough? Does this make the sandbox secure enough to be made part of the web app?
Beside blocking function calls like this, are there anymore security measures that should be taken?
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.
Any other suggestions/advice on how to go about this will be highly appreciated.
I think it's very hard, if not impossible, to foresee all the possible harmful function calls in order to fake their output (for example, highlight_file or its alias show_source are not on your list). Besides, using the same server for both the real app and the honeypot rises other concerns: does the app use extensions? if it does many more functions have to be blocked/faked. What if you update one of those extensions? you'll have to recheck for new security holes. Also, what if a malicious file is uploaded to the honeypot, and then accessed from the main app?? sure you will take measures to not allow that to happen, but if you have a bug at some point, the harmful code will already be on the server... doesn't look safe to me.
I think it would be better to set up a vm as MitMaro suggested. In that case, the VM itself would be as good as a sandbox as you can get, and without much effort you can let all those nasty php functions execute inside the VM without compromising the security of the main app
I'm developing an application in PHP and Javascript and I need to set up disk quotas for a given user (as I'm using an FTP daemon (ProFTPd in this case) to allow for users to have their own document manager) so elFinder (which is the document manager I'm currently thinking on using) can run 'freely' (instead of having to create my own PHP function to control how much space is actually being used).
The idea is to run a single command to adjust the disk quota on the server side, but... is it safe to let PHP run system commands (even if I'm not going to accept parameters or allow any kind of user interaction with the system)?
Usualy is not safe. It doesn't matter if you let users send commands or any other kind of interactivity. Even if your script runs alone, exploits can be invented to make use of it in one form or another and maybe alter it's actions.
But, this applies only if you want to have insane security rules on your server. In real world, the chance is minimal that you can compromise your server security.
I still have some suggestions for you :
make sure your script does not accept any input from outside, it does not read a database or a file. Everything must be enclosed inside the script.
Try to put the script somewhere outside the documentRoot so it won't be accesible by users.
Put some special permissions on the script so that it's actions are limited to the user it runs as. Even if someone breaks it somehow, the OS will not let him do something else than running just that particular command in a particular environment.
This of course may be completed with more rules, but this is just what comes in mind now. Hope it helps
It is unsafe if you let the user enter info; POST or GET values without filtering.
If you have to use a GET value the user enters, you should use escapeshellarg() or escapeshellcmd().
http://www.php.net/manual/en/function.escapeshellarg.php
http://php.net/manual/en/function.escapeshellcmd.php
As long as you are not getting any user input and for the command the be run, it is just as safe to use exec() as it is to do it from the command line. If you are going to use user input in the commands, use escapeshellarg() or escapeshellcmd() and it should still be safe.