Wordpress

月額$2.5で東京リージョンがある激安SSD VPSを契約してWordPressを移行した「Vultr」

WordPress は脆弱性が多く、その影響も大きいものが有ります。 さすがに自分のサーバーに WordPress を置いとくのは何となく怖いのでVPSを契約した。   Vultr 東京リージョンがあるのにも関わらず月額$2.5から契約できるVPSです。 スペックと料金は公式サイトを見てみてください。 https://www.vultr.com/pricing/ 今回契約したのは最安の 1CPU / 512MB / 20GB(SSD) です。 今開いてるこのサイトはそのVPSで動いています。   UIが直感的で分かりやすい サーバーのリソース状況も「User Graphs」タブから色々見れる。 noVNCも実装されているので万が一SSHができなくなっても安心ですね?   東京リージョンは素晴らしい VPSのスペックは低くても東京リージョン+SSDのお陰かSSHもストレスなく作業できた。 東京リージョンでも価格が変わらない点もとても良い?   デフォルトでプライベートIPがない [crayon-5b28893c7ecd7210372403/] 管理画面から無料で追加することが可能 パブリックIPは月$2で追加可能(最大2つまで 計3つまで可能?)   弱小WordPressならメモリ512MBでもギリギリ足りる [crayon-5b28893c7ecea912245868/] 記事編集中のfree -mです。 いつもは nginx を使うのですが今回は検証も兼ねて Openlitespeed を使っています。 Openlitespeed に関しても次の記事にでもしようかと思います。便利ですよ。 ちなみにメモリ使用率TOP10 [crayon-5b28893c7eced664581680/] mariadbをチューニングしたらもうちょっとはメモリに余裕が生まれそう。 たまにmariadbが落ちて「データベース接続確立エラー」が起こる。   WordPressを動かすVPSを探している人にはオススメ 何かステマっぽいですけど一切ステマじゃないです。 オススメです。 https://www.vultr.com/

自作プラグインでwp-config.phpを読み込んでキャッシュの設定を確認する

開発中の block-wpscan というプラグインがあるのですが Wordpressのキャッシュプラグインを使っていると変な動作をすることが分かった。 例外クローラーの追加、判定結果が分かるように。block-wpscan 0.4.2 をリリースしました block-wpscan 0.7.5 で wp-config.php を読み込んでキャッシュが有効なのかどうかを 判定してみたのでそれの覚書です。     概要 WordPress の関数に define(‘WP_CACHE’, true|false) を判定する関数がないので wp-config.php を読み込んで正規表現でやっていこうと思います。 もし関数があったら教えてほしいです…。     コード WP_CONTENT_DIR で /var/www/wordpress/wp-content のパスを取得して 7行目で変数に wp-config.php をそのままぶち込んでます。 9行目で正規表現を使ってキャッシュが有効なのかどうかを判定してます。 define(‘WP_CACHE’, true); define(‘WP_CACHE’,true); define(‘WP_CACHE’, false); #define(‘WP_CACHE’, true); define(‘WP_CACHE’, TRUE); 大文字小文字含めて全部は判定できてると思う(願いたい)     WordPress のプラグインって最初だけ審査が必要なんですけどアップデートとかはいらないんですよね。 絶対情報盗むようなプラグインあるだろうなぁ…。

About Me 3000 widget でメールのアイコンが表示されない問題

右サイドバーに存在する「About Me 3000 widget」 自分が何者かを簡単に知らせることのできる便利なWordpressプラグインですが メールのアイコンが表示されない問題がある。   本来ならTwitterのマークの横にはメールアドレスのアイコンが表示されるはずですが 404となっている。   解決方法  (クリック) wp-content/plugins/aboutme3000.php を編集します。 変更内容は上記の通りです。   きちんとメールのアイコンが表示されればok Wordpressの設定である site_url と home_url が異なる場合に起きる問題です。 というか作者のミスかもしれない。

nginxの多段リバースプロキシ環境でWordpessをパス指定で振り分ける

nginxの多段リバースプロキシを使って、パスによって振り分け先はWordpressにしてみます。 そもそもサブドメインで振り分けるのが設定も複雑にならず、分かりやすくていいんですけどね…。     目標 多段リバースプロキシの環境でパスによって参照するWordpressの乗ったサーバーを振り分ける。 例) http://hoge.com/gallery/docker と http://hoge.com/gallery/docker1 は別なWordpress Dockerfileは下記のものを使いました。 [blogcard url=”https://github.com/eugeneware/docker-wordpress-nginx”][/blogcard]     構成 最上リバプロ : nginx 後段リバプロ : nginx WordPress  : nginx WordPressが乗ってるコンテナはDockerです。docker,docker1,docker2はそれぞれ独立したコンテナです。 また、Wordpress側はローカルでクライアントからIPアドレスだけで開ける状態です。 リクエストパスに /gallery があるものは後段リバプロへ行き /gallery/docker は dockerコンテナへ /gallery/docker1 は docker1コンテナへといった感じです。     設定 WordPressが載ってるNginxから見たリクエストURLには /gallery/docker が含まれるともちろんですが 404 が返ってきます。 しかしWordpressが載ってるコンテナのPHPから見た $_SERVER のREQUEST_URI, SCRIPT_NAME, PHP_SELF に /gallery/dockerが含まれていないとPHP側が返す(作成する)ヘッダには /gallery/docker が含まれないレスポンスURLになってしまい、 ログインはできても管理画面が http://hoge.com/wp-admin となり、/gallery/docker が含まれずそれ以降どこのリンクを押しても 404 となります。     最上リバースプロキシ 最上リバースプロキシは後段リバースプロキシへ /gallery というパスを伝えないといけないので http://docker-reverse-proxy/gallery というリクエストURLで後段リバースプロキシへ。 [crayon-5b28893c7efe2759771039/]       後段リバースプロキシ リクエストURLが /gallery/docker のものは http://docker へ /gallery/docker1 のものは http://docker1 へと言った感じにします。 また、Wordpress(docker)のNginxがリクエストURLを見たときに /gallery/docker が含まれないようにします。 [crayon-5b28893c7efeb033618324/] 最上リバースプロキシでは location ディレクティブの後ろに / をつけませんでしたが 後段リバースプロキシでは付与します。 ココらへんの説明は下記のサイトさんが詳しいです。 [blogcard url=”https://www.xmisao.com/2014/05/09/nginx-proxy-pass.html”][/blogcard]     WordPress(docker)側の設定 – wp-config.php 前述した通り、PHPから見た $_SERVER のREQUEST_URI, SCRIPT_NAME, PHP_SELF には /gallery/dockerが含まれていないと 404 になってしまうのでグローバル変数を書き換えます。 [crayon-5b28893c7efef879142365/]   これらの設定をすることで管理画面へログインしても正常に動作すると思います。     php-fpm の設定を変更する wp-config.php の編集ではなく、Wordpress(docker)側の php-fpm の設定でも可能です。…

WordPressで記事新規追加時にレイアウトが崩れたりした時の対処法 Refused to apply inline style because it violates the following Content Security Policy directive

お久しぶりな記事 この夏はインターンに参加したり、今は静岡で合宿免許に来てます。 平日の休みと言えば三日間ぐらいしかありませんでしたが毎日充実してます。(家帰りてえ・・・)   合宿免許で暇だったので記事を書こうと思ってWordpressの新規追加をクリックしたところ テキストボックスは表示されるもそれ以外は適当に表示されていて頭を抱えました。 そんなときに便利なデベロッパーツールを使うとこんなエラーが! Refused to apply inline style because it violates the following Content Security Policy directive ~~~ エラーログにも書かれているように Content Security Policy を適切に設定しろってことですね。 ブラウザのセキュリティの一環でXSS対策、クリックジャッキング対策ができます。 ただもちろん弊害もあって、インラインのコードが実行されなくなります。 詳しくは知らないのでこちらのサイトが参考になるかと思います。   対処 アクセス制御を行う値をヘッダーに載せます。 nginxでの設定を記述しますがApacheでもできます。 /etc/nginx/conf.d/.confのserver {}に以下を記述します。 [crayon-5b28893c7f13f932799438/] 見にくいですけどとりあえずこのまんまコピペすればいいと思います。 値の意味に関してはこちらのサイトが参考になります。   これでnginxを再起動してヘッダーを見ると変わっている箇所があると思います。 このContent-Security-Policyにあるサイトからのファイルは展開されるようになります。 Content-Security-Policy, X-XSS-Protection, X-Frame-OptionsとかWebサイトを公開する人は知っておかないとダメですね…徒歩歩

no image

Amazon CloudFront CDN を使用して WordPress を使ってみる

CDN をどれ使おうかと色々試してみる中で勉強がてらAmazon CloudFrontのCDNとWordpressを組み合わせて使ってみることにした。   CDNの種類 [table "19" not found /]     CloudFront CDN Amazon AWSのCDN、従量課金制で別ドメイン型である。 リクエスト数だけで見ると料金は安いがページの容量が大きかったりすると一気に料金が跳ね上がる。 画像の容量を抑え、CSSなどはインライン化とかしてリクエスト数を減らせば料金も抑えられると思う。 HTTPSで運用しているサイトは、HTTPSで配信する必要性がある。     CloudFrontの設定 証明書のアップロード 初めてCloudFrontを使ったわけですが証明書のアップロードが面倒くさいです。 Web上からできないのでコマンドラインから証明書をアップデートする必要性があります。 参考 http://qiita.com/n0bisuke/items/a2a7d5efdc1311dc479a なおCDN用に証明書を用意できないので今回はデフォルトの証明書を使います。   CloudFrontの設定 イメージ図的にはこんな感じであってるのだと思う。draw.io 便利〜 HTTPSでサーバーを動かしてるときには 同じくHTTPSでCDNから転送しないと主要ブラウザではエラーを吐いてレイアウトが崩れて表示されてしまいます。   General Default CloudFront Certificate (*.cloudfront.net) にチェックをつけます。 独自ドメインでCDN配信するにはまた工程が増えるのでこのまま使うことをオススメします。   Origins Originの設定です。 今回はHTTPSでしか配信を行わないので Origin Protocol Policy は HTTPS Only にします。   Behaviors 特に記述することもなく。   ログイン画面、管理画面でキャッシュさせないように上記のような設定をします。 Path Patternに関して私の環境では /wordpress を付けてます。     Behavioursの設定は上記のようになると思います。   WordPressの設定 WordPressアドレス(URL) : https://<CloudFrontから割り当てられたアドレス>/wordpress サイトアドレス : https://luispc.com とします。   これで画像を開いてみるとCloudFrontアドレスになっていると思います。

no image

WordPressに攻撃してくるリクエストがおもしろい!【block-wpscan】

WordPressを使用しているサーバーは脆弱性だらけとよく言われてます。 セキュリティはしっかりしないと簡単に侵入されたりしてしまいます。 そんな中で面白かったものをいくつか挙げてみたいと思います。 ちなみにここで紹介している不正アクセスは block-wpscan というプラグインでブロック可能です。   オーソドックスなブルートフォースアタック とログを見てみると無かった。これは意外だった。   xmlrpc.php   xmlrpc.php とは xmlrpc.phpはそもそも、これを使うことで標準の管理画面以外からもAPIを使って、記事の投稿ができるようになるもの。どうやらここへのブルートフォースアタックでのっとりをしようとしているか、Pingback機能を悪用して当サーバーを踏み台にして攻撃に利用するためにアタックされる事例が多い – https://iritec.jp/web_service/10258/ ブルートフォースアタックでもなく、落とそうとしたわけでもないですがやっぱりアクセスはあった。 しかも PHP直打ち。何がしたかったんだろうか…。 wp-login.php へのブルートフォースアタックするのもありますが、xmlrpc.php へでもID/PWをブルートフォースアタックすることができます。     意味不明な攻撃 UserAgentも何だか怪しいし、リクエストURLもやばい。 これだけ見ても全く理解できません。 実際のリクエストURLは長いです↓ [crayon-5b28893c7f253348427235/] で実際これが何なのか調べてみたら他CMSで使われる PoPs (Points of Presence) といわれる攻撃らしい。 影響あるのは Joomla というCMS。Wordpressには影響なさそう。 ちなみにbase64の部分をデコードしていくと、PHPコードが出てきます。 ということで割愛しますが、詳しくはここで解説されてます。 と、ここまで面白みのある不正なアクセスはそこまでありませんでしたがこれらの攻撃も防げる block-wpscan オススメです!

例外クローラーの追加、判定結果が分かるように。block-wpscan 0.4.2 をリリースしました

block-wpscan WordPressのプラグインです。 不正っぽいアクセスをブロックするものです。 WordPressでwpscan,tor,proxy,コマンドラインからのアクセスをブロックするプラグイン「block-wpscan」   Changelog Twitterbotを例外に追加 なんでブロックされたかを表示     Twitterbotを例外に追加 ブログの記事URLをツイートとかすると”Twitter-bot”からのアクセスがくる。 これがブロックされてたので例外へ追加するように。     なんでブロックされたかを表示 新たに”Judge”という項目を追加 ”Not browser”というのはコマンドラインからのアクセスを指します。 ベンチマーク取ってみたんだけど、何故かプラグインが無効の時のほうが速い…。 なんでだろう。誰かベンチマーク取ったら教えて下さい…。