クラウドサーバー運用、セキュリティ対応が地味にしんどい話
- ⏱ 約5分で読めます - 👁 … viewsクラウドを立ち上げた瞬間から始まる「戦い」
当社では、GenbaFlow.comを頭に、複数の顧客業務向けのクラウドサーバを運用しています。 クラウドで提供するメリットは、
- サーバーのスケールアップやダウンが容易
- データのバックアップや復旧が容易
- セキュリティ対応が容易
- プログラムの更新に現地に出向く必要がないので交通費が浮く。
などがありますが、逆に面倒な部分も出てくるのです。
クラウドサーバーを運用していると、避けて通れないのがセキュリティ対応です。AWSでもVPSでも、サーバーをインターネットに公開した瞬間から、世界中のボットがじわじわとアクセスを試みてきます。これ、誰かが「このサーバーを狙おう」と思っているわけじゃなくて、自動化されたスキャンが24時間365日、全IPアドレスに向けて淡々と走り続けているんですよね。
fail2banが一日に何をしているか、見てみた
セキュリティ対策としてfail2banという機能があります。
これは、webサーバへのアクセス状況を監視して、悪意のあるアクセスを見つけ出し（フィルタを書く必要があります）、そのIPアドレスからのアクセスを遮断するということを自動でやってくれる機能です。
このログを眺めていたんですが、改めて数字にしてみるとちょっと引きました。SSHを使用した不正ログイン攻撃だけでも1日だけで200件近いBanが記録されていたんです。
しかもSSHだけじゃない。Webサーバーへの攻撃もあって、内訳はざっくりこんな感じ。
- SSH辞書攻撃：
ubuntu、admin、root、deploy…よくあるユーザー名を手当たり次第に試してくる。ダントツで多い - 不審なUserAgent：ボットやスキャナーが使うような怪しいUserAgentでWebをノック
- Webエクスプロイト：既知の脆弱性を突くようなパスに直接アクセス
.envファイル（システムのパスワードや他サーバへのTokenなどが記載されるファイル）や設定ファイルを探し回るやつ
全部自動化されたボット。人件費ゼロで1万台を試して1台でも入れれば採算が取れる、という発想で動いてる。仮想通貨マイニングの踏み台とかスパム送信の起点として使われる。
bantimeの設定が地味に重要だった
ここで気づいたのが、bantimeの設定が短すぎると意味が薄いという話です。デフォルト設定のままだとbantimeが10分になっていたりする。
10分でUnbanされると何が起きるか。同じIPが1日に25回以上Banと解除を繰り返していたんですね😇 つまりBanしても10分後にはまたノックしてくる。もはやイタチごっこです。
Ban [攻撃元IP] → 10分後 Unban → また攻撃 → またBan → 10分後 Unban → …
これが1日中続く。
対策としては、bantime を 48h あるいは -1（永久Ban）に延ばすのが効果的です。よほど誤検知が心配な環境でなければ、長くしておいて損はないです。
さらに同じ /24 サブネットから組織的に攻撃が来ているパターンもある。そういう場合はサブネットごとiptablesでDROPするのが手っ取り早い。fail2banのBan/Unbanサイクルに関係なく、パケット自体を捨てられる。
「ほっといてもいい」は半分本当、半分ウソ
「fail2ban入れておけば勝手に守ってくれるんじゃないの？」という気持ちはよく分かります。実際、日常的な攻撃はfail2banがほぼ防いでくれます。
でも油断できないところが3つある。
- デフォルト設定のまま放置すると隙がある（bantimeが短い、maxretryが緩い、など）
- ログを誰も見ていないと、異常が起きてても気づけない
- SSHを守っていてもWebアプリが穴になる
3番目が個人的に一番やらかしそうで怖い。fail2banを入れてて安心していても、Webアプリに古い脆弱性が残っていたらそっちから入られる。
加えて言えば、顧客向けのサーバでは、検索エンジンのクローラーだと判定したら、１回で永久Banにしてもいいくらいです。
クラウド運用の「地味なしんどさ」の正体
クラウド運用の面倒くさいところって、劇的な障害より「じわじわとした管理コスト」にあると思ってます。
サーバーが落ちる、DBが吹っ飛ぶ、みたいな派手なインシデントは分かりやすい。でも「誰かが毎日自分のサーバーをノックし続けている」「設定が少しずつ古くなっていく」「ログが誰にも読まれないまま溜まっていく」、そういった静かな劣化が積み重なっていく。
インフラをちゃんと維持するってのは、華やかなものじゃなくて、こういう地道な観察と調整の繰り返しなんですよね。
セキュリティを守るというのは重要なのですが、「関係ないお前らのために、重要なサーバ資源を使わせてやるもんか」くらいの気持ちでやらないといけないのでしょうね。
あなたの会社のホームページサーバ、Web系の会社が代行していると思いますが、そのサーバ本当に大丈夫ですか？って確認するのも必要になるかもですよ。