6
1
2017
9

WordPress 被入侵有感

吶,昨天说到VPS被报告有攻击行为,后来异常流量被逮到了,经过追查,真相大白。

前天(还是前天,因为又过了一天)分析了异常流量的时间分布之后,发现该流量从上午9点多开始,一直持续。于是我又 netstat -npt 了一下,看到了大量对各网络公司IP 80端口的连接。它还在呢!其实我早该 htop 瞅一眼的说。

发现三四个「php /tmp/tmp」进程,每个进程有大量连接。试图通过 /proc/PID/fd 取得它打开的文件失败,因为都是空的……然后,为了中止攻击,我停了 php-fpm 服务,杀掉了所有 php 进程。杀完才后悔,我连它是哪个用户跑的都没看呢 -_-||| 心急就忘记了应该发 SIGSTOP 信号的。

时间上与任何 cron job 都不匹配。不过我还是检查了可能的 PHP 脚本任务,并没有发现异常。这时 VPS 的主人 Edison 说,是不是 WordPress 的锅?于是他去扫描了一下 WordPress。这个 WordPress 是数年前 Edison 手工部署的,后来并没有怎么用。并不是通过软件仓库安装,所以 dpkg 没有检查出异常,也因此没有任何更新,年久失修。结果检查出来好多个后门。

这些后门都是在 PHP 脚本里加一两句话,对某个特定的 POST 参数进行求值(eval)。简单有效的后门呢。也难怪我怎么都没有找到恶意程序,原来是直接从网络提交过来的,通过 php-fpm fork 了进程出来。

嗯,就是这样。并没有多么神秘,也没能拿到攻击脚本。这件事充分地说明了我坚持不使用 WordPress 是个无比正确的决定 :-)

其实呢,这种攻击对于 Linux 来说是很奇怪的。就像作为 Python 使用者,SQL 注入对我来说是很奇怪的一样。最不安全的也并不是 PHP,而是 WordPress,核心逻辑上的漏洞不补,再怎么从细枝末节上修补也是软弱无力的。

它丫的 www 用户为什么对 WordPress 的代码文件有写权限啊?

它丫的 www 用户为什么对 WordPress 的代码文件有写权限啊?

它丫的 www 用户为什么对 WordPress 的代码文件有写权限啊?

嗯,重要的事情要说三遍。现在互联网越来越险恶,竟然还有著名软件项目不知道 W^X 这个常识我也是醉了……

一点安全常识,给不懂的人:

  • 任何时候,尽力做到权限最小化(不要学360拿 suid 跑 GUI)
  • Web 网站,用户可写目录一定不能被执行,能够执行的目录执行者一定不能有写权限(你看我的 MediaWiki 曾经暴露在外网那么久也只是招来了一些 spam,从来没人能远程执行代码)
  • 尽量使用发行版提供的软件包,及时更新,特别是对于没有充分时间关注和维护的东西

还有,我还挺想念 systemd 的,直接 systemctl status 就能知道进程属于哪个服务了。而且可以几行配置就把不需要的权限干掉~

Category: Linux | Tags: WordPress PHP Linux
10
2
2014
4

我从 Apache httpd 切换到 nginx 了

因为工作上一直在用 nginx,对 nginx 配置的了解日益深入,而对 Apache httpd 配置的了解依然非常少以至于不知道如何添加一个虚拟主机的配置而不用修改大量已有配置,决定将自己本地的 Apache httpd 替换成 nginx。一开始这个 httpd 只是跑了一个 MediaWiki、一些静态文件和单独的 PHP 脚本,随着时间的流逝,后来陆续添加了 phpPgAdmin、RockMongo、PHP Xcache、into2html CGI 脚本等东西。于是配置起来似乎也不那么容易了。

首先第一点:这么多 PHP 的服务,我不想每一个 location 块里边一堆相同或者相似的 FastCGI 配置。于是把相关配置写到一个文件里去。(直到这时我才意识到 location 是可以嵌套使用的!)

index   index.php index.html;
location ~ (.+\.php\d?)($|/) {
        fastcgi_pass    unix:/run/php-fpm/php-fpm.sock;
        fastcgi_index   index.php;
        set     $script $request_filename;
        if ($request_filename ~ ^(.+\.php\d?)(/.*)$){
                set $script     $1;
                set $pathinfo   $2;
        }
        fastcgi_param   PATH_INFO       $pathinfo if_not_empty;
        fastcgi_param   SCRIPT_FILENAME $script;
        include         fastcgi_params;
}

因为是嵌套的 location,所以得在外边也写一下index,不然 nginx 会不知道的。

另一个问题是默认的 fastcgi.conf 里定义的SCRIPT_FILENAME$document_root$fastcgi_script_name。但是我的 MediaWiki 使用了alias而不是root,于是$document_root会访问错地方。网上似乎没人完全地解决或者绕过了这个问题,大概是因为他们的配置不会被包含到多个 location 里吧。后来使用$request_filename这方案是我自己读了文档之后「发明」的。

另外,nginx 自定义的变量似乎是词法作用域,不能被 include 进来的配置访问到。大概因为 FastCGI 脚本路径是自己处理的,PATH_INFO也得自己处理。

然后就可以这么用啦(这是我的 MediaWiki 配置):

location /w/ {
        alias /usr/share/webapps/mediawiki/;
        include php;
}
location /wiki {
        rewrite ^/wiki(/.*)?$ /w/index.php$1 last;
}

以前的 Apache httpd 的配置是这样的:

Alias /w /usr/share/webapps/mediawiki

RewriteEngine On
RewriteRule ^/?wiki/(.*)$ /w/index.php/$1 [PT,L,QSA]
RewriteRule ^/?wiki$ /w/index.php [PT,L,QSA]

<Directory /usr/share/webapps/mediawiki>
        Options +FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>

另外一个被我写成单独的配置文件以便被 include 的限制只允许本地访问用的:

allow   127.0.0.1;
allow   ::1;
deny    all;

比 httpd 的好理解一些。

另一个问题是 CGI 脚本。nginx 是有两个方案的,fcgiwrap 或者 nginx-fcgi。前者是个二进制程序,在 Arch 和 Debian 源里都有。后者是个 Perl 脚本,已经难以下载到了(给的链接是我从互联网存档取得的)。

Arch 的 fcgiwrap 包提供了一个 systemd socket 文件,直接启动它就可以了。启动 .service 服务似乎会有问题。

$ sudo systemctl start fcgiwrap.socket

nginx 里就这么写就可以了:

fastcgi_pass    unix:/run/fcgiwrap.sock;
fastcgi_param   QUERY_STRING       $query_string;
fastcgi_param   REQUEST_METHOD     $request_method;
fastcgi_param   CONTENT_TYPE       $content_type;
fastcgi_param   CONTENT_LENGTH     $content_length;
fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param   REQUEST_URI        $request_uri;
fastcgi_param   DOCUMENT_URI       $document_uri;
fastcgi_param   DOCUMENT_ROOT      $document_root;
fastcgi_param   SERVER_PROTOCOL    $server_protocol;
fastcgi_param   GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param   SERVER_SOFTWARE    nginx;
fastcgi_param   REMOTE_ADDR        $remote_addr;
fastcgi_param   REMOTE_PORT        $remote_port;
fastcgi_param   SERVER_ADDR        $server_addr;
fastcgi_param   SERVER_PORT        $server_port;
fastcgi_param   SERVER_NAME        $server_name;
fastcgi_param   REMOTE_USER        $remote_user;

引用的时候就是这样子:

location /cgi-bin {
        root /srv/http;
        include fcgiwrap;
}

经过测试,默认参数时 php-fpm 空闲时有三个 worker,高峰时会多一点,但是 Apache httpd 平时就有八个 worker,高峰时更多。每个 worker 对内存的占用是差不多的。至于响应速度,对于 MediaWiki nginx 稍慢 httpd 一点,但是服务启动后第一次访问会很多,而且 ab 测试时失败数少不少。更重要的是,systemd-analyze blame表示 nginx + php-fpm 组合启动时间远远少于 Apache httpd(0.1 秒 vs 好几秒)!

PS: 谁能告诉我 systemd-analyze 怎么查看以前启动的时间信息呀?

Category: Linux | Tags: php nginx apache httpd

Mastodon | Theme: Aeros 2.0 by TheBuckmaker.com