☰

限制 Apache 用户的推荐方法

tag-icon • tag-icon linux apache-2.2 security
限制 Apache 用户的推荐方法

继为什么我们应该限制 Apache 用户，又出现了两个问题：

  1. 限制 Apache 用户可以遍历和读取文件系统的位置的推荐方法是什么？
  2. 如何应对 fork 炸弹和其他 shell 脚本问题？（允许使用 bash 脚本）

我可能的解决方案（我更想知道您选择哪种解决方案以及原因）：

  1. chroot 或 mod_chroot
  2. 禁用 bash 或使用受限 BASH

如果您认为合适，请提供其他解决方案。（也许是 selinux？）

当前状态：

  • 允许用户执行 bash 脚本（例如通过 PHP）
  • suexec 处于活动状态
  • Apache 请求由 PHP 的 FastCGI 提供

编辑：

抱歉，我还没有提供赏金。我需要知道的最后一件事是关于问题 #2：当允许通过 PHP 编写 bash 脚本时，我该如何保护我的系统免受攻击（fork 炸弹、读取敏感数据）？SELinux/Apparmor 可以防御这些攻击吗？

答案1

SELinux或者装甲是实现真正高水平安全性的严肃方法，而且不仅适用于 Web 应用程序。虽然它们并不简单，但许多现代发行版已做了很多工作来集成它们，Redhat/SELinux 和 Ubuntu/Apparmour（后者被认为“更易于”维护）。

如果您想要非常认真地考虑安全性问题，我建议您尽快开始！

答案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 策略以保护系统文件免受非管理员用户的攻击等）。

相关内容