![限制 Apache 用户的推荐方法](https://linux22.com/image/538378/%E9%99%90%E5%88%B6%20Apache%20%E7%94%A8%E6%88%B7%E7%9A%84%E6%8E%A8%E8%8D%90%E6%96%B9%E6%B3%95.png)
继为什么我们应该限制 Apache 用户,又出现了两个问题:
- 限制 Apache 用户可以遍历和读取文件系统的位置的推荐方法是什么?
- 如何应对 fork 炸弹和其他 shell 脚本问题?(允许使用 bash 脚本)
我可能的解决方案(我更想知道您选择哪种解决方案以及原因):
- chroot 或 mod_chroot
- 禁用 bash 或使用受限 BASH
如果您认为合适,请提供其他解决方案。(也许是 selinux?)
当前状态:
- 允许用户执行 bash 脚本(例如通过 PHP)
- suexec 处于活动状态
- Apache 请求由 PHP 的 FastCGI 提供
编辑:
抱歉,我还没有提供赏金。我需要知道的最后一件事是关于问题 #2:当允许通过 PHP 编写 bash 脚本时,我该如何保护我的系统免受攻击(fork 炸弹、读取敏感数据)?SELinux/Apparmor 可以防御这些攻击吗?
答案1
答案2
使用suexec
,将 PHP 作为 FastCGI 服务运行(也许使用safe_mode
和open_basedir
但这些将来会被弃用)。由于 ,它们suexec
不应被允许进入其他目录,假设每个网站都有自己的专用用户,user1
例如/var/www/www.website1.com/
和。user2
/var/www/www.website2.com/
修改您的/etc/fstab
以不允许执行文件/tmp
。
如果真的偏执,您可以一起禁用 CGI/FastCGI,并设置 Apache 来代理您的软件的独立应用程序(Ruby on Rails 应用程序、Catalyst 应用程序等)。这些应用程序依次由其各自的用户执行。
答案3
当前的趋势只是运行轻量级虚拟化(openvz、lxc 等)并在系统中分离客户。
这并不能让您 100% 分离资源,但大大降低了多个客户之间共享资源所带来的风险。
一般来说,共享主机==共享安全,可以肯定有人会滥用它,不管你如何努力地强化它;)
答案4
为了确保 apache 生成的 CGI 以拥有它们的用户身份运行,我依赖于苏普;它不仅限于 PHP,可以使用任何解释器处理任意 CGI,并提供相对可控的环境来执行它们。一旦您确定用户可以使用其非特权帐户进行操作,接下来就是像平常一样保护系统免受具有登录权限的用户的攻击(每个用户的进程和内存限制、SELinux 策略以保护系统文件免受非管理员用户的攻击等)。