Ubuntu 9.10 と FreeNX で Linux ターミナルサーバを構築する方法

重要: これらは筆者環境で動作した手順です。ネットワークやセキュリティ要件は環境ごとに異なるため、実運用で使用する前に必ず自組織のセキュリティ基準に照らして検証してください。

目的と適用範囲

この文書は次を目的とします:

• Ubuntu 9.10 を FreeNX サーバとして設定する具体的手順を示す。
• SSH ベースの接続を前提に、最低限のファイアウォールと自動ブロック（fail2ban）を利用した運用例を提示する。
• クライアント側（NoMachine NX Client）での接続手順とキー管理について説明する。

対象読者: Linux サーバ管理者、中小規模オフィスのIT担当者、リモートワーク用に自宅マシンを公開したい上級ユーザー。

定義（1行ずつ）:

• FreeNX: NoMachine の NX プロトコルをオープンソースで実装したサーバソフトウェア。
• NX Client: NoMachine が提供するクライアントソフト（GUI 接続ウィザードを含む）。
• firehol: iptables を簡易に管理するためのユーティリティ。
• fail2ban: ログ解析に基づいて侵入試行を自動でブロックするツール。

用意するもの

• Ubuntu 9.10 がインストール済みのマシン（サーバ候補）
• 管理権限（root または sudo）
• クライアントマシン（Windows, macOS, Linux など）
• ネットワーク設定情報（現在の IP、ゲートウェイ、DNS、DHCP 範囲）
• ルーター/ファイアウォールの管理権限（外部接続を許可する場合）

重要: Ubuntu 9.10 は古いリリースです。セキュリティ更新が既に終了している可能性があるため、公開環境やインターネット直結環境での運用はリスクが高いです。可能であれば新しい LTS（長期サポート）版への移行を検討してください。

準備: 管理者権限を取得する

まず端末を開き、ルートに切り替えます。デスクトップ環境では「アプリケーション -> アクセサリ -> 端末」を開いてください。

 sudo su -l

この後の手順は root（または sudo）で実行します。

必要パッケージのインストール

OpenSSH サーバは FreeNX の前提条件です。加えて fail2ban と firehol を入れて基本的な防御を構築します。パッケージマネージャとして aptitude を使う例を示します。

 aptitude update && aptitude install openssh-server fail2ban firehol

インストール後、SSH サーバが稼働しているか簡単に確認します:

 ssh 127.0.0.1

初回は RSA キーフィンガープリントが表示され、接続の継続確認が求められます。ここでは Control-C で切断して構いません。フィンガープリントは後でクライアント側で照合するためメモしておくと安心です。

ネットワークの静的設定

サーバとして公開するなら固定 IP を割り当てるのが運用上わかりやすいです。DHCP サーバ側で静的割当を設定できるならそれでも構いません。ここでは /etc/network/interfaces を編集して静的 IP を設定する方法を示します。

現在の設定確認:

 ifconfig eth0
 cat /etc/resolv.conf
 route

上記で得た addr（IP）、Bcast（ブロードキャスト）、Mask（サブネットマスク）、nameserver（DNS）および default（ゲートウェイ）を控えます。DHCP が割り当てない空き IP を選び、以下のように interfaces を編集します。

 nano /etc/network/interfaces

dhcp 設定がある場合は次の行を変更します:

 iface eth0 inet dhcp

static に変更、または以下を追加します（ここでは例）:

 iface eth0 inet static
     address 192.168.1.253
     netmask 255.255.255.0
     network 192.168.1.0
     broadcast 192.168.1.255
     gateway 192.168.1.1
     dns-nameservers 8.8.8.8 8.8.4.4

注: dns-nameservers はカンマではなくスペース区切りにするのが一般的です。ここでは Google Public DNS（8.8.8.8 / 8.8.4.4）を例示していますが、組織ポリシーに従って変更してください。

設定を反映させます:

 /etc/init.d/networking restart

その後、ブラウザでインターネット接続ができるか確認してください。

ファイアウォールの基本設定（firehol）

このチュートリアルでは外部からの受信を SSH（ポート 22）のみ許可し、発信は制限しません。まず firehol を起動する設定に切り替えます。

 nano /etc/default/firehol

 START_FIREHOL=NO

を

 START_FIREHOL=YES

に変更します。次に IANA の予約アドレスリストを更新します:

 get-iana

firehol の設定ファイルを編集します:

 nano /etc/firehol/firehol

ファイル末尾に最低限次の行を追加して SSH の受信を許可します:

 server ssh accept

設定を保存してファイアウォールを起動します:

 firehol start

正常なら次のような出力が表示されます:

 Activating new firewall (47 rules): OK

ルールの一覧を確認するには:

 iptables --list

重要: 本例は最小構成です。実運用では管理用ネットワークのみアクセス許可、ログ収集、侵入検知、ACL の分離など追加対策を検討してください。

FreeNX のインストール

Ubuntu の PPA（当時の freenx-team）から FreeNX をインストールします。端末で以下を実行してください:

 add-apt-repository ppa:freenx-team
 aptitude update
 aptitude install freenx
 /usr/lib/nx/nxsetup --install

インストール後、カスタムキーを生成することが可能です。カスタムキーを生成すると、クライアント側で同じキーの導入が必要になります。内向きネットワークで管理下にある環境なら必須ではありませんが、外部へ公開する場合は各クライアントに配布する専用キーを作成することを強く推奨します。

キー生成の例:

 /usr/lib/nx/nxsetup --keygen

生成したキーは安全な場所に保管し、クライアント設定時にインポートします。

クライアントのインストールと接続設定

クライアント側は NoMachine の NX Client を使用します。公式ダウンロードページから OS に適したクライアントを取得してください:

http://www.nomachine.com/download.php

インストール後、NX Connection Wizard を起動します。ウィザードで次を設定します:

• セッション名: 任意（例: Office-NX）
• サーバ IP: サーバの固定 IP
• 接続速度: LAN（あるいは環境に応じて選択）
• デスクトップタイプ: Ubuntu 9.10 標準が GNOME であれば GNOME を選択（KDE がデフォルトになっている場合は変更する）

カスタムキーを使用している場合は「Advanced Configuration（詳細設定）」で Keys を選び、サーバで生成・取得したキーをインポートします。

ログイン時に SSH（RSA）キーのフィンガープリント確認を求められます。最初に控えたフィンガープリントと一致することを確認し、以降同じ警告が再度出る場合は注意が必要です（鍵が置き換えられた可能性）。

ユーザー管理

複数人で利用する場合、各ユーザーをシステムに追加します。GUI で: 「システム -> 管理 -> ユーザーとグループ」から追加できます。コマンドラインでは次のように:

 adduser username

ユーザーごとにホームディレクトリ、シェル、グループ権限を適切に設定してください。

ルーター/ポートフォワーディング（外部接続を許可する場合）

外部から接続させる場合、ルーター側で TCP/22 をサーバへ転送（ポートフォワード）します。ルーター設定は製品ごとに異なりますが、次の点に注意してください:

• グローバル IP を直接公開することのリスクを理解する。
• NAT で公開する場合は外部ポートを変える（例: 外部 2222 -> 内部 22）などの「ポートハーニング」は軽度の秘匿性を提供するが、セキュリティ対策の代替にはならない。
• 公開するなら必ずカスタム鍵か少なくとも強力なパスワードポリシーを採用し、fail2ban の設定を厳格にする。

セキュリティ強化（推奨）

以下は運用で検討すべき追加の対策です。

• SSH の設定変更: /etc/ssh/sshd_config を編集し、PermitRootLogin を no、PasswordAuthentication を no（公開鍵認証のみ）にする。

 PermitRootLogin no
 PasswordAuthentication no

その後 ssh サービスを再起動します:

 service ssh restart

• SSH 接続ポートの変更（ポート移動は防御の本質ではありませんが、自動スキャンのノイズを減らすのに役立ちます）。
• fail2ban のフィルタと jail を調整してブルートフォース攻撃を早期に遮断する。
• ログ監視と定期的なログレビュー（/var/log/auth.log など）。
• SELinux や AppArmor のプロファイルを利用してプロセスごとのアクセス制御を強化する（Ubuntu では AppArmor がデフォルト）。
• クライアント側のソフトウェアが最新であるか確認する。古いクライアントは既知の脆弱性を含む可能性がある。

注意: これらの設定は運用環境のポリシーに合わせて慎重に変更してください。公開サーバを運用する場合、専門家によるセキュリティ監査を推奨します。

運用チェックリスト（ロール別）

管理者向けチェックリスト:

• SSH キーとパスフレーズを安全に管理する。
• fail2ban のログとブロック履歴を週次で確認する。
• firehol のルールと iptables の状態を定期的にエクスポートして保存する。
• ユーザーの追加・削除があれば速やかにアカウント管理を行う。
• 定期的にバックアップ（/home、設定ファイル、/etc）を取得する。

エンドユーザー向けガイド:

• クライアント接続情報（サーバ IP、ポート、必要なキー）を安全に受け取る。
• 公共の Wi-Fi から接続する場合は端末の OS とクライアントを最新に保つ。
• セッション終了時は必ずログアウトする。

セキュリティ担当向け:

• 侵入検知アラートを SIEM に送る（可能なら）。
• 重要なイベント（不正ログイン試行、鍵の置き換え）を即時調査する。

展開 SOP（簡易プレイブック）

1. ベース OS インストール（Ubuntu 9.10 インストール手順 1-3 を完了）
2. root に昇格し、必要パッケージをインストール
3. ネットワークの静的 IP 設定と /etc/resolv.conf の検証
4. firehol を有効化し、ssh のみ受け入れる最小ルールを適用
5. FreeNX を PPA からインストールし、nxsetup を実行
6. カスタム鍵を生成する場合は安全なメディアに保存し、クライアントに配布
7. クライアントで接続確認（最初の RSA フィンガープリント一致を確認）
8. 運用手順と緊急時連絡先をドキュメント化してスタッフに周知

インシデント対応（障害発生時の簡易手順）

1. 侵入または異常を検知したら即座に外部公開を停止（ルーターでポートフォワードを切るか、firehol で受信拒否）
2. 影響範囲を特定（どのユーザー／プロセスが関与したか）
3. ログ（/var/log/auth.log、/var/log/syslog、fail2ban ログ）を保存して分析
4. 必要に応じて該当ユーザーのパスワードや鍵を無効化し、再発行
5. システム全体の整合性検査（rootkit 検査、diff で設定ファイル比較）
6. 復旧後、対応手順を振り返り、再発防止策をドキュメント化

テストケースと受入基準

最低限の受入基準（KPI 的ではなく運用上の条件）:

• 初回接続時にクライアントが RSA フィンガープリント照合を行い、管理者が控えた値と一致すること。
• 単一ユーザーが同時に GUI セッションで操作できること（ラグや画像破綻がないこと）。
• fail2ban が一定回数の認証失敗を検知して接続元をブロックすること。
• firehol のルールにより TCP/22 以外からの外部受信が遮断されていること。

具体的なテスト手順:

• クライアントから接続してログイン→GUI が期待通り表示されるか確認。
• 誤ったパスワードで複数回ログイン試行→fail2ban によるブロックを確認。
• 外部から別ポート（例 80）で接続を試み、到達しないことを確認。

トラブルシューティング

問題: クライアントが「フィンガープリントが一致しない」と表示する 対応:

• サーバ側で sshd のホスト鍵が変更されていないか確認（/etc/ssh/sshhost* をチェック）。
• 中間のネットワークで MitM（中間者攻撃）がないか疑う。鍵の差分が正当な変更か確認するまで公開アクセスを停止する。

問題: 接続はできるが画面が非常に遅い／アニメーションや動画がカクつく 対応:

• NX の接続速度設定を低速（低帯域）に変更して帯域節約モードを試す。
• ネットワークの帯域や遅延（ping, traceroute）を測定する。
• サーバの CPU/メモリ使用率を確認し、リソース不足でないかチェックする（top/htop）。

問題: firehol が起動しない／ルールが適用されない 対応:

• firehol の設定ファイルの文法エラーを確認する（ログにエラーが出る）。
• /var/log/syslog や /var/log/firehol を確認する。

代替案と比較

• VNC: シンプルだが帯域効率とレスポンスで NX に劣る。暗号化も別途必要。
• RDP（xrdp）: Windows と高い互換性。Linux デスクトップを公開する場合は X サーバの構成に差がある。
• x2go: NX プロトコルに似た代替で、オープンソースで比較的高性能。FreeNX と比べてメンテナンスや互換性が変わるため検討の価値あり。

選択のヒューリスティック: 低帯域／高応答性が重要なら NX/x2go、Windows との互換性優先なら RDP、設定の単純さを優先するなら VNC（ただし暗号化を確保する）を選ぶ。

マイグレーションの注意点（近代的な Ubuntu へ移行する場合）

Ubuntu 9.10 は古いため、可能であれば以下を検討してください:

• 新しい Ubuntu LTS（例: 20.04, 22.04）へ移行する。パッケージ名、PPA、Systemd（/etc/init.d ではなく systemctl）などに差分がある。
• FreeNX はプロジェクトの状況によりパッケージが変化しているため、x2go や最新の NoMachine 商用クライアントを検討する。
• firehol の設定ファイル構文や get-iana の利用可否がディストリビューションで変わる可能性がある。

移行手順（高レベル）:

1. テスト環境に現行設定を復元する（設定ファイル、ユーザーデータ）。
2. 新環境に同等のサービス（SSH、NX/x2go）をインストールして動作確認。
3. ネットワーク構成・ファイアウォールルールを移植して比較テスト。
4. 切替ウィンドウを決めて段階的に移行する。

よくある質問（FAQ）

Q: FreeNX はどのように暗号化されていますか？ A: FreeNX はデフォルトで SSH トンネルを使用するため、SSH の暗号化が適用されます。追加の暗号化が必要な場合は SSH の暗号設定を強化してください。

Q: なぜ fail2ban が必要なのですか？ A: ブルートフォース攻撃や不正ログイン試行を検出して、一定回数失敗した接続元 IP を自動でブロックすることで、攻撃表面を低減します。

Q: FreeNX は商用 NoMachine と互換性がありますか？ A: 基本的に NoMachine の NX プロトコルを利用するためクライアント互換はありますが、バージョンや独自拡張によって挙動が異なる場合があります。クライアントとサーバの互換性は事前にテストしてください。

決定支援フロー（Mermaid）

graph TD
  A[要件: リモート GUI アクセス] --> B{低帯域で高応答性か}
  B -- Yes --> C[FreeNX / x2go を検討]
  B -- No --> D{Windows 互換性が必要か}
  D -- Yes --> E[RDP (xrdp) を検討]
  D -- No --> F[VNC (暗号化を別途設定) を検討]
  C --> G[SSH と鍵管理を計画]
  E --> G
  F --> G

用語集（1行定義）

• SSH: リモートシェルおよびトンネルのための暗号化プロトコル。
• PPA: Ubuntu の Launchpad にある個別パッケージリポジトリ。
• NAT: ネットワークアドレス変換。ルーターでプライベート IP をグローバル IP に変換する技術。

追加リソース

• Ubuntu FreeNX Documentation（公式ドキュメントを参照）
• Firehol（firehol.org）
• Fail2ban（公式ドキュメント）
• NoMachine（公式ダウンロードとドキュメント）

まとめ

このガイドでは Ubuntu 9.10 上に FreeNX を導入してターミナルサーバとして稼働させる手順を、ネットワーク設定、ファイアウォール、インストール手順、クライアント接続、セキュリティ強化、運用チェックリスト、トラブルシューティングまで包括的に説明しました。実運用に移す際は、公開環境での既知のリスクと古い OS のサポート終了による脆弱性を考慮し、可能であれば最新のディストリビューションへ移行することを強くお勧めします。

重要: 本記事の手順を実行する際には、自組織のポリシー・セキュリティ基準に従い、必要であれば専門家によるレビューを実施してください。