|
Hi, I've had a couple of attacks on my account where the intruder appears to have gained access through one of my Web apps, then inserted malicious code into the php code of all of the Web apps in my account. I'm now in the process of rebuilding the sites I look after, and trying to be more careful this time how I set things up so this doesn't happen again. I was wondering if it's possible to use file ownership and permissions to insulate apps from each other so access to one doesn't give access to all of them? Does the apache process always serve files using the same user id? Also, could you give me some idea of how your control panel sets up the apache vhosts which serve php / cgi webapps? In particular what the default directory access directives are set to? This would help me decide whether I need extra htaccess directives for each app, to limit the files which can be reached from a break in on that app. asked 30 Aug '14, 01:42 highfellow |
|
The community post Installing a private instance of the shared apache should answer all your questions and give you steps to implement the solution you are after. answered 30 Aug '14, 11:42 aaront ♦♦ Thanks for the information. I've read through this, and I'm wondering whether it entirely solves the problem, as CGI programs in different web apps will still be running as the same user. Hence there is still a risk that malicious code which has been added to one app could be used to infect another. I have been thinking about whether its worth using the suexec and/or chroot directives of apache to avoid this. In principle, a setup where the cgi programs for each app run as a different user should be more secure, but this would be more effort to set up and possibly overkill. In your experience, would you say I'm likely to be safe enough just using a private apache instance under a single user, or is it worth the extra time and complication to use suexec / chroot? My sites are: - a few simple wordpress sites for myself and other people. - a personal wiki using dokuwiki. - a larger site using drupal which I'm in the process of developing. This one in particular needs to be set up as securely as possible, as it is a public multiuser site.
(29 Sep '14, 08:01)
highfellow
Incidentally, have you considered adding an option to the control panel whereby users can specify for a given website what ssh user the CGI scripts should run as? This would allow people to set things up much more securely by default.
(29 Sep '14, 09:25)
highfellow
I'm pretty sure that you can't use suexec and chroot on our system, since you need to start Apache as root in order to do so. So, really a private apache instance for each user that you want to isolate is the only way to go at this time.
That is something that is under consideration, but I'm unable to say when, or even if, it will be available.
(29 Sep '14, 15:16)
seanf
I have done some more research and it looks like chroot needs root privs, but suexec works via a setuid root wrapper program. On your system, this is (sensibly) limited to use by the apache group, so I wouldn't be able to use it. I think I'll just set up a single apache instance for all my apps, and try to get the permissions right to give as much protection as possible.
(01 Oct '14, 01:17)
highfellow
I'm a bit unclear what you mean by "CGI programs in different web apps will still be running as the same user". No, they won't. When you create a private instance of the shared apache under a separate SSH user, it runs as that SSH user. Nginx
(01 Oct '14, 02:18)
ryans ♦♦
I was talking about the situation where you have a single private apache instance for all the sites. I understand that you can have as many instances as you like, which would fully insulate the apps from each other, but this seems like overkill in terms of complexity and resource use. I was hoping for a solution where I could run a single apache instance but still run each cgi app as a different user. It looks like this is impossible though without running apache as root.
(01 Oct '14, 12:30)
highfellow
showing 5 of 6
show 1 more comments
|
