この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
朝のルーティンチェック中に、その事実に気づいたとき、頭が真っ白になりました。
私がSEとして客先のサーバーを担当していた2004年のことです。20年以上Linuxサーバーを運用してきた経験の中でも、あの朝の「これは何だ」という感覚は今でも鮮明に覚えています。
この記事では、SE時代（2001年～2006年）に経験した不正アクセスを疑う出来事と、そこから生まれた毎朝のログ確認の習慣について正直に話します。
この記事のポイント
・2004年、担当サーバーの/tmpに見覚えのないファイルを発見した実体験
・lastコマンドと/var/log/secureで不審なアクセスの痕跡を確認した流れ
・不審ファイルは消す前に報告する「証拠保全の鉄則」を身をもって学んだ
・この経験からSSH公開鍵認証の徹底と毎朝のログ確認が20年間続いている
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その朝、/tmpに見知らぬファイルがあった
2004年、私はSIerのSEとして客先のLinuxサーバーを担当していました。当時は今のようにセキュリティ監視ツールが整備されておらず、ほぼ手作業でサーバーを管理していた時代です。その日も朝のルーティンとしてSSHでサーバーに接続し、ディレクトリを確認していました。
# /tmpの中身を毎朝確認するのが当時のルーティン $ ls -la /tmp total 48 drwxrwxrwt 8 root root 4096 Apr 9 08:30 . drwxr-xr-x 19 root root 4096 Mar 15 12:00 .. -rwxr-xr-x 1 nobody nobody 1024 Apr 8 22:22 .scan.sh drwx------ 2 miyazaki miyazaki 4096 Apr 9 08:42 .ICE-unix
「誰かが不正にこのサーバーにアクセスしたかもしれない」
その考えが頭をよぎった瞬間、体が少し固まりました。
手が震えながらコマンドを打った
まず「誰がいつログインしたのか」を確認しようと思いました。当時も今も、最初に打つコマンドはlastです。1. lastコマンドでログイン履歴を確認した
# ログイン履歴を確認する $ last miyazaki pts/0 192.168.10.5 Fri Apr 9 08:42 still logged in nobody pts/1 203.0.113.44 Thu Apr 8 22:17 - 22:31 (00:14) miyazaki pts/0 192.168.10.5 Thu Apr 8 09:01 - 18:33 (09:31) reboot system boot Thu Apr 8 07:01
手が少し震えていたことを覚えています。
2. /var/log/secureでSSHの痕跡を追った
次に/var/log/secureを確認しました。Red Hat Linux系ではSSHのログイン成功・失敗の記録がこのファイルに残ります。# SSHのログを確認する $ grep sshd /var/log/secure | tail -30 Apr 8 21:58:32 server01 sshd[3421]: Failed password for root from 203.0.113.44 port 51234 ssh2 Apr 8 21:59:01 server01 sshd[3422]: Failed password for root from 203.0.113.44 port 51235 ssh2 Apr 8 22:01:44 server01 sshd[3423]: Failed password for nobody from 203.0.113.44 port 51241 ssh2 Apr 8 22:17:09 server01 sshd[3441]: Accepted password for nobody from 203.0.113.44 port 51310 ssh2 Apr 8 22:31:05 server01 sshd[3441]: pam_unix(sshd:session): session closed for user nobody
セキュリティへの意識が今ほど高くなかった時代の話です。
3. ファイルを消そうとしたら先輩に止められた
私が反射的に「とにかくこのファイルを消さなければ」と手を伸ばしたとき、たまたま通りかかった先輩エンジニアが声をかけてくれました。「待て。まず証拠のコピーを取って、それから上司に報告する。順番を間違えるな」
私はそのファイルを安全な場所にコピーしてから、上司に報告しました。ファイルの中身は、他のサーバーを踏み台にするためのシンプルなシェルスクリプトでした。いわゆるスクリプトキディが使う定型的なツールです。幸い、それ以上の被害は確認されませんでした。
この経験から20年間変わっていない3つの習慣
あの日の経験が、私の日常的なサーバー運用の習慣を大きく変えました。20年以上経った今も、以下の3つは変わらず続けています。1. 毎朝最初にlastコマンドを打つ
サーバーにSSHでログインしたら、最初にlastコマンドを打つ習慣が身につきました。昨夜から今朝にかけて、どのアカウントがどのIPアドレスから何時にログインしたかを確認する。たった10秒の作業ですが、「見知らぬログイン」を早期発見するための最も素朴で確実な手段です。lastコマンドでログイン履歴を確認する方法｜lastb・lastlogやセキュリティ調査もでコマンドの詳細な使い方を確認できます。
私がセミナーで3,100名以上を指導してきた中で、「lastを毎朝確認している」と言える受講生は最初はほとんどいません。あの経験をお話しすると、多くの方が翌日から実践してくれます。
2. 不審なファイルはすぐに削除しない
先輩に教わった「証拠保全が最優先」という原則は今も守り続けています。不審なファイルを発見したとき、最初にやりたくなるのは「とにかく消す」ことです。しかしそうすると、後から状況を正確に把握できなくなります。まずファイルのコピーを安全な場所に保存する。次に報告する。その後で対処する。この順番を崩さないことが、インシデント対応の基本です。
3. SSHをパスワード認証から公開鍵認証に切り替えた
あの事件の直接原因は「パスワードが単純すぎた」ことでした。対策として、まずすべてのアカウントのパスワードを強化し、その後でSSHを公開鍵認証に完全移行しました。公開鍵認証に切り替えると、パスワードを試す攻撃が原理的に無効化されます。ssh-keygenコマンドでSSH公開鍵認証を設定する方法は、私のセミナーで必ず最初期の設定として紹介する内容になりました。
まとめ
あの朝の経験から学んだことをまとめます。| 習慣・対応 | ポイント |
|---|---|
| 毎朝lastコマンドを打つ | 前夜から今朝のログイン履歴を10秒で確認できる |
| 不審ファイルはコピーしてから報告 | 証拠を保全してから対処する順番が重要 |
| SSHを公開鍵認証に切り替える | ブルートフォース攻撃を原理的に防ぐ |
| /var/log/secureを定期確認する | SSHの接続成功・失敗がすべて記録されている |
日常的な確認習慣と、SSH公開鍵認証の徹底。この地味な積み重ねが、現場での信頼を作るのだと思っています。
次に読む記事
・Linuxのログを読む習慣が身につくと現場の見え方が変わる理由｜20年以上の運用経験から伝えたいこと
・lastコマンドでログイン履歴を確認する方法｜lastb・lastlogやセキュリティ調査も
セキュリティの基礎から現場で使えるサーバー管理の「型」を学びませんか？
SSH公開鍵認証の設定、ログ監視の習慣、インシデント時の初動対応——これらは教科書よりも「現場での経験」から学ぶことが多いスキルです。現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxでバッチ処理がSSH切断で止まった話｜nohupを知らなかったSE時代の失敗と現役講師が今も守る長時間処理の鉄則
- 前のページへ：Linuxのcronが「動かない」と3時間格闘した日の話｜SE時代の体験と現役講師が語るcron3つの落とし穴
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます