文章目录
一、前文
二、思考问题
事后转念一想，又在思考：如果是配置问题，那么服务应该无法启动才对。
为何服务能够正常运行三四小时才崩溃，深入思考并咨询了天谋科技的工程师之后。
那么新的问题来了，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密码修改复杂点
- 重启IoTDB服务
[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
[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 入门教程 企业篇④——安全控制 | 白名单、审计日志、登录日志和操作日志
六、总结
觉得好，就一键三连呗（点赞+收藏+关注）