phpmyadmin 本身不支持登录失败告警，需通过 fail2ban 监控 apache/nginx 日志实现；mysql 层日志不可靠，修改源码发邮件存在升级覆盖、性能阻塞等严重问题。
phpMyAdmin 本身不支持登录失败告警
phpMyAdmin 是一个纯前端+PHP 的数据库管理界面，它没有内置的失败登录事件钩子、日志告警模块或邮件发送能力。所有“密码错误”行为最终都体现为 HTTP 401 响应或 login_error 会话提示，但这些不会自动触发外部通知。
真正可监控的是 Web 服务器（如 Apache/Nginx）或 MySQL 服务层的日志——尤其是当攻击者反复尝试时，会在 /var/log/apache2/error.log、/var/log/nginx/error.log 或 MySQL 的 error_log 中留下痕迹，比如：
Access denied for user 'root'@'192.168.1.100' (using password: YES)
所以告警必须绕过 phpMyAdmin 自身，从日志源头切入。
用 fail2ban 监控 Apache/Nginx 日志并触发邮件
fail2ban 是最轻量、最可靠的方案：它持续 tail 日志，匹配正则，达到阈值后执行动作（如发邮件、封 IP）。关键在于写对 filter 和 action。
- 确认你的 phpMyAdmin 登录失败在 Web 日志中可见（默认开启
LogLevel warn通常足够） - 新建 filter 文件：
/etc/fail2ban/filter.d/phpmyadmin-login.conf，内容包含匹配login_error或 401/403 响应的正则，例如：failregex = ^.*"POST \/phpmyadmin\/index\.php.*" 401.*$
- 在
jail.local中启用该规则，设置maxretry = 3、findtime = 600、bantime = 3600 - 使用
action = %(action_mw)s启用邮件告警（需先配置好sendmail或mta = mail）
MySQL 层面无法直接捕获 phpMyAdmin 密码错误
MySQL 的 general_log 不记录认证失败；error_log 只在用户不存在或 host 不匹配时写入，而「密码错」通常静默失败，不落 MySQL 日志。所以依赖 MySQL 日志做告警不可靠。
如果你强制开启了 log_warnings = 2（MySQL 5.7+），部分密码错误可能出现在 error log，但：
- 格式不稳定，不同版本输出差异大
- 容易和合法连接拒绝（如 max_connections）混淆
- fail2ban 匹配难度高，误报率上升
不如专注 Web 层日志更可控。
不要改 phpMyAdmin 源码加 sendmail
有人试图在 libraries/common.inc.php 或 index.php 里插入 mail() 调用，这存在严重问题：
- 升级 phpMyAdmin 时所有修改会被覆盖
-
mail()函数在多数环境默认禁用或需额外配置 SMTP - 错误处理路径复杂（重定向、AJAX 登录、token 验证失败等），极易漏触发或重复发送
- PHP 进程阻塞在发信上，影响登录响应速度
真正的生产告警应该解耦：日志 → 监控代理 → 通知通道。把逻辑塞进 phpMyAdmin，等于把消防栓焊死在厨房水龙头上。
Web 日志路径、fail2ban 规则写法、邮件 MTA 配置，三者任一环节出错都会让告警失效——它们比代码补丁更难调试，也更容易被忽略。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
