文章目录
一、前文
二、思考问题
从上一篇博客得知，因为内存大小设置的不合理，容易导致OOM内存溢出，最终导致服务崩溃。
事后转念一想，又在思考：如果是配置问题，那么服务应该无法启动才对。
为何服务能够正常运行三四小时才崩溃，深入思考并咨询了天谋科技的工程师之后。
我们认为是：外网攻击，一次性注入大量数据，导致OOM内存溢出。
那么新的问题来了，IoTDB服务这么容易被攻击至崩溃吗？
这时候，我拍了拍脑壳，root密码我还没改，还在用默认的。
三、验证问题
想到方法，就马上去验证。
- 在
iotdb-datanode.properties中，还原# dn_thrift_max_frame_size
sh
# 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
shell
[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 stopbash sbin/start-standalone.sh
shell
[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，主要还是人为操作原因。
不要老怪系统不好用，静下心来，花点时间，深入排查，总是有收获的。
觉得好，就一键三连呗（点赞+收藏+关注）