先说下背景。一个客户的服务器，去年找我帮忙维护，其实主要解决的问题是网站被挂马。

当时，接过来花费了我很多精力，各种找，各种查。但，毕竟我不是专业搞安全的，所以只能是摸着石头过河，哪里有问题就搞哪里。

总之，找到了好多有问题的代码，也分析了很久的访问日志，但始终没有找到根本问题点。

但有一点可以肯定，这个***可以拿到root权限，因为网站的核心代码文件我都给了root属主，www用户肯定不可写，但依然被替换，而且替换后还把同目录下所有文件都给改成某一个时间点，这就加大了排查难度。

既然可以拿到root，那说明要么他是通过80端口，要么就是通过22端口。对于22端口的防护，很容易做。首先把密码登录关闭，只能用密钥，然后做一个IP登录的白名单。

如果是80端口的话，只要你仔细分析访问日志，一定可以找到后门文件的。由于能以root的身份操作，所以除非是webshell，否则，一般的web漏洞，只能以普通用户身份（如，运行php-fpm服务的用户）来鼓捣，我们给它一个open_basedir限定，基本上可以解决问题。

这台机器，我陆陆续续折腾了大半年，一直有各种各样的问题，最近又发现一个这样的问题：

在百度搜索该站点最新收录的文章里，有太多不相干的网页，点击后进入到了其他站点。

我呢，思维定势了，一直认为是代码有问题，然后就分析代码，始终不得其解。今天我换了一个思路。

它访问的url很有规律，都是以rr开头，比如 rrc8hsq/cgyxrb.htm。

但是网站程序目录下面并没有rrc8hsq目录，更没有cgyxrb.htm文件，通过和客户那边的程序员沟通，代码中并没有做过这样的rewrite规则。我突发奇想，直接创建 rrc8hsq目录，并创建cgyxrb.htm，结果访问它依然跳转到另外的网站。

此时，很明显，矛头指向nginx上，首当其冲，要看该站点的虚拟主机配置文件。仔细查看后，我勒个去，他给加了一句

include other.conf;

查看other.conf，内容是这样的：

location ^~ /rr {

   rewrite ^/rr(.*)$ /rr$1 break;

   proxy_pass http://xxxx.com;

}

罪魁祸首就是这个文件。由于之前从来没有遇到过此类手法，所以nginx配置文件也从没认真查看过。唉，疏忽了，竟然浪费了大把时间。

至于百度为何去收录这种rr开头的url链接，我还没有找到最终的原因。我分析可能跟网站某段代码有关，还有一种可能，这种链接已经被该SB留在了某个站点的某个页面上，百度可以直接访问并收录。

提醒一下各位，如果你已经是运维或者你将成为运维。服务器的基础安全一定要做好，最起码做一个密钥认证+限定登录IP。