SIP UDP 请求突破 iptables

信息安全 linux 防火墙 sql注入 iptables 啜
2021-08-23 13:56:24

我最近一直在调查一些实例，其中 SIP UDP 流量以某种方式逃避了 iptables 中定义的规则集，这导致我怀疑我们的规则中存在漏洞，因此我正在寻找有关如何加强本地系统防御的建议。我们在此服务器之前有一个可以改进的防火墙，但是在我们研究其他措施之前了解这个问题似乎很重要，因为这个问题直接与本地服务器防御有关 - 特别是 iptables。

SIP 数据包开始包含 SQL 注入尝试，我担心如果不直接处理，应用程序最终可能会受到损害。目前，“呼叫者”设法建立一个简单地播放我们的无服务通知的呼叫，因此他们正在与本地服务器开始 SIP 对话 - 不理想！

我已经使用一致的编辑方案复制了下面的详细信息，但是如果需要其他信息，请在下面发表评论，我会提出来。

感谢任何建议，感谢您的关注！

源IP：185.107.83.35 SIP服务器IP：200.200.114.207

我将从一个攻击性 SIP 数据包的示例开始：

INVITE sip:00*31203697460@200.200.114.207:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 185.107.83.35:5060;branch=z9hG4bK-524287-1---i9aif7pifkudxkd8
Max-Forwards: 70
Contact: <sip:...hi'or...x...='x';@185.107.83.35:5060;transport=UDP>
To: <sip:00*31203697460@200.200.114.207;transport=UDP>
From: <sip:...hi'or...x...='x';@200.200.114.207;transport=UDP>;tag=gj0njz16
Call-ID: LztInRxh5KJSOAGxCOGB0T..
CSeq: 1 INVITE
Content-Type: application/sdp
User-Agent: Avaya one-X Deskphone
Allow-Events: presence, kpml, talk
Content-Length: 515

v=0
o=Avaya 0 0 IN IP4 185.107.83.35
s=Avaya
c=IN IP4 185.107.83.35
t=0 0
m=audio 8000 RTP/AVP 18 3 110 8 0 97 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:98 AMR/8000
a=rtpmap:9 G722/8000
a=rtpmap:100 SPEEX/8000
a=rtpmap:99 AMR-WB/16000
a=rtpmap:102 SPEEX/16000
a=rtpmap:121 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:105 opus/48000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

主机IP配置：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:11:22:33:44:7d brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.20/24 brd 255.255.255.255 scope global em1
    inet6 aaaa::aaaa:aaaa:aaaa:aaaa/64 scope link
       valid_lft forever preferred_lft forever
3: em2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:11:22:33:44:7f brd ff:ff:ff:ff:ff:ff
    inet 200.200.114.207/26 brd 200.200.114.255 scope global em2
    inet6 aaaa::aaaa:aaaa:aaaa:aaaa/64 scope link
       valid_lft forever preferred_lft forever
4: em3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:11:22:33:44:81 brd ff:ff:ff:ff:ff:ff
5: em4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:11:22:33:44:83 brd ff:ff:ff:ff:ff:ff

这是来自的输出iptables -v -n --list

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
4769K  538M ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           /* 000 accept all icmp */
 645M  276G ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           /* 001 accept all to lo interface */
  11G 2946G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           /* 002 accept related established rules */ state RELATED,ESTABLISHED
4036K  238M ACCEPT     tcp  --  em1    *       0.0.0.0/0            0.0.0.0/0           multiport ports 22 /* 101 accept SSH from internal interface */
36907 2036K ACCEPT     all  --  em1    *       192.168.4.0/24       0.0.0.0/0           /* 102 accept all traffic from site 1 LAN */
 160K 6397K ACCEPT     all  --  em1    *       192.168.5.0/24       0.0.0.0/0           /* 103 accept all traffic from site 1 LAN */
8651K  527M ACCEPT     all  --  em1    *       192.168.20.0/24      0.0.0.0/0           /* 105 accept all traffic from site 2 LAN */
    0     0 ACCEPT     tcp  --  em2    *       190.190.89.10        0.0.0.0/0           multiport ports 22 /* 106 accept SSH from WAN */
    0     0 ACCEPT     tcp  --  em1    *       0.0.0.0/0            0.0.0.0/0           multiport ports 2812 /* 107 accept monit from LAN */
41878   19M ACCEPT     udp  --  em2    *       190.190.89.0/26      0.0.0.0/0           multiport ports 5060 /* 150 accept SIP from WAN */
 144K   55M ACCEPT     udp  --  em2    *       200.200.114.192/26   0.0.0.0/0           multiport ports 5060 /* 152 accept SIP from WAN */
    0     0 ACCEPT     udp  --  em2    *       180.180.63.32/27     0.0.0.0/0           multiport ports 5060 /* 201 accept SIP from carrier */
    0     0 ACCEPT     udp  --  em2    *       180.180.63.32/27     0.0.0.0/0           multiport ports 8000:60000 /* 202 accept RTP from carrier */
    0     0 ACCEPT     udp  --  em2    *       170.170.67.2         0.0.0.0/0           multiport ports 5060 /* 210 accept SIP from carrier */
    0     0 ACCEPT     udp  --  em2    *       170.170.67.2         0.0.0.0/0           multiport ports 8000:60000 /* 211 accept RTP from carrier */
  55M 8576M ACCEPT     udp  --  em2    *       0.0.0.0/0            0.0.0.0/0           multiport ports 16384:32768 /* 300 accept all RTP */
 489K  219M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           /* 999 reject all other requests */ reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           /* 998 reject all FORWARD */ reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 12G packets, 3230G bytes)
 pkts bytes target     prot opt in     out     source               destination
4个回答

您应该检查该数据包上的 IP 标头。在 TTL 值之后，它应该指示协议。如果协议作为一个进来，那将是你的问题。我以前见过这样的事情。

协议值 1 表示 ICMP，您在全球范围内允许将其作为您的第一条规则。虽然这是 ping 正常工作所必需的，但它将允许格式错误的数据包，除非您将外围防火墙配置为拒绝它们。

根据您的特定配置，有效的 SIP 数据包标头应为 UDP 使用 17 或为 TCP 使用 6。

如果攻击者使用格式错误的 SIP 数据包（设置为协议 1 而不是 17），您可以将防火墙配置为丢弃除 ping 之外的所有类型的 ICMP 数据包。除了来自外部主机的有效 ping 之外，几乎没有理由接受任何东西。

在这种情况下，可能是 pcap 文件有帮助，但是，根据给出的信息，我认为这是发生的事情：

INVITE 有源 IP 和目标 IP 200.200.114.207， 

To: <sip:00*31203697460@200.200.114.207;transport=UDP>
From: <sip:...hi'or...x...='x';@200.200.114.207;transport=UDP>;tag=gj0njz16

如果 INVITE 是正确的，它看起来 IP 地址与我认为的您的规则之一匹配。

144K   55M ACCEPT     udp  --  em2    *       200.200.114.192/26   0.0.0.0/0

你可以做的是从端口规则开始，5060 和 5061 是常规的 SIP 端口，然后是你的 iptables 上的 IP 范围。

您在链的开头有一个相关/既定的规则（就像我们一样）。检查 iptables 的 sip 模块是否存在。

lsmod |grep -i sip

这可能是泄漏的根源。如果是这样，请尝试绕过它以获取 SIP 流量。

仅供参考，我有这个完全相同的问题。从测试来看，UDP 连接跟踪（在 RELATED、ESTABLISHED 规则中调用）似乎以某种方式将指定用于 UDP/5060 的数据包识别为现有或相关会话的一部分。您可以通过查看连接跟踪表并在 UDP/5060 上搜索整体来检查这一点；违规条目将具有 [ASSURED] 标志。

我的猜测是 conn 跟踪器将数据包视为相关会话的一部分，并允许数据包通过。然后服务器做出响应（通常是 SIP INVALID 响应），并将其发送到 ASSURED 状态。从技术上讲，相关部分只应该由连接跟踪器助手（如 SIP ALG 助手）调用；我没有加载该内核模块，所以也许我有点偏离并且它没有将其视为相关，但实际上是一个已建立的会话。如果是这样，那就是更大的错误了。

我目前的解决方法是在达到 ESTABLISHED / RELATED 规则之前阻止来自那些违规 IP 的数据包。这解决了它，没有那么多，但它很烦人。

其它你可能感兴趣的问题
上一篇IMEI 号码的安全性如何？ 下一篇Android 更新电话号码，“要继续，请先验证您的身份”