BeginnerEngineerBlog
ホーム 最近公開の記事
中の人
中の人

【サイバー攻撃】ブルートフォース攻撃

公開: 2023-11-23 21:55
更新: 2023-12-24 12:57
35
セキュリティ ssh サイバー攻撃 ブルートフォース攻撃 ec2
攻撃されました

ついにきたぞぉぉぉ

こんにちは！

中の人です！

なんかサイト重いなーと感じて色々調べたら攻撃されてたので紹介します


攻撃対象


つまりこのサイト

現象


サイト表示が重くなる
アクセス後のプログラムの動作が重いというよりネットワーク自体が重い感じ
要はこのサイトのローディング画面が表示されるまでの時間が数十秒かかる感じ

原因


このサイトはawsのec2を利用しているのですが、原因はCPUクレジットなるものが枯渇してたからでした

「ec2 重くなる」で調べたところ

こちらにCPUクレジット確認した方がいいですよって書いてありましたので、確認してみました


おお
グラフが急降下してる

確かに重いなって感じた時間はほぼクレジットは0でした

また、ロードバランサーのリクエスト数を確認したところ


CPUクレジットが急降下するタイミングでリクエスト数が激しくなってました
攻撃前と攻撃中の差がやばくてそれはそれで悲しくなる笑
めっちゃ攻撃しとるやん
何が不満でこのサイト攻撃したのかわからんが謝るから許してくれ。ごめんて


ログ


冒頭の画像がアクセスログの一部です

Received disconnect from 59.3.76.218 port 39938:11: Bye Bye [preauth]

こちらで検索したところ

ブルートフォース攻撃

ということがわかりました。


ブルートフォース攻撃



何度もssh接続を試みる攻撃だそうです


対策


・キーペアでの認証
・セキュリティグループのsshのインバウンドルールのipを制限する
・portを22以外を設定
・アクセス試行回数設定
・その他参考記事参照

もともとキーペアでの認証方式でしたので、ひとまずは？サーバーへの侵入は防げてたみたいです。多分

セキュリティグループのsshのインバウンドルールのipを制限する


ただec2のセキュリティグループのSSHの設定が


攻撃されるまで、タイプは

SSH

で、ポートは

22

ソースは

0.0.0.0/0

これになってました

つまりなんでも来いの状態で放置してました

このサイトの公開に向けてec2でのサイト構築していた当時、関連の参考記事に沿ってセキュリティグループを設定していましたが、多分ですけど、「一旦0.0.0.0/0にしときましょう」的な内容だったと思うんです。覚えてないですけど。
当時は訳分からん状態でしたので、実際ssh接続できていぇーいってテンションでそのままにしてました

こちらのソースのipを一つに制限したところ、上記で紹介したアクセスログはピタッと止まりました

portを22以外を設定


上記のと並行して、ポート範囲を22から適当なportに変更しました


タイプのカスタムTCPはもともとSSHだったのですが、
こちらを参考にしてportを変更しました

なんかブルートフォース攻撃の特徴というか、攻撃されやすいのはデフォルトの22(まぁそうだよね)を狙うのが多いらしく、適当なportを指定しました

参考記事に沿って作業しましたが、自分のメモとして簡単に手順を紹介します

・ec2にsshでアクセス
・sudo vim /etc/ssh/sshd_config
・Portを指定
・ec2インスタンスのセキュリティグループを上記のように変更
・sudo service sshd reload

で変更しました

アクセス試行回数設定


最後に一定回数失敗したら一定時間アクセス不可にする設定を追加しました


こちらも参考記事に詳しく記載されてますが、自分がやった内容

・ec2にsshで接続
・vim /etc/pam.d/password-auth
auth        required      pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth        [default=die] pam_faillock.so authfail audit deny=3 unlock_time=600
account     required      pam_faillock.so

を追加
・ec2インスタンスを再起動

適用されてるかよくわかんなかったので念の為ec2を再起動しました
(特に何もしなくても大丈夫っぽいです)


終わりに


対策後


数時間後

CPUクレジット



回復してきた

リクエスト数




11/23あたりでちょびっと伸びてますが、以降は攻撃前と同じ感じ？

ただその時間帯のCPUクレジットは低下してないので、多分、あくまで多分ですが対策が功を奏したって感じでしょうか？
あと攻撃者も攻撃をやめたのか攻撃前と同じ感じのちょびちょびしたリクエストになりました

数日様子を見てみようと思います

多分最適解


多分ですが、今後も改善しない場合は
にあるようにAmazonGuardDutyを利用するのが一番確実なのかなぁと感じました
あとWAF
でもコスト発生するんですよねぇ。。

このサイトの収益で工面できるくらいになったら考えるかもしれません

今後もし当サイトにアクセスして重かったら、あーまだ攻撃されてんなーと思ってください
(ローディング画面から表示への移行の遅さはデフォルトです！)


ということで


ec2ユーザーや他でも私と同じように放置している方は今すぐ！対策するのだ！
実際に攻撃に気づくとドキィィィっとするぞ！

ちなみに攻撃してきたipを調べたところ韓国やベトナムとかがcountryで登録されていましたが、多分ですが踏み台かなーと感じてます

今回の経験からセキュリティについてもっと勉強しないとって思わされました
その意味では攻撃者には感謝してます

感謝してますけど、超〜〜〜〜〜迷惑(ﾟ∀ﾟ )< ｱﾔﾏﾙｶﾗﾔﾒﾃｸﾀﾞｻｲ

迷惑だけどしゃーないですね。webは攻撃者がいることが前提ですから

ということで

お互い気をつけましょー
0
0
0
0
通信エラーが発生しました。
似たような記事