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

サーバーの管理をしていると、いつもセキュリティが心配になります。 もちろん、鍵のセットをしていても、IPアドレスでアクセスを制御していても、ほぼほぼ大丈夫なのですが、 100％とは言い切れないのがインターネットの怖い所です。 過去に恐怖を体験した、AWSの乗っ取り事件の時も、1週間ぐらいトラウマ状態になりましたからwww AWSの不正利用対応奮戦記 そして、今回は自宅でブログ公開と、自分の勉強用として公開しているサーバーで、気になってログ調査をしていた所、auth.logが、数MBほどに膨らんでいる事が判明したので、その対応方法をまとめておきます。

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

これは、サーバーにログインする際に書き込まれるログで、成功しても失敗しても、書き込まれるので、所謂自分以外のアクセスがある場合は、不正アクセスという事になります。 普通に公開して、対応がされていないサーバーであれば、海外（中国やロシアなど）からのIPアドレスで大量にログが書き込まれていると思います。 一定周期で、ログイン失敗ログが書き込まれているのを見ると、パスワード解読を、時間をかけてやっているようにも見えます。 怖いですね。この時点で、パスワードが解読されてしまったら、もうアウトですよね。乗っ取られ成功です。

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

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

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

もっと他にもありそうですが、簡単に思いつくのはこの辺ですね。 ちなみに、auth.logのデータ容量は以下の様になっていました。 $ ls -lha auth.log -rw-r----- 1 root adm 37M Sep 17 12:07 auth.log ログローテーションで毎回数十メガ消費しているようなので、パスワード変更対応よりは、もとのアクセスをシャットダウンした方がいいですね。

今回行った対策

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

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

冒頭１００％ではないと書いたが、外部からのログインを遮断すると、仕事にも影響がでるので、自分端末だけアクセスできるようにしておく必要がある。 鍵も必須にしようと思ったが、まずはrootのみを塞いでおこう。 auth.logでは、rootアクセスのみ行われているようなので・・・

作業手順

rootのsshログインを禁止 「/etc/ssh/sshd_config」を編集します。 $ vi /etc/ssh/sshd_config # PermitRootLoginを「no」に変更 PermitRootLogin yes ↓ PermitRootLogin no # 構文チェック $ sshd -t # サービス再起動 $ /etc/init.d/sshd restart これで設定が完了。 当然だが、事前にユーザーアカウントでアクセスできるようにはしておく必要がある。 それを忘れたら、目も当てられなくなるので・・・ そして、rootでアクセスしてみて、ログインが通らない事を確認できたら、設定完了です。 お疲れ様でした。