在 Linux 上沙箱 Apache 的最佳方法
我在面向公众的 Debian 服务器上运行 Apache，并且有点担心安装的安全性。 这是一台托管多个业余爱好项目的机器，因此使用该机器的我们没有人真正有时间不断地监视上游补丁，了解安全问题等。但我想将坏人拒之门外，或者如果他们进来了，就把他们放在沙箱里。
那么最好的、易于设置、易于维护的解决方案是什么？ 在 Debian 上设置用户模式 Linux 沙箱容易吗？ 或者也许是 chroot 监狱？ 我希望能够从外部轻松访问 Sadbox 内的文件。 这是我非常清楚我是一名程序员，而不是系统管理员的时刻之一。 任何帮助将非常感激！
I have Apache running on a public-facing Debian server, and am a bit worried about the security of the installation. This is a machine that hosts several free-time hobby projects, so none of us who use the machine really have the time to constantly watch for upstream patches, stay aware of security issues, etc. But I would like to keep the bad guys out, or if they get in, keep them in a sandbox.
So what's the best, easy to set up, easy to maintain solution here? Is it easy to set up a user-mode linux sandbox on Debian? Or maybe a chroot jail? I'd like to have easy access to files inside the sadbox from the outside. This is one of those times where it becomes very clear to me that I'm a programmer, not a sysadmin. Any help would be much appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
当您运行完整的沙箱环境时，Chroot Jail 可能非常不安全。 攻击者可以完全访问内核功能，例如可以安装驱动器来访问“主机”系统。
我建议您使用 linux-vserver。 您可以将 linux-vserver 视为改进的 chroot 监狱，内部有完整的 debian 安装。 它非常快，因为它在一个内核中运行，并且所有代码都是本机执行的。
我个人使用 linux-vserver 来分离我的所有服务，并且几乎没有明显的性能差异。
请查看 linux-vserver wiki 以获取安装说明。
问候，丹尼斯
Chroot jails can be really insecure when you are running a complete sandbox environment. Attackers have complete access to kernel functionality and for example may mount drives to access the "host" system.
I would suggest that you use linux-vserver. You can see linux-vserver as an improved chroot jail with a complete debian installation inside. It is really fast since it is running within one single kernel, and all code is executed natively.
I personally use linux-vserver for seperation of all my services and there are only barely noticeable performance differences.
Have a look at the linux-vserver wiki for installation instructions.
regards, Dennis
我赞同 xardias 的说法，但推荐使用 OpenVZ 。
它与 Linux-Vserver 类似，因此您在选择此路线时可能需要比较这两者。
我已经设置了一个带有代理 http 服务器 (nginx) 的 Web 服务器，然后将流量委托给不同的 OpenVZ 容器（基于在主机名或请求的路径上）。 在每个容器内，您可以设置 Apache 或任何其他 Web 服务器（例如 nginx、lighttpd、..）。
这样，您就不必使用一个 Apache 来处理所有事情，但可以为任何服务子集（例如每个项目）创建一个容器。
OpenVZ 容器可以很容易地完全更新（“for i in $(vzlist); do vzctl exec apt-get upgrade; done”）
不同容器的文件存储在硬件节点中，因此您可以通过以下方式轻松访问它们SFTP 到硬件节点。
除此之外，您可以向某些容器添加公共IP地址，在那里安装SSH，然后直接从容器访问它们。
我什至听说过 SSH 代理，因此即使在这种情况下，额外的公共 IP 地址也可能是不必要的。
I second what xardias says, but recommend OpenVZ instead.
It's similar to Linux-Vserver, so you might want to compare those two when going this route.
I've setup a webserver with a proxy http server (nginx), which then delegates traffic to different OpenVZ containers (based on hostname or requested path). Inside each container you can setup Apache or any other webserver (e.g. nginx, lighttpd, ..).
This way you don't have one Apache for everything, but could create a container for any subset of services (e.g. per project).
OpenVZ containers can quite easily get updated altogether ("for i in $(vzlist); do vzctl exec apt-get upgrade; done")
The files of the different containers are stored in the hardware node and therefore you can quite easily access them by SFTPing into the hardware node.
Apart from that you could add a public IP address to some of your containers, install SSH there and then access them directly from the container.
I've even heard from SSH proxies, so the extra public IP address might be unnecessary even in that case.
您始终可以在虚拟机内设置它并保留它的映像，以便您可以在需要时重新滚动它。 这样，服务器就从您的实际计算机中抽象出来，并且任何病毒等都包含在虚拟机内。 正如我之前所说，如果您保留图像作为备份，您可以很容易地恢复到以前的状态。
You could always set it up inside a virtual machine and keep an image of it, so you can re-roll it if need be. That way the server is abstracted from your actual computer, and any virus' or so forth are contained inside the virtual machine. As I said before, if you keep an image as a backup you can restore to your previous state quite easy.
为了确保这一点，CHRoot Jails 很少是一个好主意，尽管是有意为之，但它很容易被打破，事实上，我已经看到用户不小心这样做了！
To make sure it is said, CHRoot Jails are rarely a good idea it is, despite the intention, very easy to break out of, infact I have seen it done by users accidentally!
无意冒犯，但如果您没有时间查看安全补丁，也没有时间了解安全问题，那么无论您的设置如何，您都应该担心。 另一方面，您考虑这些问题这一事实本身就使您与其他 99.9% 的此类机器所有者区分开来。 你走在正确的道路上！
No offense, but if you don't have time to watch for security patches, and stay aware of security issues, you should be concerned, no matter what your setup. On the other hand, the mere fact that you're thinking about these issues sets you apart from the other 99.9% of owners of such machines. You're on the right path!
我发现令人惊讶的是没有人提到 mod_chroot 和 suEXEC，这是您应该开始的基本内容，而且很可能是您唯一需要的内容。
I find it astonishing that nobody mentioned mod_chroot and suEXEC, which are the basic things you should start with, and, most likely the only things you need.
您应该使用 SELinux。 我不知道 Debian 对它的支持情况如何； 如果不是，只需在虚拟机中安装启用了 SELinux 的 Centos 5.2 即可。 不应该做太多工作，而且比任何业余 chroot 安全得多，后者并不像大多数人认为的那么安全。
SELinux 因难以管理而闻名，但如果您只是运行网络服务器，那应该不是问题。 您可能只需要执行一些“sebool”即可让 httpd 连接到数据库，但仅此而已。
You should use SELinux. I don't know how well it's supported on Debian; if it's not, just install a Centos 5.2 with SELinux enabled in a VM. Shouldn't be too much work, and much much safer than any amateur chrooting, which is not as safe as most people believe.
SELinux has a reputation for being difficult to admin, but if you're just running a webserver, that shouldn't be an issue. You might just have to do a few "sebool" to let httpd connect to the DB, but that's about it.
虽然以上所有都是很好的建议，但我还建议添加 iptables 规则以禁止意外的传出网络连接。 由于大多数自动化网络攻击所做的第一件事就是下载其余的有效负载，因此阻止网络连接可能会减慢攻击者的速度。
可以使用与这些类似的一些规则（请注意，您的网络服务器可能需要访问其他协议）：
iptables --append OUTPUT -m 所有者 --uid-owner apache -m 状态 --state 已建立，相关 --jump 接受
iptables --append OUTPUT -m 所有者 --uid-owner apache --协议 udp --destination-port 53 --jump ACCEPT
iptables --append OUTPUT -m 所有者 --uid-owner apache --jump REJECT
While all of the above are good suggestions, I also suggest adding a iptables rule to disallow unexpected outgoing network connections. Since the first thing most automated web exploits do is download the rest of their payload, preventing the network connection can slow the attacker down.
Some rules similar to these can be used (Beware, your webserver may need access to other protocols):
iptables --append OUTPUT -m owner --uid-owner apache -m state --state ESTABLISHED,RELATED --jump ACCEPT
iptables --append OUTPUT -m owner --uid-owner apache --protocol udp --destination-port 53 --jump ACCEPT
iptables --append OUTPUT -m owner --uid-owner apache --jump REJECT
如果使用 Debian，debootstrap 与 QEMU、Xen、OpenVZ、Lguest 或大量其他工具结合起来是您的朋友。
If using Debian, debootstrap is your friend coupled with QEMU, Xen, OpenVZ, Lguest or a plethora of others.
制作一个虚拟机。 尝试 vmware 或 qemu 之类的东西
Make a virtual machine. try something like vmware or qemu
你真正想解决什么问题？ 如果您关心该服务器上的内容，则需要防止入侵者进入其中。 如果您关心入侵者会对您的服务器执行什么操作，则需要限制服务器本身的功能。
这些问题都无法通过虚拟化来解决，而不会对服务器本身造成严重损害。 我认为您问题的真正答案是：
What problem are you really trying to solve? If you care about what's on that server, you need to prevent intruders from getting into it. If you care about what intruders would do with your server, you need to restrict the capabilities of the server itself.
Neither of these problems could be solved with virtualization, without severly criplling the server itself. I think the real answer to your problem is this: