背景
这两天收到安全部门同事的邮件，说线上OpenStack环境的物理机VNC端口能够自由访问，要求整改。我这随机抽查了两台宿主机的VNC端口，确实很多业务的同学使用noVNC后没有退出终端的习惯，往往都是用完了就直接关闭窗口。不得不说这样隐患很大啊，首先不说通过外部方式规避风险，如果内网里面有一些script kiddie随时都能将我们线上的虚拟机VNC端口扫出来干些坏事。我这里也用过nmap测试了下开发环境的网络端口，如下：
$ nmap 192.168.68.0/24
Nmap scan report for kvm54.com (192.168.68.54)
Host is up (0.00017s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
111/tcp open rpcbind
5900/tcp open vnc
5901/tcp open vnc-1
6789/tcp open ibm-db2-admin
Nmap scan report for kvm55.com (192.168.68.55)
Host is up (0.00020s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
111/tcp open rpcbind
5900/tcp open vnc
5901/tcp open vnc-1
5902/tcp open vnc-2
Nmap scan report for kvm56.com (192.168.68.56)
Host is up (0.00023s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
5900/tcp open vnc
5901/tcp open vnc-1
5902/tcp open vnc-2
Nmap scan report for kvm57.com (192.168.68.57)
Host is up (0.00018s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
5900/tcp open vnc
5901/tcp open vnc-1
5902/tcp open vnc-2
6789/tcp open ibm-db2-admin
这个结果很恐怖啊，如果有业务同学在使用noVNC之后没有退出终端，那么另一个人如果知道了宿主机的IP和端口是完全可以登录这台虚拟机的。
解决
知道了问题，那就有对应的解决方案！
我这里目前暂时只想到两个方法来解决这个问题，也希望有大牛可以指点。
方案一
通过IPTABLES限制INPUT表对5900:5999的访问规则方案二
添加密码访问VNC
操作
IPTABLES
我们知道OpenStack通过VNC Proxy将管理网和业务网隔离开来，以便我们可以使用管理网络的6080端口访问虚拟机VNC，同时提供Token用于验证访问的合法性。一个VNC Proxy在OpenStack里的处理流程如下：
1. 一个用户试图从浏览器里面打开连接到虚拟机的VNC Client
2. 浏览器向nova-api发送请求，要求返回访问vnc的url
3. nova-api调用nova-compute的get vnc console方法，要求返回连接VNC的信息
4.nova-compute调用libvirt的get vnc console函数
5.libvirt会通过解析虚拟机运行的/etc/libvirt/qemu/instance-0000000c.xml文件来获得VNC Server的信息
6.libvirt将host, port等信息以json格式返回给nova-compute
7.nova-compute会随机生成一个UUID作为Token
8.nova-compute将libvirt返回的信息以及配置文件中的信息综合成connect_info返回给nova-api
9.nova-api会调用nova-consoleauth的authorize_console函数
10.nova-consoleauth会将instance –> token, token –> connect_info的信息cache起来
11.nova-api将connect_info中的access url信息返回给浏览器：http://172.24.1.1:6080/vnc_auto.html?token=7efaee3f-eada-4731-a87c-e173cbd25e98&title=helloworld%289169fdb2-5b74-46b1-9803-60d2926bd97c%29
12.浏览器会试图打开这个链接
13.这个链接会将请求发送给nova-novncproxy
14.nova-novncproxy调用nova-consoleauth的check_token函数
15.nova-consoleauth验证了这个token，将这个instance对应的connect_info返回给nova-novncproxy
16.nova-novncproxy通过connect_info中的host, port等信息，连接compute节点上的VNC Server，从而开始了proxy的工作
这里重要的就是第16步, nova-novncproxy是通过连接host:vncport的方式提供vnc访问服务。
那么也就是说，计算节点的VNC端口只需要让nova-novncporxy服务能够访问就行，有了这个就好办了。
操作IPTABLES
在所有计算节点IPTABLES的INPUT表中添加如下规则：
$ iptables -A INPUT -s {{ CONTROLLER_NODE_IP }}/32 -p tcp -m multiport --dports 5900:5999 -m comment --comment "ACCEPT VNC Port only by Controller Node" -j ACCEPT
$ iptables -A INPUT -p tcp -m multiport --dports 5900:5999 -j REJECT --reject-with icmp-port-unreachable
原理很简单，就是只接受控制节点访问本机的5900到5999端口，其他的连接一律拒绝。
当下次再用nmap扫描局域网的宿主机端口时，便不能看到VNC的端口。
$ nc -vz 192.168.68.58 5900
nc: connect to 192.168.68.58 port 5900 (tcp) failed: Connection refused
VNC添加访问密码
另外我们知道Libvirtd在<graphics>域里面是支持配置VNC的访问密码的。
...
<graphics type='vnc' port='-1' autoport='yes' listen='192.168.68.57' passwd='YOUR-PASSWORD-HERE' keymap='en-us'/>
...
那么Nova在创建虚拟机配置的方法中也可以找到对应graphics的代码，我这里修改得很简单，直接在返回的dev列表里面添加个passwd的value，而value就是VNC的访问密码。
virt/libvirt/config.py
1361 class LibvirtConfigGuestGraphics(LibvirtConfigGuestDevice):
1362
1363 def __init__(self, **kwargs):
1364 super(LibvirtConfigGuestGraphics, self).__init__(root_name="graphics",
1365 **kwargs)
1366
1367 self.type = "vnc"
1368 self.autoport = True
1369 self.keymap = None
1370 self.listen = None
1371
1372 def format_dom(self):
1373 dev = super(LibvirtConfigGuestGraphics, self).format_dom()
1374
1375 dev.set("type", self.type)
1376 if self.autoport:
1377 dev.set("autoport", "yes")
1378 else:
1379 dev.set("autoport", "no")
1380 if self.keymap:
1381 dev.set("keymap", self.keymap)
1382 if self.listen:
1383 dev.set("listen", self.listen)
1384 dev.set("passwd", "magine1989")
1385
1386 return dev
修改过后重启nova-compute服务，即在下次创建虚拟机的时候生效，其结果如下：
关于两种方案的思考
关于上面两种方案，很显然第一种方案很简单，而且高效更安全。唯一一点不好的就是访问计算节点的VNC端口只能通过控制节点做ssh代理，有时候在界面上使用noVNC访问虚拟机，实时性没那么好。至于第二种方案，在做公有云的场景下并不适用，不可能让用户在访问VNC的过程中再加一层密码。密码的灵活性先不谈，单是用户体验上就不太友好。如果在私有云或者内网环境下，VNC的访问密码还是可以在一定程度上隔离掉脚本小子的骚扰，又不至于影响VNC端口不能访问的尴尬，不管怎样方案二还是具有一定的侵入性。但是我相信Nova的开发没将VNC访问密码作为用户安全的辅助手段还是有道理的。毕竟有了第一种比较完美解决方案，再加个不太灵活的密码就太画蛇添足了。
参考：
