提供:ZStack云计算
内容介绍
在设置基础设施、运行应用程序以及进行后期维护工作时,安全保障都是一项不容忽视的重要要求。
在今天的教程中,我们将共同了解与应用程序配置及设置相关的基础安全实践。
SSH密钥
SSH密钥是一组加密密钥对,可用于替代密码凭证登录SSH服务器。公钥与私钥相配合所建立的这套验证机制更为安全,其中私钥由用户个人持有,而公钥则可共享给其他用户。
要配置SSH密钥验证,大家需要将用户公钥保存在服务器上的特定目录内。在接入该服务器时,服务器会验证客户端的关联私钥。SSH客户会使用私钥做出响应,旨在证明自己的合法身份。要了解更多与SSH密钥工作原理相关的内容,请参阅此文。
SSH密钥是如何提升安全性的?
在SSH的帮助下,包括密码验证在内的任何验证机制皆可进行加密。不过在启用密码登录机制时,恶意人士可能会以反复尝试的方式入侵服务器。
设置SSH密钥验证允许大家禁用密码登录。SSH密钥所中容纳的字符位远超过普通密码,意味着其内容更难为攻击者所猜测。另外,目前存在多种SSH密钥算法,即使利用现代计算设备也需要极长时间才能找出正确的组合。
实现难度高吗?
SSH密钥易于设置,亦作为首选Linux或Unix服务器环境远程登录方案。SSH密钥对可在大家的个人设备上生成,且只需几分钟就能够将公钥发送至服务器。
要了解更多与密钥设置相关的内容,请参阅此教程。如果大家仍然希望使用密钥验证,则可参考fail2ban方案以降低密码被破解的可能性。
防火墙
防火墙可表现为软件(或者硬件),负责控制能够与网络相接触的各项服务。这意味着其能够阻断或者限制针对任一端口的访问,除非确认其安全。
在一般的服务器上,通常会运行有一系列服务,我们将其归为以下几类:
- 公共服务,即可由内网中的任意用户以匿名方式进行访问,典型例子为Web服务器。
- 专有服务,只允许特定认证账户组或者特定位置进行访问,典型例子为数据库控制面板。
- 内部服务,只能从服务器内部访问且不向外部公开任何服务,典型例子为只接受内部连接的数据库。
防火墙能够确保指向软件的访问根据以上分类受到相应限制。对于那些尚未使用的端口,大多数防火墙配置会直接全面屏蔽。
如何提升安全性?
防火墙属于服务器配置中的核心组成部分。即使服务本身已经实现了安全功能或者存在接口限制,防火墙也能够带来额外的保护层。
经过良好配置的防火墙应当限制除特定服务外的一切访问,同时只公开部分软件以缩小服务器攻击面、降低漏洞被利用的可能性。
实现难度如何?
目前存在大量针对Linux系统的防火墙选项,其中一些方案的学习难度较低。总体而言,防火墙的设置只需要几分钟时间,且只在服务器初始设置或者变更计算机所提供的服务时要求做出调整。
入门选项为UFW防火墙。其它选项则包括iptables或者CSF防火墙。
VPN与专有网络
专有网络是指只可用于特定服务器或者用户的网络。例如在DigitalOcean中,某些数据中心内部网络即属于专有网络。
VPN的全称为虚拟专有网络,用于在远程计算机之间建立安全连接,并作为连接机制接入本地专有网络。通过这种方式,大家能够配置服务以确保专有网络与远程服务器之间使用安全连接。
如何提升安全性?
利用专有网络替代公共网络实现内部通信已经成为一种共识。不过由于也有部分数据中心内其他用户能够访问同样的网络,因此我们仍然需要采取部分手段保护服务器间通信安全。
利用VPN,我们能够将专有网络映射为仅供各内部服务器访问,从而保证通信专有与安全。其它应用亦可通过配置经由VPN软件公开的虚拟接口发送流量。如此一来,只有公共互联网上各客户端所需要的服务才会面向公共网络公开。
实现难度如何?
在数据中心内使用专有网络与创建服务器以及配置应用与防火墙的难度基本相当。请注意,数据中心内的专有网络与其它使用同一网络的服务器共享空间。
VPN的初始设置存在一定难度,但其安全性效果绝对物有所值。VPN上的每台服务器都必须安装并配置共享安全及配置数据,从而建立安全连接。在VPN开始运行后,应用必须配置以使用该VPN隧道。要了解更多与VPN安全连接的设置方式,请参阅OpenVPN 使用指南。
公钥基础设施与SSL/TLS加密
公钥基础设施,简称PKI,这是一套专门用于创建、管理及验证证书以识别个人及加密通信的系统。SSL或者TLS证书可被用于验证不同条目,验证之后其亦可用于建立加密通信。
如何提升安全性?
建立一套证书颁发体系并为服务器管理证书,如此一来基础设施当中的每个条目都能够彼此验证成员身份并进行流量加密。通过这种方式,我们可以防止中间人攻击活动——即攻击者冒充服务器进行流量拦截。
每台服务器都可以通过配置信任集中式证书颁发机制。在此之后,任意该系统签发的证书都可直接受信。如果我们所使用的应用及协议支持TLS/SSL加密,则可利用这种方式对系统进行加密,但无需承载由VPN隧道带来的维护工作(VPN同样在内部使用SSL)。
实现难度如何?
配置认证中心并设置其它公钥基础设施组件存在一定难度。另外,管理证书往往也会给管理员带来一定强度,包括证书创建、签署或者反调。
对于多数用户,我们往往需要在基础设施的扩展过程中为其配合完整的公钥基础设施。作为权宜措施,我们可以使用VPN实现组件间通信,直到确定PKI所带来的收益已经大于日常支出。
服务审计
服务审计是指发现运行在基础设施内各服务器上服务的过程。一般来讲,默认操作系统配置会在引导时运行特定服务。安装其它软件有时候也会向引导列表中添加更多条目。
服务审计能够了解系统中正在运行的各项服务、其使用哪些端口进行通信以及能够支持哪些协议。这些信息能够帮助大家更好地配置自己的防火墙设置。
如何提升安全性?
服务器在处理各类内部任务与外部客户端时需要启动大量进程。每个进程对于恶意人士而言则代表着潜在突破口。我们运行的服务越多,攻击者利用现有软件内安全漏洞的可能性就越大。
在了解到设备中所运行的网络服务后,接下来就是分析这些服务。大家可以首先分析以下几个问题:
- 此服务是否应该运行?
- 此服务是否运行在非必要的接口上?其是否应被绑定至单一IP?
- 你的防火墙规则是否允许合法流量接入此服务?
- 你的防火墙规则是否会屏蔽不合法流量?
- 是否有方法收取与各服务内安全漏洞相关的安全警报?
此类服务审计机制应当在基础设施内任意新服务器的配置过程中成为标准实践。
实现难度如何?
执行基础服务审计其实非常简单。大家可以使用netstat命令了解各服务在各接口上监听的端口。下面来看具体示例:
sudo netstat -plunt
返回结果如下:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 887/sshd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 919/nginx
tcp6 0 0 :::22 :::* LISTEN 887/sshd
tcp6 0 0 :::80 :::* LISTEN 919/nginx
这里需要关注的是Proto、Local Address以及PID/Program name几列。如果其地址为0.0.0.0,则该服务可接收全部接口上的连接。
文件审计与入侵检测系统
文件审计是利用已知良好状态对当前系统文件及其中所记录文件特征进行比较的过程。这种方案可用于检测授权系统中的变更。
入侵检测系统,简称IDS,是一类软件,能够监控系统或者网络中的未授权活动。大多数基于主机的IDS实现方案都会利用文件审计检查系统是否存在变更。
如何提升安全性?
与以上提到的服务层审计类似,如果大家需要严格保护系统安全,则可在系统中执行文件层审计。我们可以通过周期性方式将IDS作为自动化流程的组成部分。
一般来讲,攻击者希望能够在系统中隐藏一段时间,在此期间文件系统审计会及时发现其活动痕迹,这也将巩固我们对于系统完整性的信心。
实现难度如何?
实现IDS或者进行文件审计往往是个相当困难的流程。在初始配置中,我们需要告知审计系统任何在服务器上进行过的非标准变更,同时定义用于创建基准读取流程的路径。
这些工作往往带来大量日常负担。更新流程会更加复杂,我们需要在更新前重新检查系统,并在运行更新后针对新版本重新构建基准。大家还需要将报告迁移至其它位置,这样入侵者就无法干扰审计工作来掩盖自己的足迹了。
值得关注的文件审计/入侵检测系统包括Tripwire与Aide。
隔离执行环境
隔离执行环境是指能够使不同组件在自身专有空间内运行的任何实现方法。
这意味着我们可以对服务器中的应用组件进行拆分,也可以参考配置服务并将其运行在chroot环境或者容器当中。隔离性的实际水平取决于应用自身要求及基础设施的具体情况。
如何提升安全性?
将各进程隔离为独立执行环境能够帮助我们有效分散各类安全问题。类似于利用bulkheads与专区帮助容器抵御内部漏洞,将各组件进行拆分也能够限制入侵者对基础设施内各部分的访问能力。
实现难度如何?
根据实际方案,应用隔离工作的难度并不太大。我们可以将独立组件封装至容器之内,从而实现快速隔离,不过Docker方面并未将其容器化技术作为安全功能加以考量。
为每个组件设置一套chroot环境同样能够实现隔离效果,但这也并非万无一失的办法,因为通常有多种方式能够突破chroot环境。将组件迁移至专有设备往往效果最好,也最易于实现,但会因添置大量设备而带来可观的实现成本。
总结
上述策略只是提高系统安全性的部分途径。需要强调的是,采用某种安全方案的时间点越晚,其效果就会更差。所以请大家尽快行动起来,抢在恶意人士之前部署保护措施。