メール受信から.forwardでコマンド実行したときの環境

Linux環境(postfix使用)で個人が.forward置いてコマンド利用するとどういう環境になるのか、軽く検索してたどり着けなかったので実験した。

.forwardの中身は
\username,”|/home/username/test.sh”
で、test.shは実行属性をつけてある。

結果、カレントディレクトリは /var/spool/postfixであることがわかった。
なので.forwardのほうもフルパス指定してやらないとそもそもshが起動しなかった。

あとついでに。shじゃなくてもphpも実行できる。
#!/usr/bin/php
<?php echo “Hello\n”;
って感じで実行ファイルにできる。(知ってたけど意外とやってなかったこと)

WordPressからフォームでメールを送るとGmailに拒否される

WordPress + Contact Form 7でメールを送ってもらっていたサイトが、2月あたりからGmailに拒否されるようになってしまった。GmailがSPAM対策強化をしていたのでそれが関係するだろうということで調査。

SPFに対応するのは必須。しかしSPFがPASSしても拒否される。メールを見てみると、いわゆるenvelope fromのアドレスが異なっていた。
シェルから echo ‘test’ | mail -s ‘test’ -r (自ドメインのアドレス) (送信先Gmailのアドレス) とするとテストできるが、これは通る。
しかしWordpressから送ると apache@サーバー名 で送られてしまう。

WordPressのメールの仕組みはenvelope fromを書き換えないし、CF7ではReturn-Pathを設定しても反映されないようだ(WP関数内で落とされる)。
結局このへんの回避のために WP Mail SMTP というプラグインを導入。いろいろリッチなオプションを求められますが最低限でOK。
「送信元アドレスを返信先 (return-path) として設定」このチェックが重要。

これでGmailにも拒否されなくなりました。もっとやるならDKIM、dmarc対応までやらねばならない。

phpMyAdmin置いたら真っ白

CentOS8からCentOS Stream 8への移行作業を行って、必要になりphpMyAdminを設置。
しかし動かない、真っ白…

エラーログには
PHP message: PHP Fatal error: Uncaught Error: Call to a member function getCookie() on null in /path-to-pma/libraries/classes/Url.php:220

そんなみんな使ってるバージョンなのに動かないなんてことはないよねーと追いかけたらスタックトレースにしっかり「warnMissingExtension(‘json’,true)」とか「book.json.php」とか出ている。

php-jsonパッケージをインストールしたら動きました。

nginxでalias下のfastcgiへのパスの渡し方

nginx + php-fpm の環境。
最近はドメインのトップからWordpressのようなシステムを置くことが増えたので
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
で良かったのですが、
URI上の一部分を別のディレクトリに置いていたりするパターンでは、rootの定義し直しではなくてaliasを使ったほうがよさげらしい。
しかしaliasにしてしまうと不都合もあるようで

server {
  server_name example.com;
  listen 80;
  root /var/www/example.com/;
  location /somepath/ {
    alias /var/www/somepath/;
    index index.php index.html;
    location ~ \.php$ {
      fastcgi_pass unix:/run/php-fpm/www.sock;
      fastcgi_index index.php;
      # fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_param SCRIPT_FILENAME $request_filename;
      fastcgi_param PATH_INFO $fastcgi_path_info;
      include fastcgi_params;
    }
  }
}

example.com/somepath/hoge.php をリクエストすると
$document_root$fastcgi_script_nameの場合 /var/www/somepath//hoge.php が渡されちゃう。スラッシュが2重になってしまうのでalias下では使えないことに。
$request_filenameの場合 /var/www/somepath/hoge.phpが渡る。こちらは望み通りの結果。

じゃあalias下じゃなくても$request_filename使えば良いのでは?と思って試した結果、
example.com/fuga.php のリクエストに対してどちらも /var/www/example.com/fuga.php となった。

大本がどこからのコピペだったか忘れたが、$request_filenameで良さそうだ。ただしrootとかaliasとかindexがしっかり定義されている文脈に限る。
rootのときは最後の/を調整してくれるけどaliasではしてくれないあたりからの違いってことか

参考
落とし穴とよくある間違い | NGINX 日本語訳
nginx $document_root$fastcgi_script_name と $request_filename の違い – Qiita

WordPressへの攻撃対処 ThemeGrill Demo Importer脆弱性

「Wordpressが消えちゃったんですけど!」と猛烈な勢いで連絡をいただいたので、他のことをストップして対処しました。
いろいろと見てみると、データベースが初期化されてました。

MySQLが吹っ飛んだのかな?とも思いましたが、MySQL4.x時代ならともかく、もう10年以上そんな事態は見たことがありません。

こちらのサイトは同一データベースに複数のwordpressを、DBのprefixで分けて設置していましたが、今回初期化されていたのは該当の1サイトだけ。他のサイトは無事でした。そして吹っ飛んだ側のサイトもwp_postが1件だけ存在。インストール時のデフォルトの投稿記事です。どうやら吹っ飛んだ感じではなさそうです。

格闘すること2時間弱、アクセスログに見つけました。

45.129.xxx.xxx - - [18/Feb/2020:HH:MM:SS +0900] "GET /wp-admin/admin-post.php?do_reset_wordpress=1 HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36" "-"
45.129.xxx.xxx - - [18/Feb/2020:HH:MM:SS +0900] "GET /wp-admin/themes.php?page=demo-importer&browse=all&reset=true; HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36" "-" 

do_reset_wordpress=1ってなんじゃいな!w
探してみると ThemeGrill Demo Importerプラグインの脆弱性だそうで、1日前に報告されています。ゼロデイ攻撃っぽい。
このプラグインはThemeGrillというテーマシリーズがあって、そちらの必須プラグインみたいです。いろいろテーマを試すには便利な仕組みのようです。

とりあえずこのプラグインは停止、削除。
データベースをバックアップから復旧して、サイトの記事は少し前の状態に戻ってしまいましたが、回復。

ついでにwp-admin以下にアクセス制限をかけます。誰でもGET/POSTできるとか危ない。

余計なテーマやプラグインは削除しておけとは思いますが、使用中のテーマの必須プラグインなんだから、普通は止めちゃいけないと思いますわな…

Critical Bug in WordPress Theme Plugin Opens 200,000 Sites to Hackers