すべての KapsuleHost サーバーには、デフォルトで受信トラフィックを拒否するマネージドファイアウォール、ブルートフォース保護、ウェブアプリケーションファイアウォール、自動セキュリティパッチが付属しており、これらはすべて KPanel の 1 ページから制御できます。
デフォルト設定は、新しいサーバーが何も操作していない段階で安全になるように選択されています。その上に追加するのは通常、自分のアプリケーションが必要とするポートだけです。このガイドでは Server management ページ全体を説明しています。ファイアウォールはその 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 は常に開いているため、ファイアウォール変更によってマシンからロックアウトされることはありません。
- ウェブアプリケーション用のポート 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、ウェブアプリケーションファイアウォール
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.」 ポートフィールドは、その範囲内の整数を取ります。範囲とサービス名はここでは受け入れられません。
ルールは保存されましたが、何も変わりませんでした。 「Live apply unavailable」バナーを探してください。表示されている場合、変更は保存されていますがまだサーバーにプッシュされていません。
1 つのネットワークからサービスに到達できますが、別のネットワークからは到達できません。 これは通常、サーバーのファイアウォールではなく自分の送信ファイアウォールです。ここでルールを変更する前に、別の接続からテストしてください。
パッチ実行が FAILED を示します。 行のエラーメッセージを読んでください。ディスク容量が不足しているのが最も一般的な原因です。ディスクをクリアして、Run patch now をクリックしてください。
正当なトラフィックがブロックされ始めました。 ModSecurity をブロッキングモードに切り替えた場合、検出のみに戻し、ログを読み、ルールを特定してからもう一度試してください。
ファイアウォールルールが適用を拒否する場合、または許可したサービスからロックアウトされた場合、support@kapsulehost.com にサーバー名、ポート、および到達可能にしたいことを記載して電子メールを送信してください。