サーバーのファイアウォール設定方法：DDoS攻撃・悪質ボットから守るための完全ガイド

サーバーのファイアウォール設定は、不要な通信を遮断し、必要なポートだけを開放することでDDoS攻撃やブルートフォース、悪質なボットからサーバーを守る最初の防御ラインとなります。実際には、SSHアクセスの制限、ウェブサービスの選択的な公開、不審なリクエストへのレートリミット設定、ログ監視、可能ならCDNやWAFなどの上位防御によるトラフィックフィルタリングも含まれます。

ウェブサーバーをインターネットに公開すると、数分以内にポートスキャンやSSHログイン試行、脆弱性を狙うボット、偽ユーザーエージェントがアクセスしてきます。特にWordPress、ECサイト、管理パネル、API、ゲームサーバーなどを運用する場合、ファイアウォールは技術的選択肢を超えた「必須」の対策です。本記事ではLinuxサーバー向けに、UFW、firewalld、nftables、Fail2ban、Webアプリ向けファイアウォール、DDoS軽減策まで、実運用で役立つ防御構成をステップごとに解説します。

重要な前提ですが、ローカルファイアウォールだけでは大規模DDoS攻撃を完全に止めることはできません。20Gbpsや80Gbpsといった大量の攻撃トラフィックがデータセンターやネットワークまで届くと、OSレベルのルールが処理する前に帯域が溢れてしまいます。最適なアプローチは「多層防御」です。プロバイダーのDDoS対策、CDN/WAF、OSファイアウォール、アプリ側のレート制限、定期的なログ解析などを組み合わせましょう。適切なインフラ選定にはHostragons VPSとVDSサーバーソリューションページ、ウェブサイト用の安全なホスティングならHostragons ウェブホスティングパッケージページを参考にできます。

サーバーファイアウォールの役割とは？

サーバーファイアウォールは、ネットワークトラフィックを送信元IP、宛先IP、ポート、プロトコル、接続状態、場合によってはパケットの属性でフィルタリングするセキュリティ層です。例えば、ウェブサイトなら80番（HTTP）と443番（HTTPS）だけを開放し、データベース用の3306番は外部からアクセスできないようにします。SSH（22番）も全世界から開放するのではなく、自分のオフィスIPのみ許可するほうが安全です。

ファイアウォールの目的は「魔法のようにすべての攻撃を防ぐ」ことではありません。実際の狙いは攻撃対象面（アタックサーフェス）を減らすことです。面積が小さければ攻撃者の選択肢も減り、リスクも低減します。新規構築サーバーではSSH、管理パネル、メール、データベース、監視エージェント、テスト用サービスなどが同時に動いていることもあり、それぞれが独立したリスクを持ちます。良いファイアウォールは「デフォルト拒否、必要なものだけ許可」の原則で動きます。

DDoS攻撃とボットトラフィックの理解

DDoS攻撃が特別な理由

DDoS（分散型サービス妨害）は、複数の発信元から大量の通信を送りつけ、サービス自体を利用不可にする攻撃です。帯域消費型、CPUやRAM消費型、アプリケーション層の重い処理を狙う型など様々。例えば小規模アプリが秒間5万件のHTTPリクエストを受ければ、回線が詰まらなくともPHP-FPMやNode.js、DB接続プールがパンクすることもあります。

すべてのボットが悪質ではない

GooglebotやBingbotなどの検索エンジンボットやモニタリング用ボットは有益です。しかし悪質なボットは管理パネル探索、ディレクトリ一覧取得、フォームスパム、コンテンツ盗用、XML-RPC悪用、偽ユーザー登録やログイン試行などの行動をします。ボット管理の目的は「全て遮断」ではなく、挙動で良悪を分けること。高いエラー率、短時間大量リクエスト、ブラウザらしくないヘッダー、不審なURLパターンが主な警戒ポイントです。

設定前のチェックリスト

実稼働サーバーでファイアウォール設定時、最大のリスクは「自分自身を締め出してしまう」ことです。設定変更前に以下のチェックリストで準備しましょう。

• SSH接続を切らず、別の端末でテスト用セッションを持つ。
• サーバー事業者のコンソール、VNC、リカバリアクセスが利用できるか確認。
• 現在の開放ポートを確認：ss -tulpnやnetstat -tulpnで調査。
• ウェブ、メール、DNS、DB、パネル、監視サービスの使用ポートをメモ。
• IPv6を利用している場合、IPv6用ファイアウォールも計画。
• まず許可ルール（allow）、次に拒否ルール（deny）を適用。
• ルールが永続（再起動後も維持）されることを確認。

例：ウェブサイト運用のみの場合、開放すべきポートは通常80、443、限定SSHのみ。メールサーバー不要なら25、465、587、993などは閉じる。DBがローカル運用なら3306や5432は外部から閉じておきましょう。

どのファイアウォールツールを選ぶべきか？

Linuxでは複数のファイアウォールツールがありますが、どれも内蔵のカーネルフィルタ基盤を異なるUIで操作します。初心者ならUFWがシンプルで素早く導入可能。企業やRed Hat系ではfirewalldが標準。高度な運用ではnftablesが最新で柔軟です。下記の比較表を参考にしてください。

ステップ別サーバーファイアウォール構築

1. 開放ポートとサービスの確認

まずLinuxサーバーでss -tulpnコマンドなどを使い、どのサービスがどのポートで待ち受けているか調べます。例えばnginxが0.0.0.0:80や443でリッスンしていれば全ネットワークからウェブトラフィックを受けている状態。MariaDBが0.0.0.0:3306ならリスクが高く、通常は127.0.0.1運用が望ましいです。

基本ルールは「外部から不要なサービスは0.0.0.0でリッスンしない」。まずサービス側の設定を修正し、その後ファイアウォールで閉じるのが理想です。ファイアウォールが無効化されても、サービス自体が外部に公開されていない状態が安全です。

2. デフォルトポリシーを閉じる

安全なルールセットでは、基本的に外部からの通信は全て拒否し、必要なものだけを許可します。これにより後から追加されたサービスが意図せず公開されることを防げます。UFWなら、まずSSH許可、次に80と443許可、最後にデフォルト受信ポリシーをdeny（拒否）し、ファイアウォールを有効化します。

流れの例：管理者のIPアドレスだけSSH許可、HTTP/HTTPS公開、不要ポート閉鎖、そして有効化。SSH許可前にファイアウォールをONにすると、特に遠隔サーバーで自分が締め出されるミスが多発します。

3. SSHアクセスの制限

SSHは攻撃者が最も狙うサービスの一つ。デフォルト22番を開放していると、1日で数百～数千件のパスワード試行があることも。最適なのは特定IPだけSSH許可すること。固定IPならオフィスやVPNのIPのみ許可。固定IPがない場合、最低限鍵認証を有効化しパスワード認証は無効にしましょう。

• rootでの直接SSHログインを禁止
• パスワードではなくSSHキーを利用
• AllowUsersやAllowGroupsでユーザー制限
• Fail2banで失敗回数による自動遮断
• 管理パネルもIP制限を実施

ポート変更だけでは抜本的な防御にはなりませんが、ボットによる雑音は減ります。真の防御はIP制限、強力な認証、ログ監視の組み合わせです。

4. ウェブポートの選択的開放

ウェブサイト運用なら基本的に80（HTTP）と443（HTTPS）が必要です。ただし現代では443（HTTPS）が主流となっており、80はHTTPSへのリダイレクト用途のみ開放が推奨されます。SSL未導入サイトはユーザー信頼・SEOにも悪影響です。Hostragons SSL証明書から安全なHTTPS導入ができます。

ポート開放時にはCDNやリバースプロキシ運用の場合、全世界から開放せずCDNのIPレンジだけ許可することで防御力が大幅UP。攻撃者が本来IPを知っても直接アクセスできません。

5. データベース・内部サービスの遮断

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDBなどを外部公開すると、重大なリスクとなります。Redisは認証不足、Elasticsearchは無許可インデックスアクセス、MongoDBは管理ポート放置など、過去に多くの情報漏洩事例があります。これらは基本的にlocalhostやプライベートネットワークでのみリッスンしましょう。

例えばWordPressが同じサーバーで動いているなら127.0.0.1のみで十分。アプリとDBが別サーバーの場合も、アプリサーバーのIPだけ許可し、インターネット全体に3306や5432を開放しないよう注意。

6. Fail2banによるブルートフォース防止

Fail2banはログ監視により、繰り返される失敗ログインを検知し該当IPを一時的に遮断します。SSH、nginx、Apache、Postfix、Dovecot、WordPressログイン、管理パネルなど幅広く利用可能。例として、10分間に5回失敗したら1時間遮断するといった設定がシンプルかつ効果的です。

Fail2banのルールは過度に厳しくしすぎないこと。誤検知で正規ユーザーまで遮断するリスクがあるため、まずは適度なbantimeで運用し、ログを観察しつつ段階的に厳格化するのが安全です。

7. レートリミット・接続数制限の導入

DDoSやボット対策として、OSレベルやWebサーバー側でレートリミット（頻度制限）が有効です。同じIPから大量の新規接続が発生した場合、制限を加えます。nginxならlimit_reqやlimit_conn、Apacheならmod_evasiveなどが利用可能。アプリ側ではログイン、検索、カート、決済、APIエンドポイントごとにレート制限を設ける必要があります。

例：ログインページでは1IPにつき1分間に10回まで、検索APIでは1秒に2～5回など。APIならユーザーごとのトークン制限、IP制限、行動分析を組み合わせることで、単にIP変更だけでは突破できなくなります。

UFWで安全な初期設定例

UbuntuやDebian系サーバーの場合、まずサービス確認、管理者IPからSSH許可、80/443開放、デフォルト拒否、UFW状態確認という流れが基本です。SSHが固定IPで制限できない場合は、一時的に全IP許可し、後日VPNや固定IP化を検討しましょう。

例：203.0.113.10が管理者IP。SSHはこのIPだけ許可。ウェブは80/443を全ユーザーに開放。DBやRedis、管理パネル、テスト用ポートは外部から閉鎖。これは中小企業のウェブサイトでの標準的な初期構成です。DNS運用やドメイン設定にはHostragons ドメイン検索と登録ページが参考になります。

firewalldのゾーン運用

AlmaLinux、Rocky Linux、RHEL系ではfirewalldが主流。ゾーン（zone）概念で、public zoneはインターネット向け、trusted zoneは内部ネットワーク用、drop zoneは不要トラフィックを静かに遮断する用途です。特にruntime（即時適用・再起動で消失）とpermanent（永続・reload必要）の違いに注意。

企業運用ではサービス単位の定義が便利。例：public zoneでhttp/https公開、SSHは特定IPのみ許可。管理ネットワークやバックアップネットワーク、ユーザー通信を分離すれば、ゾーン構成がセキュリティと運用性を向上させます。

CDN・WAF・プロバイダーDDoS対策

ローカルファイアウォールはサーバー到達後の通信を処理しますが、大規模DDoS攻撃ではサーバー到達前にトラフィックを遮断する必要があります。CDNは静的コンテンツをエッジで配信し、WAFはアプリ層の悪質リクエストを遮断、プロバイダーの防御はネットワークレベルの大量攻撃を吸収・除去します。

理想構成はDNSがCDN経由、サーバーIP非公開、ファイアウォールはCDNのIPレンジのみ80/443許可。管理ポートはVPNや固定IPでアクセス。こうすることで直接IP攻撃やボット流入も大幅に軽減できます。ウェブサイトスピードアップとセキュリティガイドの内容も参考になります。

ボット対策：アプリ層の実践防御

ボット対策は単なるIPブロックではありません。現代ボットはプロキシ、モバイル回線、データセンターIP、変化するユーザーエージェントを駆使します。挙動分析が必要です。短時間大量ログイン試行、頻繁な404エラー、wp-login.phpやxmlrpc.phpの過剰アクセス、通常ユーザーと異なるクリック傾向、不審なヘッダーを解析します。

• ログイン・登録フォームで適切なレートリミット導入
• 不要なXML-RPCは閉鎖か制限
• 管理パネルはURL変更、IP制限、多要素認証で防御
• WAFで怪しいuser-agentやrefererパターンを遮断
• フォームにはCAPTCHAや不可視ボット認証を適度に追加
• APIエンドポイントで鍵・署名・クォータ・タイムスタンプ検証

ボット対策でユーザー体験を損なわないことも重要。過剰CAPTCHAや過度フィルタ、誤った国別遮断は正規顧客にダメージとなるため、測定・テスト・段階的強化が適切です。

ログ監視とアラート設定

設定完了＝安心ではありません。ファイアウォールは常に監視し運用する必要があります。auth.logやsecureでSSHログイン試行、nginxアクセスログで異常リクエスト、エラーログの404/500増加、システムメトリックのCPU・接続数監視などが重要。アラート設定で攻撃時に迅速対応可能です。

初期の閾値例：5分間で同一IPから100回以上の404、1分間でログインページに20回以上アクセス、CPU10分間90%以上、接続数が通常の3倍など。サイトによって閾値は調整必須ですが、「普段のトラフィック」を把握することが重要です。

よくあるミスと回避方法

• SSH許可前にファイアウォール有効化：遠隔サーバーへのアクセス喪失。必ず2つ目のセッションでテスト。
• IPv6の設定忘れ：IPv4側が閉じてもIPv6でサービスが開放されている場合あり。
• データベースを外部公開：3306、5432、6379、9200などはボットが常時スキャン。
• CDN導入後も本来IP公開：攻撃者がCDNを迂回し直接攻撃可能。
• ルール変更を記録しない：トラブル時にどのルールが何のためか判別困難。
• バックアップアクセス計画なし：ルールミスでコンソールアクセス不能なら復旧遅延。

実践ファイアウォールポリシー例

中小企業ウェブサイト向けの基本ポリシー例：外部からの通信はデフォルトで拒否、443は全訪問者へ開放、80はHTTPSリダイレクト用のみ開放、SSHはVPNや固定管理者IPのみ許可、DBはlocalhostや内部ネットワークのみ。CDN利用時は80/443もCDN IPレンジだけ許可。Fail2banでSSH/ウェブログイン監視、ログは中央監視ツールへ集約。

ECサイトなど中規模の場合は、決済callback IPのallowlist、管理パネルはVPN経由、APIはユーザー別クォータ、WAFでSQLインジェクションやXSSルール強化、国やASNによる一時フィルタ計画追加。ポリシーは文書化しておき、攻撃時は事前手順に従って迅速対応しましょう。

テスト：ファイアウォールルールの検証方法

設定後は必ずテストを行いましょう。別ネットワークからポートスキャン、SSHが許可IPのみ通るか、ウェブサイトがHTTPSでアクセス可能か、DBポートが外部から遮断されているか確認。CDN利用時は本来IPに直接HTTPリクエストして遮断されているかもチェック。

テスト時、実稼働サーバーへ過度なスキャンは避け、あくまで安全な確認のみ。また、変更ごとにルールセットを記録・エクスポートし、万一の際に復旧しやすくしておきましょう。

運用・更新の計画

サーバーセキュリティは「一度設定して終わり」ではなく、定期的な運用が不可欠です。新サービス追加時はポート要件見直し、不要サービス削除時は関連許可を消去、セキュリティパッチも速やかに適用、ログは定期的に監視。月1回のポートスキャン、3ヶ月毎のルール見直しが良いスタートです。

さらにバックアップ計画もセキュリティ戦略の一部。DDoS攻撃でアクセス遮断されても、ランサムウェアや不正アクセスによるデータ損失リスクもあります。安全なホスティング、SSL、ドメイン管理、バックアップをセットで考えましょう。安全なホスティング選択時の注意点やSSL証明書の設置方法の関連記事も活用できます。

まとめ

サーバーファイアウォール設定はDDoSやボットから完全に「不可視」にするものではありませんが、攻撃面を大幅に減らし、無許可アクセスリスクを下げ、インシデント発生時に冷静な対応が可能になります。最適な防御は、プロバイダーのDDoS対策、CDN/WAF、厳格なポート管理、SSH制限、Fail2ban、レートリミット、定期ログ監視の総合運用によって実現されます。

新規プロジェクト公開時は、最初からファイアウォールポリシーを設計することで、後から修正するより遥かに安全かつ効率的です。Hostragonsでサーバー・ホスティング・ドメイン・SSLを選ぶ際も、セキュリティ要件と併せて検討し、より堅牢なウェブ環境を構築しましょう。まずは簡単なチェックリストから始めて、開放ポートの遮断、SSH制限、HTTPS強制、ログ監視を徹底してください。

よくある質問

サーバーファイアウォールだけでDDoS攻撃を完全遮断できますか？

いいえ。ローカルファイアウォールは小規模か特定プロトコルの攻撃を軽減できますが、大規模DDoSではプロバイダー防御やCDN/WAFの導入が必須です。

ウェブサーバーで開放すべきポートは？

一般的なウェブサーバーは80（HTTP）と443（HTTPS）。SSHは管理者IPのみ許可。DBや内部サービスは外部公開しません。

UFWとfirewalldどちらが良い？

UbuntuやDebian系ならUFWが簡単。AlmaLinux、Rocky Linux、RHEL系ならfirewalldが標準。高度運用やカスタム構成ならnftablesも選択肢です。

IP遮断だけでボットトラフィックは防げますか？

通常は不十分。現代のボットはIP・プロキシを切り替えるため、IP遮断に加えてレートリミット、WAFルール、行動分析、CAPTCHA、アプリ側クォータが必要です。

ファイアウォール設定時の最大リスクは？

最大のリスクはSSHアクセス喪失。必ずSSH許可を定義し、2つ目のセッションでテスト、プロバイダーのコンソールアクセスも事前準備しましょう。