如果您遭受多次重新感染,您的网站是帐户中的许多网站之一,那么您遇到跨站点污染的可能性很大。
跨站点污染是由于在服务器或帐户配置上的隔离差的情况下,站点受到相同服务器中的相邻站点的负面影响。这种现象是VPS /专用/共享托管安全或不安全辩论的最大贡献者之一。
跨站点污染的最大贡献者是我所说的汤厨房服务器。汤厨房的服务器是人类已知的每个安装和配置的环境。它可能包括10或100的不同站点或不同的平台(即Drupal,Joomla,WordPress等)。问题不是数量。他们也可能包括生活在不同阶段的网站 – 开发,分期,制作。
这些配置的最大罪魁祸首是机构,自由开发商和有抱负的主机。
功能隔离引物
功能隔离的概念不是新的,而是难以应用。这是一个想法,一个环境应该只用于一个目的。一个典型的例子可能是将Web服务器用作电子邮件服务器,反之亦然。一般的经验法则是,使用环境不止一个目的是不好的做法。然而,理论和实践应用总是两个不同的东西。
大多数组织(个人)不会梦想每个站点都有服务器,在许多方面都是不切实际的。所以我的建议是通过三件事情来解决:技术,功能和阶段。
- 技术:不要混合技术,如果你能帮助它。例如,不要使用WordPress站点部署Drupal站点等…每个平台都有根本的不同,并且更容易强化与尝试记住环境中存在的环境相似的环境。
- 功能:不要混合服务器功能。如果您有电子邮件服务器,请不要将其用作文件服务器或Web服务器等…使用环境来实现。
- 舞台:不要为每个场地混合不同阶段的生活。是指在开发,测试还是生产阶段。至少应该有至少两个环境 – 开发和生产。三个是理想的(包括测试),但是对于许多不是实用的(或成本高昂的)。
接下来你想要考虑的 – 帐户。
共享主机的安全性差,声誉不佳,但并不完全准确。虽然这是真的,但过去一直存在挑战,我们大概在2010/2011。这些天,共享主机的问题不是共享的主机本身,而是一对多的关系网站所有者拥有他们的帐户和网站。
示例:一个帐户有100个站点。
在这些配置中,我们看到的攻击并不是在共享主机上的帐户之间横向移动的攻击,而是在同一个帐户内横向移动的攻击。
当您配置帐户以为每个站点创建唯一用户时,请务必确保用户不能在同一帐户的用户之间移动权限,这一点非常重要。
网站防火墙和跨站点污染
对于网站所有者来说,最令人沮丧的是当他们部署所有推荐的安全控件,并且继续受到感染。我们一直在与客户部署我们的控件,包括我们的防火墙,并重新发现。
在10个例子中的9个中,由于内部攻击(而不是外部)而发生再感染。然而,这样做的挑战是需要调查和教育。
- 内部攻击:恶作剧能够利用环境中的内部弱点,通过在整个环境中横向移动来执行恶意行为(例如:跨站点污染)的攻击。
- 外部攻击:恶作剧者能够远程利用弱点进行访问并继续执行恶意行为的攻击(例如:远程利用软件漏洞 – 认为SQLi)。
看到您网站上的感染并不意味着网站本身被利用。如果您继续体验多次重新感染,那么查看整个环境是件好事,看看上述任何条件是否可能导致问题。
运行我们的再感染调查时,我们发现的最大的贡献者包括:
- 被遗忘的网站在同一个帐户
- 同一帐户配置错误的网站
- 尚未在同一帐户上安全的网站
如果您是网站所有者,并且想知道这是否会影响您,请与开发人员或主持人打开对话,并询问他们在同一服务器和帐户上处理多个网站的方法。询问他们是否在您的帐户中管理其他网站,以及如何向您保证您的网站与其他邻近网站正确隔离。如果您继续遇到问题,可能是配置错误。
防止跨站点污染
我在这里提出的方法很简单,性价比高,是提高整体安全状态的第一步。它将有助于减少与跨站点污染相关的风险,同时也有助于简化维护活动。
功能隔离与“最低特权”或“深度防御”一样古老,但也可能是最少的讨论。我会扩展它,鼓励你不仅考虑功能隔离,而且考虑隔离。结合起来,这些都将大大减少跨站点污染的威胁。
几个最后的想法:
- 如果您决定部署像Sucuri防火墙,请确保它部署在同一帐户的所有站点上,并且您已遵循所有步骤以确保对服务器的直接访问受到限制。
- 如果你只关心一个站点,而不是另一个站点,那么将这个站点移动到自己的环境中。
- 如果你有一个服务器做所有的事情,停止!根据上面提供的建议,利用您的服务器和帐户。
- 如果您是网站所有者提出问题,请成为此过程中涉及的成员。安全是您的责任,就像您的设计师或主持人一样。
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/260774.html