一、前文
二、思考问题
从上一篇博客得知,因为内存大小设置的不合理,容易导致OOM内存溢出,最终导致服务崩溃。
事后转念一想,又在思考:如果是配置问题,那么服务应该无法启动才对。
为何服务能够正常运行三四小时才崩溃,深入思考并咨询了天谋科技的工程师之后。
我们认为是:外网攻击,一次性注入大量数据,导致OOM内存溢出。
那么新的问题来了,IoTDB服务这么容易被攻击至崩溃吗?
这时候,我拍了拍脑壳,root密码我还没改,还在用默认的。
三、验证问题
想到方法,就马上去验证。
- 在
iotdb-datanode.properties
中,还原# dn_thrift_max_frame_size
# thrift max frame size, 512MB by default
# Datatype: int
# dn_thrift_max_frame_size=16777216
- 把root密码修改复杂点
ALTER USER SET PASSWORD ‘password’;
- 重启IoTDB服务
bash sbin/stop-standalone.sh
[root@iZgw0bdpdtyqxyz77dha9nZ apache-iotdb-1.3.2-all-bin]# bash sbin/stop-standalone.sh
Check whether the internal_port is used..., port is 10710
Stop ConfigNode, PID: 30555
Check whether the rpc_port is used..., port is 6667
No DataNode to stop
bash sbin/start-standalone.sh
[root@iZgw0bdpdtyqxyz77dha9nZ apache-iotdb-1.3.2-all-bin]# bash sbin/start-standalone.sh
Execute start-standalone.sh finished, you can see more details in the logs of confignode and datanode
- 等待一天后,IoTDB服务正常运行。
- 这时候基本确认,服务崩溃的原因是外网攻击导致。
- 但是为了双重确认,这时候再将root密码改回默认。
- 重启IoT服务,继续等待。不到半天,IoT服务崩溃了。
- 定案了,就是外网攻击导致服务器崩溃。
五、深入思考
如果我是黑客,我会如何攻击?
- 如果没有密码,我确实无法着手,毕竟咱也没做过黑客,也没做过红客。
- 如果有root密码,那直接登录连接,然后使用sql查询数据和插入数据。
- 一次插入大量数据,超过512M,又因为我内存设置不合理。IoT服务直接崩溃。
根源找到了,如何解决问题?
- 加强用户密码管理,加强用户权限管理。
- 事后追责定责,需要登录日志和操作日志。
于是我继续追问天谋科技工程师,是否能够查询IoTDB的登录日志和操作日志?
-
被告知:开源版本无该功能,企业版有该功能。如下图所示。
六、总结
很多的bug,主要还是人为操作原因。
不要老怪系统不好用,静下心来,花点时间,深入排查,总是有收获的。
觉得好,就一键三连呗(点赞+收藏+关注)