ファイアウォールとSSH設定
前提:5-5が完了し、ホームディレクトリ(~)にいる状態から始めます。5-4・5-5で「サーバーは常に外部から狙われている」「ポートは部屋番号」ということを確認しました。このページはその集大成として、ufwというファイアウォール※1を使い、必要なポートだけを開けて他をすべて閉じる設定を行います。第5章のここまでで一番、操作を間違えると危険なページです。正しい順序を守れば何も怖くありませんが、順序を間違えると自分自身がサーバーから締め出されてしまいます。
このページではSET 1〜3、合計30行のコマンドを上から順に叩きます。手打ち推奨(コピーは確認用)ですが、このページに関しては特に、行の意味を理解してから1行ずつ叩くことを強くおすすめします。
SET 1 ― 現状確認とOpenSSHの許可
- $sudo ufw status
- Status: inactive
- $sudo ufw status verbose
- $sudo ufw app list
- Available applications: OpenSSH
- $sudo ufw app info OpenSSH
- $sudo ufw default deny incoming
- $sudo ufw default allow outgoing
- $sudo ufw allow OpenSSH
- Rule added
- $sudo ufw show added
- ufw allow OpenSSH
- $sudo ufw status
- $cd ~
1行目のsudo ufw statusで、ファイアウォールの現在の状態を確認します。ufw(Uncomplicated Firewallの略。名前のとおり、複雑なファイアウォール設定をシンプルなコマンドで扱えるようにした道具)は、Ubuntu標準ではまだ有効化されていないため、出力例のようにStatus: inactive(無効)と返ってきます。ここが今回の出発点です。ufwの操作にはシステム全体の通信ルールを書き換えるためsudoが必要です。2行目のようにverboseを付けても、無効な状態では大きな違いは出ません。
3行目のsudo ufw app listで、あらかじめ登録済みのアプリケーションプロファイルを確認します。出力例のようにOpenSSHという項目があり、これは「SSH接続に使う22番ポートを開ける」設定をあらかじめ名前で呼び出せるようにしたショートカットです。4行目のsudo ufw app info OpenSSHで、このプロファイルが具体的にどのポートを対象にしているかの詳細を確認できます。
5行目のsudo ufw default deny incoming、6行目のsudo ufw default allow outgoingは、Ubuntu標準の初期方針(「外からの通信は基本拒否、こちらから外へ出る通信は基本許可」)を明示的に指定し直すコマンドです。実はこれはUbuntuの初期設定と同じ内容なので実行しても変化はありませんが、この方針こそがファイアウォールの土台になっていることを意識しておいてください。
そして7行目、このページで一番大事な1行です。sudo ufw allow OpenSSHで、SSHの通信を許可するルールを追加します。8行目のsudo ufw show addedで、確かにルールが登録されたことを確認します。9行目でもう一度sudo ufw statusを確認すると、ルールは追加されたものの、まだufw自体を有効化していないため(SET 1の1行目でinactiveだったことを思い出してください)、実際の通信制御はまだ始まっていません。次のSET 2で有効化する前に、まずこの許可ルールを先に用意しておく、というのがこのページ全体の核心です。
もし先にsudo ufw enableを実行してからallow OpenSSHを追加しようとすると、有効化した瞬間にSSH接続(22番ポート)が塞がれ、今まさにつないでいるターミナルごと切断されて、二度とサーバーに入れなくなる可能性があります。Lightsailならブラウザ版のコンソール接続で復旧できる場合もありますが、最悪インスタンスの作り直しが必要になることもあります。必ず「allow OpenSSHが先、enableは後」の順序を守ってください。このページのSET 1とSET 2の順番は、そのために意図的に分けてあります。

ファイアウォールって「家の鍵をかける」イメージだけど、鍵をかける前に「自分の合鍵(SSHのルール)」をちゃんと用意しておくのが今回のポイントだよ! 合鍵を作らずに先に鍵を閉めちゃうと、自分の家なのに入れなくなるのと同じことがサーバーでも起きるから、順番だけは絶対に守ってね。
SET 2 ― ufwを有効化して確認する
- $sudo ufw enable
- Command may disrupt existing ssh connections. Proceed with operation (y|n)?
- $y
- Firewall is active and enabled on system startup
- $sudo ufw status
- Status: active
- $sudo ufw status verbose
- $sudo ufw status numbered
- $systemctl is-enabled ufw
- $who
- $whoami
- $w
- $cd ~
SET 1でallow OpenSSHを済ませたので、ここでようやく1行目のsudo ufw enableを実行します。出力例のように「既存のSSH接続を切断する可能性があります、続けますか」という確認が出ますが、すでにOpenSSHを許可済みなので、2行目でyと答えて問題ありません。3行目のメッセージのとおりファイアウォールが有効化され、今後サーバーを再起動しても自動的に有効な状態が続きます。
4行目のsudo ufw statusで、出力例のようにStatus: activeに変わったことを確認します。5行目のsudo ufw status verbose(詳細)では、許可ルールの一覧や、デフォルトの方針(通常は「受信は拒否、送信は許可」)まで確認できます。6行目のsudo ufw status numberedでは、各ルールに番号が振られた一覧を確認できます(この番号の使い方はSET 3で扱います)。7行目のsystemctl is-enabled ufw(5-2で学んだコマンドの復習です)で、ufw自体もsystemdのサービスとして自動起動が有効になっていることを確認できます。
もしここでSSH接続が切れていなければ、正しい順序で設定できた証拠です。8行目のwho、9行目のwhoami(2-3で登場済み)で、自分が今も無事にログインし続けていることを確認します。10行目のwはwhoに加えて現在の負荷状況なども表示する、似た仲間のコマンドです。
ufw enable実行後、もし本当に接続が切れてしまった場合は、Lightsailのブラウザ版コンソール接続(0-2で使った方法)から入り直し、sudo ufw allow OpenSSHを実行してからsudo ufw reloadする、という手順で復旧できます。とはいえ、今回のように先にallowしておけばこの事態自体を避けられます。
SET 3 ― ルールの追加・削除とsshd_configの確認
- $sudo ufw allow 8080/tcp
- $sudo ufw status numbered
- [1] OpenSSH ALLOW IN Anywhere
- [2] 8080/tcp ALLOW IN Anywhere
- $sudo ufw allow 8443/tcp
- $sudo ufw status numbered
- $sudo ufw delete 3
- $sudo ufw delete allow 8080/tcp
- $sudo ufw status
- $sudo less /etc/ssh/sshd_config
- $q
- $cd ~
1行目のsudo ufw allow 8080/tcpのように、アプリケーション名(OpenSSHなど)だけでなく、ポート番号を直接指定してルールを追加することもできます。7-1で扱うWebサーバー公開の練習として、ここでは試しに8080番ポートを許可してみます。2行目のsudo ufw status numberedで、出力例のように各ルールに番号が振られた一覧を確認できます。
3行目でもう1つ8443/tcpを許可し、4行目のstatus numberedで確認すると、ルールが3番まで増えているはずです。5行目のsudo ufw delete 3のように、numbered一覧の番号を指定して削除する方法を使うと、8443番のルールを素早く削除できます。
6行目のsudo ufw delete allow 8080/tcpは、番号ではなくルールの内容そのものを指定する削除方法です。delete allow <ルール>のように、追加したときと同じ書き方の先頭にdeleteを付けます。7行目のsudo ufw statusで、OpenSSHのルールだけが残っていることを確認します。
8行目のsudo less /etc/ssh/sshd_configでは、SSHサーバー自体の設定ファイルを覗きます。これは見るだけで、このドリルでは編集しません。ファイル内を/Portのように検索(1-4で学んだlessの検索機能)すると#Port 22という行が、/PasswordAuthenticationで検索するとPasswordAuthentication yesのような行が見つかります。前者はSSHの待受ポート番号(先頭の#はコメントアウトで、変更したい場合はこの記号を外して数字を書き換えます)、後者はパスワードでのログインを許可するかどうかの設定です。確認できたら9行目のqで抜けます。

sshd_configのPort 22を別の番号に変えたりPasswordAuthenticationをnoにしたりすると、より安全なSSH設定にできるんだけど、設定ミスすると本気で締め出されるからこのドリルでは見るだけにしてるよ。慣れてきたら、練習用インスタンスで自己責任で試してみてね!
Lightsailコンソール側のファイアウォールとの関係
ここまで設定してきたufwは、あくまでサーバーのOSの内側で動くファイアウォールです。実はLightsailには、それとは別にもう1つ、ブラウザのLightsailコンソール画面から設定する、ネットワーク経路側のファイアウォールが存在します。インスタンスの管理画面から「ネットワーキング」タブを開くと、許可するポートの一覧を設定できる画面があり、初期状態ではSSH(22番)とICMP(pingへの応答)だけが許可されています。
つまり、あなたのサーバーへの通信は「Lightsailコンソール側のファイアウォール」→「サーバー内のufw」という2段階の関門を両方通過しないと届きません。7-1でWebサーバー(80番ポート)を公開する際は、この2つの両方で80番を許可する必要があります。ufwだけ許可してLightsailコンソール側を忘れる、あるいはその逆、という片方だけの設定漏れは非常によくある事故なので、「開けたはずのポートに繋がらない」ときはこの二重構造を思い出してください。
ufw=部屋の中に置いた鍵付きの扉、Lightsailコンソールのファイアウォール=建物の入り口の警備員、とイメージしてください。建物の入り口を通過できても部屋の扉が閉まっていれば入れませんし、部屋の扉を開けていても建物の入り口で止められれば同じく入れません。
まとめ
5-6では、ufwを正しい順序(allowしてからenable)で設定し、ルールの追加・削除、sshd_configの確認、そしてLightsail側との二重構造までを学びました。この章末時点でufwは有効化され、OpenSSHの通信が許可された状態が続きます。このページで叩けるようになったコマンドを一覧にまとめます。
| コマンド | 何をするか | 覚え方 |
|---|---|---|
sudo ufw status | ファイアウォールの有効/無効を確認する | 今、鍵はかかってる? |
sudo ufw allow OpenSSH | SSH通信を許可するルールを追加する | 鍵をかける前の合鍵作り |
sudo ufw enable | ファイアウォールを有効化する | allowの後に叩く |
sudo ufw status verbose | ルールと方針を詳しく表示する | 詳細な鍵の一覧 |
sudo ufw allow <ポート>/tcp | 指定ポートの通信を許可する | 特定の部屋の鍵を開ける |
sudo ufw delete allow <ルール> | 許可ルールを削除する | allowの前にdeleteを付ける |
sudo less /etc/ssh/sshd_config | SSHサーバーの設定ファイルを閲覧する | 見るだけ、編集は慎重に |
これで第5章「管理者の仕事」は完了です。次のページ「6-1. 変数と環境変数」からは第6章に入り、シェルそのものの力、つまり変数やスクリプトを使ってコマンドを組み立てる世界に進みます。
- ファイアウォール … 特定の通信だけを許可し、それ以外を遮断する仕組み。建物の警備員のように、決められたルールに沿って通信の出入りを管理する。↩