Hyper-V中的访问控制列表

最新推荐文章于 2023-04-09 10:55:16 发布

weixin_34408624

最新推荐文章于 2023-04-09 10:55:16 发布

阅读量157

点赞数

原文链接：http://blog.51cto.com/maomaostyle/1538554

版权

微软在Windows Server 2012中对虚拟交换机做了很多的改进和增强，其中不但增加了诸如RSS、dVMQ、端口映射以及支持PVLAN等技术，还提供了非常实用的访问控制列表（ACL）功能。

在Technet中可以查看到Windows Server 2012中对于ACL的称谓叫做Port Access Control Lists，它是基于源/目的地址、方向和动作（允许/拒绝）来进行规则筛选的：

Local or Remote Address	Direction	Action
12-34-56-78-9A-BC	Inbound	Allow
12-34-56-78-9A-BC	Outbound	Allow
FF-FF-FF-FF-FF-FF	Inbound	Allow
Any	Inbound	Deny
Any	Outbound	Deny

通过上面的列表可以看到在2012的ACL功能当中是支持IP与MAC地址的，并且像“Any”这类通配指令也是支持的，所以对于熟悉主流网络设备的童鞋来讲不需要适应过程，可谓是极易于上手的。

那么在Windows Server 2012R2中，ACL功能又得到了加强，被称为“Extended Port Access Control Lists”即扩展端口访问控制列表，不难看出这就好比网络设备上的标准ACL与扩展ACL一样，后者在原有基础上增加支持源/目的端口、协议、权重等，下面就实际演示一下Windows Server操作系统中的ACL功能：

##########################################################################################

演示环境：

主机：Windows 8.1

虚拟机：Windows Server 2008R2 SP1 Standard

因为ACL功能对操作系统版本没有过分的要求，它是属于Hypervisor层的技术，所以我就用自己的笔记本电脑（Windows8.1）启用Hyper-V功能即可，如下图所示我准备了两台测试虚机，一台叫做SQL2008R2（运行SQL2008R2），另一台叫做WIN2008R2（运行IIS7）

在开始配置ACL之前，我把两台虚拟机的防火墙都关闭，其中SQL2008R2的IP为192.168.10.12，它是能够PING通WIN2008R2（192.168.10.11）的，如下图：

此外可以看到SQL2008R2这台虚机当前TCP 1433端口处于监听状态

回到WIN2008R2这台机器上，此时也是能够PING通192.168.10.12（SQL2008R2）的

并且已经安装了Web Server角色，本机默认站点可以正常访问,而且可以telnet到SQL2008R2的1433端口

##########################################################################################

测试环境准备好之后，来看一下主机上的PowerShell，主要筛选一下Hyper-V Module下的ACL相关命令，可以看到本文前面提到过的“标准ACL”与“扩展ACL”，如下图：

接着就来试一下标准ACL的效果，实用下面的命令对虚机WIN2008R2配置一条ACL，针对目的地址192.168.10.12的出方向进行Deny操作。

配置生效后可以通过Get命令查询已存在的ACL，如下图所示：

此时回到WIN2008R2再去PING SQL2008R2时已经不可达了。

接着删掉刚刚生效的ACL

再去WIN2008R2重新PING SQL2008R2，通信又恢复正常了。

此外除了IP意外，还可以使用MAC地址作为筛选条件，如下图所示，还是对于WIN2008R2这台虚机，使用MAC地址并拒绝入方向流量。

来到SQL2008R2上去PING WIN2008R2可以看到ACL生效了。

##########################################################################################

上面的演示主要是针对Windows Server 2012中的“标准ACL”进行的操作，而在R2当中，“扩展ACL”又分为两类，在Technet中对此介绍为Detailed ACL rules以及Stateful ACL rules；那么它们有什么区别呢？众所周知，在很多会话类的通信中，我们需要对于进出方向都做规定才可以保证链接通畅，举个例子，某台客户端电脑要访问外网的一台Web Server，那么为了安全考虑，管理员首先要permit这台客户端电脑出方向的请求，比如允许它访问外网80端口的tcp协议，那么当Web Server收到访问请求后，需要返回给客户端电脑相应的数据包，此时就需要管理员permit客户端本地端口的入方向请求。OK，入方向请求没问题，关键是本地端口是多少？开启1024~5000端口？别闹。。。。

到这一步就会发现即便是扩展ACL也不太好实现我们的需求，那么怎么办？对于这些特定场景的需求，特别是有状态类会话怎么办？于是乎变有了上面提到的Stateful ACL rules。

顾名思义，Stateful ACL就跟有状态防火墙（Stateful Firewall）是一样的，究其工作原理大致如下：

数据包到了防火墙这里时，状态检测引擎会查看该连接请求是否为一个初始化连接（即是否携带SYN标记）。
接下来就去与ACL规则最比对，当然如果不满足的就丢掉了，满足的话就继续。
防火墙内会有一个状态表，并把这个连接作为一条会话添加进表中进行维护。
表内条目大致会包括一些源/目的地址、源/目的端口号、连接时间等信息。
后续数据包再到达时，如果不是初始化连接请求，即没有SYN，则直接去跟状态表中的内容最比对。
如果后续数据包与状态表中信息匹配，则直接转发，不需要再去与ACL中的规则做比对，如果不属于任何会话则丢弃。
此外会话还包含一个timeout值，当超过这个保活时间后，会话会被删除。

##########################################################################################

下面来看一下Stateful ACL的特别之处，下图中是一条没有附加“-Stateful”参数的ACL，针对于虚机SQL2008R2的本地1433端口入方向进行允许，另外还加了一条“-Weight”权重值参数，该参数值越大越先被执行，因为Hyper-V内的ACL并没有一条默认的规则，例如deny any any之类的，所以Weight值会被用来与其他ACL配合使用。

仅仅配置了这条ACL后，SQL2008R2这台机器的1433端口还是不能被WIN2008R2访问的，如下图所示；除非我再加一条针对WIN2008R2入方向的ACL，但那样就比较繁琐了

接着再试一下Stateful ACL的效果，同样是刚才的命令，只不过在后面追加了一个“-Stateful”并赋予$true，如下图：

由于Stateful ACL会自动打开返回流量的端口，并根据timeout值维护这个会话，因此WIN2008R2可以telnet到SQL2008R2的1433端口了。

同样对于Web访问类请求也适用，下图中SQL2008R2受到ACL的限制是无法访问WIN2008R2的IIS站点的。

通过-Stateful参数允许SQL2008R2出方向的TCP80请求，如下图：

ACL生效，拖Stateful的福，可以访问WIN2008R2的默认站点了。

###########################################################################################

Hyper-V的ACL使虚拟机的网络安全性得到了多一层的保护，在上面的测试中我没有添加“-timeout”参数，有需要的筒子可以自行查看get-help；不过遗憾的是，我没有找到在大范围环境中批量执行ACL的途径，纵然VMM可以集成Cisco Nexus 1000v之类的第三方产品，但是一方面需要投入额外成本，另一方面又增加了维护开销；当然如果纯粹使用PS脚本应该也是可行的，但要是能在今后增加图形化界面的全局配置想必是极好的。

转载于:https://blog.51cto.com/maomaostyle/1538554