☰

mysql.log 中存在黑客攻击尝试？

tag-icon • tag-icon mysql
mysql.log 中存在黑客攻击尝试？

我在 Ubuntu 上运行 plesk。在注意到一些可疑数据后，我开始记录所有查询。几个小时后... 似乎有人创建了一个数据库并试图将新用户插入 mysql.user 表中。

从那时起，我为 Plesk 创建了新密码并更新了 Plesk。我注意到 Plesk 更新说明中他们修复了一个安全问题。也许这就是有人入侵的方式？

我希望我只是有点偏执

750 Connect admin@localhost on 
750 Query   SELECT VERSION()
          748 Query select `name`,`version` from Components
          750 Query create database `BUG115166_19826690404F97A4DB6CCAB` /*!40101 default charset=utf8 */
          750 Query create database `bug115166_19826690404f97a4db6ccab` /*!40101 default charset=utf8 */
          750 Query insert into mysql.user (Host, User, Password) values ('%', 'bug115166_29609', password('BUG115166_19826690404F97A4DB6CCAB'))
          750 Query FLUSH PRIVILEGES
          750 Query GRANT ALL ON `BUG115166_19826690404F97A4DB6CCAB`.* to 'bug115166_29609'
          751 Connect   bug115166_29609@localhost on 
          751 Query USE `BUG115166_19826690404F97A4DB6CCAB`
          751 Query USE `bug115166_19826690404f97a4db6ccab`
          751 Init DB   Access denied for user 'bug115166_29609'@'%' to database 'bug115166_19826690404f97a4db6ccab'
          750 Query REVOKE ALL ON `BUG115166_19826690404F97A4DB6CCAB`.* FROM 'bug115166_29609'
          750 Query DELETE FROM mysql.user WHERE User='bug115166_29609'
          750 Query FLUSH PRIVILEGES
          750 Query drop database if exists `bug115166_19826690404f97a4db6ccab`
          750 Query drop database if exists `bug115166_19826690404f97a4db6ccab`
          750 Query drop database if exists `BUG115166_19826690404F97A4DB6CCAB`
          750 Query drop database if exists `BUG115166_19826690404F97A4DB6CCAB`
          751 Quit  
          750 Query show databases like 'd21193485464f97a4db6c8a9'
          750 Query create database `d21193485464f97a4db6c8a9` /*!40101 default charset=utf8 */
          750 Query drop database if exists `d21193485464f97a4db6c8a9`
          750 Query drop database if exists `d21193485464f97a4db6c8a9`

答案1

也可以看看出现了奇怪的 MySQL 用户（例如 bug115166_10073），且不是我创建的。

谷歌了一下，发现这在 Plesk 上比较常见。考虑到这种情况的普遍性，我几乎怀疑这是否是某种内部 Plesk 进程，会定期检查某种类型的错误（因此用户命名，以及它从本地主机连接的事实）。但是，我找不到任何证据来支持这一点，所以这可能是一个错误的线索。

无论如何，您绝对希望锁定它。假设您有一个时间戳，请查看您的访问日志以查找该时间戳，以尝试确定是否有任何相应的请求。真正的问题不是这些GRANT；而是能够运行 SQL 命令的事实。找到那脆弱性，你就会填补上真正重要的漏洞。

相关内容