在这里,我们已经有关于强化Apache,强化PHP和保护SSH的问题。

要继续这种趋势,我对人们采取什么措施来强化Linux服务器很感兴趣。就像人们在设置新服务器时总是采取什么步骤一样,这些步骤不是特定于应用程序的。例如将tmp分区设置为noexec,卸载/禁用某些服务,例如

评论

我为这个问题添加了一笔赏金,因为我希望看到一些更详细的答案,而不仅仅是指向其他列表的链接。寻找关于强化Apache问题的最佳答案之类的东西-security.stackexchange.com/questions/77/apache-server-hardening / ...

@Mark恕我直言,我会信任与CIS等基准测试的链接,这远比我会信任随机列表来加强Linux服务器的工作要多得多。 CIS比其他人在此站点上提出的内容要深入,经过同行评审和证明。

这就是为什么我将答案保留为需要考虑的关键事项列表的原因,但又足够笼统,以至于它们适用于几乎所有Linux服务器。

这感觉就像一个维基问题。 “正确”的答案是什么样的?最长的时间是谁? :)

@nealmcb我确实很感谢这个问题的难度,而且如果人们希望特定于发行版的话,它的范围很广。我个人使用Debian和Ubuntu服务器,因此为他们量身定制的答案很棒。

#1 楼

确定所需的应用程序和流程,并应用清单,以避免安装它们,或者在初始构建后最坏的情况下将它们卸载。默认情况下有很多发行版!


NFS服务:nfsd,lockd,mountd,statd,portmapper
telnet服务器和ftp服务器
R服务:rlogin,rsh,rcp ,rexec
BIND和DNS服务器,除非需要
邮件服务器,例如sendmail
X11(除非需要桌面)
finger守护程序等

下一步是遍历潜在的弱服务并限制对它们的访问


使用at.allow和cron.allow限制对crontab的访问
确保所有设备对普通用户都是不可读和不可写的(不包括/ dev / tty和/ dev / null等文件)
密钥文件-这些文件的权限应归root用户所有:
/ etc / fstab,/ etc / password,/ etc / shadow
仔细检查hosts.equiv-大量访问权限s此处:-)
类似地,如果需要NFS配置,则将其锁定。
禁用不需要的系统帐户。
查看文件系统-所有可执行文件和公用目录的粘滞位。
检查所有根目录要求(PATH环境变量,没有以root身份进行远程访问,组成员身份,密码要求)
检查所有用户要求(特权组的成员资格,有效的shell,umask,SUID,SGID要求
,当然,SANS指南是一个非常好的来源!


评论


可能是一个愚蠢的问题,但是...为什么不应该允许用户写入/ dev / null或从中读取?我知道还有其他方法可以获取其功能(例如verboseprogram | :)?是否曾经有过不安全的/ dev / null实现?

–Parthian Shot
14年7月14日在20:05

不包括,Parthian

–Rory Alsop♦
14年7月14日在20:19

谷歌多一点哦。你偷偷摸摸的秃鹰...

–Parthian Shot
2014年7月14日20:49



“确定所需的应用程序和过程并应用清单,以避免安装它们”为什么要避免安装所需的应用程序?我假设您的意思是“标准但不是必需的应用程序”?

–西蒙东
15年7月29日在6:13

#2 楼

“ Linux服务器”空间包括各种发行版,每个发行版都有其自己的默认配置更新策略,程序包管理工具链以及默认服务和开放端口的方法。还有多种部署方案:加固Web服务器与加固基于Linux的路由器有很大不同。通过询问您最关心的发行版和用例,您可能会得到更好的建议。

我会在这里通过指向一些相关资源来解决Ubuntu安全性,尽管其中大部分会在其他情况下也很有用。

此处是一个很好的介绍:http://www.andrewault.net/2010/05/17/securing-an-ubuntu-server/

社区在这里描述了一些更严格的默认设置和强化技巧,即使在可用性受到影响的情况下,它们也更倾向于安全性:https://help.ubuntu.com/community/StricterDefaults
Ubuntu安全功能摘要,以帮助人们研究您在其他地方找到的清单:https://wiki.ubuntu.com/Security/Features

要查看如何自己进行一些测试,请查看http://people.canonical.com/~kees/demo/ec2-session.log
中的脚本由http://people.canonical.com/~kees/demo/
执行以下操作的摘要:https ://wiki.ubuntu.com/Security/Privileges

Ubuntu的安全团队在其wiki上还有一些其他有用的东西:https://wiki.ubuntu.com/Security/

#3 楼

时间点系统强化是一项有益的壮举,但真正定义安全部署服务器的方法是维护该状态。

选择任何质量检查清单(请参阅下面的链接),其中详细列出了推荐的检查清单。进行配置修改以增强服务器的安全性,并应用对您的设置有意义的那些更改。更好的是,通过Puppet(http://www.puppetlabs.com/)整理建议:这是双赢的方式,您将可以更安全地部署,并且可以长期获得强化配置的战斗机会。

奖励:做攻击建模/威胁建模(http://taosecurity.blogspot.com/2007/06/threat-model-vs-attack-model.html)来集中精力进行防御。例如,问自己一些问题,例如:


攻击者如何获得对这些服务器的访问权限?


将您对第二个问题的答案转换为特定的配置更改(强化)或通过实施其他控件。当然,该游戏是要最大程度地降低任何威胁成功的可能性。这会花费一些时间,但是您会对所做的更改以及为什么进行更改而不是偶然进行更改感到满意,因为有人说这样做很好。

擅长记录和审查。预防总是会失败–为了应对这种现实,您想要增强日志记录,以便可以更快地识别事件并做出反应,并更快地恢复。 OSSEC(http://www.ossec.net/)是我最喜欢的增强防御和增强Linux登录性能的工具。花费额外的时间来定制OSSEC随附的规则以监视您更关心的事情是一项值得的活动(例如,列出其他目录和文件(如果它们被修改了,则在发出警报时予以警告),添加规则或提高现有规则的严重性以进行警报)您要进行身份验证异常,添加规则以监视mysql用户表的更改(http://blog.rootshell.be/2011/01/07/auditing-mysql-db-integrity-with-ossec/),无限制) 。理查德·贝特里奇(Richard Bejtlich)刚发布了一个及时的博客文章,标题是防御者的七个很酷的开源项目(http://taosecurity.blogspot.com/2011/01/seven-cool-open-source-projects-for.html)

为了支持对服务器防御的持续验证,您可以使用Internet安全中心(CIS)Linux审核模板持续运行Nessus(http://www.nessus.org/nessus/)。将结果用作基准,注意更改并修复发现的弱点。

回顾一下:

1)利用现有的安全强化检查清单来帮助您起草一个适合您的环境的自定义清单(希望在执行攻击/威胁建模活动和选择配置管理框架)

2)增强观察功能:增强日志记录(即,调整系统以为要观察的活动生成足够的日志),部署HIDS(例如OSSEC),部署日志分析工具(例如logwatch-http://sourceforge.net/projects/logwatch/),也许捕获网络流(例如通过softflowd)

3)成为系统的坚定捍卫者有责任

4)持续进行审核和测试,以验证您认为正在完成的工作

基准/清单资源:。


http://cisecurity.org/互联网安全中心(CIS)是一家非营利性企业,其基准和指标部门可以帮助组织降低业务和电子商务的风险由于技术安全控制不足而造成的中断。该部门为企业提供了有关安全配置的共识最佳实践标准,以及用于衡量信息安全状态和做出有关安全投资的合理决策的资源。

http://iase.disa.mil/stigs / checklist /国防信息系统局(DISA)

http://web.nvd.nist.gov/view/ncp/repositoryhttp://csrc.nist.gov/fdcc/faq-common_security_configurations。 html
由NIST SP 800-70修订版1定义的国家检查清单计划(NCP)是美国政府可公开获得的安全检查清单(或基准)的存储库,可为设置安全配置提供详细的低级指导操作系统和应用程序。


#4 楼

您可能会比从Sans清单开始做得差很多。

对此,我唯一的批评是,它没有足够强调管理已部署系统的安全性-特别是确保供应商补丁程序可以日期,规划良好的权限模型,管理IDS异常报告等。

#5 楼

首先,您必须确定服务器的用途以及要防御的威胁模型。它是一次性服务器吗?多个用户可以访问吗?如果多个用户可以访问,您是否全部信任他们?

让我假设此服务器仅用于网络服务,并且您不必应对来自某人的攻击威胁谁在您的计算机上拥有一个帐户。请按以下步骤操作:


启用防火墙。我使用iptables设置本地防火墙。我使用默认拒绝策略:默认情况下,除非防火墙策略中明确允许,否则所有传入连接都默认被阻止。我启用了到要导出到世界的服务的传入连接(例如,如果端口25是邮件服务器,则为端口25;如果是网络服务器,则为端口80/443,依此类推)。 iptables对状态过滤提供了出色的支持,因此一旦建立连接,所有与该连接相关联的数据包都将被允许。
升级所有软件包,并启用自动更新。我将Linux发行版更新为所有软件包的最新版本(Fedora上为yum upgrade,但请使用适合您的配置的任何版本)。我还设置了一个cron脚本来每天自动获取并安装一次更新(在Fedora上为yum -y upgrade)。我意识到一些有经验的系统管理员可能会建议您不要进行自动更新,因为存在更新中断某些服务的风险。您必须权衡该风险与由于过时的软件包而导致的安全破坏风险。就个人而言,我认为自动更新的省心和方便值得中断服务的风险,但这可能不是在所有操作设置中的正确答案。
启用S​​ELinux。 SELinux提供了第二层防御,可以抵御对公开服务的攻击。有时可能会有些痛苦(它有时会给我造成问题,以难以调试的方式破坏服务),但是对于安全性至关重要的设置,我认为这是值得的。
设置SSH进行远程管理。您应该设置SSH,以便可以远程管理计算机。我建议您在客户端上生成DSA私钥,使用口令对其进行加密,在服务器上的authorized_keys文件中安装相应的公钥,然后使用私钥登录。您可能还想在服务器上自定义sshd_config配置文件。考虑禁用PasswordAuthentication并要求人们使用公共密钥登录。万一您的私钥出现问题,密码身份验证可能是一个有用的后备方法,但这也带来了更大的风险,因为人们通常会选择可猜测的密码。如果您的系统上还有其他用户无法选择高质量的密码,则可以禁用PasswordAuthentication。如果只有您自己并且对所有密码都非常有信心,则可以将其保持启用状态。我不会阻止root用户通过SSH登录,但是您可能会有所不同。
如果您有多个系统管理员,请为其设置帐户。为每个用户授予sudo访问权限,或者为每个sysadmin设置一个单独的根帐户。
启用DNSSEC。我将服务器配置为运行本地缓存DNS服务器,该服务器尽可能使用DNSSEC验证主机名,以减少DNS欺骗的风险。

然后,对于暴露给全世界的每项服务,我都会采取预防措施以确保该服务的安全。例如,我尽可能启用加密功能(例如,邮件服务器为STARTTLS)以及chroot或沙盒服务器。但是,具体内容因服务而异。因此,我建议为您打算运行的每个服务提交一个单独的问题,以寻求有关如何锁定该服务的建议。

如果您正在寻找已经具有出色功能的Linux发行版,如果要进行大量的加强,我强烈建议您使用Openwall Linux。 。如果您对此感到担心,建议您提出一个单独的问题,即如何锁定服务器以防止服务器上的帐户受到本地用户的攻击,因为这样做的技术方法完全不同。)

#6 楼

还有Grsecurity / PAX内核补丁,这些补丁包括非常好的功能,可以在内核级别强化服务器。

摘要:


保护堆和堆栈溢出
隐藏其他用户进程
基于角色的访问控制列表
Chroot强化
/ proc,FIFO和dmesg限制
高级日志记录功能


#7 楼

对于Red Hat,NSA提出了加强建议。请参阅Red Hat Enterprise Linux 5的配置指南-NSA / CSS。

它们也应对CentOS和其他衍生产品有用。

评论


感谢@ graham-lee在Windows 2000问题中指出了聊天中的NSA链接。如果需要内部消息,请加入聊天!

–nealmcb
2011年2月3日在21:10

链接已死。

–user22208
13年6月21日在1:16

@EvanTeitelman谢谢。通过简单的Google搜索修复的链接。

–nealmcb
2013年6月21日14:26

#8 楼

对于RHEL而言,Internet安全中心提供的CIS Red Hat Enterprise Linux 5 Benchmark似乎是不错的资源。

#9 楼

如果您试图通过卸载不需要的软件包/服务来保护系统,那么您已经遇到了更大的问题。这些软件包不应该首先安装。

您应该安装一个简约的系统,仅添加您真正需要的软件包。同样适用于您的内核。仅使用所需功能来编译自己的内核。不要在支持所有功能的情况下使用发行版内核(无论如何您都不需要95%的支持)

评论


虽然安装最小的系统并从那里开始是个好主意,但是滚动自己的内核将很快使人沮丧。 1:每次有新的安全修复程序出现时,您都需要自己重新编译它。 2:如果您使用的是RHEL或SLES,则运行用户编译的内核的系统(尤其是具有自定义.config的内核)处于“不支持”状态。将不使用的mod列入黑名单是个好主意。

–休伯特·卡里奥(Hubert Kario)
2013年12月6日15:19

您拥有的内核越小,出现安全漏洞的机会就越少。如果您排除了95%不需要的功能,那么您还将摆脱95%的“攻击面”。此外,如果数百万用户使用相同的内核,则在该特定内核中更容易发现漏洞。

–马丁·维格特(Martin Vegter)
2013年12月6日18:23



我并不是说这不会对安全性有所帮助。我是说,这需要管理员方面的大量努力,并且服务器运行过时内核的可能性更大(因为管理员忘记了或没有注意到或没有时间准备新的配置等)。第二个问题是,如果您依赖第三方支持,则使用自定义内核配置可能根本就不可能。

–休伯特·卡里奥(Hubert Kario)
2013年12月8日上午10:36