Can somebody advice on web directories under /var/ vs /home/username/? Or where else you normally put web directories?
What I can think of, /var is more natural since web serving is a site event and is the default. But under /home seems more secure because that doesn't need to turn on ftp chroot.
I am moving from single-user/single-site to multi-user/multi-site in a server, so this question becomes important.
Both are feasible.
From the point of view of a web server, Apache for example, it doesn't matter what directory path is used to store each site files, as long as the web server and virtual host configuration files are correct.
A more important aspect, specially for security aspects, is related with permissions. This includes permissions for these users:
The system user that runs the web server process, like for example www or www-data
The owner and group associated to the directories and files of each site
The other users of the system
If your scenario depends on personal web sites for one or more users, something like Apache mod_userdir module could be helpful.
That's all for now.
My webserver is running as www-data, but for some reason this image file can be seen from the web without problem. Here are the permissions/ownership:
ls -alht /var/www/html/file.jpeg
-rw------- 1 www-data www-data
If I do a chmod 000 on that file, it cannot be seen as would be expected.
I'm completely stumped by this, anyone have any idea what is going on? Many thanks.
Linux permissions work only in the context of linux users not website users.
Your webserver is a single app running as a user:group identity (www-data:www-data) within the linux system. That's all that matters. If your webserver can read/execute the file then technically anybody who visits the website can unless your website app explicitly prohibits them according to ip, app based credentials or similar.
The only thing you can effect by changing permissions on the Linux OS level is to prevent the webserver from reading the file or serving it to anybody or to make so that other linux users on the same system cannot access them. This is particularly important when using shared hosting, where multiple linux users represent many different people using the same Linux server.
http://linuxcommand.org/lts0070.php
If you want to prevent a file on your webserver from being served by your webserver to the public, you should configure your .htaccess file or similar website conf file such as /etc/apache2/sites-available/mysite.conf to disallow access to a particular location.
If you are using nginx as a webserver then your conf file should be found under /etc/nginx/conf.d or /etc/nginx/sites-available or similar
http://www.ducea.com/2006/08/11/apache-tips-tricks-deny-access-to-some-folders/
Alternatively you can restrict access via password using htpasswd
https://wiki.apache.org/httpd/PasswordBasicAuth
I plan to create a web interface to configure a part of my system, including some files owned by root. I will be a NodeJS server and I know that running it as root is not a good idea.
Any suggestions about how to perform that without performance and security issues?
Thank you.
I decided to create a specific script that will be owned by root with high restricted rights and allow a sudo on that script for a dedicated user without password so that could not log in (only root can do a su on it).
In the script i will perform wanted action (updte, upgrade, files copy, etc.)
Let's hope that scurity is good enought
I have multiple websites on a dedicated server running under Linux/Apache. The sites need to access common data from a directory named 'DATA' under the doc root. I cannot replicate this directory for every site. I would like to put this under a common directory (say /DATA) and provide a symbolic link to this directory from the doc root for each of the sites.
www/DATA -> /DATA
Is there a better way of doing this?
If I put this common directory (/DATA) directly under Linux root directory, can there be problems from Linux standpoint as the directory size can be several gigabytes and the sub directories under /DATA will need have write permissions.
Thanks
Use Alias along with the Directory directive. This will allow the site to access the directory via a url path.
I'm not sure what exactly it means that you'll have scripts accessing the directory to provide data. Executing shell scripts to read an produce data is a different story entirely, but you probably want to avoid this if this is what you're doing. Application pages could be included in the data directory and use a relative path to get to the data. Then all sites get the same scripts and data.
I don't know what your data is, but I'd probably opt to put it in a database. Think about how you have to update multiple machines if you have to scale your app. Maybe the data you have is simple and a DB is overkill.
I have a folder on my server on which I have changed the permissions to 777 (read, write and execute all) to allow users to upload their pictures.
So I want to know, what are the security risks involved in this?
I have implemented code to restrict what file formats can be uploaded, but what would happen if someone was to find the location of the directory, can this pose any threat to my server?
Can they start uploading any files they desire?
Thanks.
When users are uploading files to your server through a web form and some PHP script, the disk access on the server happens with the user id the web server is running under (usually nobody, www-data, apache, _httpd or even root).
Note here, that this single user id is used, regardless of which user uploads the file.
As long as there are no local users accessing the system by other means (ssh, for example), setting the upload directories permissions to 0777 would make not much of a difference -- appart from somebody exploiting a security vulnerability somewhere else in your system there's no one those permissions apply to anyway, and such an attacker would probably just use /tmp.
It is always good practice to set only those permissions on a file or directory that are actually needed. In this case that means probably something like:
drwxrws--- 5 www-data www-data 4096 Nov 17 16:44 upload/
I'm assuming that other local users besides the web server will want to access those files, like the sysadmin or a web designer. Add those users to the group your web server runs under and they don't need sudo or root privileges to access that directory. Also, the +s means that new files and directories in upload/ will automatically be owned by the same group.
As to your last question: just because an attacker knows where the directory is, doesn't mean he can magically make files appear there. There still has to be some sort of service running that accepts files and stores them there... so no, setting the permissions to 0777 doesn't directly make it any less safe.
Still, there are several more dimensions to "safety" and "security" that you cannot address with file permissions in this whole setup:
uploaders can still overwrite each others files because they all work with the same user id
somebody can upload a malicious PHP script to the upload directory and run it from there, possibly exploit other vulnerabilities on your system and gain root access
somebody can use your server to distribute child porn
somebody could run a phishing site from your server after uploading a lookalike of paypal.com
...and there are probably more. Some of those problems you may have addressed in your upload script, but then again, understanding of unix file permissions and where they apply comes usually waaaay at the beginning when learning about security issues, which shows that you are probably not ready yet to tackle all of the possible problems.
Have your code looked at by somebody!
By what means are these users uploading their pictures? If it's over the web, then you only need to give the web server or the CGI script user access to the folder.
The biggest danger here is that users can overwrite other users files, or delete other users files. Nobody without access to this folder will be able to write to it (unless you have some kind of guest/anonymous user).
If you need a directory that everyone can create files in, what you want is to mimic the permissions of the /tmp directory.
$ chown root:root dir; chmod 777 dir; chmod +t dir;
This way any user can create a file, but they cannot delete files owned by other users.
Contrary to what others have said, the executable bit on a directory in unix systems means you can make that directory your current directory (cd to it). It has nothing to do with executing (execution of a directory is meaningless). If you remove the executable bit, nobody will be able to 'cd' to it.
If nothing else, I would remove the executable permissions for all users (if not owner and group as well). With this enabled, someone could upload a file that looks like a picture but is really an executable, which might cause no end of damage.
Possibly remove the read and write permissions for all users as well and restrict it to just owner and group, unless you need anonymous access.
You do not want the executable bit on. As far as *nix goes, the executable bit means you can actually run the file. So, for example, php scripts can be uploaded as type JPEG, and then someone can run that script if they know the location and it's within the web directory.