linux中国_ 发布的文章

开源法规对成功有不同寻常的要求。一起来了解开源组织的律师如何帮助其雇主找到可行路径。

正如我在这个分为两部分的系列文章的第一部分中所分享的那样,我是 红帽公司 ( Red Hat ) 的一名开源律师。我工作中的一个重要部分是向其他公司(包括其内部法律顾问)提供有关红帽公司如何采用完全开源的开发模式来构建企业级产品的信息,并回答他们有关开源许可的一般问题。在听了红帽公司的成功经验之后,这些律师与我对话的话题常常转变为其所在组织如何发展成为更具开源意识和能力的组织,他们也经常询问我如何改善他们的做法,以便更熟练地为其组织的雇员提供开源法律咨询。在这两篇文章中,我将分享我通常在这些主题上告诉内部法律顾问的那些内容。

总是要找到一条可行路径

我的雇主红帽公司在使用开源软件方面的独特之处在于,我们的开发模式始于具有数千名贡献者的开源社区,并产生了经受过尝试、测试和信任的最终产品。更具体地说,通过我们独特的开发模式,我们从社区创建的开源软件开始,并在每个项目的基础上加强安全性,修复错误,修补漏洞并添加新功能。然后,我们将这些改进回馈给每个项目,以便使整个开源社区受益。此方法的效用非常重要,包括:

  1. 通过内部团队与组织外部其他人之间的协作来利用外部创新;
  2. 当现有或潜在的社区与您在同一问题上开展工作而且能够合作时,可以避免您自己开发和维护开源解决方案的成本和效率低下的问题;
  3. 通过与合作伙伴和上游项目社区的富有成效的合作,能够避免维护主项目下游分支的昂贵代价。

    • 一些公司发现创建上游代码的非公共分支很诱人,因为它是解决特定 用例 use case 的快速方法,或者因为它们不愿意在社区中进行协作。然而,由于增加的开发成本、互操作性损失和其他原因,这种分支的长期维护负担可能是令人望而却步的。相比之下,将开发集中在原始上游社区中,可以在所有参与者之间分担开发成本。

除少数例外(例如红帽公司)外,大多数使用开源软件的组织可能都拥有专有软件许可模式(或与 SaaS 等效的概念),并在其业务中对专有软件进行许可。这些组织认为他们拥有可以提供某些竞争优势的软件组件,并且不希望看到这些组件在开源条款下对其他人可用。这是可以理解的。但是,我会鼓励任何咨询此类问题的开源律师来敦促其客户采用开源开发模式,尤其是对于所有无差异且通用的软件。

例如,如果您的公司开发了用于手机的应用程序,并且您需要一个软件模块来读取和写入 PNG 图像文件,那么使用 GitHub 上流行的开源 PNG 软件模块之一将便宜得多。对于您的业务而言,对 PNG 图像进行编码和解码可能是无差别的,那么为什么要花费宝贵的工程时间来编写自己的版本?此外,为此功能编写自己的模块也可能会导致与使用常用开源模块的其他软件的兼容性问题。这是为什么呢?尽管您的模块和开源模块可能已被编写为对已发布的 PNG 规范进行编码和解码,但有时对规范的解释可能会有所不同,也可能会出现实施错误。使用同一模块执行此功能的每个人都可以确保大多数用户的兼容性,并降低开发和维护成本。

还必须意识到,您可能需要某些软件来保持专有性,并且不受开源条款的约束。取决于您系统的软件体系架构和所使用的开源许可证,除非采取某些措施(超出本文的范围),否则打算保留专有权的软件代码可能会受到开源许可证条款的约束。在这里向客户提供一些有关许可证选择和体系架构的咨询服务将变得很有用。

寻找灵活的解决方案

之前主要许可专有软件的组织逐渐增加了对开源软件的使用,但审核和批准的要求可能会增长(以我的经验甚至成倍增长)。由于资源限制,这样的组织可能会陷入困境。下面介绍了一些可以采用的灵活的解决方案。

授权并委托他人

律师不能也不应成为看门人。那样效率低下,并且肯定会导致开发和发布时间出现瓶颈,从而产生挫败感和收入损失。相反,应将审批权限授予产品或项目管理和工程领域有能力的个人。这可以让组织有效地保持灵活性。对客户进行教育(请参阅下一节)对于成功实现这一点至关重要。

我采用的一种方法是为整个工程组织提供开源培训,以便他们可以进行基本的许可模式和体系架构选择,同时为软件开发人员提供更专业的培训,以使他们能够提供更复杂的指导和决策。也要考虑在每个级别上对权限进行明确限制,包括哪些类型的问题和决定必须上报给作为他们开源律师的您。您组织的特定授权级别将取决于您团队在开源方面的经验以及对某些开源问题的敏感性。

教育客户

我发现培训是将您的组织迁移到更具开源意识组织的最有效工具之一。培训您的软件工程师和产品经理至关重要。让我详细说明。

尽管您的软件工程师处在最前沿,并且通常可能对开源问题和软件许可非常了解,但是基于您组织的特定要求对他们进行培训仍然很重要。例如,您的公司可能只允许使用宽松的开源许可证,并且可能对其版权声明和源代码可用性有某些要求。为避免开发中出现随后必须纠正的问题(一种昂贵且耗时的实践),最好培训工程师最大程度地减少不当行为的可能性,尤其是在所有开发过程的开始时(请参阅下一节)。

产品经理也必须接受培训。在许多公司中,产品经理负责营销的经典四个环节(产品、价格、定位和促销),并负责产品从生到死的整个生命周期。产品经理工作的方方面面可能会受到使用开源软件的影响。出于上述相同的原因,了解使用开源软件的要求对他们很有用。此外,更重要的是,产品经理在组织中的重要影响,意味着他们通常能够对流程和政策进行必要的更改。产品经理可能会成为您针对“开放”进行流程变更的最强有力的拥护者之一。

早期发现

在开发过程快要结束时解决开源许可问题非常困难且成本很高。随着软件的发布日期临近,体系架构和开源软件模块都是已经选定且难以更改了。如果检测到问题,例如专有软件模块中嵌入的“左版”(copyleft)软件(当该专有模块无意受开源条款约束时),则在该开发阶段修改体系架构或模块可能非常困难且成本昂贵。相反,应该在开发过程中尽早进行架构分析和开源模块选择的过程,以便可以进行成本更低且更有效的更正。

开源法规的“奖励”

实践开源法规是一项有益的职业,因为它具有影响组织朝着“开放”方向发展的能力,这具有很大的好处。是否成功取决于您随着组织的成长和成熟而找到具备可行性和灵活性的解决方案的能力。


作者简介:Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 红帽公司 ( Red Hat ) 开源法务团队的资深商务法律顾问,还担任 北卡罗来纳大学 ( University of North Carolina ) 的兼职法律教授。在任职红帽公司之前,Jeffrey 曾担任 高通公司 ( Qualcomm ) 的专利和开源法律顾问。

译者简介:薛亮,集慧智佳知识产权咨询公司互联网事业部总监,擅长专利分析、专利布局、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。

简介

Red Hat Enterprise Linux 是 Red Hat 公司的 Linux 发行版,面向商业市场,包括大型机。红帽公司从 Red Hat Enterprise Linux 5 开始对企业版 Linux 的每个版本提供 10 年的支持。而 Red Hat Enterprise Linux 常简称为 RHEL。

Red Hat Enterprise Linux 大约 3 年发布一个新版本。

下载

RHEL 是商业版本,并不提供免费下载和使用。需要购买 Red Hat 公司的商业服务才能合法取得,并得到商业支持。

可以使用 RHEL 的开源衍生版本来取得除了商业支持之外一样的软件,比如:CentOS。

安装

发行

最初,Red Hat Enterprise Linux 基于 Red Hat Linux,但使用较为保守的发布周期。后来版本都是基于 Fedora。大约每六个版本的 Fedora 会有一个新版本的 Red Hat Enterprise Linux 发布,因此:

  • Red Hat Linux 6.2 → Red Hat Linux 6.2E
  • Red Hat Linux 7.2 → Red Hat Enterprise Linux 2.1
  • Red Hat Linux 9 → Red Hat Enterprise Linux 3
  • Fedora Core 3 → Red Hat Enterprise Linux 4
  • Fedora Core 6 → Red Hat Enterprise Linux 5
  • Fedora 12 → Red Hat Enterprise Linux 6
  • Fedora 19 → Red Hat Enterprise Linux 7

当前版本

  • Red Hat Enterprise Linux 当前的最新版本是 7.4。
  • Red Hat Enterprise Linux 7 当前仅支持 64 位CPU:64-bit AMD、64-bit Intel、IBM POWER7 和 POWER8、IBM System z。可以将32位操作系统作为虚拟机运行,包括之前的RHEL版本。
  • 包含 Kernel 3.10 版本,支持 swap 内存压缩可保证显著减少 I/O 并提高性能,采用 NUMA (统一内存访问) 的调度和内存分配,支持 APIC (高级程序中断控制器) 虚拟化,全面的 DynTick 支持,将内核模块列入 黑名单,kpatch 动态内核补丁 (技术预览) 等等。
  • 存储和文件系统方面,RHEL 7.0 使用 LIO 内核目标子系统,支持快速设备为较慢的块设备提供缓存,引进了 LVM 缓存 (技术预览),将 XFS 作 为默认的文件系统。
  • 引进网络分组技术作为链路聚集的捆绑备用方法,对 NetworkManager 进行大量改进,提供动态防火墙守护进程 firewalld,加入 DNSSEC 域名系统安全扩展,附带 OpenLMI 用来管理 Linux 系统提供常用的基础 设施,引进了可信网络连接功能 (技术预览)等。
  • 对 KVM (基于内核的虚拟化) 提供了大量改进,诸如使用 virtio-blk-data-plane 提高快 I/O性能 (技术预览),支持 PCI 桥接,QEMU 沙箱,多队列 NIC, USB 3.0 支持 (技术预览) 等。
  • 引入 Linux 容器 Docker。
  • 编译工具链方面,RHEL 7.0 包含 GCC 4.8.x、glibc 2.17、GDB 7.6.1。
  • 包含 Ruby 2.0.0、Python 2.7.5、Java 7 等编程语言。
  • 包含 Apache 2.4、MariaDB 5.5、PostgreSQL 9.2 等。
  • 在系统和服务上,RHEL 7.0 使用 systemd 替换了 SysV。
  • 引入 Pacemaker 集群管理器,同时使用 keepalived 和 HAProxy 替换了负载均衡程序 Piranha。
  • 此外,还对安装程序 Anaconda 进行了重新设计和增强,并使用 引导装载程序 GRUB 2。

历史

派生版本

派生版本有 CentOS,Scientific Linux 及 Oracle Linux 等。

各版本比较:

免费下载免费使用技术支持 (商业)
RHEL否否付费
CentOS是是不提供
Scientific Linux是是不提供
Oracle Linux要求简单登记是付费

注:部分资料来自维基百科。

2016 年 12 月 12 日, CentOS 维护人员 Karanbir Singh 高兴的宣布,期待已久的基于 Red Hat Enterprise Linux 的 CentOS Linux 7 (1611) 系统发布。

简介

CentOS(Community Enterprise Operating System)是Linux发布版之一,它是来自于Red Hat Enterprise Linux依照开放源代码规定发布的源代码所编译而成。由于出自同样的源代码,因此有些要求高度稳定性的服务器以CentOS替代商业版的Red Hat Enterprise Linux使用。两者的不同,在于CentOS并不包含封闭源代码软件。CentOS 完全遵守 Red Hat 的再发行政策,并且致力与上游产品在功能上完全兼容。CentOS 对组件的修改主要是去除 Red Hat 的商标及美工图。

下载

CentOS 从 7 开始,和 RHEL 7 一样都只支持 64 位架构。

DVD ISO

  • Intel & AMD/ 兼容 PC 64 位 4GB ISO 镜像,适用于 64-bit 位 PC ,点此下载

Everything ISO

  • Intel & AMD/ 兼容 PC 64 位 8GB ISO 镜像,适用于 64-bit 位 PC ,点此下载

CentOS 6

由于 CentOS 7 采用了一系列 systemd 相关的技术,因此还有相当多的产品环境的 Linux 服务器依旧使用 CentOS 6。

  • Intel & AMD/ 兼容 PC 64 位 ISO 镜像,适用于 64-bit 位 PC ,DVD 1,DVD 2
  • Intel & AMD/ 兼容 PC 32 位 ISO 镜像,适用于 32-bit 位 PC ,DVD 1,DVD 2

安装

发行

从 CentOS 7 开始,CentOS版本号有三个部份,主要和次要版本号分别对应于RHEL的主要版本与更新包,并使用第三部分代表发行的时间。当前最新版本是 CentOS 7.4-1708 (基于 RHEL 7.4)。

CentOS基本上会在对应的RHEL版本推出不久之后发行。

当前版本

一如每个主要版本的首个发行本,多数组件都已作出改动及更新至较新版本。最重大的改动计有:

  • 当前仅支持64位CPU。可以将32位操作系统作为虚拟机运行,包括之前的RHEL版本。
  • 包含 Kernel 3.10 版本,支持 swap 内存压缩可保证显著减少 I/O 并提高性能,采用 NUMA (统一内存访问) 的调度和内存分配,支持 APIC (高级程序中断控制器) 虚拟化,全面的 DynTick 支持,将内核模块列入 黑名单,kpatch 动态内核补丁 (技术预览) 等等。
  • 存储和文件系统方面,使用 LIO 内核目标子系统,支持快速设备为较慢的块设备提供缓存,引进了 LVM 缓存 (技术预览),将 XFS 作 为默认的文件系统。
  • 引进网络分组技术作为链路聚集的捆绑备用方法,对 NetworkManager 进行大量改进,提供动态防火墙守护进程 firewalld,加入 DNSSEC 域名系统安全扩展,附带 OpenLMI 用来管理 Linux 系统提供常用的基础 设施,引进了可信网络连接功能 (技术预览)等。
  • 对 KVM (基于内核的虚拟化) 提供了大量改进,诸如使用 virtio-blk-data-plane 提高快 I/O性能 (技术预览),支持 PCI 桥接,QEMU 沙箱,多队列 NIC, USB 3.0 支持 (技术预览) 等。
  • 引入 Linux 容器 Docker。
  • 编译工具链方面,包含 GCC 4.8.x、glibc 2.17、GDB 7.6.1。
  • 包含 Ruby 2.0.0、Python 2.7.5、Java 7 等编程语言。
  • 包含 Apache 2.4、MariaDB 5.5、PostgreSQL 9.2 等。
  • 在系统和服务上,使用 systemd 替换了 SysV。
  • 引入 Pacemaker 集群管理器,同时使用 keepalived 和 HAProxy 替换了负载均衡程序 Piranha。
  • 此外,还对安装程序 Anaconda 进行了重新设计和增强,并使用 引导装载程序 GRUB 2。

历史

CentOS的发行历史就是RHEL的发行历史,亦步亦趋。

支持周期

CentOS 版本发布日期完全更新维护更新
32004年3月19日2006年7月20日2010年10月31日
42005年3月9日2009年3月31日2012年2月29日
52007年4月12日2014年一季度2017年3月31日
62011年7月10日2017年二季度2020年11月30日
72014年7月7日2020年四季度2024年6月30日

注:部分资料来自维基百科。

Fedora 开发团队正在非常努力的开发下一代版本 Fedora 25,这将带来最新的技术改进。

Wayland 就是一个新的技术,这个下一代显示服务器的设计目标即是替代老旧的 X.Org 服务器(即 X11)。X11 被几乎所有的 GNU/Linux 操作系统用作默认的显示服务器,但是 X11 本身有很多安全隐患,却由于种种原因而不能修复。所以,多年以来一直有呼声要求设计新的显示服务器以取代已经用了几十年的 X11 服务器,而 Wayland 就是被寄予期望的一个替代品。

Wayland 的取代过程虽然很慢,但是一直在继续。许多开源软件,比如说 GNOME 和 KDE 家族的那些软件都在积极支持新的 Wayland 显示服务器,除此之外, Enlightenment 家族和其它那些虽然不属于桌面环境家族,但也活跃开发的软件也对 Wayland 表示了支持。另外,Canonical 公司开发了一个他们自己的显示服务器,叫 Mir,也是用来替代 X11 的,不过目前只在 Ubuntu 家族取得了一定进展。

Fedora 作为 Linux 发行版界的技术先锋,总是积极地在他们的发行版中采用各种新的技术,比如 Systemd,也比如 Wayland。虽然因此带来一些负面结果——比如发布延期、稳定性和兼容性有时候不太好,但是作为一个为 RHEL 和 CentOS 趟路的发行版,似乎也无可厚非——Just for fun,新技术总是好玩的,不是么?

从 Fedora 24 开始,他们就想着在 Fedora 里面默认采用 Wayland 显示服务器,但是直到发布时,也没完全搞好,只能将这个重任放到下一个版本,即 Fedora 25 中。而在上周,Fedora Wiki 网站上发布了一篇新功能建议草案,提议 Fedora 25 的 Workstation 版本采用 Wayland 做 GNOME 桌面环境的默认显示服务器。

在该草案中说“我们将在 GNOME 中让 GDM 默认使用 Wayland。如果 Wayland 不可用(比如使用 nvidia 显卡时),代码会自动切换到 Xorg。用户可以在 /etc/gdm/custom.conf 中设置 WaylandEnable=false 来禁用 Wayland,但是不再为 GNOME 分别设置 X11 和 Wayland 两个入口菜单了。”

用户不会注意到采用不同的显示服务器的明显不同,事实上,采用 Wayland 会让应用彼此之间以及和底层系统隔离的更好。换句话说, Wayland 比 X11 更安全。

Fedora 25 目前计划将在今年的 11 月 15 日到来,当然,按照 Fedora 的“传统”,延期是一定的,现在已经延期一次了。但是,不要紧,等着等着就习惯了。在 Fedora 25 发布之前,你还可以在 Fedora 24 中使用 Wayland 显示服务器,并将你发现的问题反馈给社区,让他们可以更好的改善 Wayland 显示服务器的表现。总之,希望 Fedora 25 能给我们带来惊喜,将 Wayland 作为默认显示服务器显然会带来引导作用,必然会引领一些发行版跟进。

参考:softpedia。

如今,我们依赖于越来越多的线上服务。我们每注册一个线上服务,就要设置一个密码;如此,我们就不得不记住数以百计的密码。这样对于每个人来说,都很容易忘记密码。我将在本文中介绍 Keeweb,它是一款 Linux 密码管理器,可以为你离线或在线地安全存储所有的密码。

当谈及 Linux 密码管理器时,我们会发现有很多这样的软件。我们已经在 LinuxAndUbuntu 上讨论过像 Keepass 和 Encryptr,一个基于零知识系统的密码管理器 这样的密码管理器。Keeweb 则是另外一款我们将在本文讲解的 Linux 密码管理器。

Keeweb 可以离线或在线存储密码

Keeweb 是一款跨平台的密码管理器。它可以离线存储你所有的密码,并且能够同步到你自己的云存储服务上,例如 OneDrive、Google Drive、Dropbox 等。Keeweb 并没有它提供它自己的在线数据库来的同步你的密码。

要使用 Keeweb 连接你的线上存储服务,只需要点击界面中的“more”,然后再点击你想要使用的服务即可。

现在,Keeweb 会提示你登录到你的云盘。登录成功后,给 Keeweb 授权使用你的账户。

使用 Keeweb 存储密码

使用 Keeweb 存储你的密码是非常容易的。你可以使用一个复杂的密码加密你的密码文件。Keeweb 也允许你使用一个秘钥文件来锁定密码文件,但是我并不推荐这种方式。如果某个家伙拿到了你的秘钥文件,他只需要简单点击一下就可以解锁你的密码文件。

创建密码

想要创建一个新的密码,你只需要简单地点击 + 号,然后你就会看到所有需要填充的输入框。根据你的需要创建更多的密码记录。

搜索密码

Keeweb 拥有一个图标库,这样你就可以轻松地找到各种特定的密码记录。你可以改变图标的颜色、下载更多的图标,甚至可以直接从你的电脑中导入图标。这对于密码搜索来说,异常好使。

相似的服务的密码可以分组,这样你就可以在一个文件夹里找到它们。你也可以给密码打上标签并把它们存放在不同分类中。

主题

如果你喜欢类似于白色或者高对比度的亮色主题,你可以在“设置 > 通用 > 主题”中修改。(Keeweb)有四款可供选择的主题,其中两款为暗色,另外两款为亮色。

不喜欢 Linux 密码管理器?没问题!

我已经发表过文章介绍了另外两款 Linux 密码管理器,它们分别是 Keepass 和 Encryptr,在 Reddit 和其它社交媒体上有些关于它们的争论。有些人反对使用任何密码管理器,也有人持相反意见。在本文中,我想要澄清的是,存放密码文件是我们自己的责任。我认为像 keepass 和 Keeweb 这样的密码管理器是非常好用的,因为它们并没有自己的云来存放你的密码。这些密码管理器会创建一个文件,然后你可以将它存放在你的硬盘上,或者使用像 VeraCrypt 这样的应用给它加密。我个人不使用也不推荐使用那些将密码存储在它们自己数据库的服务。


via: http://www.linuxandubuntu.com/home/keeweb-a-linux-password-manager

译者:ChrisLeeGit 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

这是一个针对 PHP、Go、Python 等语言的 CGI 应用的漏洞。

httpoxy 是一系列影响到以 CGI 或类 CGI 方式运行的应用的漏洞名称。简单的来说,它就是一个名字空间的冲突问题。

  • RFC 3875 (CGI)中定义了从 HTTP 请求的 Proxy 头部直接填充到环境变量 HTTP_PROXY 的方式
  • HTTP_PROXY 是一个常用于配置外发代理的环境变量

这个缺陷会导致远程攻击。如果你正在运行着 PHP 或 CGI 程序,你应该马上封挡 Proxy 头部!马上! 具体做法参见下面。httpoxy 是一个服务器端 web 应用漏洞,如果你没有在服务器端部署这些代码,则不用担心。

如果我的 Web 应用存在这种漏洞会怎么样?

当一个利用了此漏洞的 HTTP 客户端发起请求时,它可以做到:

  • 通过你的 Web 应用去代理请求别的 URL
  • 直接让你的服务器打开指定的远程地址及端口
  • 浪费服务器的资源,替攻击者访问指定的资源

httpoxy 漏洞非常容易利用。希望安全人员尽快扫描该漏洞并快速修复。

哪些受到影响?

以下情况会存在安全漏洞:

  • 代码运行在 CGI 上下文中,这样 HTTP_PROXY 就会变成一个真实的或模拟的环境变量
  • 一个信任 HTTP_PROXY的 HTTP 客户端,并且支持代理功能
  • 该客户端会在请求内部发起一个 HTTP(或 HTTPS)请求

下列情形是已经发现存在该缺陷的环境:

语言环境HTTP 客户端
PHPphp-fpm mod\_phpGuzzle 4+ Artax
Pythonwsgiref.handlers.CGIHandler twisted.web.twcgi.CGIScriptrequests
Gonet/http/cginet/http

肯定还有很多我们没有确定是否存在缺陷的语言和环境。

PHP

  • 是否存在缺陷依赖于你的应用代码和 PHP 库,但是影响面看起来似乎非常广泛
  • 只要在处理用户请求的过程中使用了一个带有该缺陷的库,就可能被利用
  • 如果你使用了有该缺陷的库,该缺陷会影响任意 PHP 版本

    • 甚至会影响到替代的 PHP 运行环境,比如部署在 FastCGI 模式下的 HHVM
  • 确认影响 Guzzle、Artax 等库,可能还有很多很多的库也受影响

    • Guzzle 4.0.0rc2 及其以后版本受影响,Guzzle 3 及更低版本不受影响
    • 其它的例子还有 Composer 的 StreamContextBuilder 工具类

举个例子说,如果你在 Drupal 中使用 Guzzle 6 模块发起外发请求(比如请求一个天气 API),该模块发起的请求就存在这个 httpoxy 缺陷。

Python

  • Python 代码只有部署在 CGI 模式下才存在缺陷,一般来说,存在缺陷的代码会使用类似 wsgiref.handlers.CGIHandler 的 CGI 控制器

    • 正常方式部署的 Python web 应用不受影响(大多数人使用 WSGI 或 FastCGI,这两个不受影响),所以受到影响的 Python 应用要比 PHP 少得多
    • wsgi 不受影响,因为 os.environ 不会受到 CGI 数据污染
  • 存在缺陷的 requests 库必须信任和使用 os.environ['HTTP_PROXY'],并且不做内容检查

Go

  • Go 代码必须部署在 CGI 下才受影响。一般来说受到影响的代码会使用 net/http/cgi 包

    • 像 Python 一样,这并不是部署 Go 为一个 Web 应用的通常方式。所以受到影响的情形很少
    • 相较而言,Go 的 net/http/fcgi 包并不设置实际的环境变量,所以不受影响
  • 存在缺陷的 net/http 版本需要在外发请求中信任并使用 HTTP_PROXY ,并不做内容检查

马上修复

最好的修复方式是在他们攻击你的应用之前尽早封挡 Proxy 请求头部。这很简单,也很安全。

  • 说它安全是因为 IETF 没有定义 Proxy 请求头部,也没有列在 IANA 的消息头部注册中。这表明对该头部的使用是非标准的,甚至也不会临时用到
  • 符合标准的 HTTP 客户端和服务器绝不应该读取和发送这个头部
  • 你可以从请求中去掉这个头部或者干脆整个封挡使用它的请求
  • 你可以在上游没有发布补丁时自己来解决这个问题

    • 当 HTTP 请求进来时就检查它,这样可以一次性修复好许多存在缺陷的应用
    • 在反向代理和应用防火墙之后的应用剔除 Proxy 请求头部是安全的

如何封挡 Proxy 请求头部依赖于你的配置。最容易的办法是在你的 Web 应用防火墙上封挡该头部,或者直接在 Apache 和 Nginx 上做也行。以下是一些如何做的指导:

Nginx/FastCGI

使用如下语句封挡传递给 PHP-FPM、PHP-PM 的请求头,这个语句可以放在 fastcgi.conf 或 fastcgi\_param 中(视你使用了哪个配置文件):

fastcgi_param HTTP_PROXY "";

在 FastCGI 模式下,PHP 存在缺陷(但是大多数使用 Nginx FastCGI 的其它语言则不受影响)。

Apache

对于 Apache 受影响的具体程度,以及其它的 Apache 软件项目,比如 Tomcat ,推荐参考 Apache 软件基金会的官方公告。 以下是一些主要信息:

如果你在 Apache HTTP 服务器中使用 mod_cgi来运行 Go 或 Python 写的脚本,那么它们会受到影响(这里 HTTP_PROXY 环境变量是“真实的”)。而 mod_php 由于用于 PHP 脚本,也存在该缺陷。

如果你使用 mod\_headers 模块,你可以通过下述配置在进一步处理请求前就 unset 掉 Proxy 请求头部:

RequestHeader unset Proxy early

如果你使用 mod\_security 模块,你可以使用一个 SecRule 规则来拒绝带有 Proxy 请求头部的请求。下面是一个例子,要确保 SecRuleEngine 打开了。你可以根据自己的情况调整。

SecRule &REQUEST_HEADERS:Proxy "@gt 0" "id:1000005,log,deny,msg:'httpoxy denied'"

最后,如果你使用 Apache Traffic Server 的话,它本身不受影响。不过你可以用它来剔除掉 Proxy 请求头部,以保护其后面的其它服务。具体可以参考 ASF 指导。

HAProxy

通过下述配置剔除该请求头部:

http-request del-header Proxy

Varnish

通过下述语句取消该头部,请将它放到已有的 vcl\_recv 小节里面:

sub vcl_recv {
    [...]
    unset req.http.proxy;
    [...]
}

OpenBSD relayd

使用如下语句移除该头部。把它放到已有的过滤器里面:

http protocol httpfilter {
    match request header remove "Proxy"
}

lighttpd (<= 1.4.40)

弹回包含 Proxy 头部的请求。

  • 创建一个 /path/to/deny-proxy.lua文件,让它对于 lighttpd 只读,内容如下:
if (lighty.request["Proxy"] == nil) then return 0 else return 403 end
  • 修改 lighttpd.conf 以加载 mod_magnet 模块,并运行如上 lua 代码:
server.modules += ( "mod_magnet" )
magnet.attract-raw-url-to = ( "/path/to/deny-proxy.lua" )

lighttpd2 (开发中)

从请求中剔除 Proxy 头部。加入如下语句到 lighttpd.conf中:

req_header.remove "Proxy";

用户端的 PHP 修复没有作用

用户端的修复不能解决该缺陷,所以不必费劲:

  • 使用 unset($_SERVER['HTTP_PROXY']) 并不会影响到 getenv() 返回的值,所以无用
  • 使用 putenv('HTTP_PROXY=') 也没效果(putenv 只能影响到来自实际环境变量的值,而不是来自请求头部的)

httpoxy 的历史

该漏洞首次发现与15年前。

2001 年 3 月
Randal L. Schwartz 在 libwww-perl 发现该缺陷并修复。

2001 年 4 月
Cris Bailiff 在 curl 中发现该缺陷并修复。

2012 年 7 月
在Net::HTTP 的 HTTP_PROXY 实现中, Ruby 团队的 Akira Tanaka 发现了该缺陷

2013 年 11 月
在 nginx 邮件列表中提到了该缺陷。发现者 Jonathan Matthews 对此不太有把握,不过事实证明他是对的。

2015 年 2 月
Stefan Fritsch 在 Apache httpd-dev 邮件列表中提到了它。

2016 年 7 月
Vend 安全团队的 Scott Geary 发现了对该缺陷,并且它影响到了 PHP 等许多现代的编程语言和库。

所以,这个缺陷已经潜伏了许多年,许多人都在不同方面发现了它的存在,但是没有考虑到它对其它语言和库的影响。安全研究人员为此专门建立了一个网站: https://httpoxy.org/ ,可以在此发现更多内容。