クラウドサーバー
クラウドサーバーのファイアウォールとセキュリティ管理
Every KapsuleHost Server ships with a managed firewall that denies inbound traffic by default, plus brute-force protection, a web application firewall and automatic security patching, all controlled…
Cloud Server Firewall and Security Management
KapsuleHostのすべてのサーバーには、デフォルトでインバウンドトラフィックを拒否する管理ファイアウォール、ブルートフォース保護、Web アプリケーションファイアウォール、自動セキュリティパッチが搭載されており、すべてKPanelの 1 ページから制御できます。
デフォルト設定は、新しいサーバーが何も触らないうちから安全になるように選択されています。その上に追加するのは、通常、独自のアプリケーションが必要とするポートだけです。このガイドはサーバー管理ページ全体を説明します。ファイアウォールはその一つのセクションであり、他のセクションはファイアウォール自体が必要なくなるようにするものだからです。
管理ページを開く
- KPanelにサインインします。
- 左サイドバーのCloud Serversをクリックしてから、サーバーをクリックします。
- ページ上部のアクションボタンからManagementをクリックします。
直接アドレスは/cloud-servers/<server-id>/managementです。ページは「Firewall, OS patches, fail2ban, and ModSecurity. Changes apply over SSH within seconds.」と説明しています。

「Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately」というバナーが表示される場合、パネルは現在サーバーに接続できません。設定は保存されていますが、まだ適用されていません。サーバーが実行中で到達可能であることを確認してください。
デフォルトファイアウォールポリシー
**Firewall (UFW)**セクションは、ポリシーを 1 行で述べています。「Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below.」
実際には以下を意味します。
- インターネットからサーバーに到達できるのは、ルールで許可されたもののみです。
- ポート 22 は常に開いているため、ファイアウォール変更によってマシンからロックアウトされることはありません。
- Web アプリケーション用のポート 80 や 443 など、アプリスタックが必要とするポートは自動的に開きます。
- サーバーからのアウトバウンドトラフィックは制限されません。
カスタムルールがない場合、セクションは「No custom rules. Defaults: SSH + app-stack ports.」と表示されます。これは設定がないのではなく、健全な状態です。
カスタムルールを追加する
デフォルトポリシーがカバーしていないポート (Node アプリケーション用の 3000、直接到達する必要があるデータベース用の 5432、UDP ポート上のゲームやメディアサーバーなど) で何かを実行している場合は、ルールを追加してください。
- **Firewall (UFW)**セクションを開きます。
- 最初のフィールドにPort番号を入力します。有効な値は 1 ~ 65535 です。
- TCPまたはUDPを選択します。
- AllowまたはDenyを選択します。
- Addをクリックします。
ルールがリストに表示され、ALLOWまたはDENYバッジとポート、プロトコルが付与されます。例えば3000/tcpです。管理接続を通じてサーバーにプッシュされ、数秒以内に適用されます。
ルールを削除するには、その行の末尾のXをクリックします。Allowルールを削除すると、そのポートは直ちに閉じられます。
データベースポートをインターネット全体に公開するのは、サーバーが侵害される最も一般的な方法の 1 つです。3306、5432、6379、27017 を許可する前に、接続するものがサーバー自身のループバックインターフェースまたはプライベートネットワークを経由してデータベースに到達できるかどうか自問してください。本当に外部から到達可能である必要がある場合は、サービス自体が強力な認証と暗号化を要求することを確認してください。
最初にルールを追加してから、サービスを開始します。閉じたポートの背後で起動するサービスは、開始に失敗したサービスとまったく同じように見え、デバッグに長時間を無駄にする可能性があります。
アプリスタック
App stackセクションは、このサーバーが実行するアプリケーションの種類をプラットフォームに伝えるため、ハードニングプリセットをそれに合わせて調整できます。パネルを通じてアプリケーションをインストールすると、これが自動的に設定されます。
認識されるスタックは WordPress、WooCommerce、Ghost、Nextcloud、GitLab、Mattermost、Generic web、No app stack です。セクションは「The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this.」と説明しています。
スタックは、どのポートが自動的に開くかに影響し、他の保護 (特に fail2ban) がどのように調整されるかにも影響します。
fail2ban
fail2ban は認証試行を監視し、失敗を繰り返すアドレスをバンしています。デフォルトでオンになっており、ページは「Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too.」と説明しています。
これをオンのままにしてください。ページ上の最も安価な保護であり、パフォーマンスにコストがかからず、絶え間ないパスワード推測の試行をまったく何もない状態に変えます。WordPress または WooCommerce スタック上では、ログインフォームも保護します。これは実際のところ、WordPress に対する攻撃が着地する場所です。
ModSecurity:Web アプリケーションファイアウォール
ModSecurity は HTTP リクエストを OWASP Core Rule Set に対して検査し、攻撃に見えるものにフラグを付けます。KapsuleHost サーバー上では、検出のみモードで開始されます。「OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned.」
検出のみが正しい出発点です。Core Rule Set は完全であり、実際のアプリケーションでは、正当なリクエストの一部がルールに一致します。検出のみモードでしばらく実行し、ログを読み、独自のトラフィックがどのルールをトリップするか把握してから、サーバー内でブロッキングに切り替えてください。
最初にチューニングせずにブロッキングをオンにすると、自分のサイトが破損する可能性があります。リッチテキストを含むフォーム送信、ファイルアップロード、異常なペイロードを持つ API クライアントが通常の被害者です。切り替える前にログを確認してください。
OS 自動パッチング
セキュリティアップデートは自動的に適用されます。セクションはセーフティネットを説明しています。「Security updates applied automatically. Snapshot-protected: a server snapshot is taken before each run, with automatic rollback if the server becomes unreachable after reboot.」
トグルの下に 2 つの設定があります。
- Allow automatic reboot when a kernel update needs it (only during quiet hours below). カーネルアップデートは再起動後にのみ有効になります。これをオフのままにすると、カーネルパッチはインストールされますが、自分で再起動するまでアクティブになりません。
- Quiet window (UTC)、開始時間と終了時間。再起動はその中でのみ発生します。視聴者にとって最も静かな時間に設定し、このフィールドは現地時間ではなく UTC であることを忘れないでください。
自動パッチングをオンのままにしてください。侵害されたサーバーの圧倒的多数は、数週間前に公開されたパッチを実行していることがあります。パッチ前のスナップショットと自動ロールバックは、通常の異議である「アップデートが何かを破損するかもしれない」が既に処理されていることを意味します。
パッチ履歴と今すぐパッチを実行
Patch historyセクションは、RUNNING、SUCCESS、ROLLED_BACK、FAILED、SKIPPED のステータス、更新されたパッケージ数、サーバーが再起動したかどうか、開始時刻を含む各実行を一覧表示します。
スケジュールを待つのではなく直ちにパッチを適用するには、Run patch nowをクリックします。確認は「A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it.」と読みます。
ROLLED_BACK エントリはセーフティネットが仕事をしたことを意味します。サーバーは再起動後に正常に戻ってこなかったため、パッチ前のスナップショットが復元されました。これらのスナップショットがどのように機能するかについては、Cloud Server Snapshotsを参照してください。
合理的なベースライン
ほとんどのサーバーでは、これがセキュリティ設定全体です。
| 設定 | 推奨 |
|---|---|
| ファイアウォール | オン、デフォルトルール、プラスアプリが必要とするポートのみ |
| fail2ban | オン |
| ModSecurity | オン、ログを読むまで検出のみ |
| OS 自動パッチング | オン、静かなウィンドウでの再起動を許可 |
| SSH 認証 | キー、パスワードではなく |
最後の行はこのページにはありませんが、残りを合わせたより重要です。Connecting to Your Cloud Server With SSHを参照してください。
トラブルシューティング
「Could not load management config.」 パネルはこのサーバーの設定を読み込めませんでした。リロードし、サーバーが存在し、プロビジョニングされていることを確認してください。
「Port must be 1-65535.」 ポートフィールドはその範囲内の整数を受け取ります。範囲とサービス名はここでは受け入れられません。
My rule saved but nothing changed. 「Live apply unavailable」バナーを探してください。表示されている場合、変更は保存されていますが、サーバーにまだプッシュされていません。
I can reach my service from one network but not another. これは通常、サーバーの外部ファイアウォールではなく、独自のアウトバウンドファイアウォールです。ここでルールを変更する前に、別の接続からテストしてください。
A patch run shows FAILED. 行のエラーメッセージを読んでください。ディスクが満杯なのが最も一般的な原因です。スペースを解放し、Run patch nowをクリックしてください。
Legitimate traffic started getting blocked. ModSecurity をブロッキングモードに切り替えた場合は、検出のみに戻し、ログを読み、再度試す前にルールを特定してください。
ファイアウォールルールが適用されない場合、または許可したサービスからロックアウトされた場合は、support@kapsulehost.comにサーバー名、ポート、および到達すると予想される内容を含めてメールしてください。