公開サーバーのauth.logが肥大化してないかい?

castle-2688920_1280
LINEで送る
Share on GREE
Share on LinkedIn

サーバーの管理をしていると、いつもセキュリティが心配になります。
 

もちろん、鍵のセットをしていても、IPアドレスでアクセスを制御していても、ほぼほぼ大丈夫なのですが、
100%とは言い切れないのがインターネットの怖い所です。
 

過去に恐怖を体験した、AWSの乗っ取り事件の時も、1週間ぐらいトラウマ状態になりましたからwww
 

AWSの不正利用対応奮戦記
 

そして、今回は自宅でブログ公開と、自分の勉強用として公開しているサーバーで、気になってログ調査をしていた所、auth.logが、数MBほどに膨らんでいる事が判明したので、その対応方法をまとめておきます。

auth.logってなんのログファイル?

これは、サーバーにログインする際に書き込まれるログで、成功しても失敗しても、書き込まれるので、所謂自分以外のアクセスがある場合は、不正アクセスという事になります。
 

普通に公開して、対応がされていないサーバーであれば、海外(中国やロシアなど)からのIPアドレスで大量にログが書き込まれていると思います。
 

一定周期で、ログイン失敗ログが書き込まれているのを見ると、パスワード解読を、時間をかけてやっているようにも見えます。
 

怖いですね。この時点で、パスワードが解読されてしまったら、もうアウトですよね。乗っ取られ成功です。

対策方法はどんなのがあるのか?

とりあえず、知ってる限りの対策方法を書き出してみます。

・ルータで22番ポートのアクセスをブロックする。
・/etc/hosts.deny ファイルに、不正アクセスのIPアドレスを追記してブロック。
・ログインパスワードを周期的に変更し、強固なもので運用する。
・サーバー内のFirewallでポートを塞いでしまう。

もっと他にもありそうですが、簡単に思いつくのはこの辺ですね。
 

ちなみに、auth.logのデータ容量は以下の様になっていました。

 

ログローテーションで毎回数十メガ消費しているようなので、パスワード変更対応よりは、もとのアクセスをシャットダウンした方がいいですね。

今回行った対策

とりあえず、以下の仕様でサーバーセットしておこうと思います。

・サーバーはrootでsshログインできない。

冒頭100%ではないと書いたが、外部からのログインを遮断すると、仕事にも影響がでるので、自分端末だけアクセスできるようにしておく必要がある。
 

鍵も必須にしようと思ったが、まずはrootのみを塞いでおこう。
auth.logでは、rootアクセスのみ行われているようなので・・・

作業手順

rootのsshログインを禁止
「/etc/ssh/sshd_config」を編集します。
 

&nbsdp;

これで設定が完了。
 

当然だが、事前にユーザーアカウントでアクセスできるようにはしておく必要がある。
それを忘れたら、目も当てられなくなるので・・・
 

そして、rootでアクセスしてみて、ログインが通らない事を確認できたら、設定完了です。
 

お疲れ様でした。

Leave a Reply

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です


*