是否经常进行“ apt-get升级”以确保Web服务器的安全？

#1 楼

您已经消除了许多通常会给您带来麻烦的问题（即假设您托管的应用程序是完全安全的）。从实践的角度来看，您绝对必须考虑这些。

但是大概是因为您知道它们，所以您已经采取了一些保护措施。那么，让我们来谈谈其余部分。

首先，您可能不应该“经常”运行更新。大多数发行版都运行安全公告邮件列表，并且一旦在其中发布漏洞，它就是公开的（嗯，通常早于此，但是在您的情况下，您无法真正监视世界上所有的安全列表）。这些是低流量列表，因此您应该真正订阅发行版并在收到通知时进行升级。

通常，长时间不经意维护的服务器可能会受到暴力破解或长期受到字典攻击一段时间，因为维护人员并没有真正寻找迹象。这是一个好主意，然后应用通常的对策-无需ssh密码身份验证，ssh和apache上的fail2ban-理想情况下是在发生可疑活动时设置监视警报。如果这超出了您的维护（时间）预算，请养成定期登录以手动检查这些内容的习惯。

虽然传统上不将其视为安全性的一部分，但您要确保可以快速启动新服务器。这意味着服务器配置脚本（无论如何，Ansible，Chef等工具在系统管理中都很有用）和经过测试的自动备份系统。如果您的服务器遭到破坏，则必须假定它已永远受到威胁，只需擦除它即可，如果您不定期备份数据，那会很糟糕。

#2 楼

不能。这不足以确保您的安全。
它可能会使您获得一定的安全，但是安全性复杂且节奏很快，因此您的方法对于长期的安全性而言确实不够好。如果每个人都做出与您在问题中所做出的相同假设，那么互联网到现在将是一个大型僵尸网络。
所以，不，我们不应该将这个问题局限于软件包。让我们从整体上看一下服务器的安全性，以便任何人阅读此书后都可以真正了解有多少个移动部件。


APT（例如Ubuntu的存储库）仅覆盖了软件堆栈的一部分。如果您正在使用（例如）Wordpress或其他流行的PHP库且不受仓库控制，则也需要对其进行更新。较大的框架具有自动执行此操作的机制，但请确保备份和监视服务状态，因为它们并不总是运行良好。


您自己编写了所有代码，因此您认为自己从脚本小子安全吗？到处都有自动SQL注入和XSS漏洞攻击机器人，戳每个查询​​字符串和形式都一样。
实际上，这是一个好的框架可帮助防止那些不了解这些攻击的细微差别的程序员的地方之一。让合格的程序员审核代码也可以缓解这里的担忧。


PHP（或Python，或您正在运行的任何东西）真的需要能够在任何地方编写代码吗？加强配置，可以缓解许多攻击。理想情况下，Web应用程序只能写数据库的地方，就是永远不会执行脚本的地方（例如，仅允许提供静态文件的Nginx规则）。
PHP默认（至少人们使用它们的方式）允许PHP在webroot中的任何位置读写PHP。如果您的网站被利用，这将产生严重的影响。
注意：如果您确实阻止写访问，则WordPress之类的内容将无法自动更新。查看类似wp-cli的工具，并使其按计划运行。


更新时间表对人体有害。 “每隔如此频繁”到底是什么？严重的远程安全漏洞的半衰期很短，但是0天和补丁程序可用性之间已经存在延迟，并且一些漏洞利用程序也从补丁程序中反向工程（以捕获缓慢的戳记）。
如果您只是每个月应用一次更新，很有可能您将在野外运行可利用的软件。 TL; DR：使用自动更新。


版本不会永远持续下去。如果您明智并选择了LTS版本的Ubuntu，那么距初始发行还有5年的时间。在此期间还将推出另外两个LTS版本，这为您提供了选择。
如果您处于“ NEWER IS更好”的水平，并且在设置服务器时使用16.10，则您有9个月的时间。是的然后，您必须先升级到17.04、17.10，然后才能在18.04 LTS上放松。
如果您的Ubuntu版本过时，则可以整天进行dist-upgrade，但是您不会获得任何安全性升级。 />

LAMP堆栈本身并不是标准Web服务器的唯一攻击媒介。


您需要加强SSH配置：仅使用SSH密钥，禁用密码，绕开端口，禁用root登录，监视暴力破解尝试并使用fail2ban阻止它们。
使用ufw（及其他）阻止所有其他服务。
切勿暴露数据库（除非公开该数据库（除非您需要，然后将传入IP锁定在防火墙中。）
请不要安装随机的PHP脚本，否则您会忘记它们，它们会遭到黑客入侵。



您的描述中没有监视。你真瞎如果确实有什么事情发生，并开始大量发送垃圾邮件，感染您的网页等，您如何分辨发生了什么不好的事情？过程监控。计划文件与git的比较（确保它是来自服务器的只读访问权限）。


请考虑ISP的安全性（物理和远程）。是不是一毛钱一头的“主机”（又名CPanel海盗）—抢购了每月2美元的无限制托管计划—在安全性上投入了与专用服务器设施相同的资源？询问并调查违规的历史。
注意：公开的违规不一定是一件坏事。小型主机往往没有任何记录，当事情被破坏时，没有许多知名主机和服务执行的公共“事后调查”。


然后有您。编写所有这些代码的计算机的安全性几乎与服务器一样重要。如果您使用相同的密码，则应承担责任。使用物理FIDO-UF2密钥保护SSH密钥。


我从事devop已有15年了，这是您可以在工作中学习到的东西，但实际上只需要花费一点时间一个漏洞（一个少年，一个机器人）会毁坏整个服务器，并导致数周的工作对工作产品进行消毒。
仅了解运行的内容和暴露的内容，有助于您更好地做出决定。我只是希望这可以帮助某人开始审核服务器。
但是，如果您（每个人都是普通的Web应用程序程序员）不愿意研究此类内容，那么您是否应该运行服务器？这是一个严重的问题。我不会告诉您绝对不应该，但是当您忽略所有这些，服务器被黑客入侵，客户亏损，暴露个人客户信息（例如帐单数据）并遭到起诉时，您会发生什么？ ？您是否为这种损失和责任承担了保险？
但是，是的，这就是为什么托管服务比笨拙的服务器要贵得多的原因。
借助备份...
完整的系统备份可能是您最糟糕的事情，以确保安全性-因为一旦遭到黑客入侵，您将很容易使用它。它们唯一的位置是从硬件故障中恢复。
在黑客中使用它们的问题是您将其重置到了更早的时间点。现在，您的堆栈中出现了更多的漏洞，甚至存在更多漏洞利用。如果您将该服务器重新联机，则可能会立即遭到黑客攻击。您可以对传入的流量进行防火墙保护，并进行软件包升级，这可能会对您有所帮助，但是目前您仍然不知道是什么原因或何时获得的。您将所有假设都基于所看到的症状（页面上出现广告注入，mailq中的垃圾邮件被反弹）。入侵可能早于几个月。
它们总比没有好，并且在磁盘快要死的情况下还可以，但是同样，它们对于安全性也很垃圾。
好的备份是秘诀
您需要某种东西-仅仅是一种普通语言的文档，或者是诸如Ansible / Puppet / Chef例程之类的技术，它们可以指导某人将整个站点还原到一台全新的服务器上。要考虑的事情：

要安装的软件包列表
要进行的配置更改列表
如何从版本控制中还原网站源。
如何还原数据库转储*，以及您可能没有版本控制的任何其他静态文件。

您在这里越详细，越好，因为它也可以作为个人备份。我的客户知道，如果我死了，他们有一个经过测试的计划，可以将其站点还原到直接控制的硬件上。
脚本化的良好还原应该不超过5分钟。因此，即使在脚本化还原和还原磁盘映像之间的时间间隔也很小。
*注意：数据库转储也必须检查。确保系统中没有新的管理员用户或随机脚本块。这与检查源文件一样重要，否则您将再次遭到黑客攻击。

评论

---

如果没有造成感染，即使经过数周的消毒工作，也无法确保已清除所有感染。这就是为什么您必须备份。工作产品，数据库，服务器配置以及所有其他可以替换的备份。如果作为OP来控制服务器，则应该从内核开始对整个系统进行备份。

–user135823
17-2-23在4:04

---

我不认为我会对内核备份有所不同。它们是浪费时间，会导致盲目恢复和解决问题的思想。备份应该是有关如何组装您唯一的东西的描述性食谱。像任何食谱一样，它们应该经过测试和完善。可能只是编写它会使您的配置更好。完全备份仅应用于硬件故障，即使那样，脚本化配方也将几乎一样快。

–奥利
17-2-23在11:20

---

#3 楼

如果您经常运行更新（即至少每天运行一次，而不是仅“经常”运行），则很有可能使服务器保持大部分安全。

但是，有时会发生诸如Shellshock或ImageTragick之类的严重错误。另外，不安全的服务器配置也可能使攻击成为可能。这意味着除了运行常规更新之外，您还应该采取更多措施，例如：


通过运行最小的系统来减少攻击面，即不要安装任何不必要的软件
通过限制可从外部访问的任何服务来减少攻击面，即不允许基于密码的SSH登录（仅基于密钥），不要运行不需要的服务等
确保您了解关键更新的影响
/>期望系统受到攻击并尝试减少影响，例如通过运行可从chroot，jail或容器内部从外部访问的服务
记录重要事件，例如登录失败，了解日志并实际分析日志

仍然，最常用的初始攻击媒介可能是不安全的Web应用程序，例如Wordpress或其他CMS。但是您的假设是Web应用程序是完全安全的，因此希望它确实是安全的。

#4 楼

大多数现代Linux发行版都带有某种自动更新解决方案。您应该考虑在服务器上打开它。这将大大减少服务器遭受攻击的时间。

提到Debian时，您应该考虑设置无人值守的升级。 RedHat具有yum-cron，Suse可以通过YaST来获取它们。

这些升级通常仅限于安全补丁，不太可能破坏系统，但是并非完全不可能。最终由您来权衡此方法的风险和收益。

#5 楼

apt-get upgrade仅安装已安装软件包的较新版本。它不会安装当前未安装的软件包，并且如果较新版本取决于当前未安装的软件包，它将不会升级已安装的软件包。

在Debian和Ubuntu中，每个版本的内核放在单独的程序包中，其名称中包含版本。此外，还有一个虚拟软件包，该软件包始终依赖于最新的可用内核，并且依赖关系随每个版本而改变。例如，到目前为止，xenial中的linux-image-generic取决于linux-image-4.4.0-63-generic。此方案允许保留旧版本的内核，并在较新版本与您的硬件不兼容的情况下进行安装。但是，许多人避免自动使用它，因为它也可以删除软件包。在较新版本的Ubuntu中，您可以使用apt-get upgrade，它会安装新的依赖项，但从不删除任何软件包。

此外，在升级OpenSSL时，您至少需要重新加载使用该库的服务；在Ubuntu中，系统只是要求重启才能保持安全，许多人对自动重启也持保留态​​度。

#6 楼

这里已经有一些不错的答案。但是，我想填补一些空白
，并指出一些现有答案中似乎没有解决的问题。


不是某些超级黑客或政府组织直接针对的目标


这是一个危险的观点。基于这种核心思想的变化，许多小型组织被迫破产。您确实无法预测谁会找到黑客入侵服务器的用途或原因。正是由于这种基本假设，政府或超级黑客可能会针对您的系统。他们可能对您的应用程序或数据不感兴趣，他们可能只是想将无辜的“跳脱”点用作更有价值的目标上更大或更复杂的hack的一部分。


正常的LAMP Web服务器正在运行Web应用程序。 （例如AWS EC2 + Apache2 + MySQL + Php7）


注意“正常”。您的设置可能与您想象的不一样。
很大程度上取决于您安装了什么以及软件包来自什么存储库。
需要注意的一些变体包括-


分布类型。例如，Ubuntu LTS
和非LTS发行版之间有很大的区别。根据经验，非LTS发行版通常会更频繁地进行更新，因此更频繁地执行
更新（或查看更新-参见下文）非常重要。
存储库类型。大多数发行版（包括Ubuntu）都具有不同类型的
存储库。 Ubuntu维护着一些核心存储库，它们通常经过相当强大的测试周期，并且可以相当及时地接收更新。然后是核心分发团队不维护的“ contrib”类型存储库。这些可以是第三方合作伙伴
或其他用户或开发组。这些重点是什么
存储库的差异可能很大。有时，他们会高度关注
安全性，而不太关注稳定性，而其他人则会关注稳定性而不是安全性。了解/了解已从中安装软件的存储库
很重要。
知道要安装什么。很多时候，您会听到一个系统被破坏而仅被发现是在一个被忽视的程序包中发生了妥协-
是默认安装的系统，还是LAMP堆栈所需的系统，
但是您没有意识到这是一个深埋或微妙的依赖。确保
已删除所有不必要的软件包（这可能很难确定
，尤其是某些软件包具有某些不寻常的依赖性）。
辅助库。通常会忽略已安装
但不受apt生态系统管理的其他库。例如，出于某些特殊目的，需要一个
PHP库，该库要么不在发行版标准负载中，要么由于其他依赖性而需要在系统上构建。一个常见的示例是用于商业
数据库的PHP数据库驱动程序。自从我上次必须管理基于PHP的堆栈以来，情况可能会有所改善，但是我回想起曾经必须为Oracle构建PHP驱动程序的时候。尽管该过程比较简单，但您必须
记住将依赖库升级到
后，重新构建该驱动程序，以确保该库与已修补的版本链接。这也可能是带有OpenSSL之类的问题。发行版可能会安装共享库的升级版
，但是您可能需要采取其他措施来确保您的应用程序实际上是在使用升级版库，而不是已知的旧版
库。漏洞。

您应该每天检查更新，然后将这些更新检查为
评估它们的重要性和破坏系统的潜力。尽管Ubuntu的apt-update过程非常健壮并且很少破坏事物，但确实会不时发生。由于强调稳定性，尤其是对于LTS
版本，因此更新过程将趋于保守，因此您需要查看
，而不仅仅是运行apt-get升级。例如，由于可能的依赖性问题
以及引入不稳定或破坏的可能性，有时，您
需要进行“ dist-upgrade”。 Ubuntu会故意这样做，以使您明确需要注意，即可以信任apt-get upgrade不会破坏事物，但可能不会安装所有安全修复程序。 apt-get dist-upgrade
将更加努力以确保应用了所有安全更新，但可能会破坏某些内容，因此
管理员必须格外小心。

不幸的是这里没有真正的捷径。现实是
您处在一个不完美的情况下，您的开发人员正在为一家小型公司工作，而又无法负担聘请开发人员和专门的
管理员。您需要以使业务风险最小化的方式来应用有限的资源，并确保业务部门知道这些风险是什么，并了解可能发生的后果和可能发生的后果-他们需要在知情的情况下进行操作
位置，并知道他们已在知情的基础上做出了决定。希望最好，但请确保您已计划好了。拥有可靠且经过测试的备份。应用更新之前，请先了解更新的作用。监视
安全列表以了解新出现的威胁，并可以
评估暴露的风险并查看日志以确认您的假设。每天检查
是否有更新。决定每天不应用更新是很合理的，但只有在您评估了它们是什么以及对其进行了修补之后，再进行
能够在知情的基础上做出决定。


与上述要点相关，没有社会工程学和Web应用程序本身是安全的。


相信自己知道并且知道可以与世隔绝。我已经失去了
安全评估显示我不知道的漏洞的次数。 PHP（或涉及的任何其他
层）中的漏洞很可能尚未被发现-或更糟糕的是，错误者已经发现了这些漏洞并且尚未广为人知。当安全专家对应用程序进行评估时，他们将永远不会声明该应用程序是安全的。他们会说未检测到任何漏洞，但这并不意味着
不存在。

#7 楼

这绝对是一个好习惯，应该成为服务器安全例程的一部分。很难说出您的安全计划是否需要超过一种实践，但是我从未见过，也没有想到没有以此为基础的良好安全计划。

不修补已安装的软件和服务会带来很高的安全风险，因为在那些软件包中发现的错误和漏洞通常可能会导致通过漏洞利用而完全访问该文件箱。这是攻击者将尝试的第一件事，如果不是第一件事。

但是系统配置错误也是攻击者危害系统的关键方法之一。仅修补软件并不一定能纠正错误的配置。有时会发生这种情况，但这是因为配置错误是由该应用程序的原始安装引起的。

要看的一件事是您的任何服务是否以root用户身份运行。在很多情况下，这是个好主意，但是碰巧服务是以root身份运行的，因为安装它的人要么不了解，要么无法让它作为非root用户运行。超级用户。那只是一个例子。

无论使用什么操作系统，都会有关于如何加强OS的最佳实践。从那里开始，然后专门加固所有已安装的服务/软件包，例如MySql，apache等。

如果在部署过程中操作系统和所有服务都是根据最佳实践专门完成的，那么在此之后可能会应用补丁是您唯一需要做的事情。

我之所以说是可能的，是因为这还不确定。这将取决于变更过程以及这些过程是否涵盖维持适当的安全性。提议的更改是否经过安全审查？结帐是否包括特定于安全性的测试？这些问题的答案通常是“否”，因此管理员可能会发生错误并且不会发现错误。

#8 楼

基本上，您不能确保Web服务器的安全。有0天的漏洞利用，可能在发现后几个小时内得到修复，但那时已经被利用。一个好的托管公司可能能够及时采取措施应对此类威胁。但是，受管服务器价格昂贵（假设托管人的管理人员不值钱）。但是，他们可能决定使服务器脱机以防万一，他们认为这是消除当前威胁所必需的，它优先考虑安全性而不是可用性-如果您始终需要安装箱并做出响应，那么这可能是错误的安全性。每小时中断一次，您会损失多少钱和多少生命？

其他地方也可能发生数据泄漏。备份是否安全存储？ （确保不受远程和物理访问的侵害；在一种情况下，我能够证明数据从现场站点而不是备份现场泄漏出来，而是从备份中证实）某人闯入服务器机房有多容易？不需要像Lex Luthor这样的超级犯罪分子直接攻击您（毕竟，他只是在40个蛋糕之后），但是您可能会造成附带损害。而且，是的，我看到过秘密的服务器场（案例1：意外打开了错误的门，显然有些白痴忘记了锁，而另一些白痴却决定在外面安装门把手，案例2：想找出原因为什么在一些共享存储设施中，刨花板后面有如此多的碎屑热量，而这些存储设施可以以平方米为间隔。从理论上讲，由专业公司运营，实际上……很好。一个人可能会抓住机会，举起一些服务器或驱动器，在eBay上出售它们，然后再走运。

对基础结构的远程攻击也经常被忽视。严格说来，这与服务器的安全级别无关，但是，如果有人攻击管理基础结构或为您的apt-get更新提供软件包的代理，则安全性仍会以某种方式降级。是的，有些人这样做很有趣。

我认为AWS EC2在这种情况下是相当安全的，但是AWS EC2仅作为示例提供，而事实并非如此。 OP的问题（不同于Web应用程序本身是安全的声明-可能是为了防止我们讨论有关SQL注入等的所有战争故事。）