CDN(キャッシュ)の導入

当ブログの構成変更を行なったといった記事を前回(https://engineer-ryo-blog.com/2024/02/18/blog-update/)書いたが、その際にAmazon CloudFrontを導入した。

Amazon CloudFrontの利用にあたっては、いくつかの注意事項があり、注意事項を理解した上で利用する必要があるが、CDNによる非常に強力なキャッシュの力を手にいれることができる。

主な注意事項は以下の通り

• キャッシュして良いもの、キャッシュすると影響が出るものがある。
  例) WordPressの場合、ログインが必要なページ(wp-adminなど)はキャッシュしてしまうと、未ログインのユーザーも閲覧できる状態になる。(見えてはいけないページが見える。)
  ビヘイビアを作成し、キャッシュポリシーを「CashingDisabled」にした上、オリジンリクエストポリシーを「All Viewer」とすることで、キャッシュさせないようにする。
• キャッシュという性質上、リアルタイムに更新される訳ではないので、要注意。
  すぐに反映したいものがある場合は、キャッシュの削除を手動で行う必要がある。
• 初回のリクエストはキャッシュされていないため、オリジンサーバーへアクセスする。
  キャッシュが効いていない状態のため、少し表示が遅い場合がある。
  ただし、2回目以降は、キャッシュから表示するため高速。
• 若干ではあるが、利用料金がかかる。
• AWS WAFも一緒に導入することをおすすめするが、こちらも利用料金がかかるので予算と要件次第。

nginxの設定変更

gzipで圧縮するよう、nginxの設定ファイルへ追記を行った。

gzip on;
gzip_types text/css application/javascript application/json application/font-woff application/font-tff image/gif image/png image/jpeg application/octet-stream;

スケールアップ

今回は行っていないが、スケールアップ(スペックの向上)も検討する必要がある。

当ブログでは、「t4g.micro」を使用しているが、バズることがなければ必要十分と感じる。
※AWS Graviton プロセッサのインスタンスのため、コスト・パフォーマンスが高い。

DB設定のチューニング

当ブログはWordpressのため、テーブル・クエリレベルのチューニングは難しいが、接続先を127.0.0.1からlocalhostへ変更した。

これにより、TCP/IPでの接続ではなく、UNIXドメインソケットでの接続になっているはず…

DBキャッシュ

当ブログでは実施していないが、インメモリDBをキャッシュとしてAP・DB間に配置することで、パフォーマンスの向上が見込まれる。

はじめに

当ブログはWordPressにて構築しています。

WordPressを狙った攻撃は多々ありますが、当ブログで発生したインシデントについてまとめてみました。

パスワード総当たり攻撃

WordPressの管理画面に対し一切制限を設けていなかったことにより、管理者ユーザーへの総当たり攻撃が行われていました。

ログを見ると10,000回以上行われていて、ちょっとゾッとしました。(わかりやすいパスワードにしていなくてよかった…)

まずかった点

• 管理者のユーザーIDがわかりやすいものになっていた。
• IP制限などを設けていなかった

対策

管理画面へアクセスできるIPアドレスを制限することにしました。

xmlrpc.phpに対するDOS攻撃

上記の総当たり攻撃の調査の一環でアクセスログを確認していたところ、

XXX.XXX.XXX.XXX - - [17/Oct/2021:19:08:01 +0900] "POST //xmlrpc.php HTTP/1.1" 

こんなログが1秒おきに…

「パケット転送料(アウトバウンド)で、高額請求になるからやめようね、ほんと」と思いながら、粛々とNginxを再起動しました。

xmlrpc.php is 何？

WordPressのRPCの模様。※詳しくは各自お調べください。

対策

Nginx側でアクセスをブロックするように、confを書き換えました。

location ~* xmlrpc.php {
    deny all;
}

.envへのアクセス

ある日ログを監視していると、こんなログが…

XXX.XXX.XXX.XXX - - [18/Oct/2021:00:23:09 +0900] "GET /.env HTTP/1.1" 301 169 "-"

dot envを表示しようとGETリクエストしているようですが…

当サイトはdot envを使用しておらず被害は無しですが、利用されている方はお気をつけくださいませ。

※ステータスコードが、301となっているのは、HTTPをHTTPSにリダイレクトしているためです。

phpMyAdmin関連

ログを見ていると、phpMyAdmin関連のアクセスがありました。

当サイトではphpMyAdminは使用しておらず、sshトンネルでの運用としているためこちらも影響なしでした。

まとめ

ブログを運用されている皆様、一度ご自身のブログのセキュリティを見直しされてみてはいかがでしょうか？

追記

(こんなアクセスよりもPVが伸びるといいなぁ…)