![拥有自己的服务器,多个网站:最安全的 PHP 设置](https://linux22.com/image/534542/%E6%8B%A5%E6%9C%89%E8%87%AA%E5%B7%B1%E7%9A%84%E6%9C%8D%E5%8A%A1%E5%99%A8%EF%BC%8C%E5%A4%9A%E4%B8%AA%E7%BD%91%E7%AB%99%EF%BC%9A%E6%9C%80%E5%AE%89%E5%85%A8%E7%9A%84%20PHP%20%E8%AE%BE%E7%BD%AE.png)
我们拥有一个公司服务器,上面有各种网站。这些网站由我们公司内部的不同人员维护。所有网站都是公开的。服务器访问权限仅限于我们公司。这不是共享托管环境。
我们正在研究如何保护服务器,目前正在分析与文件权限相关的风险。我们认为风险最高的是文件上传后被公众打开/执行的情况。这种情况不应该发生,但脚本中的错误可能会允许人们这样做(有图片上传器、文件上传器等)。上传器脚本使用 PHP。
所以问题是:设置/组织文件和进程权限的最佳方法是什么?似乎有几种选项可以运行 PHP(和 Apache)并设置权限。我们应该考虑什么?有什么建议吗?
我们正在考虑 mod_php 和 FastCGI,但考虑到我们的情况,也许我们更喜欢其他解决方案?
答案1
我强烈建议跑步苏普。使用 suPHP,每个网站都可以划分为自己的用户名,而不是以一般 Apache 用户的身份运行。这意味着,如果有人碰巧因为服务器上的不安全脚本而“入侵”服务器;他们只能访问该网站,而不是整个服务器。例外情况是,如果存在 root 漏洞,他们就可以访问整个服务器……但至少 suPHP 将有助于保护每个单独网站的安全。
一旦你在不同的用户上拥有 Apache/PHP,服务器上文件的读/写权限就变得很重要。你也可以从组织的角度更充分地利用权限,允许用户更新服务器上的文件他们的网站,而不仅仅是任何一个。
答案2
另外两个安全性不同的选项:
Apache 上的 suexec。Apache 可能会占用内存。(并且我认为它不适用于 fcgi)
虚拟设备,每个站点一个。此解决方案当然提供了有关 php 版本等方面的最大自由度。(我运行 openvz 非常成功。)
问候,/t
答案3
/var/tmp
上传内容默认存储在,因此请将其挂载为,+noexec +nosuid
并使用以下配置VirtualHost
Apachephp_flag engine 0
(参考:PHP 手册)对于包含上传文件的目录(如果你必须接受文件上传 - 否则,请file_uploads 0
设置php.ini
)设置
allow_url_fopen 0
好php.ini
(以防万一你的某个程序员想到了包含 URL 的好主意)并考虑苏霍辛如果你的员工中有可疑的编码员
答案4
这绝对不应该发生——如果你是这个网站的管理员这是你的错
我们正在考虑 mod_php 和 FastCGI,
这是与问题无关您目前拥有什么,也不知道如何确保系统安全。
您首先需要的是权限模型和流程,以受控的方式支持将代码部署到服务器。
一种方法是为每个项目设置一个排除 Web 服务器 uid 的组,然后将所有文件部署为用户和开发组的 rw-rw-r - Web 服务器依靠“其他”权限来读取文件。设置所有目录并设置组粘性位。
每个项目都应位于文档根目录内的自己的子目录中,并且每个项目都应有一个可由文档根目录外的 Web 服务器 uid 写入的上传目录,并且文档根目录外至少有一个专用的(每个组)包含目录(最好每个都位于自己的虚拟主机上)。访问应受 open_basedir 限制
发布一个编码标准,该标准应指定不能从标准设置中操纵权限 - 并调整您的 IDS 以获取任何添加的 PHP 文件或更改的权限。
但还有其他模型。
重要的是:
网络服务器永远不应该能够写入可通过网络服务器直接访问的文件。
如果要访问用户上传的内容,则应在上传时彻底清理,并通过控制器脚本介导访问。
如果服务器上部署了恶意代码,则应严格限制其造成的损害程度
应该能够检测系统上代码的更改时间
您的权限模型应该防止一个项目干扰另一个项目的行为(例如,假设您有一个通用的“包含”目录 - 即使不同的项目不能修改其他文件,它们也可以通过在包含路径的其他地方使用相同的文件名来掩盖行为 - 或者更糟糕的是,通过两次使用相同的函数或类名来创建错误)。