创新沙盒:“软件定义安全”不再是实验室产物

自从著名咨询机构Gartner在《The Impact of Software-Defined Data Centers on Information Security》 一文中提出软件定义安全(Software Defined Security,SDS)的概念后,软件定义与安全的结合已成为业界的前沿发展热点。背后的原因很直观:软件定义安全强调了安全控制平面与数据平面分离,从而在控制平面上可灵活调整应用策略,快速变更安全业务。 在安全可被软件定义后,新的安全业务可在企业网络中可新上线,特别是在数据中心中,可实现计算、存储、网络和安全的弹性控制,实现软件定义的数据中心SDDC。正是因为这些优秀的特性,解决了企业客户长期面临的安全管理和运营“痛点”,软件定义安全自从开始就引起了学术界和工业界极大的关注。 各大厂商都开始做相关的研究和研发工作,RSA大会一直是厂商们展现自己最新工作的舞台。如Check Point在RSA 2014大会上宣布推出软件定义防护(Software Defined Protection,SDP)革新性安全架构,可在当今日新月异的IT和威胁环境中为企业提供虚拟化的边界防护。赛门铁克也在RSA 2015提出使用软件定义网络技术对APT攻击进行取证的话题也提供了一种安全事件事后快速分析的新思路 。 而RSA大会开到了第25个年头时,我们惊喜地发现更多的公司在展示在软件定义安全的领域的工作,特别是在体现创新的Innovation Sandbox(创新沙盒)竞赛中,10家经过专业评审的公司,居然有3家与这个话题有关,分别在不同的方面做出了开创性的工作。 如Versa Networks公司,强调在软件定义广域网(SD-WAN)和分支(Branch)网络的环境中,通过虚拟化网络功能(VNF)技术,将各种各样异构的网络功能编程通用的组件,可快速在相应的网络中部署,大大减少了企业部署相应业务的开销,提高了整个过程的敏捷程度。 Skyport Systems公司同样也是为企业提供高效的安全计算基础设施,但按照传统建立边界思维,攻击者在进入系统内部后就容易进一步攻击内部其他重要资源。该公司的逻辑是,所有的资源都是零信任,这样即便内部某资源被攻破,那么从该点作为跳板进一步攻击也是困难的。那么这里就涉及到软件定义的访问控制,例如如何做到“零信任”条件下各处的访问控制策略快速调整。该公司在B轮融资中获得3000万美元。 再如Phantom Cyber公司认为在大量出现攻击的场景下,花费大量的人力去发现解决问题已不太现实。与前两个公司不同,Phantom Cyber从应用层入手,构建自动化、可编排的安全应用体系。它支持多种主流的数据分析平台,可利用较为高层的脚本实现安全运维自动化。 当然除了这些初创公司,还有很多公司也在基于自身产品做相关的工作。如在29日的Session环节,VMWare的安全产品部门SVP Tom Corn就演示了在NSX的环境中,如何可按需定义微分段(MicroSegmentation),并对任意APP间快速添加加密处理。厂商展示区域,Catbird公司的软件定义安全架构 通过微分区(Micro-Segmentation)在虚拟环境中划分不同的区域,并通过编排将安全策略下发给多种类型的安全设备,并作用在区域级别或虚拟机级别。这些工作都体现了各家在成熟产品线通过软件定义做了很多延展性的工作。 绿盟科技自2013年开始研究SDN和软件定义安全,研发了包括软件定义的抗DDoS、流量异常检测和Web安全等原型系统,并在2015年发布了软件定义安全的白皮书,探讨在该领域的进展。 创新沙盒中10个产品中出现了三个能体现SDS的产品,笔者认为其背后的原因有几个:其一,作为软件定义安全的支撑技术,如VNF/NFV、SDN方案,在国外已经有一些成熟的应用,如NSX已经代替Vsphere成为VMWare成长最快的产品,Cisco的ACI方案也与很多安全厂商有合作;其二,企业的高效安全运营需求,直接催生了安全编排这些应用层面的创新;其三,也是最重要的,出于企业对降低成本的天然需求,软件定义的理念转换为实际产品的动力十足。 … Continue reading

ssh翻墙简单说明

1 购买vps。设置用户名user和密码pass 2 新建ssh profile。以xshell为例,新建一个profile,输入vps的ip、port、user和pass 3 建立隧道。在profile属性->连接->SSH->隧道->添加,类型为Dynamic,侦听端口1080。同时启用转发x11(不知是否需要),保存profile。 4 连接vps,默认情况下连接成功。存在两 会等时候,可能被封掉… 5 安装浏览器扩展,如firefox的foxyproxy 6 以foxyproxy为例,新建一个proxy,URL匹配模式为要翻墙的url,如*google*,代理服务器细节中选择手动配置代理服务器,主机为127.0.0.1,端口1080,socks代理。确认 7 启用该proxy,即可正常翻墙

Ubuntu下openvswitch添加tcp监听

本来这不应该是什么值得写的内容,不过有些需要hack一下,所以还是记一下为好。 Ubuntu下面的openvswitch默认是开启punix(被动监听unix)进行管理ovsdb的,那么就不能查看和控制远程主机的ovsdb,openvswitch其实还可以开启ptcp或pssl模式,就可以打开远程的访问(当然存在风险,需假设控制网络是可信的)。 不过配置文件(/etc/default/openvswitch-switch,/etc/init.d/openvswitch-switch)都没有该配置项,后来找了找,相关脚本在/usr/share/openvswitch/。(dpkg -L openvswitch-switch) 其中启动ovsdb-server的脚本在/usr/share/openvswitch/scripts/ovs-ctl里面。 187 set “$@” -vconsole:emer -vsyslog:err -vfile:info 188 set “$@” –remote=punix:”$DB_SOCK” –remote=ptcp:6640 这里面添加一个tcp端口即可。 p.s. 如果去掉punix应该不行,因为ovs-vsctl默认使用了punix的方式,所以这里使用了同时启用punix和ptcp模式。 另,这个py-ovsdb-client项目还不错,封装了多种ovsdb的api,直接在python中调用即可。

在宿主机中用ovs连接内网vm

经常需要做实验验证VM的性能,那么实验环境为:H是一个物理主机(物理网卡网段为192.168.19.0/24),H中启动一台VM,VM的一个管理口eth-M配有私网ip(网段100.100.100.0/24),并连接到一个OVS桥br-test上。现在需要在H中直接连接VM。 一个直观的想法是直接ping VM,但VM与宿主机的主IP不是一个网段,所以不能直接通信,需要一个网关GW。那就直接在br-test上新建一个类型为internal的接口做网关。 ovs-vsctl add-port br-test gw — set Interface gw type=internal ifconfig gw 100.100.100.1 iptables -t nat -I POSTROUTING -j SNAT -s 192.168.19.0/24 –to-source 100.100.100.1 iptables -t nat -I POSTROUTING -j SNAT -s 100.100.100.0/24 … Continue reading

使用cloud-init实现虚拟机信息管理

为什么要用cloud-init 不同种类的设备VM启动总是一件非常麻烦的事情,例如安全设备有WAF、IPS等,每种设备的网络接口、启动脚本互不一样,即便同一种设备,其主机名、网络地址等也不一样。那么如何对这些VM启动过程进行管理,并完成所有数据的配置呢? 在这之前,我的实习生是怎么做的:将一台VM的管理口网络地址设置为192.168.2.100,然后每次启动实例之后定时访问http://192.168.2.100/somepath,当成功访问这个页面之后,使用REST接口配置该机器的IP地址为所需的新地址(如200.0.0.2);这个时候网络会短暂不同,然后在访问http://200.0.0.2/somepath,当成功访问之后,接下来配置各种值。 整个过程比较麻烦,所有的配置都需要实现REST接口,无法做到自定义启动脚本的更新;最不可接受的是,这个过程是串行的,当要启动100个VM时,只能一个VM一个VM顺序启动,否则两个VM都有同一个地址(192.168.2.100),那么网络访问就可能出现问题了。 不过受到各种Stack管理虚拟机用到cloud-init的启发,我认为我们也可以使用这套工具实现上述过程的。 什么是cloud-init cloud-init(简称ci)在AWS、Openstack和Cloudstack上都有使用,所以应该算是事实上的云主机元数据管理标准。那么问题来了,google相关的文档,发现中文这方面几乎没有,Stacker你们再搞虾米呢?当然话说回来英文的资料除了官网外几乎也没有什么,我花了近一周的时间才弄明白了。 首先要明确的是cloud-init在工作之前,VM是从DHCP服务器获取到了IP,所有DHCP发现不是cloud-init的事情。当你在Openstack中用ubuntu cloud VM启动卡在cloud-init界面时,多半是因为DHCP还没获取IP,而不是cloud-init本身的问题。那么cloud-init主要走什么呢?它向一台数据服务器获取元数据(meta data)和用户数据(user data),前者是指VM的必要信息,如主机名、网络地址等;后者是系统或用户需要的数据和文件,如用户组信息、启动脚本等。当cloud-init获取这些信息后,开始使用一些模块对数据进行处理,如新建用户、启动脚本等。 cloud-init工作原理 首先,数据服务器开启HTTP服务,cloud-init会向数据服务器发送请求,确认数据源模块,依次获取版本、数据类型和具体数据内容信息。 确认数据源模块 cloud-init会查找/etc/cloud/cloud.cfg.d/90_dpkg.cfg中的datasource_list变量,依次使用其中的数据源模块,选择一个可用的数据源模块。如我的配置文件中:datasource_list: [ Nsfocus, NoCloud, AltCloud, CloudStack, ConfigDrive, Ec2, MAAS, OVF, None ],那么ci首先调用$PYTHON_HOME/dist-packages/cloudinit/sources/DataSourceNsfocus.py中类DataSourceNsfocus的get_data函数,当且仅当访问链接DEF_MD_URL为正常时,这个数据源被认为是OK的。 在我的实践中,CloudStack的DEF_MD_URL为DHCP的服务器ip,而Openstack和AWS则为一个常值169.254.169.254,然后在宿主机的中做一个iptables重定向,这样就到了我们的服务器监听端口8807: $ sudo ip netns exec ns-router iptables … Continue reading

Openstack节点网卡连Cisco交换机出现环路的处理

前一阵子部署了两台Openstack的计算节点,奇怪的是每隔一段时间连管理网的网卡eth0灯不亮,交换机上对应的19端口灯变橙色,登陆上去一看,eth0显示: 2: eth0: mtu 1500 qdisc mq master ovs−system state DOWN mode DEFAULT group default qlen 1000 运行ip link set eth0 up无效。 登陆交换机,查看端口状态: Switch>enable Switch#show interfaces gigabitethernet 0/19 status Port Name Status Vlan Duplex Speed … Continue reading

openstack icehouse update errors

最近将Openstack从havana升级到icehouse,总体问题不大,但是还是有点小问题,花了一点时间。 1 密钥过期,keystone的密钥提示过期。 如nova提示: 2014-04-29 10:52:14.074 27081 WARNING keystoneclient.middleware.auth_token [-] Verify error: Command ‘openssl’ returned non-zero exit status 4 解决办法是1) 备份/etc/keystone/ssl目录并删除,运行keystone-manage pki_setup –keystone-user keystone –keystone-group keystone,上面的ssl目录会生成,这里的用户名和用户组为linux系统中的keystone对应的用户和组 3) 修改ssl目录属主和权限700. neutron也可能由此提示,解决办法是删除/var/lib/neutron/keystone-signing目录,并重启neutron-server。 此外,可能还需要删除/tmp下的keystone-signing-xxxxx目录。 总体而言,上面的错误表面现象为keystone 401 Unauthorized的错误,但是解决问题需要定位到相应模块,用debug=true和verbose=true从调试信息中找出问题。 如nova list返回401的原因有可能是neutron的证书问题,所以大家在调错是一定要仔细。 … Continue reading

Openstack中构造伪造源地址攻击

前一篇是将防御,这一篇简单说一下openstack下如何发动伪造源ip的DoS攻击 1 修改iptables和ebtables的设定,例如攻击vm为100.0.0.17,那么查询相应的iptables规则: neutron port-list |grep 17 | 091f121f-8cd7-4a02-b1d8-53866ab25d3d | | fa:16:3e:f7:9d:70 | {“subnet_id”: “57b30eb5-e9ee-489f-85ea-77bcaa6249e5”, “ip_address”: “100.0.0.17”} | 找到iptables中含有091f121f-8的链:neutron-openvswi-s091f121f-8,neutron-openvswi-i091f121f-8,neutron-openvswi-o091f121f-8,和nova-instance-xxx(与该vm对应的)插入一条优先级最高的ACCEPT链 找到ebtables中nat表中091f121f-8的链:I-tap091f121f-8c-arp-ip,I-tap091f121f-8c-ipv4-ip,插入一条优先级最高的ACCEPT链 2 安装ruby,下载pentibox 3 启动pentibox,选择Network tools->Net DoS Tester -> 任意一种即可发动攻击 如果第1步中加了规则还是不通,请检查源主机和目的主机的安全组是否允许 下面的我写的脚本,希望对大家有所帮助 #!/bin/bash ip=$1 echo $ip … Continue reading

Openstack中伪造源地址攻击的防御

背景:Openstack在H版之前的时候,租户可以租用虚拟机发动DoS攻击,很多攻击的方式是伪造源地址。还有别的攻击,如ARP攻击等等,都是通过伪造源MAC或IP地址实现的。本文简单介绍一下openstack中抵御虚假源地址的攻击。 这种攻击的特点是攻击者从虚拟化系统内部发起,攻击目标可能是公网主机,或者是内网的主机。对于前者的防御比较容易,只需要在物理网络边界就可以部署安全设施进行检测和清洗;但是后者的攻击流量大部分是存在于虚拟网络和虚拟网络设备中,物理的安全设备是无法观测或理解物理网络中的流量,无法进行有效的防护,所以对于始于内部的DoS攻击,应该在虚拟化环境中将检测并抵御。 在Openstack的架构下,预计一种检测DoS攻击的方式是依靠检测模块Ceilometer,等它成熟之后,就可及时通知管理员或系统,通过Ceilometer与Neutron协作堵住这种攻击。 不过现在Ceilometer还在初级阶段,所以还是需要依靠网络虚拟化模块Neutron进行防护,好在IaaS系统知道VM的真实IP和MAC,所以可以直接在L2防火墙上对数据包进行过滤,H版已经引入了这部分特性。 下面以一台vm为例: # neutron port-list|grep 100.0.0.16 | 368d35e1-4db7-405f-af26-1f2b6f224bd8 | | fa:16:3e:34:c8:f8 | {“subnet_id”: “57b30eb5-e9ee-489f-85ea-77bcaa6249e5”, “ip_address”: “100.0.0.16”} | 2013.2.1引入了基于IPTABLES的过滤方案 iptables -L -nvx 可以看到: Chain neutron-openvswi-s368d35e1-4 (1 references) pkts bytes target prot opt in … Continue reading

neutron中一种常见网络不通的现象,附修复脚本

neutron中经常发现vm ping不通网关,我发现很多情况是因为ovs-plugin没有将qvb连接到qbr桥上,所以解决办法也很简单,就是将其连上,即将qbr设为master。 具体的neutron、ovs、veth和iptables等就不展开讲了,具体可以看下图 当一个vm启动或被硬重启之后,tap接口(当使用gre模式时为tap)和qbr桥会被自动创建,而且tap的master为qbr。理论上qvb的master也应该是qbr,但我经常发现这个link的master没有被设置。那么设置脚本就很简单了: #!/bin/bash LINKS=`ip link|grep qvb |awk ‘{print $2}’ |sed s’/.$//’|sed s’/^…//’` for LINK in $LINKS do # a qbr link should appear after hard reboot an instance ip link set “qbr$LINK” up … Continue reading