Openstack Neutron ： 安全
|
目录 |
|
- tables - chains - rules - 方向 - 更高的安全 - 无处安放的安全 - 公共安全 |
当业务从传统环境迁移到云上之后，安全问题变得更为复杂了。Neutron包含了2大安全组件：安全组（security group）、防火墙（firewall）。安全组解决的是虚拟机东西向的访问控制问题，而防火墙解决的则是南北向的访问控制问题。
两者都只解决了网络层和传输层的访问控制，更高层级的安全功能，则留待更为专业的安全厂商解决，如：Palo Alto、Checkpoint、F5 等等。在这一点上 Openstack 和 VMware 等各个云平台的做法可以说是非常的一致。各个传统的安全厂家也纷纷转型推出云上的安全解决方案。
iptable：起源
安全组、防火墙的功能都依赖于iptables实现。Iptables 很早就已经集成到了Linux 的内核中，它由转发表 和 规则链 组成，通过表和链的组合，能适应各种场景下的安全需求功能。
tables
iprable默认包含了表，每个表都有不同的用途，比如 Filter 表用来过滤数据包，发往主机内部的包，和发往主机外部的包都由 filter 表中相应规则链来处理。主机中默认的表有：
- Raw：数据包最先经过的表，一般用来配置需要绕过iptable处理的流量。在安全组和防火墙功能中都没有使用到该表。
- Filter ：默认用于过滤数据包的表。neutron安全组和防火墙都是通过该表的不同链来实现的。
- NAT：看名字就知道，用于网络地址转换。
- Mangle： 可以修改数据包的特定字段，常用来标记流量（如用来实现策略路由功能），也没有被安全组或防火墙使用。
http://cn.linux.vbird.org/linux_server/0250simple_firewall.php
查看filter表内的转发规则
chains
链这个概念指的是一组规则，这些规则会在不同的场景下生效。默认有5种规则链，规则链内部的规则详细地定义了数据包的处理方式（转发或丢弃等等）。一旦开启iptables后，所有进出接口的数据包都需要经过至少一条规则链。规则允许数据包从一个规则链跳转到另一条规则链。如果跳转后没有匹配上任何规则，数据包将回到跳转之前的位置，并继续向下匹配规则。
- Prerouting：跟名字一样，在数据包执行路由的策略之前会进入该规则链。除了Filter以外，其他表都有用到该策略链。比如NAT，在数据包路由之前修改数据包的源地址或目的地址。
- Input：所有发往本地主机的数据包（即目的地址是本地的地址）都会经该规则链处理。Mangle 和 Filter 中都有用到。
- Forward：所有目的地址非本机的数据包都用到该规则链。Mangle 和 Filter都有用到。
- Output：由本地主机发往外部的数据包都使用该规则链。Raw、Filter、NAT、Mangle都有用到。
- Postrouting：所有完成了路由选择的数据包都将通过该规则链。安全组的功能没有使用到这个规则链，但浮动ip则有使用。Mangle和NAT表有使用。
Chain 的应用流程可以用上图来囊括，所有进入主机的数据包都要先经过prerouting链，raw、mangle、nat表中都有prerouting链，所以数据包要依次匹配 raw——>mangle——>nat 三个表中prerouting链的规则。随后主机将进行路由选择，如果是数据包的目的是主机自己，那么接下来则由input 链来处理，此时是数据包是经过 mangle——>filter表的，然后数据包被拆包并发往本地的进程。
而从本地发出的流量，经过路由选择后进入output链，分别经过raw—mangle—nat—filter表后交给postrouting。
如果数据不是发往本地的，则是经过prerouting，forward，postrouting3个规则链。
rules
可以看到表格内的规则被组织成不同的链，默认的规则链会在不同的场景下生效，一个规则链内通常包含多条规则，规则的语法与我们常用的ACL语法类似，同样是对数据包头的字段进行匹配，包括常用的数据包的5元组：
- 协议< -p protocol>：需要匹配的数据包的协议，例如ICMP、TCP、UDP等
- 源地址< -s source ip address>：数据包头的源地址
- 目的地址<-d destination ip address>：包头的目的地址
- 源端口< -sport source port>：包头的源端口
- 目的端口<-dport destination port>：包头的目的端口
- 入接口<-i interface>：数据包进入主机的接口（需要在input链中使用）
- 出接口<-o interface>：数据包出主机的接口（注意，当使用该项来匹配数据包时，只有在主机执行了路由选择之后的output链中才能生效，表 raw、mangle、output、filter中都有）
- （除此之外还可以通过各种插件来匹配更多的字段）
安全Rule匹配和动作示例
而一旦规则中的条件匹配到数据包后，数据包就会执行规则配置的动作。每个规则支持的动作包括：
- Accept ：接受
- Drop：丢弃
- Reject：丢弃。与drop不同的是，reject会向数据包的源地址返回一个错误信息
- Log ：记录数据包的细节信息
- DNAT：重写数据包的目的地址
- SNAT：重写数据包的源地址
- RETURN：将数据包返回给跳转前的规则
有经验的人一眼就能看出 accept、drop、reject、log这些不都是一般防火墙上常见的操作么，是的，防火墙主要用的Filter表中的规则主要就是记录的数据包的丢弃、转发等操作。
方向
Neutron正是应用了iptable不同的表和链实现了安全组和防火墙的功能。
这样配置规则时就很清晰了，当要对发往本地主机内部的流量进行控制时，则需要在filter表 的input 链内设置访问控制规则。
而当主机作为路由器，在不同的网段之间进行数据转发时，则需要在filter表的forward链内设置访问控制规则。
这样就清晰了，无论是经由主机转发（充当路由器）、或者是发往本主机、以及本主机发出去的流量，都有特定的表和规则链进行处理。而且iptable是支持状态的，即由内部向外部发起的会话而产生的回包，防火墙是能记录并放行的。也正是借用了iptable的功能Neutron才得以实现NAT、浮动IP、安全组、防火墙等等的功能，可以说iptables占据了Neutron的半壁江山。
更多iptables的介绍可以参考鸟哥的 http://cn.linux.vbird.org/linux_server/0250simple_firewall.php
Security group 安全组：
安全组的核心就是上面提到iptables了。而且因为安全组是直接关联的虚拟机的端口，所有进出虚拟机网卡的流量都要经过iptables处理。这样vpc内部虚拟机与虚拟机之间东西向的流量也能通过安全组管理起来，所以安全组也已经成了所有云服务的标配了。
而一个安全组指的是采用同一套访问控制规则的一个或多个虚拟机。这些虚拟机都向外提供相同的服务，访问群体也相同，例如：一组向外提供web服务的虚拟机，同样开放80端口，允许其他网段的访问。用户配置的安全组策略，最终会通过neutron自动映射到虚拟机所在的计算节点内的 iptables 规则上。
因为安全组是直接关联的虚拟机接口，所以的当虚拟机在集群中迁移时，通过安全组配置的规则也会随之迁移到新的宿主机。
安全组策略的创建
在之前讲二层的博客中有提到，正因为通过 iptables 实现的安全组需要经过主机的ip协议栈，而ovs的流表转发模式不支持，而且ovs流表不支持记录连接状态，所以类似NAT、状态防火墙等功能均无法实现，导致ovs的二层环境下要在ovs和虚拟机之间额外添加一个Linuxbridge 来实现安全组的功能。
但是ovs还是有一个原生的防火墙驱动，通过流表而不是 iptable 的方式来实现安全组的功能。这要求宿主的 linux 系统内核版本为 4.3及更高，并支持conntrack。也就是使用conntrack来记录会话的状态信息，以实现状态防火墙功能。但是该实现方式在实现环境中使用得较少。
可通过修改ovs节点上 openvswitch_agent.ini 文件中的以下参数来开启。
[securitygroup]
firewall_driver = openvswitch
开启后对于用户来说没有明显的不同，neutron提供的是与 iptables 相同的API。但是实现方式已经从iptables/netfilter 换成了ovs流表。虚拟机发出的包依旧由 br-int进行处理，但是全部会由conntrack来记录会话的状态。
Firewall 防火墙：
Neutron中的防火墙和安全组一样，是通过iptables系列工具来实现的。不同的是防火墙与虚拟路由器关联，所有流经路由器的流量都会经过防火墙的过滤。包括南北向流量和用户不同vpc之间的流量。
防火墙规则也同样支持网络的五元组。
firewall-rule-create [--tenant-id 租户] [--name 名称] [--description 描述] [--shared] [--source-ip-address 源地址] [--destination-ip-address 目的地址] [--source-port 源端口] [--destination-port 目的端口] [--enabled 是否启用该规则] --protocol {tcp,udp,icmp,any 协议} --action {allow,deny 动作}
防火墙策略的创建
跟负载均衡一样，防火墙在 openstack 的 Newton 版本中也迎来了 FWaaS v2。在v2 中防火墙的概念变成了防火墙组。防火墙组由入策略和出策略组成。并且不是再是在整个路由器级别生效，而是可以将防火墙关联到特定的路由器端口。这样可以对不同的接口（子网）设置不同的防火墙规则，使用起来更加方便。官方对比图如下：
相比 LBaaS v2带来的巨大变化，FWaaS v2只能算得上是一次功能的优化，使得防火墙能够为每个子网提供更细粒度的访问控制。后续二层的防火墙的更新也会给防火墙带来更强的生命力，整体算是一次不大不小的进步。
更高的安全
无处安放的安全
openstack和能为用户提供的安全特性非常有限，仅能实现基础的访问控制，这肯定不够，所以这到了传统安全企业的发挥空间。所以在讨论云上的安全时，更多的应该讨论安全企业们在云上的解决方案。水平有限不再展开，不过还是有几个有意思的变化值得梳理一下：
首先就是云供应商和安全企业的关系：
无论是原来的网络供应商还是服务器供应商、亦或是软件供应商，安全的供应商都很少跟他们有过交集，大家相安无事好多年，各自岁月静好。较为松散的业务结构，使得各种设备能够很好地塞到用户的数据中心，但是这种情况已经完全被打破，云已经吞噬掉用户的网络、服务器、存储、管理平台等占据了数据中心的核心位置，所有其他数据容灾、备份、网络管理、网络安全、业务安全厂商突然发现自己与用户之间多了一层隔膜。至于大的云供应商在努力向客户证明自己的一体化方案已经足够完善，同时也支持第三方的服务。当然这种支持从来就是有限度的，出于利益的角度，或者出于控制力的角度。而小的云供应商们则在抱团以提升竞争力，云供应山和安全供应商都在努力向用户证明自己平台的开放兼容性，处于相互利用的情况。而且大家都知道这种合作关系太不牢靠，一旦有任何一方开始涉足对方的领域，那么这层薄薄的关系就变得岌岌可危。这其中占主动的已经是云供应商。果然还是谁更靠近用户，谁就更有话语权。
目前私有云市场还处于混战的阶段，没有谁能号令四方，这种情况也许还要持续一段时间。私有云暂时还无法完全吞下用户的数据中心，安全厂家们终将走上一条共同的道路，实现在方案层面而非产品层面上实现与私有云们的共存，以至于不让私有云过于牵制自身发展，又不用过多地去适配各种云厂家。或许网络资源池/安全资源池是个出路。
然后就是用户与安全企业的关系
关键字是统一，当用户发现计算、存储、网络资源都可以在一个平台里随意管理、使用的时候，开始尝到了统一管理的甜头，这是以前网管、运维系统多少年想做都没做成的事情，所以说进步靠的不是厂家之间的合作，而是代替。
而现在，用户强调统一管理比以前多得多得多。但凡涉及到基础IT资源，都想实现在一个平台内的统一管理。基础架构即是云，云即是统一平台。用户对于各种厂家统一的期盼，就是能够和云平台进行适当的融合，减少管理复杂性。
公共安全
虽然AWS一直以来的口号都是由用户和AWS共担责任，但是类似AWS和阿里云这样的大型公有云已经在越来越多地染指高级的安全服务，对应的安全产品也越来越齐全，用户已经可以使用公有云服务商的安全产品搭建较为完善的安全防护体系。而与之对应的是，公有云上各种安全合作伙伴的产品购买量实在稀少。大量安全产品购买量维持在个位数。
这种情况非常常见，各安全企业在公有云上基本在赔本赚吆喝。
一来是因为公有云彻底改变了安全行业，最传统的4层防火墙、DDOS设备、堡垒机。他们要么弱化成云上的一个服务，要么已经不适用。特别在PaaS化后，甚至SaaS化后，云租户需要承担的安全建设责任越来越少。安全厂家的主战场已经完全转移到了私有云和混合云上。谁转型更快、谁的产品更好谁将重洗企业安全市场。
二，传统厂家的安全设备在公有云上的使用体验太差，因为网络结构、底层架构变化的原因，传统安全设备在云上的部署过程繁琐，而且许多传统网络中的功能不再适用。安全厂家们急匆匆搬上云的各种安全服务无论在UI亦或功能上都没能为云用户做出足够多的优化，导致用户体验极差。而各种云们天生集成的各种安全服务，在这种情况下优势明显。
所以我依旧认为公有云最终将成长为巨无霸型的IT服务商，巨大的用户量足以支撑公有云将各种常用的IT产品全部包含在其产品体系内，其产品体系将越来越庞大。公有云企业吞噬掉的的不仅仅是传统IT硬件的市场份额，还包括部分软件和服务的市场空间。
所以当我们说IT总市场在不断增长，但是这其中有相当大一部分将被公有云蚕食，公有云在IT建设中的比重将越来越高，中小IT企业的存活堪忧。也许用不到10年，到那时公有云或许已经不能叫公有“云”了。当未来云计算公司真的变成自来水公司后，IT将变成什么样子？眼镜、手表会不会纳入到云计算的平台？是否会有新的计算平台出现，又引领一波自建的浪潮？运维这一职业是否变成开发语言的package？也许唯一能够肯定的是，现在我们耳熟能详的业务都会“消失”，人们不再提起它，但是IT行业将变得更具活力。到那个时候 Nicholas G. Carr 应该再写一篇 “Cloud Doesn't Matter”。
扯得有点远，但是只有放开脑洞畅想一下未来，才能更好地看清现在。
neutron的vpn没啥可讲的，所以就看一看sd-wan吧。
