在加载配置这个事情上，许多linux应用程序只需要发一个信号，应用自己就完成配置重载，无需重启中断服务，但是依然有很多程序并不支持。

今天我第一次学习使用fail2ban，以前都没用过这样的东西，小地方没有太多攻击看上，但是工作之后这些安全意识和规范还是会加深认识，fail2ban很简单的远离，分析日志，正则匹配查找，iptables ban ip，然后我今天花了很长时间都没办法让他工作起来，我写了一个简单的规则ban掉尝试暴力登录phpmyadmin的ip，60秒内发现3次ban一个小时。

我通过fail2ban-regex测试工具测试的时候结果显示是能够正常匹配的，我也试了不是自己写的规则，试了附带的其他规则的jail，也是快速失败登录很多次都不能触发ban，看fail2ban的日志更是除了启动退出一点其他日志都没有。

然后就开始网上搜索各种解决方案，有的说inotify有问题要换gamin甚至是polling来监控日志，我试了一样没用，测试期间我跟改其他程序配置一样，改一下配置，重启一下服务，测试一下，不行，又重复再来，搞了很久，搞得都烦躁了，然后就去洗了个澡。

洗了个澡回来看到有一个问题里面说到fail2ban启动的时候会读一遍日志计算一次，我在想会不会是日志文件太大处理速度慢？看了一下那几个日志都是MB级别而已不大（logrotate是王道，但当这两个东西一起的时候又会有其他问题产生了，搜索的时候无意中看到的），然后我想起了我用fail2ban-regex测试的时候测试结果好久才出来，好几分钟，那测试工具是只测试一个过滤器作用在一个文件上的，我就联想到会不会是因为程序没初始完所以不work呢。于是我没有重启服务又测试了一次，这次成功ban了。

后面我把配置还原，重启服务，这次我注意到重启服务之后整个负载都高了起来，fail2ban-server直接是占满了一个核，这种情况居然持续了十几分钟的样子，简直不能忍。这下我清楚了应该是这个问题没跑了。然后再去换关键词搜索fail2ban启动慢的问题，好像是一个bug，然后稳定版里面没有修复，第三方提交的patch出现在今年一月份，简直无语……

扯完了蛋疼的fail2ban之后来说说安全，其实phpmyadmin这种东西是不应该放在公网上的，像我们厂是禁止的，不过有一些特殊情况例如说是对外提供服务或者说没有内网只有公网的站点，phpmyadmin就必然是暴露出来的。这里可以看看sae是怎么做的，他是通过静态的二次密码认证，然后直接从sae管理后台带登录态到phpmyadmin，而不是在phpmyadmin直接输入密码什么的。所以还算平衡了安全和便捷性的要求。

其实像phpmyadmin这种登录表单只有一个用户名一个密码输入，没有验证码也没有其他安全策略之类的系统从安全上看是很儿戏的，随时暴力破解没商量。最弱智的至少也应该有个验证码，好一点的暴力N次之后出验证码，所以其实fail2ban也没啥用，有足够的时间和ip还是可以慢慢破解的，这里又涉及到另一个问题，就是慢慢破解有没有人能发现的问题，应该算是安全运营的范畴。大部分同学，日志不出事不会去看，即便出事了如果没有告警机制，那么只有日志和机器知道，人是不知道的，这些做法都不靠谱。

其实对于我自己来说我觉得静态密码是不靠谱的，应该搞个动态密码加静态密码，动态密码你不用搞什么硬件令牌，软件的像google身份验证器就挺好的，后面我想做一个http中间件，在这些保护缺失的关键页面上加上动态密码验证。google身份验证器还有pam模块可以用，但是我觉得pam配置麻烦了些，账户管理也不方便，把这些东西放在应用层会灵活一些。

然后有一些地方好像不太好集成动态密码的，例如说ftp，pam认证可以搞，我还是嫌麻烦。其实我建议是直接在使用前生成临时用户和临时密码，给一个很短的有效期，用完就遗弃。还有一些地方能不用密码的就不用密码了，例如说服务器的ssh登录，搞成证书验证之后实际上很爽的，也安全的多。管理我自己的服务器的时候，我也有一个专门的跳板机，跳板机可以密码登录，但是密码超级复杂。其他机器全部只允许证书登录，跳板机上可以证书验证ssh登录其他机器。