【LVS】keepalived 是LISTEN了112端口吗

疑问：

keepalived  LISTEN的是112端口吗？

keepalivd主备节点之间使用vrrp协议进行通信。vrrp是一个组播协议，IPv4使用224.0.0.18进行通信。

通过netstat命令可以发现keepalived确实有一条LISTEN信息：

但是这个LISTEN信息和普通的tcp LISTEN（对比的是ssh的22端口）明显有所不同。

个人理解如下：

vrrp协议和TCP，UDP等等处于同一层级，基于ip层进行工作。IP头中有一个8位的协议号字段。用来表明ip层之上是什么协议。

比如TCP的协议号是6。操作系统检测到报文的协议号字段为6时，就会将报文交给TCP模块处理（同样由操作系统实现）。用户进程LISTEN的是端口号，端口号是tcp协议里面的概念。TCP模块处理完成之后，将报文交给对应的进程。

比如说上面的截图中，sshd使用的就是TCP的22端口。

UDP和TCP一样。

但是操作系统没有解析VRRP协议的模块，所以当IP层发现报文协议号是112号，就必须查看是否有进程在接收这个协议号的报文。如果有，则将报文交给对应的进程处理。否则就只能将报文丢弃，并视情况而决定是否需要返回一个错误信息。

所以，上面我们有netstat 命令查看到的，即是keepalived这个进程在LISTEN所有协议号为112的报文。这种直接基于ip层的连接，称之为raw socket。不过state 7表示什么没有查到。

但是，keepalived   LISTEN的ip地址却是0.0.0.0，这可能存在一定的安全风险。

显然，更为安全的做法，是只LISTEN目的地址为224.0.0.18，协议号为112的报文。但是查了很久，却没有找到对应的设置方法。

如果有需要，可能只能通过查看源码来寻找解决方案了。

为了进一步验证keepalived监听0.0.0.0到底有多大安全风险，专门去学习了一番发包工具scapy，并进行了验证。

构造报文并发送：

ppp=IP(src="100.101.80.177",dst="10.185.191.142", ttl=255)/VRRP(version=2L, type= 1L, vrid= 143 , priority= 200, ipcount= 1, authtype= 0,adv= 1, addrlist= ['10.185.191.143'], auth1= 0, auth2= 0)
send(ppp, loop=True, inter=1)

查看10.185.191.142日志：

linux Keepalived_vrrp[5871]: invalid ttl. 247 and expect 255
linux Keepalived_vrrp[5871]: bogus VRRP packet received on eth0 !!!
linux Keepalived_vrrp[5871]: VRRP_Instance(LVS_DR_HW) Dropping received VRRP packet...
linux Keepalived_vrrp[5871]: invalid ttl. 247 and expect 255
linux Keepalived_vrrp[5871]: bogus VRRP packet received on eth0 !!!
linux Keepalived_vrrp[5871]: VRRP_Instance(LVS_DR_HW) Dropping received VRRP packet...

说明构造的报文确实能够被keepalived进程收到，只是由于ttl值不满足要求而被丢弃了。

不过比较奇怪的是不明白为什么ttl值变成了247,ping表明只会经过3跳：

换到和10.185.191.142同一个局域网内的10.185.191.140，再发送伪造的vrrp报文时，就成功的迷惑了10.185.191.142上面的keepalived。

倒换为了备节点：

linux Keepalived_vrrp[5871]: VRRP_Instance(LVS_DR_HW) Received higher prio advert
linux Keepalived_vrrp[5871]: VRRP_Instance(LVS_DR_HW) Entering BACKUP STATE
linux Keepalived_vrrp[5871]: Opening script file /opt/envs/RCLVSService/to_backup.sh

结论：

由于ttl校验的存在，从外网应该是无法攻击keepalived的。

但也并非绝对：

1. 既然keepalived会处理这个报文，那是不是就可以发送足够多的报文，把keepalived撑爆

2. keepalived的实现上如果存在bug。构造特殊的报文从而绕过校验

更为安全的做法显然还是只监听224.0.0.18。怎么才能监听224.0.0.18, 需要进一步研究。