4.3. 保护服务
虽然用户对组织内的系统管理员而言是管理控制的一个重要问题,但监控哪些网络服务对于管理和运行 Linux 系统的人员至关重要。
Red Hat Enterprise Linux 7 下的许多服务都是网络服务器。如果网络服务在计算机上运行,则服务器应用(称为 守护进程)正在侦听一个或多个网络端口的连接。这些服务器的每个服务器都应被视为潜在的攻击。
4.3.1. 对服务的风险
网络服务可能会给 Linux 系统带来很多风险。以下是一些主要问题的列表:
- 拒绝 Service Attacks (DoS) - 通过向服务填充请求,拒绝服务攻击可能会导致系统因为尝试记录并回答每个请求而不可用。
- Service Attack (DDoS)的分布式拒绝(DDoS) - 使用多个受损机器(通常以千计或更多个)对服务进行协调攻击,利用请求并无法使用它。
- 脚本漏洞攻击 - 如果服务器使用脚本来执行服务器端操作,作为 Web 服务器通常做的,攻击者可以将不正确的编写脚本作为目标。这些脚本漏洞攻击可能会导致缓冲区溢出状况,或者允许攻击者更改系统上的文件。
- buffer Overflow Attacks - 希望侦听端口 1 到 1023 的服务必须以管理特权启动,或者需要为它们设置
CAP_NET_BIND_SERVICE
功能。当进程绑定到端口并正在侦听它后,通常会丢弃特权或功能。如果没有丢弃特权或功能,且应用程序有可被利用的缓冲区溢出,攻击者可能会作为运行守护进程的用户访问系统。由于存在可利用的缓冲区溢出,因此攻击者使用自动化工具来识别具有漏洞的系统,一旦获得访问,它们使用自动化的 rootkits 来保持对系统的访问权限。
注意
在 Red Hat Enterprise Linux 7 中,执行Shield (可执行内存分段和保护技术)中可以缓解缓冲区溢出漏洞的威胁。execshield 通过将虚拟内存划分为可执行和非可执行文件段来降低缓冲区溢出的风险。试图在可执行段外执行的任何程序代码(如从缓冲区溢出漏洞注入的恶意代码)都会触发分段错误并终止。
execshield 还包括对 AMD64 平台和 Intel® 64 系统上的 No eXecute (NX)技术的支持。这些技术与 ExecShield 结合使用,以防止恶意代码在虚拟内存的可执行部分以 4KB 的可执行代码运行,从而降低攻击缓冲区溢出漏洞的风险。
重要
要限制暴露会受到攻击的网络,应关闭所有未使用的服务。
4.3.2. 识别和配置服务
为增强安全性,Red Hat Enterprise Linux 7 安装的大多数网络服务都会默认关闭。然而,有一些值得注意的例外:
- cups - Red Hat Enterprise Linux 7 的默认打印服务器。
- cups-lpd - 备用打印服务器。
- xinetd - 控制到一系列从属服务器(如 gssftp 和 telnet )连接的超级服务器。
- sshd - OpenSSH 服务器,这是 Telnet 的安全替换。
在确定这些服务是否运行时,最好使用常见意义,并避免承担任何风险。例如,如果打印机不可用,请不要让 cups 运行。对于 portreserve,也是如此。如果您没有挂载 NFSv3 卷或使用 NIS ( ypbind 服务),则应禁用 rpcbind。检查哪些网络服务可在引导时启动是不够的。建议还要检查哪些端口处于打开状态并侦听。如需更多信息,请参阅 第 4.4.2 节 “验证正在列出哪些端口”。
4.3.3. 不安全的服务
任何网络服务都不安全。这就是关闭未使用的服务非常重要的原因。对服务的利用会频繁发现和修补,因此定期更新与任何网络服务关联的软件包非常重要。请参阅 第 3 章 使您的系统保持最新状态 了解更多信息。
某些网络协议本质上比其他协议更安全。这包括以下任何服务:
- 通过网络 Unencrypted - 很多较旧的协议(如 Telnet 和 FTP)传输 用户名和密码,不要加密身份验证会话,并应尽可能避免。
- 通过网络 Unencrypted 传输敏感数据 - 很多协议通过网络未加密的传输数据。这些协议包括 Telnet、FTP、HTTP 和 SMTP。许多网络文件系统(如 NFS 和 SMB )也通过网络未加密的传输信息。在使用这些协议来限制传输的数据类型时,用户的职责。
本质上不安全的服务示例包括 rlogin、rsh、telnet 和 vsftpd。
应仔细实现的服务,并在防火墙后面包括:
- auth
- nfs-server
- SMB 和 nbm (Samba)
- yppasswdd
- ypserv
- ypxfrd
有关保护网络服务安全的更多信息,请参阅 第 4.4 节 “保护网络访问”。
4.3.4. 保护 rpcbind
rpcbind 服务是 RPC 服务的动态端口分配守护进程,如 NIS 和 NFS。它有较弱的身份验证机制,并可为其控制的服务分配大量端口。因此,很难保护。
注意
保护 rpcbind 仅影响 NFSv2 和 NFSv3 实现,因为 NFSv4 不再需要它。如果您计划实施 NFSv2 或 NFSv3 服务器,则需要 rpcbind,并且适用以下部分。
如果运行 RPC 服务,请遵循以下基本规则。
4.3.4.1. 使用 TCP wrapper 保护 rpcbind
务必要使用 TCP wrapper 来限制哪些网络或主机可以访问 rpcbind 服务,因为它没有内置的身份验证形式。
此外,在限制对该服务的访问时,只使用 IP 地址。避免使用主机名,因为它们可以通过 DNS poisoning 和其他方法进行伪造。
4.3.4.2. 使用 firewalld 保护 rpcbind
要进一步限制对 rpcbind 服务的访问,最好将
firewalld
规则添加到服务器,并限制对特定网络的访问。
以下是
firewalld
丰富的语言命令示例。第一个允许从 192.168.0.0/24 网络到端口 111 (由 rpcbind 服务使用)的 TCP 连接。第二个允许从 localhost 到同一端口的 TCP 连接。 所有其他数据包都将被丢弃。
~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop' ~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept'
要类似限制 UDP 流量,请使用以下命令:
~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop'
注意
4.3.5. 保护 rpc.mountd
如果运行 RPC 服务,请遵循以下基本规则。
4.3.5.1. 使用 TCP Wrappers 保护 rpc.mountd
使用 TCP Wrappers 限制哪些网络或主机可以访问 rpc.mountd 服务非常重要,因为它没有内置的身份验证形式。
此外,在限制对该服务的访问时,只使用
IP
地址。避免使用主机名,因为它们可以通过 DNS
poisoning 和其他方法进行伪造。
4.3.5.2. 使用 firewalld 保护 rpc.mountd
要进一步限制对 rpc.mountd 服务的访问,请在服务器中添加
firewalld
丰富的语言规则并限制对特定网络的访问。
以下是
firewalld
丰富的语言命令示例。第一个允许从 192.168.0.0/24
网络挂载连接。第二个 允许
从本地主机挂载连接。所有其他数据包都将被丢弃。
~]# firewall-cmd --add-rich-rule 'rule family="ipv4" source NOT address="192.168.0.0/24" service name="mountd" drop' ~]# firewall-cmd --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept'
注意
4.3.6. 保护 NIS
网络信息服务 (NIS)是一个 RPC 服务,称为 ypserv,它将与 rpcbind 和其他相关服务结合使用,用于将用户名、密码和其他敏感信息分发到其域中的任何计算机。
NIS 服务器由多个应用程序组成。它们包括以下内容:
- /usr/sbin/rpc.yppasswdd - 也称为 yppasswdd 服务,此守护进程允许用户更改其 NIS 密码。
- /usr/sbin/rpc.ypxfrd - 还称 ypxfrd 服务,此守护进程负责 NIS 通过网络传输。
- /usr/sbin/ypserv - 这是 NIS 服务器守护进程。
NIS 因当今的标准而不安全。它没有主机身份验证机制,并通过未加密的网络传输所有信息,包括密码哈希。因此,设置使用 NIS 的网络时必须非常小心。这进一步复杂,NIS 的默认配置本质上不安全。
建议任何计划实施 NIS 服务器的用户首先保护 rpcbind 服务,如 第 4.3.4 节 “保护 rpcbind” 所述,然后解决以下问题,如网络规划。
4.3.6.1. 仔细规划网络
由于 NIS 通过网络传输未加密的敏感信息,因此该服务必须在防火墙后面和分段安全网络后面运行。每当通过不安全的网络传输 NIS 信息时,都会拦截它的风险。仔细的网络设计可帮助防止严重的安全漏洞。
4.3.6.2. 使用类似密码的 NIS 域名和主机名
NIS 域中的任何机器都可以使用命令从服务器中提取信息,而无需身份验证,只要用户知道 NIS 服务器的 DNS 主机名和 NIS 域名。
例如,如果某家计算机连接到网络,或者从外部中断到网络(并管理到欺骗内部 IP 地址),以下命令显示 /etc/passwd 映射:
ypcat-d
<NIS_domain>-h
<DNS_hostname>passwd
如果这个攻击者是一个 root 用户,可以通过输入以下命令来获取 /etc/shadow 文件:
ypcat-d
<NIS_domain>-h
<DNS_hostname>shadow
注意
如果使用 Kerberos,则 /etc/shadow 文件不会存储在 NIS 映射中。
要使对 NIS 映射的访问更难于攻击者,请为 DNS 主机名创建一个随机字符串,如
o7hfawtgmhwg.domain.com
。同样,创建不同的 随机 NIS 域名。这使得攻击者更难以访问 NIS 服务器。
4.3.6.3. 编辑 /var/yp/securenets
文件
如果
/var/yp/securenets
文件为空或不存在(如默认安装后的情况),NIS 侦听所有网络。首先要做的事情之一是将子网掩码/网络对放在文件中,以便 ypserv 仅响应来自适当网络的请求。
以下是
/var/yp/securenets
文件中的示例条目:
255.255.255.0 192.168.0.0
警告
在不创建
/var/yp/securenets
文件的情况下,不要在第一次启动 NIS 服务器。
这个技术不提供对 IP 欺骗攻击的保护,但它至少对 NIS 服务器服务的网络上的限制。
4.3.6.4. 分配静态端口和使用 Rich Language 规则
与 NIS 相关的所有服务器都可以被分配除 rpc.yppasswdd 以外的特定端口 - 允许用户更改其登录密码的守护进程。将端口分配给其他两个 NIS 服务器守护进程 rpc.ypxfrd 和 ypserv,允许创建防火墙规则来进一步保护 NIS 服务器守护进程不受入侵者的影响。
要做到这一点,请在
/etc/sysconfig/network
中添加以下行:
YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"
然后,以下丰富的语言
firewalld
规则可用于强制服务器侦听这些端口的网络:
~]# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="834-835" protocol="tcp" drop' ~]# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="834-835" protocol="udp" drop'
这意味着,如果请求来自
192.168.0.0/24
网络,服务器仅允许连接到端口 834 和 835。第一个规则用于 TCP
,第二个规则用于 UDP
。
注意
有关使用 iptables 命令实现防火墙的详情,请参考 第 5 章 使用防火墙。
4.3.6.5. 使用 Kerberos 身份验证
使用 NIS 进行身份验证时需要考虑的问题之一是,每当用户登录计算机时,都会通过网络发送
/etc/shadow
映射中的密码哈希。如果入侵者获得了对 NIS 域的访问并嗅探网络流量,他们可以收集用户名和密码哈希。如果有足够的时间,攻击者可能会猜测弱密码,攻击者可以获得对网络上有效帐户的访问权限。
由于 Kerberos 使用 secret 密钥加密,所以不会通过网络发送密码哈希,使系统更安全。有关 Kerberos 的更多信息,请参阅 Linux 域身份、身份验证和策略指南中的使用 Kerberos 登录到 IdM 部分。
4.3.7. 保护 NFS
重要
可以在所有版本中使用 TCP 发送 NFS 流量,它应当与 NFSv3 一起使用,而不是使用 UDP,在使用 NFSv4 时是必需的。作为
RPCSEC_GSS
内核模块的一部分,NFS 的所有版本都支持 Kerberos 用户和组身份验证。仍然包含 rpcbind 的信息,因为 Red Hat Enterprise Linux 7 支持使用 rpcbind 的 NFSv3。
4.3.7.1. 仔细规划网络
传统上 NFSv2 和 NFSv3 传递数据。现在,NFS 的所有版本都能够使用 Kerberos 验证(并选择性地加密)普通文件系统操作。在 NFSv4 下,所有操作都可以使用 Kerberos;在 NFSv2 或 NFSv3 下,文件锁定和挂载仍无法使用它。使用 NFSv4.0 时,如果客户端位于 NAT 或防火墙后面,则可以关闭委派。有关使用 NFSv4.1 来允许委托通过 NAT 和防火墙操作的详情,请参考 Red Hat Enterprise Linux 7 存储管理指南 的 pNFS 部分。
4.3.7.2. 保护 NFS 挂载选项
在
/etc/fstab
文件中介绍了使用 mount 命令,请参见 Red Hat Enterprise Linux 7 存储管理指南 中的" 使用 mount 命令 "章节。从安全管理的角度来看,值得注意,也可以在 /etc/nfsmount.conf
中指定 NFS 挂载选项,可用于设置自定义默认选项。
4.3.7.2.1. 查看 NFS 服务器
警告
仅导出整个文件系统。导出文件系统的子目录可能是安全问题。在有些情况下,客户端可能会"破坏"文件系统的导出部分,并得到取消导出部分(请参阅
exports (5)
手册页中有关子树检查的部分)。
使用
ro
选项将文件系统导出为只读文件系统,以减少用户可以写入挂载的文件系统的用户数量。仅在需要时使用 rw
选项。详情请查看 man exports (5)
页面。例如,允许写入访问会增加符号链接攻击的风险。这包括临时目录,如 /tmp
和 /usr/tmp
。
必须使用
rw
选项挂载目录的位置,避免尽可能使目录全局可写,以降低风险。导出主目录也被视为风险,因为有些应用以明文或弱方式加密存储密码。随着应用程序代码被检查并改进,这个风险会降低。有些用户没有在 SSH 密钥上设置密码,因此这也意味着主目录会带来风险。强制使用密码或使用 Kerberos 可降低该风险。
只将导出限制给需要访问权限的客户端。在 NFS 服务器上使用 showmount -e 命令来检查服务器正在导出的内容。不要导出不需要的任何内容。
不要使用 no_root_squash 选项,并查看现有安装以确保不使用它。请参阅 第 4.3.7.4 节 “不要使用 no_root_squash 选项” 了解更多信息。
secure
选项是用于将导出限制到 “保留端口” 的服务器端导出选项。默认情况下,服务器仅允许来自 “保留端口” 的客户端通信(编号小于 1024 的端口),因为传统客户端只有允许的 “可信” 代码(如内核 NFS 客户端)使用这些端口。但是,在很多网络上,任何人无法在某些客户端上成为 root 用户,因此,对于服务器来说,假设来自保留端口的通信都具有特权非常安全。因此,对保留端口的限制具有有限的值;最好根据 Kerberos、防火墙和对特定客户端的导出限制来决定。
大多数客户端仍然尽可能使用保留的端口。但是,保留的端口是一个有限的资源,因此客户端(特别是那些具有大量 NFS 挂载的客户端)也可以选择使用高数字的端口。Linux 客户端可以使用 “noresvport” 挂载选项进行此操作。如果要在导出上允许此操作,您可以使用 “insecure” export 选项进行此操作。
最好不允许用户登录到服务器。查看 NFS 服务器上的以上设置时,请查看谁和什么可以访问服务器。
4.3.7.2.2. 查看 NFS 客户端
使用
nosuid
选项禁止使用 setuid 程序。nosuid
选项禁用 set-user-identifier
或 set-group-identifier
位。这可防止远程用户通过运行 setuid 程序获得更高的特权。在客户端和服务器端使用这个选项。
noexec
选项禁用客户端上的所有可执行文件。使用此选项来防止用户意外执行放在被共享的文件系统中的文件。nosuid
和 noexec
选项对于大多数都不是所有文件系统的标准选项。
使用
nodev
选项防止 “device-files” 被客户端作为硬件设备处理。
resvport
选项是一个客户端挂载选项,而 secure
是对应的服务器端导出选项(请参阅上述说明)。它限制了与"保留端口"的通信。保留或"well known"端口为特权用户和进程保留,如 root 用户。设置此选项可让客户端使用保留源端口与服务器通信。
NFS 的所有版本现在支持使用 Kerberos 身份验证挂载。启用此选项的挂载选项为:
sec=krb5
。
NFSv4 支持对完整性使用
krb5i
的 Kerberos 挂载,使用 krb5p
进行隐私保护。使用 sec=krb5
挂载时会使用它们,但需要在 NFS 服务器上进行配置。如需更多信息,请参阅 exports (man 5 导出
)的 man page。
NFS man page (
man 5 nfs
)有一个 “SECURITY CONSIDERATIONS” 部分,它解释了 NFSv4 中的安全增强,并包含所有 NFS 特定的挂载选项。
重要
krb5-libs 软件包提供的 MIT Kerberos 库不支持在新部署中使用数据加密标准(DES)算法。由于安全性和某些兼容性原因,在 Kerberos 库中,DES 默认被弃用并禁用。只有在您的环境不支持任何更新和更安全得算法时,才出于兼容性的原因使用 DES。
4.3.7.3. 语法错误
NFS 服务器通过咨询
/etc/exports
文件来确定要导出哪些主机以及要将这些目录导出到哪个文件系统。在编辑此文件时,请小心不要添加额外的空格。
例如,
/etc/exports
文件中的以下行将目录 /tmp/nfs/ 共享到主机 bob.example.com,其读/写权限。
/tmp/nfs/ bob.example.com(rw)
另一方面,
/etc/exports
文件中的以下行与主机 bob.example.com
共享同一目录,并具有只读权限,因为主机名后面有一个空格字符来与 全局 共享。
/tmp/nfs/ bob.example.com (rw)
使用 showmount 命令检查任何配置的 NFS 共享是不错的做法:
showmount -e
<hostname>
4.3.7.4. 不要使用 no_root_squash 选项
默认情况下,NFS 共享将 root 用户改为 nfsnobody 用户(非特权用户帐户)。这会将所有 root 创建文件的所有者更改为 nfsnobody,这样可防止上传设置了 setuid 位的程序。
如果使用 no_root_squash,则远程 root 用户可以更改共享文件系统上的任何文件,并将 Trojans 破坏的应用程序留给其他用户意外执行。
4.3.7.5. NFS 防火墙配置
NFSv4 是 Red Hat Enterprise Linux 7 的 NFS 的默认版本,它只需要为 TCP 打开端口 2049。如果使用 NFSv3,则需要四个额外的端口,如下所述。
为 NFSv3 配置端口
用于 NFS 的端口由
rpcbind
服务动态分配,这可能会在创建防火墙规则时造成问题。要简化这个过程,请使用 /etc/sysconfig/nfs
文件指定要使用的端口:
MOUNTD_PORT
- mountd 的 TCP 和 UDP 端口(rpc.mountd)STATD_PORT
- status (rpc.statd)的 TCP 和 UDP 端口
在 Red Hat Enterprise Linux 7 中,在
/etc/modprobe.d/lockd.conf
文件中为 NFS 锁定管理器(nlockmgr)设置 TCP 和 UDP 端口:
nlm_tcpport
- nlockmgr (rpc.lockd)的 TCP 端口nlm_udpport
- UDP 端口 nlockmgr (rpc.lockd)
指定的端口号不得被任何其他服务使用。将您的防火墙配置为允许指定的端口号,以及 TCP 和 UDP 端口 2049 (NFS)。有关其他可自定义 NFS 锁定管理器参数的描述,请参阅
/etc/modprobe.d/lockd.conf
。
在 NFS 服务器上运行 rpcinfo -p 命令,以查看正在使用的端口和 RPC 程序。
4.3.7.6. 使用红帽身份管理保护 NFS
在使用 Red Hat Identity Management (包括在 Red Hat Enterprise Linux 中)的环境中可以大大简化 Kerberos 感知 NFS 设置。
请参阅 Red Hat Enterprise Linux 7 Linux 域身份、身份验证和策略指南,特别是 设置 Kerberos 感知 NFS 服务器 以了解如何在使用 Red Hat Identity Management 时使用 Kerberos 保护 NFS。
4.3.8. 保护 HTTP 服务器
4.3.8.1. 保护 Apache HTTP 服务器
Apache HTTP 服务器是 Red Hat Enterprise Linux 7 中最稳定和安全的服务之一。有很多选项和技术可用于保护 Apache HTTP 服务器 - 这太多是为了深入处理 Apache HTTP 服务器。以下章节简要解释了运行 Apache HTTP 服务器时的良好做法。
在将脚本放入生产 之前,请始终验证系统上运行的任何脚本是否按预期工作。此外,确保只有 root 用户对包含脚本或 CGI 的任何目录具有写入权限。要做到这一点,以 root 用户身份输入以下命令:
chown root
<directory_name>
chmod 755
<directory_name>
使用以下配置选项(在
/etc/httpd/conf/httpd.conf
中配置)时,系统管理员应小心:
FollowSymLinks
- 默认情况下,这个指令是启用的,因此请务必在创建 Web 服务器文档根的符号链接时小心。例如,最好提供指向
/
的符号链接。 索引
- 这个指令默认为启用,但可能不需要。要防止 visitors 浏览服务器上的文件,请删除此指令。
UserDir
- 默认情况下,
UserDir
指令被禁用,因为它可以确认系统中存在用户帐户。要在服务器上启用用户目录浏览,请使用以下指令:UserDir enabled UserDir disabled root
这些指令激活用户目录浏览/root/
以外的所有用户目录。要将用户添加到禁用帐户列表中,请在UserDir disabled
行中添加以空格分隔的用户列表。 ServerTokens
ServerTokens
指令控制发送到客户端的服务器响应标头字段。它包括可使用以下参数自定义的各种信息:ServerTokens Full
(默认选项)- 提供所有可用信息(OS 类型和使用的模块),例如:Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2
ServerTokens Prod
或ServerTokens ProductOnly
- 提供以下信息:Apache
ServerTokens Major
- 提供以下信息:Apache/2
ServerTokens Minor
- 提供以下信息:Apache/2.0
ServerTokens Min
或ServerTokens Minimal
- 提供以下信息:Apache/2.0.41
ServerTokens OS
- 提供以下信息:Apache/2.0.41 (Unix)
建议使用ServerTokens Prod
选项,以便可能的攻击者不会获取您系统的任何宝贵信息。
重要
不要删除
IncludesNoExec
指令。默认情况下,Server-Side Includes (SSI)模块无法执行命令。建议您不要更改此设置,除非绝对必要,因为它可能会使攻击者在系统中执行命令。
删除 httpd 模块
在某些情况下,删除某些
httpd
模块来限制 HTTP 服务器的功能是很有帮助的。为此,请编辑 /etc/httpd/conf.modules.d
目录中的配置文件。例如,要删除代理模块:
echo '# All proxy modules disabled' > /etc/httpd/conf.modules.d/00-proxy.conf
请注意,
/etc/httpd/conf.d/
目录还包含用于加载模块的配置文件。
httpd 和 SELinux
如需更多信息,请参阅 Red Hat Enterprise Linux 7 SELinux 用户和管理员指南中的 Apache HTTP 服务器和 SELinux 章节。
4.3.8.2. 保护 NGINX
NGINX 是一个高性能 HTTP 和代理服务器。本节简要记录了强化 NGINX 配置的其他步骤。在 NGINX 配置文件的
server
部分中执行以下所有配置更改。
禁用版本字符串
要防止攻击者了解服务器上运行的 NGINX 版本,请使用以下配置选项:
server_tokens off;
这会影响版本号,只需报告由 NGINX 提供的所有请求中的字符串
nginx
的影响:
$ curl -sI http://localhost | grep Server Server: nginx
包括其他与安全相关的标头
NGINX 提供的每个请求都可以包括额外的 HTTP 标头来缓解某些已知的 Web 应用程序漏洞:
add_header X-Frame-Options SAMEORIGIN;
- 此选项拒绝域之外的任何页面来帧由 NGINX 提供的任何内容,从而有效地缓解了攻击。add_header X-Content-Type-Options nosniff;
- 这个选项在某些较旧的浏览器中防止 MIME 类型嗅探。add_header X-XSS-Protection "1; mode=block";
- 这个选项启用跨站点脚本过滤(XSS)过滤,这可以防止浏览器渲染由 NGINX 响应中包含的潜在的恶意内容。
禁用 Potentially Harmful HTTP 方法
如果启用,某些 HTTP 方法可能会允许攻击者对专为开发人员测试 Web 应用程序的 Web 服务器执行操作。例如,TRACE 方法已知允许跨站点追踪(XST)。
您的 NGINX 服务器可以通过只列入允许的用户来禁止这些有害 HTTP 方法以及任何任意方法。例如:
# Allow GET, PUT, POST; return "405 Method Not Allowed" for all others. if ( $request_method !~ ^(GET|PUT|POST)$ ) { return 405; }
配置 SSL
要保护 NGINX web 服务器提供的数据,请考虑仅通过 HTTPS 提供它。要在 NGINX 服务器中为启用 SSL 生成安全配置配置文件,请参阅 Mozilla SSL 配置生成器。生成的配置可确保禁用已知存在安全漏洞的协议(如 SSLv2 或 SSLv3、密码和哈希算法(例如 3DES 或 MD5)。
您还可以使用 SSL 服务器测试 验证您的配置是否满足现代安全要求。
4.3.9. 保护 FTP
文件传输协议 (FTP)是一种较旧的 TCP 协议,旨在通过网络传输文件。因为与服务器进行的所有事务(包括用户身份验证)都是未加密的,所以它被视为不安全的协议,应该仔细配置。
Red Hat Enterprise Linux 7 提供两个 FTP 服务器:
- 红帽内容加速器 (tux)- 具有 FTP 功能的内核空间 Web 服务器。
- vsftpd - FTP 服务的独立、面向安全的实现。
以下安全指南是设置 vsftpd FTP 服务。
4.3.9.1. FTP Greeting Banner
在提交用户名和密码前,所有用户都会看到问候横幅。默认情况下,此横幅包含有助于识别系统中弱点的版本信息。
要更改 vsftpd 的问候横幅,请在
/etc/vsftpd/vsftpd.conf
文件中添加以下指令:
ftpd_banner=<insert_greeting_here>
将上述指令中的 < insert_greeting_here > 替换为问候消息的文本。
对于 Mutli-line banners,最好使用横幅文件。要简化对多个横幅的管理,请将所有横幅放在名为
/etc/banners/
的新目录中。本例中 FTP 连接的横幅文件是 /etc/banners/ftp.msg
。以下是此类文件的一个示例:
######### Hello, all activity on ftp.example.com is logged. #########
注意
不需要使用在 第 4.4.1 节 “使用 TCP wrapper 和 xinetd 保护服务” 中指定的 220 文件开始每行。
要引用 vsftpd 的这一问候标语文件,请在
/etc/vsftpd/vsftpd.conf
文件中添加以下指令:
banner_file=/etc/banners/ftp.msg
您还可以使用 TCP Wrappers 将额外的横幅发送到传入的连接,如 第 4.4.1.1 节 “TCP 包装器和连接标语” 所述。
4.3.9.2. Anonymous Access(匿名访问)
存在
/var/ftp/
目录可激活匿名帐户。
创建此目录的最简单方法是安装
vsftpd
软件包。这个软件包为匿名用户建立目录树,并为匿名用户将目录的权限配置为只读。
默认情况下,匿名用户无法写入任何目录。
警告
如果启用对 FTP 服务器的匿名访问,请注意敏感数据的存储位置。
4.3.9.2.1. 匿名上传
要允许匿名用户上传文件,建议在
/var/ftp/pub/
中创建只写目录。要做到这一点,请以 root 用户身份输入以下命令:
~]# mkdir /var/ftp/pub/upload
接下来,更改权限,以便匿名用户无法查看目录的内容:
~]# chmod 730 /var/ftp/pub/upload
目录的长格式列表应如下所示:
~]# ls -ld /var/ftp/pub/upload
drwx-wx---. 2 root ftp 4096 Nov 14 22:57 /var/ftp/pub/upload
允许匿名用户在目录中进行读写的管理员通常会发现其服务器成为盗窃软件的存储库。
另外,在 vsftpd 下,在
/etc/vsftpd/vsftpd.conf
文件中添加以下行:
anon_upload_enable=YES
4.3.9.3. 用户帐户
由于 FTP 通过不安全的网络传输未加密的用户名和密码进行身份验证,因此最好拒绝系统用户从其用户帐户访问服务器。
要禁用 vsftpd 中的所有用户帐户,请在
/etc/vsftpd/vsftpd.conf
中添加以下指令:
local_enable=NO
4.3.9.3.1. 限制用户帐户
要禁用特定帐户或特定帐户组(如 root 用户和具有 sudo 权限的用户)的 FTP 访问,最简单的方法是使用 PAM 列表文件,如 第 4.2.1 节 “禁止 Root 访问” 所述。vsftpd 的 PAM 配置文件为
/etc/pam.d/vsftpd
。
也可以直接禁用每个服务中的用户帐户。
要在 vsftpd 中禁用特定的用户帐户,请将用户名添加到
/etc/vsftpd/ftpusers
4.3.9.4. 使用 TCP wrapper 控制访问
按照 第 4.4.1 节 “使用 TCP wrapper 和 xinetd 保护服务” 所述,使用 TCP wrapper 控制对 FTP 守护进程的访问。
4.3.10. 保护 Postfix
Postfix 是一个邮件传输代理(MTA),它使用简单邮件传输协议(SMTP)在其他 MTA 之间发送电子邮件,以及电子邮件客户端或发送代理。虽然很多 MTA 能够在另一个 MTA 之间加密流量,但大多数都不允许,因此通过任何公共网络发送电子邮件被视为本质上是不安全的通信形式。Postfix 将 Sendmail 取代为 Red Hat Enterprise Linux 7 中的默认 MTA。
建议计划实施 Postfix 服务器的任何人都解决了以下问题。
4.3.10.1. 限制服务攻击
由于电子邮件的性质,确定的攻击者可能会非常轻松地使用邮件来填充服务器,并导致拒绝服务。可以通过设置
/etc/postfix/main.cf
文件中的指令限制来限制此类攻击的有效性。您可以更改已有指令的值,或者您可以使用以下格式所需的值添加所需指令:
<directive> = <value>.以下是可用于限制拒绝服务攻击的指令列表:
- smtpd_client_connection_rate_limit - 允许每个时间单位对这个服务进行的最大连接尝试次数(如下所述)。默认值为 0,这意味着客户端每次时间单位可以接收 Postfix 可以接受的连接数。默认情况下,可信网络中的客户端会被排除。
- anvil_rate_time_unit - 此时间单位用于速率限制计算。默认值为 60 秒。
- smtpd_client_event_limit_exceptions - 从连接和速率限制命令中排除的客户端。默认情况下,可信网络中的客户端会被排除。
- smtpd_client_message_rate_limit - 允许客户端按时间单位请求的最大消息数(无论 Postfix 是否实际接受这些消息)。
- default_process_limit - 提供给定服务的 Postfix 子进程的默认最大数量。对于
master.cf
文件中的特定服务,可以禁止这个限制。默认值为 100。 - queue_minfree - 接收邮件所需的队列文件系统中的最小可用空间量(以字节为单位)。Postfix SMTP 服务器目前使用此选项来确定它将接受任何邮件。默认情况下,当可用空间量小于 message_size_limit 的 1.5 倍时,Postfix SMTP 服务器会拒绝 MAIL FROM 命令。要指定较高的最小可用空间限制,请指定 message_size_limit 至少 1.5 倍的 queue_minfree 值。默认情况下,queue_minfree 值为 0。
- header_size_limit - 存储消息标头的最大内存量(以字节为单位)。如果标头更大,则丢弃过量。默认值为 102400。
- message_size_limit - 消息的最大大小(以字节为单位),包括信封信息。默认值为 10240000。
4.3.10.2. NFS 和 Postfix
切勿将邮件假脱机目录
/var/spool/postfix/
放置到 NFS 共享卷上。由于 NFSv2 和 NFSv3 不维护对用户和组 ID 的控制,因此两个或多个用户可以具有相同的 UID,并且接收和读取彼此的邮件。
注意
使用 Kerberos 的 NFSv4 时,情况并非如此,因为
SECRPC_GSS
内核模块不使用基于 UID 的身份验证。但是,最好不要将邮件假脱机 目录放在 NFS 共享卷上。
4.3.10.3. 仅邮件用户
为了帮助防止 Postfix 服务器上的本地用户利用,邮件用户最好使用电子邮件程序访问 Postfix 服务器。邮件服务器上的 shell 帐户不应被允许,并且
/etc/passwd
文件中的所有用户 shell 都应设置为 /sbin/nologin (root 用户可能例外)。
4.3.10.4. 禁用 Postfix 网络列表
默认情况下,Postfix 设置为仅侦听本地回送地址。您可以通过查看文件
/etc/postfix/main.cf
来验证这一点。
查看文件
/etc/postfix/main.cf
,以确保仅显示以下 inet_interfaces
行:
inet_interfaces = localhost
这样可确保 Postfix 仅接受来自本地系统而不是来自网络的邮件(如 cron 作业报告)。这是默认设置,保护 Postfix 免受网络攻击。
要删除 localhost 限制并允许 Postfix 侦听所有接口,可使用
inet_interfaces = all
设置。
4.3.10.5. 将 Postfix 配置为使用 SASL
Postfix 的 Red Hat Enterprise Linux 7 版本可以使用 Dovecot 或 Cyrus
SASL
实现进行 SMTP 身份验证 (或 SMTP AUTH)。SMTP 身份验证是 简单邮件传输协议的扩展
。启用后,需要 SMTP
客户端使用服务器和客户端都支持并接受的身份验证方法向 SMTP
服务器进行身份验证。这部分论述了如何配置 Postfix 以使用 Dovecot SASL
实现。
要安装 Dovecot
POP
/IMAP
服务器,因此在您的系统中提供 Dovecot SASL
实现,以 root
用户身份运行以下命令:
~]# yum install dovecot
Postfix
SMTP
服务器可以使用 UNIX-domain 套接字或 TCP 套接字 与 Dovecot SASL
实现通信。只有 Postfix 和 Dovecot 应用程序运行在单独的计算机上时,才需要后一种方法。本指南优先选择 UNIX 域套接字方法,其负担更好隐私。
为了指示 Postfix 使用 Dovecot
SASL
实现,需要为这两个应用程序执行多个配置更改。按照以下步骤使这些更改生效。
设置 Dovecot
- 修改主 Dovecot 配置文件
/etc/dovecot/conf.d/10-master.conf
,使其包含以下行(已包含大多数相关部分,且只需要取消注释的行):service auth { unix_listener /var/spool/postfix/private/auth { mode = 0660 user = postfix group = postfix } }
上面的示例假定使用 UNIX-domain socket 进行 Postfix 和 Dovecot 之间的通信。它还假定 PostfixSMTP
服务器的默认设置,其中包括位于/var/spool/postfix/
目录中的邮件队列,以及在postfix
用户和组下运行的应用程序。这样,读取和写入权限仅限于postfix
用户和组。或者,您可以使用以下配置设置 Dovecot 以通过TCP
侦听 Postfix 验证请求:service auth { inet_listener { port = 12345 } }
在上例中,将12345
替换为您要使用的端口数。 - 编辑
/etc/dovecot/conf.d/10-auth.conf
配置文件,以指示 Dovecot 为 PostfixSMTP
服务器提供普通
和登录
身份验证机制:auth_mechanisms = plain login
设置 Postfix
如果是 Postfix,则仅需要修改主配置文件
/etc/postfix/main.cf
。添加或编辑以下配置指令:
- 在 Postfix SMTP 服务器中启用
SMTP
身份验证:smtpd_sasl_auth_enable = yes
- 指示 Postfix 将 Dovecot
SASL
实现用于 SMTP 身份验证:smtpd_sasl_type = dovecot
- 提供相对于 Postfix 队列目录的身份验证路径(请注意,无论 Postfix 服务器是否在 chroot 中运行,使用相对路径可确保配置可以正常工作):
smtpd_sasl_path = private/auth
此步骤假设您要使用 UNIX-domain socket 进行 Postfix 和 Dovecot 之间的通信。如果您使用TCP
套接字进行通信,要将 Postfix 配置为在不同机器上查找 Dovecot,请使用类似如下的配置值:smtpd_sasl_path = inet:127.0.0.1:12345
在上例中,127.0.0.1
需要替换为 Dovecot 机器的IP
地址,并使用 Dovecot 的/etc/dovecot/conf.d/10-master.conf
配置文件中指定的端口替换12345
。 - 指定 Postfix
SMTP
服务器为客户端提供的SASL
机制。请注意,可以为加密和未加密的会话指定不同的机制。smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous
上面的例子指定,在未加密的会话中,不允许匿名身份验证,且不会允许传输未加密的用户名或密码的机制。对于加密的会话(使用TLS
),只允许非匿名身份验证机制。有关限制允许SASL
机制的所有支持策略列表,请参阅 http://www.postfix.org/SASL_README.html#smtpd_sasl_security_options。
其它资源
以下在线资源提供了用于通过
SASL
配置 Postfix SMTP 身份验证的附加信息。
- http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL - 包含有关如何设置 Postfix 以对 SMTP 身份验证使用 Dovecot
SASL
实现的信息。 - http://www.postfix.org/SASL_README.html#server_sasl - 包含有关如何将 Postfix 设置为对 SMTP 身份验证使用 Dovecot 或 Cyrus
SASL
实现的信息。
4.3.11. 保护 SSH
Secure Shell (SSH)是一种强大的网络协议,用于通过安全通道与其他系统通信。通过
SSH
的传输会被加密和保护。有关 SSH
协议的常规信息以及 Red Hat Enterprise Linux 7 中的 SSH
服务的信息,请参阅 Red Hat Enterprise Linux 7 指南中的 OpenSSH 章节。
重要
本节注意保护
SSH
设置的最常见方法。否 意味着这个建议测量列表被视为详细或确定。有关修改 sshd
守护进程行为和 ssh (1) 的所有配置指令的说明,请参阅 sshd_config (5)。
4.3.11.1. 加密登录
SSH
支持使用加密密钥登录到计算机。这比仅使用密码更安全。如果您将此方法与其他身份验证方法相结合,则它被视为多因素身份验证。有关使用多个验证方法的详情,请参考 第 4.3.11.2 节 “多个身份验证方法”。
要启用使用加密密钥进行身份验证,需要将
/etc/ssh/sshd_config
文件中的 PubkeyAuthentication
配置指令设置为 yes
。请注意,这是默认设置。将 PasswordAuthentication
指令设置为 no
,以禁用可能使用密码登录。
可以使用 ssh-keygen 命令生成
SSH
密钥。如果在没有附加参数的情况下调用,它会创建一个 2048 位 RSA 密钥集。默认情况下,密钥存储在 ~/.ssh/
目录中。您可以使用 -b
参数修改密钥的位级。使用 2048 位密钥通常就足够了。Red Hat Enterprise Linux 7 系统管理员指南中的 配置 OpenSSH 章节包含有关生成密钥对的详细信息。
您应该在
~/.ssh/
目录中看到两个密钥。如果您在运行 ssh-keygen 命令时接受了默认值,则生成的文件分别命名为 id_rsa
和 id_rsa.pub
,并分别包含私钥和公钥。您应该始终通过使私钥对除文件所有者以外的任何人都不可读来保护私钥。但是,公钥需要传送到您要登录的系统。您可以使用 ssh-copy-id 命令将密钥传送到服务器:
~]$ ssh-copy-id -i [user@]server
此命令还会自动将公钥附加到 服务器 上的
~/.ssh/authorized_keys
文件中。当您尝试登录到服务器时,sshd
守护进程将检查此文件。
与密码和任何其他身份验证机制类似,您应该定期更改
SSH
密钥。完成后,请确保从 authorized_keys
文件中删除任何未使用的密钥。
4.3.11.2. 多个身份验证方法
使用多个身份验证方法或多因素验证会增加未授权访问的保护级别,因此在强化系统时应考虑防止它受到攻击。尝试登录到使用多因素身份验证的系统的用户必须成功完成所有指定的身份验证方法才能授予访问权限。
使用
/etc/ssh/sshd_config
文件中的 AuthenticationMethods
配置指令来指定要使用哪些身份验证方法。请注意,可以使用这个指令定义多个所需的身份验证方法列表。如果是这种情况,用户必须至少以其中一个列表完成每个方法。列表需要用空白空格分开,列表中的独立 authentication-method 名称必须用逗号分开。例如:
AuthenticationMethods publickey,gssapi-with-mic publickey,keyboard-interactive
使用上述
AuthenticationMethods
指令配置的 sshd
守护进程仅在尝试成功完成 公钥身份验证
时授予访问权限,后跟 gssapi-with-mic
或 键盘交互
身份验证。请注意,每个请求的身份验证方法都需要使用 /etc/ssh/sshd_config
文件中对应的配置指令(如 PubkeyAuthentication
)显式启用。有关可用身份验证方法的常规列表,请参阅 ssh (1) 的 AUTHENTICATION 部分。
4.3.11.3. 保护 SSH 的其他方法
协议版本
尽管 Red Hat Enterprise Linux 7 提供的
SSH
协议的实现仍然支持 SSH 客户端的 SSH-1 和 SSH-2 版本,但尽可能使用后者。SSH-2 版本包含有关较旧的 SSH-1 的改进,大多数高级配置选项仅在使用 SSH-2 时可用。
红帽建议使用 SSH-2 来最大化
SSH
协议可保护使用它的身份验证和通信的扩展。可使用 /etc/ssh/ sshd
_config
文件中的 Protocol
配置指令来指定 sshd 守护进程支持的协议版本或版本。默认设置为 2
。请注意,SSH-2 版本是 Red Hat Enterprise Linux 7 SSH 服务器唯一支持的版本。
密钥类型
虽然 ssh-keygen 命令默认生成一对 SSH-2 RSA 密钥,但使用
-t
选项,也可以指示生成 DSA 或 ECDSA 密钥。ECDSA (Elliptic Curve Digital Signature Algorithm)以相同的对称密钥长度提供更好的性能。它还会生成较短的密钥。
非默认端口
默认情况下,
sshd
守护进程侦听 TCP 端口 22
。更改端口可降低系统因自动网络扫描而受到攻击的风险,从而通过模糊的方式提高安全性。可使用 /etc/ssh/sshd_config
配置文件中的 Port
指令来指定端口。另请注意,默认 SELinux 策略必须更改为允许使用非默认端口。您可以以 root
用户身份输入以下命令来修改 ssh_port_t
SELinux 类型来完成此操作:
~]# semanage -a -t ssh_port_t -p tcp port_number
在上面的命令中,将 port_number 替换为使用
Port
指令指定的新端口号。
没有根登录
只要您的特定用例不需要以
root
用户身份登录,您应该考虑在 /etc/ssh/sshd_config
文件中将 PermitRootLogin
配置指令设置为 no
。通过禁止以 root
用户身份登录,管理员可以审核哪些用户在以普通用户身份登录后运行了哪些特权命令,然后获得 root
权限。
使用 X 安全扩展
Red Hat Enterprise Linux 7 客户端中的 X 服务器不提供 X 安全扩展。因此,当连接到带有 X11 转发的不可信 SSH 服务器时,客户端无法请求另一个安全层。大多数应用程序都无法在启用此扩展的情况下运行。默认情况下,
/etc/ssh/ssh_config
文件中的 ForwardX11Trusted
选项被设置为 yes
,ssh -X remote_machine (不受信任的主机)和 ssh -Y remote_machine (可信主机)命令之间没有区别。
警告
红帽建议在连接到不可信主机时使用 X11 转发。
4.3.12. 保护 PostgreSQL
PostgreSQL 是一个对象相关数据库管理系统(DBMS)。在 Red Hat Enterprise Linux 7 中,
postgresql-server
软件包提供 PostgreSQL。如果没有安装,请以 root 用户身份输入以下命令来安装它:
~]# yum install postgresql-server
在开始使用 PostgreSQL 之前,您必须在磁盘上初始化数据库存储区域。这称为数据库集群。要初始化数据库集群,请使用命令 initdb,该集群随 PostgreSQL 一起安装。数据库集群所需的文件系统位置由
-D
选项表示。例如:
~]$ initdb -D /home/postgresql/db1
如果尚未存在,initdb 命令将尝试创建您指定的目录。在这个示例中,我们使用名称 /home/postgresql/db1。/home/postgresql/db1 目录包含数据库中存储的所有数据,以及客户端身份验证配置文件:
~]$ cat pg_hba.conf
# PostgreSQL Client Authentication Configuration File
# This file controls: which hosts are allowed to connect, how clients
# are authenticated, which PostgreSQL user names they can use, which
# databases they can access. Records take one of these forms:
#
# local DATABASE USER METHOD [OPTIONS]
# host DATABASE USER ADDRESS METHOD [OPTIONS]
# hostssl DATABASE USER ADDRESS METHOD [OPTIONS]
# hostnossl DATABASE USER ADDRESS METHOD [OPTIONS]
pg_hba.conf
文件中的以下行允许任何经过身份验证的用户使用其用户名访问任何数据库:
local all all trust
当使用创建数据库用户和没有本地用户的层次应用程序时,这可能会造成问题。如果您不想显式控制系统中的所有用户名,请从
pg_hba.conf
文件中删除这一行。
4.3.13. 保护 Docker
Docker 是一个开源项目,可在 Linux 容器内自动部署应用程序,并提供将应用与其运行时依赖项打包到容器中的功能。要使 Docker 工作流更加安全,请按照 Red Hat Enterprise Linux Atomic Host 7 容器安全指南中的步骤操作。
4.3.14. 针对 DDoS Attacks 保护 memcached
Memcached 是一个开源、高性能的分布式内存对象缓存系统。虽然它是通用的,但主要用于通过降低数据库负载来提高动态 Web 应用程序的性能。
Memcached 是一个内存键值存储,用于任意数据(如字符串和对象)的小块,来自于数据库调用、API 调用或页面渲染的结果。Memcached 允许应用程序从系统的一部分获取内存,超过其需求,并使它能被应用程序需要的区域访问。
Memcached 漏洞
2018 年,发现了向公共互联网公开的 memcached 服务器漏洞 DDoS 扩展攻击。这些攻击利用了使用 UDP 协议进行传输的 memcached 通信。攻击非常有效,因为具有高比例比例 - 几百字节大小的请求会产生几兆字节甚至几百兆字节的响应。这个问题已被记录为 CVE-2018-1000115。
在大多数情况下,memcached 服务不需要向公共互联网公开。此类风险可能有自己的安全问题,允许远程攻击者泄漏或修改存储在 memcached 中的信息。
强化 memcached
要降低安全风险,请根据您的配置执行以下步骤:
- 在 LAN 中配置防火墙。如果您的 memcached 服务器应该只可从本地网络访问,请不要允许 memcached 使用的端口的外部流量。例如,从允许的端口列表中删除默认情况下 memcached 使用的端口 11211:
~]# firewall-cmd --remove-port=11211/udp ~]# firewall-cmd --runtime-to-permanent
有关允许特定 IP 范围使用端口 11211 的firewalld
命令,请参阅 第 5.8 节 “使用区域管理流量取决于源”。 - 通过将
-U 0 -p 11211
值添加到/etc/sysconfig/memcached
文件中的OPTIONS
变量来禁用 UDP,除非您的客户端确实需要这个协议:OPTIONS="-U 0 -p 11211"
- 如果您在与应用程序相同的机器上只使用单个 memcached 服务器,请设置 memcached 以仅侦听 localhost 流量。将
-l 127.0.0.1,::1
值添加到/etc/sysconfig/memcached
中的OPTIONS
:OPTIONS="-l 127.0.0.1,::1"
- 如果可能更改身份验证,请启用 SASL (简单身份验证和安全层)身份验证:
- 在
/etc/sasl2/memcached.conf
文件中修改或添加:sasldb_path: /path.to/memcached.sasldb
- 在 SASL 数据库中添加帐户:
~]# saslpasswd2 -a memcached -c cacheuser -f /path.to/memcached.sasldb
- 确保 memcached 用户和组可以访问数据库。
~]# chown memcached:memcached /path.to/memcached.sasldb
- 通过将
-S
值添加到/etc/sysconfig/memcached
,在 memcached 中启用 SASL 支持:OPTIONS="-S"
- 重启 memcached 服务器以应用更改。
- 将 SASL 数据库中创建的用户名和密码添加到应用程序的 memcached 客户端配置中。
- 使用 stunnel 加密 memcached 客户端和服务器之间的通信。由于 memcached 不支持 TLS,因此临时解决方案是使用代理,如 stunnel,它在 memcached 协议之上提供 TLS。您可以将 stunnel 配置为使用 PSK (Pre Shared Keys),甚至最好使用用户证书。在使用证书时,只有经过身份验证的用户可以访问您的 memcached 服务器,且您的流量会被加密。重要如果您使用隧道访问 memcached,请确保该服务只侦听 localhost 或防火墙会阻止网络访问 memcached 端口。请参阅 第 4.8 节 “使用 stunnel” 了解更多信息。