On the other hand, mod_php delivers excellent performance with a low memory footprint. Because the same process serves multiple sites, the PHP process does not have to be started each time. This results in a considerable performance improvement over CGI/ suPHP. Also, because it is reusing the same process over and over, it is compatible with opcode cache such as APC.
Due to each process serving multiple sites, memory leaks and other problems in PHP and its components, this can result in the process growing in size, never freeing up memory, and consequently dying. In such cases, it is very hard to detect which site or component is causing the issue.
mod_php + mod_ruid2
RUID2 tries to address the security issue with mod_hostinglimits by making sure that the process runs under the correct user permissions. RUID2 grants Apache processes with the ability to switch their user ID via Linux capabilities. It is very careful not to let the process become root and keeps the process as safe as possible. Otherwise, it is the same as mod_php.
This approach has architectural level security issues. Attackers can use the arbitrary code execution vulnerability found in mod_php or one of its components (or in Apache, for that matter) to attack every website on the server by switching between them.
Additionally, RUID2 suffers the same stability issue as plain mod_php. The same process is reused for multiple sites and requests. However, it does deliver performance similar to mod_php and is fully compatible with opcode caching.
mod_php + MPM_ITK
MPM ITK is a patch for Apache that makes each request be served using the correct user (as defined on the VirtualHost level). After a request is served, the Apache process is killed. This allows the use of mod_php in what seems to be a secure way. It also improves stability over mod_php or mod_php + mod_ruid2 because memory leaks get cleaned up after each request.
The performance for serving PHP files is pretty good, but because the process is terminated after each request, the performance for static files is dreadful. To overcome that, MPM ITK is usually used in combination with a caching reverse proxy, such as NGINX or Varnish.
Another benefit of MPM ITK is its compatibility with opcode caching because all processes are forked from the same Apache “master” process.
From a security standpoint, however, MPM ITK is dangerous. Apache is started and runs as root until the request comes in and gets parsed, and then the virtual host configuration is determined. If there is any vulnerability in this process, the attacker will get root access to the server.
On the other hand, as soon as Apache drops permissions to the unprivileged user level, the server is in the green given that vulnerabilities in PHP or its extensions would provide the attacker access to the vulnerable site only.
027
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68