Web服务器部署的地点
网络包从互联网到达服务器的过程
,
根据服务器部署地点的不同而不同。
最简单的是图
(
a
)
中的这种情况
,
服务器直接部署在公司网络上
, 并且可以从互联网直接访问。
这种情况下
,
网络包通过最近的
POP
中的路由器、
接入网以及服务器端路由器之后
,
就直接到达了服务器
。
其中
,
路由器的包转发操作,
以及接入网和局域网中包的传输过程都和我们之前讲过的内容没有区别。
以前这样的服务器部署方式很常见
,
但现在已经不是主流方式了
。
这里有几个原因。
第一个原因是 IP 地址不足
。
这样的方式需要为公司网络中的所有设备,
包括服务器和客户端计算机
,
都分配各自的公有地址
。
然而现在公有地址已经不够用了,
因此采用这种方式已经不现实了
。
另一个原因是安全问题
。
这种方式中
,
从互联网传来的网络包会无节制地进入服务器,
这意味着服务器在攻击者看来处于
“
裸奔
”
状态
。
当然
, 我们可以强化服务器本身的防御来抵挡攻击,
这样可以一定程度上降低风险。
但是
,
任何设置失误都会产生安全漏洞
,
而裸奔状态的服务器
,
其安全漏洞也都会暴露出来。
人工方式总会出错
,
安全漏洞很难完全消除
,
因此让服务器裸奔并不是一个稳妥的办法。
因此,
现在我们一般采用图
(
b
)
中的方式
,
即部署防火墙
。
防火墙的作用类似于海关,它只允许发往指定服务器的指定应用程序的网络包通过,从而屏蔽其他不允许通过的包
。
这样一来
,
即便应用程序存在安全漏
洞
,
也可以降低相应的风险
。
因为防火墙屏蔽了不允许从外部访问的应用程序,
所以即便这些程序存在安全漏洞
,
用于攻击的网络包也进不来。当然,
即便如此风险也不会降到零
,
因为如果允许外部访问的应用程序中有安全漏洞,
还是有可能遭到攻击的
,
但怎么说也远比完全暴露安全漏洞的风险要低得多。
这就是防火墙的作用
。
将Web服务器部署在数据中心
图
(
a
)
和图
(
b
)
都是将
Web
服务器部署在公司里
,
但 Web 服务器不仅可以部署在公司里,也可以像图 (c)这样把服务器放在网络运营商等管理的数据中心里,或者直接租用运营商提供的服务器
。 数据中心是与运营商核心部分 NOC
直接连接的
,
或者是与运营商之间的枢纽 IX
直接连接的
。
换句话说
,
数据中心通过高速线路直接连接到互联网的核心部分,
因此将服务器部署在这里可以获得很高的访问速度
, 当服务器访问量很大时这是非常有效的。
此外
,
数据中心一般位于具有抗震结构的大楼内,
还具有自主发电设备
,
并实行
24
小时门禁管理
,
可以说比放在公司里具有更高的安全性。
此外,数据中心不但提供安放服务器的场地,还提供各种附加服务,如服务器工作状态监控、防火墙的配置和运营、非法入侵监控等,从这一点来看,其安全性也更高。
如果 Web
服务器部署在数据中心里
,
那么网络包会从互联网核心部分直接进入数据中心,
然后到达服务器
。
如果数据中心有防火墙
,
则网络包会先接受防火墙的检查,
放行之后再到达服务器
。
无论如何
,网络包通过路由器的层层转发
,
最终到达服务器的这个过程都是相同的
。
防火墙原理
无论服务器部署在哪里,现在一般都会在前面部署一个防火墙,如果包无法通过防火墙,就无法到达服务器
。 防火墙的基本思路
即只允许发往特定服务器中的特定应用程序的包通过,
然后屏蔽其他的包
。
不过
,
特定服务器上的特定应用程序这个规则看起来不复杂,
但网络中流动着很多各种各样的包
,
如何才能从这些包中分辨出哪些可以通过,
哪些不能通过呢
?
为此
,
人们设计了多种方式
,
其中任何一种方式都可以实现防火墙的目的
,
但出于性能
、价格、
易用性等因素
,
现在最为普及的是包过滤方式
。
因此
,
我们的下面介绍一下包过滤方式的防火墙是怎样工作的。
网络包的头部包含了用于控制通信操作的控制信息
,
只要检查这些信息,
就可以获得很多有用的内容
。
这些头部信息中
,
经常用于设置包过滤规则的字段如表
所示
。
地址转换和包过滤中用于设置规则的字段
MAC 头部
|
规则判断条件
| 含义 |
MAC 头部
|
发送MAC
地址
|
路由器在对包进行转发时会改写 MAC 地址,将转发目标路由器的 MAC 地址设为接收方 MAC 地址,将自己的 MAC 地址设为发送方 MAC 地址。通过发送方 MAC地址,可以知道上一个转发路由器的 MAC 地址
|
IP 头部
|
发送方 IP 地址
|
发送该包的原始设备的 IP 地址。如果要以发送设备来设置规则,需要使用这个字段
|
接收方 IP 地址
|
包的目的地 IP 地址,如果要以包的目的地来设置规则, 需要使用这个字段
| |
协议号
|
TCP/IP 协议为每个协议分配了一个编号,如果要以协议类型来设置规则,需要使用这个编号。主要的协议号包括 IP∶0;ICMP∶1;TCP∶6;UDP∶17;OSPF∶89
| |
TCP 头部 或
UDP 头部
|
发送方端口号
|
发送该包的程序对应的端口号。服务器程序对应的端口号是固定的,因此根据服务器返回的包的端口号可以分辨是哪个程序发送的。不过,客户端程序的端口号大多是随机分配的,难以判断其来源,因此很少使用客户端发送的包的端口号来设置过滤规则
|
接收方端口号
|
包的目的地程序对应的端口号。和发送方端口号一样,一般使用服务器的端口号来设置规则,很少使用客户端的端口号
| |
TCP 控制位
|
TCP 协议的控制信息,主要用来控制连接操作
| |
ACK:表示接收数据序号字段有效,一般用于通知发送方数据已经正确接收
PSH:
表示发送方应用程序希望不等待发送缓冲区填
充完毕,立即发送这个包
RST:强制断开连接,用于异常中断
SYN:
开始通信时连接操作中发送的第一个包中,
SYN 为 1,ACK 为 0。如果能够过滤这样的包,
则后面的操作都无法继续,可以屏蔽整个访问
FIN:表示断开连接
| ||
ICMP 消息
(非头部)的内容
|
ICMP 消息类型
|
ICMP 消息用于通知包传输过程中产生的错误,或者用来确认通信对象的工作状态。ICMP 消息主要包括以下类型,这些类型可以用来设置过滤规则
0:
针 对
ping
命 令 发 送 的 ICMP echo 消息的响
应。将这种类型的消息和下面的类型 8 消息屏
蔽后,
ping
命令就没有响应了。一般在发动攻
击之前会通过
ping
命令查询网络中有哪些设
备,如果屏蔽 0 和 8,就不会响应
ping
命令,
攻击者也就无法获取网络中的信息了。不过,
ping
命令也可以用来查询设备是否在正常工
作,如果屏蔽了 0 和 8 的消息,可能别人会误
以为设备没有在工作
8: 这个类型的消息叫作 ICMP echo,当执行 ping 命令时,就会发送 ICMP echo 消息
其他:
ICMP 消息除了 0 和 8 以外还有其他一些类型,
但其中有些消息被屏蔽后会导致网络故障,因
此如果要屏蔽 0 和 8 以外的消息必须十分谨慎
|
不过
,
光看这张表还是难以理解过滤规则是如何设置的,
所以我们来看一个具体的例子
。
假设我们的网络如图
所示
,
将开放给外网的服务器和公司内网分开部署,
Web
服务器所在的网络可以从外网直接访问
。
现在我们希望允许从互联网访问 Web
服务器
(
图
①
),
但禁止
Web
服务器访问互联网
(
图
②
)。
以前很少禁止 Web 服务器访问互联网,但现在出现了一些寄生在服务器中感染其他服务器的恶意软件,如果阻止 Web 服务器访问互联网,就可以防
止其他服务器被感染
。
要实现这样的要求
,
应该如何设置包过滤的规则呢?
我们就用这个例子来看一看包过滤的具体思路
。
在设置包过滤规则时,首先要观察包是如何流动的。通过接收方 IP 地址和发送方 IP 地址,我们可以判断出包的起点和终点。在图①的例子中,包从互联网流向 Web 服务器,从互联网发送过来的包其起点是不确定的,但终点是确定的,即 Web 服务器。因此,我们可以按此来设定规则,允许符合规则的包通过。也就是说,允许起点(发送方 IP 地址)为任意,终点(接收方 IP 地址)为 Web 服务器 IP 地址的包通过(图中表的第 1 行)。如果可以确定发送方 IP 地址,也可以将其加入规则,但这个例子中起点是不确定的,因此可以不将发送方 IP 地址设为判断条件。
这样一来
,
从互联网发往
Web
服务器的包就可以通过防火墙了
,
但光这样还无法完成访问。
因为收到包之后
,
Web
服务器需要通过确认应答机制
通知发送方数据已经正常收到
,
这需要
Web
服务器向互联网发送包
。在 Web
服务器发往互联网的包中
,
我们可以将起点
(
发送方
IP
地址
)
为Web 服务器地址的包设置为允许通过
(
图
中表的第
3
行
)。
像这样
,
我们可以先根据接收方和发送方地址判断包的流向,
并设置是允许还是阻止
。
通过端口号限定应用程序
不过
,
按照前面的设置,相当于允许了互联网和 Web 服务器之间所有的包通过,这个状态很危险
。
假如服务器上还有一个文件服务器程序在工作,
那么这些文件就可能会被非法访问从而造成信息泄露
。
有风险的还不仅是文件服务器,
现在每天都会发布若干安全漏洞
,
可以说随处都隐藏着风险。
因此
,
我们最好是阻止除了必需服务
(
也就是本例中的
Web
服务
) 以外的所有应用程序的包。 当我们要限定某个应用程序时,
可以在判断条件中加上
TCP
头部或者UDP 头部中的端口号
。
Web
服务器的端口号为
80
,
因此我们在刚才的接收方 IP
地址和发送方
IP
地址的基础上再加上
80
端口作为条件就可以了
。也就是说,
当包的接收方
IP
地址为
Web
服务器地址
,
且接收方端口号为80 时
,
允许这些包通过
(
图
中表的第
1
行
);
或者当包的发送方
IP
地址
为
Web
服务器地址
,
且发送方端口号为
80
时
,
允许这些包通过
(
图
中的表的第 3
行
)。
如果要允许访问除 Web 之外的其他应用程序,则只要将该应用程序的端口号设置到防火墙中并允许通过就可以了。
通过控制位判断连接方向
现在我们已经可以指定某个具体的应用程序了
,
但是条件还没达到
,因为还没有办法阻止 Web
服务器访问互联网
。
Web
使用的
TCP
协议是双向收发网络包的,
因此如果单纯地阻止从 Web 服务器发往互联网的包,则从互联网访问 Web 服务器的操作也会受到影响而无法进行。光判断包的流向还不够,我们必须要根据访问的方向来进行判断
。
1)web访问互联网:阻止
这里就需要用到
TCP头部中的控制位。
TCP 在执行连接操作时需要收发 3 个包,其中第一个包的 TCP 控制位中 SYN 为 1,而 ACK 为 0
。
其他的包中这些值都不同
,
因此只要按照这个规则就能够过滤到 TCP
连接的第一个包
。 如果这第一个包是从 Web
服务器发往互联网的
,
那么我们就阻止它 (图
表中的第
2
行
)。
这样设置之后
,
当然也不会收到对方返回的第二个响应包,
TCP
连接操作就失败了
。
也就是说
,
只要以
Web
服务器为起点访问互联网,
其连接操作必然会失败
,
这样一来
,
我们就阻止了
Web
服务器对互联网的访问。
2)互联网访问web:允许
那么,
从互联网访问
Web
服务器会不会受影响呢
?
从互联网访问
Web 服务器时,
第一个包是接收方为 Web 服务器,符合图表中的第 1 行, 因此允许通过
。符合
,
允许通过
。
因此从互联网访问
Web
服务器的所有包都会被允许通过。 通过接收方 IP
地址
、
发送方
IP
地址
、
接收方端口号
、
发送方端口号
、TCP 控制位这些条件
,
我们可以判断出通信的起点和终点
、
应用程序种类,
以及访问的方向
。
当然,如上表列出的那样,还有很多其他的字段可以用作判断条件。通过对这些条件进行组合,我们就可以对包进行筛选。
这里也可以添加多个规则,
直到能够将允许的访问和不允许的访问完全区分开为止。
这样
,
我们就可以通过设置规则
,
让允许访问的包通过防火墙
, 其他的包则不能通过防火墙
。
不过,实际上也存在无法将希望允许和阻止的访问完全区分开的情况
, 其中一个代表性的例子就是对 DNS
服务器的访问
。
DNS
查询使用的是UDP 协议
,
而
UDP
与
TCP
不同
,
它没有连接操作
,
因此无法像
TCP
一样
根据控制位来判断访问方向
。
所以
,
我们无法设置一个规则
,只允许公司内部访问互联网上的 DNS
服务器
,
而阻止从互联网访问公司内部的
DNS 服务器。
这一性质不仅适用于
DNS
,
对于所有使用
UDP
协议的应用程序都是共通的。
在这种情况下
,
只能二者择其一
——
要么冒一定的风险允许该应用程序的所有包通过,
要么牺牲一定的便利性阻止该应用程序的所有包通过。
通过地址转换的方式实现安全性
包过滤方式的防火墙不仅可以允许或者阻止网络包的通过
,
还具备地址转换功能
,
因此还需要进行相关的设置
。
也就是说
,
互联网和公司内网之间的包需要进行地址转换才能传输,
因此必须要进行相关的设置
。
具体
来说
,
就是和包过滤一样
,
以起点和终点作为条件
,
根据需要设置是否需要进行地址转换。私有地址和公有地址之间的对应关系,以及端口号的对应关系都是自动管理的,因此只需要设置是否允许地址转换就可以了。
请大家回忆一下地址转换的工作原理,当使用地址转换时,默认状态下是无法从互联网访问公司内网的,因此我们不需要再设置一条包过滤规 则来阻止从互联网访问公司内网。
公司内网、公开区域、互联网之间的安全性
像上图
这样的网络结构中
,
我们不仅要设置互联网和公开区域之间的包过滤规则,
还需要设置公司内网和互联网之间
,
或者公司内网与公开区域之间的包过滤规则。
这时,需要注意的是不要让这些规则互相干扰
。
例如,
为了让公司内网与公开区域之间的网络包自由流动
,
我们可以将接收方 IP
地址为公开区域的包设置成全部允许通过
。
但是,如果在这条规则里没有限定发送方 IP 地址,那么连来自互联网的包也都会被无条件允许进入公开区域了
,
这会导致公开区域中的服务器全部暴露在危险状态中
。
因此
, 我们必须谨慎地设置规则,
防止出现这样的情况,比如仅允许公司内部访问公开区域
。
防火墙的并没有那么高大尚
像这样
,
我们可以在防火墙中设置各种规则
,
当包到达防火墙时
,
会根据这些规则判断是允许通过还是阻止通过。
如果判断结果为阻止,那么这个包会被丢弃并被记录下来。这是因为这些被丢弃的包中通常含有非法入侵的痕迹,通过分析这些包能够搞清楚入侵者使用的手法,从而帮助我们更好地防范非法入侵
。 如果包被判断为允许通过,
则该包会被转发出去
,
这个转发的过程和 路由器是相同的。
如果我们只关注判断是否允许包通过这一点
,
可能会觉得防火墙是一种特殊机制,
而且市面上销售的防火墙大多是专用的硬件设备或者软件,
这也加深了大家的这种印象
。 实际上,
在防火墙允许包通过之后
,
就没有什么特别的机制了
,
因此包过滤并不是防火墙专用的一种特殊机制,
而是应该看作在路由器的包转发功能基础上附加的一种功能。
只不过当判断规则比较复杂时
,
通过路由器的命令难以维护这些规则,
而且对阻止的包进行记录对于路由器来说负担也比较大,
因此才出现了专用的硬件和软件
。
如果规则不复杂
,
也不需要记录日志,
那么用内置包
过滤功能的普通路由器来充当防火墙也是可以的。
防火墙抵御不了的攻击
防火墙可以根据包的起点和终点来判断是否允许其通过
,
但仅凭起点和终点并不能筛选出所有有风险的包。
比如
,
假设
Web
服务器在收到含有特定数据的包时会引起宕机。
但是防火墙只关心包的起点和终点
,因此即便包中含有特定数据,
防火墙也无法发现
,
于是包就被放行了
。 然后,
当包到达
Web
服务器时
,
就会引发服务器宕机。
通过这个例子大家可以看出,
只有检查包的内容才能识别这种风险
,
因此防火墙对这种情况无能为力。 要应对这种情况有两种方法。
这个问题的根源在于 Web 服务器程序的 Bug,因此修复 Bug 防止宕机就是其中一种方法
。
这类
Bug
中
,
危险性较高的会作为安全漏洞公布出来,
开发者会很快发布修复了
Bug
的新版本
,因此持续关注安全漏洞信息并更新软件的版本是非常重要的。
另一种方法就是在防火墙之外部署用来检查包的内容并阻止有害包的设备或软件
。
当然
,
即便是采用这种方法也并不是完美无缺的
,
因为包的内容是否有风险,
是由
Web
服务器有没有
Bug
决定的
,
因此当服务器程序中有潜在的 Bug
并且尚未被发现时
,
我们也无法判断包中的风险
,
也无法阻止这样的包。
也就是说,我们无法抵御未知的风险
。
从这一点来看
,
这种方法和直接修复 Bug
的方法是基本等效的
,
但如果服务器数量较多
,
更新软件版本需要花费一定的时间,
或者容易忘记更新软件
,
这时对包的内容进行检查就会比较有效。
总结:我方未知的漏洞就是防火墙的入口