あなたのSSHサーバーは 既に一日に何百回も攻撃を受けている可能性が高いです。 可能性が高いという言葉では足りません。ほぼ100％の確率であなたのサーバーは一日に何百回もの攻撃を受けていると、筆者である私は確信しています。 それでも多くの開発者は /var/log フォルダーをほとんど開いていません。 簡単な journalctl -f |grep ssh を今すぐターミナルで実行してみてください。

ログを正しく見ると:

  • 誰が

  • いつ

  • どこから

  • どのように
    サーバーに入り込もうとしたかが赤裸々に見えます。

この記事では SSHサーバーログを解釈する方法 と ハッキングの兆候を見つける実践的な分析方法 を開発者の視点で整理します。

1. SSHログはどこに残るのか？

Commandbox 광고

LinuxディストリビューションごとにSSHログの位置は少し異なります。

一般的には:

  • Ubuntu / Debian系

    • /var/log/auth.log

  • CentOS / RHEL系

    • /var/log/secure

  • systemdベースの共通コマンド

    • journalctl -u ssh.service または journalctl -u sshd

tailを使っても良いですが、個人的にはjournaldで見るのを非常に好みます。すべてのサービスのログを一か所でまとめて見られるからです。

# Ubuntuの例
sudo tail -f /var/log/auth.log

# CentOS/RHELの例
sudo tail -f /var/log/secure

# systemdサービスログをリアルタイムで見る
sudo journalctl -u ssh.service -f

tip: 開発サーバーでも、最低限、たまには tail -f でログを“監視する習慣”をつけると良いです。

journaldの具体的な使い方が気になる方は"こちら"をクリックしてください！

2. SSHログ１行の解剖

代表的なSSHログの1行を見て、構造を理解してみましょう。（Ubuntuの例）

2.1 公開鍵ログイン成功

Jan 10 12:34:56 myserver sshd[12345]: Accepted publickey for deploy from 203.0.113.10 port 50312 ssh2: ED25519 SHA256:xxxx

各部分の意味:

  • Jan 10 12:34:56 : 日付、時刻

  • myserver : ホスト名

  • sshd[12345] : プロセス名（SSHデーモン）とPID

  • Accepted publickey : 認証成功、方式は公開鍵

  • for deploy : ログインしたアカウント名

  • from 203.0.113.10 : 接続元IP

  • port 50312 : クライアント側ポート

  • ssh2: ED25519 ... : プロトコル/鍵タイプ情報

これを理解すれば、 “誰がどこから鍵で接続したのか” を迅速に把握できます。

2.2 パスワードログイン失敗

Jan 10 12:35:01 myserver sshd[12346]: Failed password for root from 198.51.100.23 port 50320 ssh2

  • Failed password : パスワード認証失敗

  • for root : rootアカウントで試行

  • from 198.51.100.23 : リモートIP

このようなログが 数秒間隔で数十～数百回 記録されていれば、
ほぼ確実に ブルートフォース攻撃です。

2.3 存在しないユーザーへのログイン試行

Jan 10 12:35:05 myserver sshd[12347]: Invalid user admin from 198.51.100.23 port 50325
  • Invalid user admin : サーバーに存在しない admin アカウントでのログイン試行

これもまた、自動化されたボットがよく使用するパターンです。

3. ログで見る代表的な攻撃パターン

Commandbox 광고

3.1 ブルートフォース攻撃

特徴:

  • Failed password ログが短時間で非常に多く発生

  • 同一IPから数十～数百回の試行

  • root、admin、test、oracle などのアカウント名を使用

迅速に確認する例:

# Failed passwordの総回数
sudo grep "Failed password" /var/log/auth.log | wc -l

# どのアカウントが最も攻撃されているか
sudo grep "Failed password" /var/log/auth.log \
  | awk '{for (i=1;i<=NF;i++) if ($i=="for") print $(i+1)}' \
  | sort | uniq -c | sort -nr | head

3.2 存在しないユーザーのスキャン

sudo grep "Invalid user" /var/log/auth.log | head

このログが多いということは “このサーバーにどんなアカウントがあるのか何でも適当に試している中”という意味です。

3.3 特定IPでの過度な試行

どのIPが特に多く失敗しているか確認:

sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -nr | head

上記の $(NF-3) は通常 from <IP> 部分のIPを指しますが、
環境によって若干異なる場合があるので、自分のログ形式に応じて調整が必要です。

4. “成功した”ログインから異常兆候を探す

攻撃は通常失敗に終わりますが、 本当に恐ろしいのは成功したログインです。

4.1 Acceptedログを集める

sudo grep "Accepted" /var/log/auth.log

この中で特に注意深く見るべきポイント:

  • 普段使用しないアカウントの接続

  • 普段と異なる時間帯の接続（例: 午前3時）

  • 見慣れない国/帯域のIP（会社/自宅/VPNでないIP）

4.2 最近の接続履歴を一度に見る

last コマンドは最近のログイン履歴を表示します。

# 最近のSSHログイン記録
last -i | head

# 失敗したログイン（サポートされている環境で）
lastb | head

これだけ定期的に確認しても、
“自分が接続していない時刻の接続記録”を簡単に発見できます。

5. 実践ログ分析: 迅速なチェックルーチンの例

SSHサーバーが一つあると仮定して、
5分でできるチェックルーチンを作成してみましょう。

5.1 ステップ1: 失敗ログインの総量確認

sudo grep "Failed password" /var/log/auth.log | wc -l
sudo grep "Invalid user" /var/log/auth.log | wc -l
  • 突然数字が大きくなった場合は“攻撃強度の増加”を疑ってみるべきです。

5.2 ステップ2: 最多攻撃IP TOP 10

sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -nr | head
  • 上位IPはファイアウォール/fail2ban ルールに追加できます。

5.3 ステップ3: rootでの試行ログイン

sudo grep "Failed password for root" /var/log/auth.log | tail
sudo grep "Accepted.*root" /var/log/auth.log
  • Acceptedが出ている場合、既にrootでログインに成功していることを意味するので非常に危険です。

5.4 ステップ4: 最近の成功したログインスキャン

sudo grep "Accepted" /var/log/auth.log | tail -n 50

ここで確認すべきポイント:

  • 自分が知らないIPか？

  • 通常の勤務時間帯か？

  • 突然初めて出現したアカウントはないか？

6. ログを見ただけではどうなる？すぐに適用する防御策

ログから攻撃の兆しを感じたら、
今度は 防御設定に移行する必要があります。

6.1 パスワードログインをオフにする（公開鍵のみ許可）

/etc/ssh/sshd_config で:

PasswordAuthentication no
PubkeyAuthentication yes

修正後:

sudo systemctl reload sshd
# または
sudo service ssh restart

必ず すでに公開鍵でのログインテストに成功してから パスワードをオフにしてください。
間違えると自分も入れなくなる可能性があります。

6.2 root直接ログイン禁止

PermitRootLogin no

rootで直接入れないようにし、
一般アカウントでログイン後に sudo を使うように強制するのが良いでしょう。

6.3 ポート変更（騒音を減らすため）

Port 22    # -> 例: 2222に変更

  • ポートを変えてもセキュリティが“強化”されるわけではありませんが、

  • 無分別な自動スキャン/攻撃ログがかなり減り、
    “本当に異常な兆候”がより見えやすくなります。

6.4 fail2banなどのツールを使用

fail2ban はログをモニタリングし、

  • 同じIPから

  • 短時間に

  • 多数のログイン失敗が発生した際に

自動的にファイアウォールのルールを追加し、遮断するツールです。

概念は簡単です:

  1. auth.log から Failed password パターンを監視

  2. 特定の閾値を超えた場合はそのIPをiptables/ufwで遮断

ログ分析を自動化して ブルートフォース攻撃を自動遮断することになります。

6.5 ファイアウォールでSSHアクセス自体を制限

可能であれば:

  • 会社VPNや特定の固定IPからのみ 22/tcp（または変更したポート）へのアクセスを許可

  • 残りは全て遮断

例: ufw 簡単な例

sudo ufw allow from 203.0.113.50 to any port 22 proto tcp
sudo ufw deny 22/tcp

7. 開発者のための“最小限の生活ログチェックルーチン”

開発者が業務中に現実的にできる範囲で要約すると、
以下の程度だけでも セキュリティ感度は完全に変わります。

週1回程度:

  1. 最近1週間の Failed password、 Invalid user 数量を一度見る

  2. 最多失敗IP TOP 10を確認

  3. Accepted ログから

    • 新しいIP、

    • 異常な時間帯、

    • 見慣れないアカウントがないか確認

  4. 疑わしいIPはファイアウォール/fail2ban などで遮断

一度でも直接目で見れば、
“ああ、このサーバーは本当に毎日攻撃を受けているんだな”という感覚が生まれ、
セキュリティ設定に時間を投資する意欲が生まれます。

ハッカーがsshサーバーを攻撃している様子

まとめ: 今すぐログを開こう

SSHのセキュリティは、大掛かりなソリューションの前に、
自分のサーバーで実際に何が起こっているのかを見ることから始まります。

  1. /var/log/auth.log または /var/log/secure を開いてみる

  2. Failed password、 Invalid user、 Acceptedを基準に読み取る

  3. おかしいと思えばすぐに設定変更やファイアウォール、 fail2ban 導入を検討する

この記事をすべて読んだなら、
“ログを見ることができずに被害に遭うハッキング”を避ける準備が整ったことになります。
さあ、ターミナルを開いて、自分でサーバーログを一度見てみてください。

開発者にとって セキュリティは選択肢ではなく必須であり、日常的なルーチンであるべきです。

Fail2banの使い方は"こちら"をクリックすると詳しい使用法が確認できます。