说一下蛋疼的wordpress和apache崩溃问题

很久之前我就发现我的博客wordpress搬到这一台服务器之后有时候wordpress后台有些页面会导致后台进程崩溃,具体是apache的进程会崩,日志显示

[notice] child pid 30702 exit signal Segmentation fault (11)

而且是必现的,具体是wordpress后台的更新页面还有插件页面。我在apache前面套了nginx,nginx表现就是502。然后想起来技巧就是直接把wp-contents目录里面的plugins子目录重命名,这样可以禁用所有插件。果然禁用了之后,一切正常。

其实apache本身还算是稳定的,能把apache搞挂了的一般就是php模块内的事情。我也不知道为何php错误日志里面啥相关信息都没有,另外搞了很久也没办法让apache把coredump保存到文件(ulimit -c | sysctl配置 | apache配置均已修改),想看看怎么崩的也没有办法,真是太蛋疼了。一种脚本语言把它的运行时以及运行时容器进程搞挂……

我觉得我离全站纯静态不远了……

记录一次离奇的pureftpd+mysql用户530无法登录问题

是这样的pureftpd还算是个比较轻量的服务器ftp软件,还可以搭配比较灵活的认证。其中有一种用法就是搭配mysql,把用户身份存在在mysql里面方便管理。但是当我把环境搭建好之后创建了ftp用户发现连接后认证失败530。在log里面看到说pureftpd无法连接数据库,access denied ftp@localhost。

网上有很多说法,包括localhost和127.0.0.1之间的host问题等。但是日志里面其实我们明确这是mysql用户登录问题,导致pureftpd无法查询数据库。然后我反反复复折腾重新创建数据库用户,确认密码正确性等等,均无果,直到有一次我在重启pureftpd服务的时候发现

[root@vps7 ~]# service pureftpd restart
Restarting Pure-FTPd: Stopping Pure-FTPd: Pure-FTPd is not running.
Starting Pure-FTPd: Running: /usr/local/pureftpd/sbin/pure-ftpd –daemonize -A -c50 -B -C5 -D -E -fftp -H -I15 -lmysql:/usr/local/pureftpd/pureftpd-mysql.conf -lunix -L2000:8 -m4 -p20000:30000 -s -U133:022 -u100 -k99 -Z

什么鬼,pureftpd not running? 我看了下进程pureftpd确实是在跑的进程,进一步查看这个启动脚本看到它从一个位置获取pureftpd的pid,而那个pid文件并不存在。所以其实我重启pureftpd服务实际上并不成功,老的进程没杀掉,新的进程肯定因为端口冲突不能正常起来,所以修改的配置也没有生效。手工杀掉重新启动服务之后就ok了,观察pid文件也正常了。

记录一下fail2ban不能正常工作的问题 & 闲扯安全

在加载配置这个事情上,许多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登录其他机器。