如果服务器配置正确,为什么需要防火墙?


59

我为我工作的公司管理一些基于云(VPS)的服务器。

服务器是最少的ubuntu安装,可运行LAMP堆栈/入站数据收集(rsync)的位。数据很大,但不是个人,财务或类似的东西(即不那么有趣)

显然,在这里人们总是问有关配置防火墙之类的问题。

我使用多种方法来保护服务器的安全,例如(但不限于)

  • 在非标准端口上使用ssh;没有密码输入,仅来自已知ips的已知ssh密钥进行登录等
  • https和受限制的shell(rssh)通常仅来自已知的密钥/ ips
  • 服务器数量最少,最新且定期修补
  • 使用rkhunter,cfengine,lynis denyhosts等工具进行监视

我对unix sys admin有丰富的经验。我有信心知道自己在设置中正在做什么。我配置/ etc文件。我从来没有迫切需要安装诸如防火墙之类的东西:iptables等。

暂时搁置VPS的物理安全性问题。

Q?我无法决定我是天真的还是fw可能提供的增量保护值得学习/安装以及服务器上额外的复杂性(程序包,配置文件,可能的支持等)。

到目前为止(接触木头),我在安全方面从未遇到过任何问题,但我也不对此感到沾沾自喜。




6
给我您的IP地址,我将告诉您为什么需要防火墙。
GregD 2011年

Answers:


87

我注意到您在捆绑几个不同的守护程序方面做得很出色,从您所说的来看,我认为您不太可能通过已经获得的那些服务使自己陷入困境。这仍然使您处于“除我已禁止的一切都被允许的状态”状态,并且您无法通过在守护程序之后逐级搜寻守护程序并逐一保护它们来摆脱该状态。

默认情况下,配置为DENY ANY ANY的防火墙会将您转移到“除允许的所有内容之外,一切都被禁止”的操作模式,多年来我发现它们会更好。

现在,给定具有系统上合法外壳程序的合法用户,她可以决定运行一些本地非特权守护程序来代理Internet的Web请求,或者在端口4662上开始文件共享,或者不小心使用-g打开侦听器使用ssh端口隧道传输时,不了解其功能;或安装sendmail可能会使您在端口587上运行MUA,尽管您已在保护端口25上的MTA sendail上进行了所有工作,但该端口配置不正确。否则可能会发生一百零一件事,绕过您细心周到的安全性,仅仅是因为当您仔细考虑要禁止的内容时,它们并没有出现。

你明白我的意思吗?目前,您已经在确保所有已知信息上付出了很大的努力,听起来它们不会咬您。您可能会咬的是您现在不知道或什至不知道的事情。

默认设置为DENY ANY ANY的防火墙是sysadmin的一种说法,即如果出现了新的情况并在此服务器上打开了网络侦听器,则在我未得到明确许可之前,任何人都无法与它进行对话


这是一个非常有见地的答案,尤其是关于从“允许一切...”切换到“禁止一切...”的文字,您对本地守护程序的理解也很不错。就像通常的情况一样-我相信你会同意的-危险常常在“内部”
Aitch

12
(Aitch,如果可以假设的话,您的个人资料表明您是serverfault的新手。当地的礼节是,当您对答案感到满意时,可以通过单击刻度线来接受它(如果有记忆的话);当然,如果您已经知道这一点,或者您正在等待看看是否有其他更好的答案出现了,那也是非常正确和适当的,请无视我。社区只问了一次您对问题的答案完全满意,可以接受。)
MadHatter

+1 @MatHatter-很好地说明了防火墙如何在默认情况下(而不是选择)提供安全性。
合作社

这是一个经过计算的风险。至少在OpenBSD上,启用pf会在内核中添加35K行代码,这可能会有bug。另一方面,默认拒绝-以及适当的日志记录防火墙-是可以购买的最大IDS。停止尝试使用Snort查找不良信息:任何时候任何计算机执行您未明确允许的操作时,都应该得到通知。
Alex Holst

14

最小特权原则。防火墙可以帮助您到达那里。深度防御原则。防火墙也可以帮助您到达那里。任何设计良好的配置都以一种或另一种方式显式地依赖于这两种方式。

另一件事是,您的服务器很可能是商品硬件,或专用于处理在标准服务器操作系统(Unix,NT,Linux)上运行的服务器软件的硬件。也就是说,它们没有专用的硬件来有效地处理和过滤传入的流量。您是否希望服务器处理即将发生的每一个可能的多播,ICMP数据包或端口扫描?

您最可能希望的是服务器仅实际处理对某些端口(80、443,ssl端口,典型的oracle 1521端口,rsync端口等)的请求。是的,当然,您需要在服务器上设置软件防火墙服务器仅侦听那些端口。但是,您的NIC仍然会受到不必要的流量的冲击(无论是组织中的恶性还是正常)。如果您的NIC受到重创,那么通过服务器的网络路径(也可能是服务器与内部客户端之间的网络路径)以及其他内部服务器和服务。)

不仅会严重打击您的NIC,还会使用您的软件防火墙,因为它必须检查它获取的每个单个数据包或数据报。

另一方面,防火墙,特别是位于子网边缘的防火墙(或将子网与外界隔离开的防火墙),往往是专门为处理这种类型的卷而构建的专用硬件。

您可以用M个防火墙包围N个服务器(N >> M)。然后,您将防火墙硬件设置为转储不定向到特定端口的所有内容。端口扫描,ICMP和其他垃圾邮件都消失了。然后,根据服务器的特定功能对服务器中的软件防火墙进行微调。

现在,您刚刚降低了(但没有消除)总停电的可能性,将其减少为网络分区或最坏情况下的部分故障。因此,您提高了系统抵御攻击或错误配置的能力。

没有防火墙,因为您的服务器有防火墙,就像在雾气笼罩下以零时速行驶时速120英里时安全带系安全带。那样行不通。


4

如果没有用于进行某种数据包级别检查的防火墙,可能会遭受许多攻击:

例子是圣诞树小包

http://en.wikipedia.org/wiki/Christmas_tree_packet

DDOS攻击可能针对您的系统,防火墙(可能在外部,在您的任何服务器之前)可能会在阻止服务器瘫痪之前阻止/减慢/杀死流量。

仅仅因为您在服务器上没有财务或个人数据,并不意味着您不会受到伤害。我确定您要为带宽或CPU使用率付费,或者您有一个计费速率。想象一下在一个晚上的过程中(您在睡觉时)有人在用电表(我已经看到这种情况发生在VOIP交换机提供商那里,在夜间受到数百万流量的打击,他们必须为此付费)。

所以要聪明一点,如果有保护,就使用保护,您并不完美,软件也不是。它是安全的,直到找到下一个漏洞。;)


2

如果您可以使用防火墙强制执行无特权最低特权原则,那么您可能不需要它。从我的角度来看,在不使用防火墙的情况下构建安全系统需要付出更多的努力,而且我很懒。当我可以使用单个配置在传输级别上分离特权时,为什么还要使用其他工具和可能很多配置文件来限制TCP连接。


1
关于单一配置的好处,减少了错误的余地。我同意尽可能地保持懒惰!cfengine确实消除了这种复杂性,对我而言部分缓解了许多配置文件的问题.....但是它仅与编写的规则一样好。因此,您将大多数配置文件保留在“默认”位置(或接近)作为辅助屏障,并将防火墙作为(至少在层意义上)首要考虑的问题。
Aitch

2
我首先为PoLP投票,然后为懒惰投票。防火墙不是使所有者变得草率的工具。您应该费心收紧攻击面,因为如果攻击者通过防火墙(毕竟您必须打开某些设备),他们可以关闭iptables。将懒惰应用到它应该属于的地方:使系统尽可能无倾斜,因此您不必长时间进行修复。
Marcin

@Marcin我的意思是,如果某人想要使用防火墙保护不带系统的安全,则他或她将必须首先创建一个全面的威胁模型。防火墙暗示着某种众所周知的,已描述的威胁模型,因此我不必为每台主机都从头开始构建它。当然,如果我们谈论军事级的安全,别无选择,那么应该建立正式的威胁模型。
Alex

1

防火墙还可以拦截不需要的数据包到达您的服务器。与其在单个服务器级别上处理它们,不如在防火墙上对其进行处理。您可以将所有此配置活动保留在单个防火墙上,而不是在多个服务器上。

例如,如果攻击者获得了外部IP的控制权,并在服务器中填充了有害数据包,并且您希望减轻其对服务器的影响,则可以配置每个受影响的服务器以丢弃恶意数据包或者只是在您的防火墙处进行更改,并且所有服务器都受到保护。安装防火墙减少了您的反应时间。


此外,这样做还是要配置防火墙-它恰好在每台服务器上。
mfinni 2011年

1

您或其他人可能有一天在您的服务器设置上出错,然后防火墙给您第二次阻止某人进入的机会。我们并不完美,我们会出错,因此值得购买一些“不必要的”保险。

(尽量不要在服务器相同的操作系统上运行防火墙,否则将导致操作系统中的一个错误。...我认为所有版本的Unix都是同一操作系统,因为它们有很多共同点)


出色的混合平台(操作系统和硬件)是关键。
DutchUncle 2011年

1

防火墙在流量操纵中特别有用。他们快速地做并且有资源。而且,您不会浪费服务器资源来过滤流量(磁盘io / proc time等)。您应该在服务器环境中配置一些安全性,但是所有流量检查和病毒扫描等都应使用专门的服务器。


-2

我会担心,如果您确实遭到黑客攻击,并且没有防火墙。黑客可能会打开服务器上的其他端口。另外,如果请一位顾问进行清理和审核,他们会说的第一件事是:“什么?!?!您没有防火墙!” 然后你可能会被烧死。


-1有点耸人听闻的答案+并非真正具有建设性。
合作社

2
如果服务器受到威胁,那么当闯入的僵尸直接将其禁用时,防火墙不一定会提供帮助!*免责声明,该问题确实提到使用iptables,而不是单独的硬件防火墙。
布赖恩
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.