Freeswitch ldns crash问题分析

最新推荐文章于 2024-03-07 22:58:44 发布

hnzwx888

最新推荐文章于 2024-03-07 22:58:44 发布

阅读量1k

点赞数

分类专栏： Freeswitch 程序崩溃专题文章标签： Freeswitch crash

Freeswitch 同时被 2 个专栏收录

62 篇文章

订阅专栏

程序崩溃专题

29 篇文章

订阅专栏

本文介绍了一次FreeSwitch coredump的问题排查过程，发现是由第三方库ldns的bug导致，在高并发请求下引发崩溃。通过分析日志与核心转储文件，最终确定为网络攻击，并采取开启防火墙等措施解决了问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

转载自：https://www.jianshu.com/p/5a4e44fd8b8e

先来看一个FS的coredump的堆栈信息。你看到这个慌不慌？

#0  0x00007f62d15af1f7 in raise () from /usr/lib64/libc.so.6
#1  0x00007f62d15b08e8 in abort () from /usr/lib64/libc.so.6
#2  0x00007f62d15eef47 in __libc_message () from /usr/lib64/libc.so.6
#3  0x00007f62d1689d87 in __fortify_fail () from /usr/lib64/libc.so.6
#4  0x00007f62d1687f40 in __chk_fail () from /usr/lib64/libc.so.6
#5  0x00007f62d1689cf7 in __fdelt_warn () from /usr/lib64/libc.so.6
#6  0x00007f62b7bd0095 in ldns_sock_wait () from /usr/lib64/libldns.so.1
#7  0x00007f62b7bd057f in ldns_udp_send () from /usr/lib64/libldns.so.1
#8  0x00007f62b7bd0d1a in ldns_send_buffer () from /usr/lib64/libldns.so.1
#9  0x00007f62b7bd1029 in ldns_send () from /usr/lib64/libldns.so.1
#10 0x00007f62b7bd5e9d in ldns_resolver_send_pkt () from /usr/lib64/libldns.so.1
#11 0x00007f62b7bd62c2 in ldns_resolver_send () from /usr/lib64/libldns.so.1
#12 0x00007f62b7bd6400 in ldns_resolver_query () from /usr/lib64/libldns.so.1
#13 0x00007f62b7dfd3d0 in ldns_lookup () from /usr/lib64/freeswitch/mod/mod_enum.so
#14 0x00007f62b7dfd61a in enum_lookup () from /usr/lib64/freeswitch/mod/mod_enum.so
#15 0x00007f62b7dfd817 in enum_dialplan_hunt () from /usr/lib64/freeswitch/mod/mod_enum.so
#16 0x00007f62d3d57dbf in switch_core_session_run () from /usr/lib64/libfreeswitch.so.1
#17 0x00007f62d3d5033e in switch_core_session_thread () from /usr/lib64/libfreeswitch.so.1
#18 0x00007f62d3d4bd83 in switch_core_session_thread_pool_worker () from /usr/lib64/libfreeswitch.so.1
#19 0x00007f62d4012900 in dummy_worker () from /usr/lib64/libfreeswitch.so.1
#20 0x00007f62d2017e25 in start_thread () from /usr/lib64/libpthread.so.0
#21 0x00007f62d167234d in clone () from /usr/lib64/libc.so.6

反正一开始我慌的一批。FreeSwitch的coredump，我又要开始扒代码了。

镇定下来一看，好像还不是FS的锅。问题出在ldns三方库上。根据coredump的时间，在FS日志中找一找看看是否有线索。

coredump时日志位置

再根据这里的提示找一下源码

mod_emun:495

看到这里难道和resolv.conf有关？这个和DNS解析有关，检查了这个文件，也没有太大问题。应该不是这个原因。

在看一下日志，这里的17940046812410296实际上是拨号计划里的DestinationNumber。为什么会有这么奇怪的DestinationNumber？
我检查了FS上的拨号计划，里面也没有配置过如此怪异的DestinationNumber。难道是网络上的攻击？

再次查看日志，发先这种奇怪的DestinationNumber出现次数比较多。

还是问一下谷歌吧。似乎找到了问题原因。请看下面的参考。

参考 https://blog.youkuaiyun.com/y_xianjun/article/details/79882632

概括一下就是ldns库中的 ldns_sock_wait使用了select等待socket。但是select使用的socket数组长度是1024。如果超过了这个长度，这里就crash了。

明白了这个原因，重新再来日志中统计一下奇怪的DestinationNumber

[root@fs freeswitch]# grep "ENUM Lookup on" freeswitch.log | wc -l
1083

好吧。黑客你赢了。

那么如何解决呢？

首先，可以选择参考中的方案，升级ldns库。但我觉得治标不治本。根本原因还是因为受到了网络攻击。
我把防火墙打开后，好了。（原谅我之前一直没有开防火墙）

作者：安安爸Chris
链接：https://www.jianshu.com/p/5a4e44fd8b8e
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。