Hello-
A couple of days ago I was having trouble with hackers on my drupal installation. The reason for the trouble was that my /public_html/files folder permissions was set to 777. I know, stupid. I set them to 755, but the file became unwritable by Drupal.
Looking this up here, I don't see an adequate answer to this problem.
I changed the ftp settings to disallow anonymous ftp and switch the permissions on /files back to 777 so that my users could write to it. I switched back and forth between permissions when I could, but that is impracticle.
Now I have files that aren't mine in that folder again. It looks like spammer stuff.
How can I solve this problem, making the /files folder both secure and writable? Can someone point me in the right direction.
Comments
it's a problem
This is a problem I've worried about as well that I think the core developers and documentation team should do more about. is it a shared host? some people think this is okay on a dedicated server.
writable isn't secure
Depending on your webhosts configuration, there is probably nothing you can do if you want to secure a directory that the webserver can write files into.
The only way to do that is if the webserver switches the user account it runs under to your user account - this is up to the webhost. When the same webserver user account (eg nobody or www-data etc) is used for all sites there is no difference to the filesystem between your own Drupal actions and the actions of other websites. It is the same user account.
But its not clear how they are writing to your directory. Can you see the ownership of these files? That should tell you whether its the web server writing them or another user of the server.
Are the spammers just uploading stuff through your Drupal instance? If so you'll need to prevent them using Drupal.
Or are they using someone elses website to write stuff there. If you use private downloads properly they won't be able to use those files without having valid Drupal accounts - unless you let anonymous users download stuff.
Are you up to date with all your Drupal patches?
It can be very difficult to set up something securely on a shared webhost if your own site needs to write to files.
One thing that may or may not work, is making your directory 766. Removing the executable bit from a directory stops its contents being listed. But that will only really stop the stupidest people, and for it to work you might need to set that on your public_html directory also which might break other stuff in Drupal.
If these files are owned by another user (not the webserver), you have some options. First tell your webhost about it. Then you could ask your webhost to change the group ownership of the files directory to the web server group (this step needs root access). After that you could set the permissions on the files directory to 770, and that should shut out those other users. Note: this approach won't work if it is the web server that is writing the files.
The only way to trust your security is with a dedicated (or virtual) server.
There is some background info here: http://drupal.org/node/34022
You're probably even more confused now eh? ;)
--
Anton
No, I'm getting it
No I'm getting it and I can see why people spend the big bucks for the dedicated server.
I've contacted my hosting company with the same problem and we'll see where i get with them, though I am not optimistic. I will mention a few of the options you described.
i guess i would have to wonder how many drupal users have dedicated servers. Is it enough not to have written this in a different way? It seems awfully short-sighted.
My other thought is: Does this pose a real risk to leave it at 777? I left it like that for ages when I was with 4.5.2. There was a lot of detritus, but nothing really bad.
Finally, how could I tell if this was coming from a Drupal user? There is no evidence of it through watchdog. Does that settle it? And what do you mean by private downloading?
Thanks
_____________________
Visit
http://www.localghost.org
Education As Intellectual Self-Defense
security
There is really no other way of writing it from Drupals point of view. This stuff all happens at the webserver and filesystem level.
If all sites run as the same operating system user account, the operating system has no way of telling them apart - short of somehow writing a filesystem that understood PHP sessions.
There are ways of configuring Apache and PHP with extra webserver modules to switch the webserver account to the account that owns the files it is accessing. But this is up to the server admin not the individual webmasters.
Switching the user account increases your protection on a shared host against access by other sites, but conversely decreases protection against someone exploiting your own site. This is preferable on a shared server though - at least the security is in your hands not everyone elses.
Well it depends on your level of comfort. How important are your files? How important is your disk space? How important is your traffic allowance? Would you want someone replacing a file with one infected with a trojan? Would your users appreciate that? Would you want someone putting child porn there? It's up to you really.
Probably unlikely that its through Drupal. You might want to ask you webhost for help in tracking down the insecure site or nefarious user based on timestamps, user ids and server logs. They might not be willing to go to that much trouble though.
Drupal can do public or private downloads. Public downloads use a publically accessible files directory and the files are just served up by Apache through direct HTTP requests. Private downloads are when you move the files directory outside the web root, and files get accessed through the Drupal system module - that way Drupal can control who gets access to what. There is an /admin/settings setting for this.
--
Anton
'777' for public folders is
'777' for public folders is the way most Web software runs on shared hosts. Secure or not, it is the standard way.
At times I have tried some tricks myself to make the permissions of the 'files' folders '755' by using a php script to make 'apache' the owner of these directories, but this is not much safer. If someone has got access to a user account on the server he can run a similar script to have 'apache' write files for him.
Drupal's 'private' file storage method, which stores your files somewhere outside your web directory and they cannot be accessed at all from the Web, has the same security issues as the 'public' one if an intruder gets into the server. If Drupal can tell 'apache' to write files there, an intruder can too.
I think the 'private' method is mostly a defence against direct linking to your files, but it does have a practical advantage for security; those files that you found planted are usually intended for spoofing and other kinds of Web mischief. If the directory is not accessible from the Web it is useless to them because their victims won't be able to access it, so they don't have any reason to go there.
Since I ran out of horror stories, I'll just repeat that this is the normal way Web software runs on shared hosts and it is reasonably safe for most people. Be clean, bug your Web host, ask him to check his logs and do his part of the job, not much else.
I'm on it
I'm on it
Thanks guys
_____________________
Visit
http://www.localghost.org
Education As Intellectual Self-Defense