セキュリティ

ウェブサーバーのファイアウォールルールiptablesとUFWの実践例

ファイアウォール iptables とUFWは、ウェブ・サーバーがどの接続を受け入れ、どの接続をブロックするかを制御する。この実践的な記事では、SSH、HTTP(S)、データベース、ロギング、IPv6、Dockerに関する明確なルール、安全なデフォルト、テスト済みのコマンドを紹介する。

中心点

コンフィギュレーションを始める前に、以下のポイントを簡単に説明する。

制限的 開始：デフォルトの着信拒否、特にオープン
SSH 最初に許可する：アクセスを危険にさらさない
世界労連 インターフェイスとして：シンプルな構文、バックグラウンドでiptables
ロギング アクティベートルールを確認し、攻撃を認識する。
永続性 確保する：再スタートに関するルールの維持

基本：一目でわかるiptablesとUFW

頼りにしているのは IPテーブルパケット、チェーン、マッチをきめ細かく制御する必要があるときは、UFWを使っている。UFWを使うのは、内部的にはiptablesルール[1]として終わる信頼性の高いルールを素早く適用したいときだ。これにより、細部に迷うことなく、シンプルなコマンドとLinuxネットフィルターのパワーを組み合わせることができる。ウェブサーバでは、Apache、Nginx、またはNodeの前に明確なフィルタを構築して、必要なトラフィックだけが届くようにする[2]。このように分離することで、攻撃対象が減り、攻撃がより頻繁に失敗するようになる。

どちらのツールもお互いを補い合うもので、状況に応じてどちらを使うかを決める。UFWは、特にUbuntuやDebian [3]での読みやすさが優れています。iptablesは、NATや特定のインターフェイス、複雑なマッチなどの拡張オプションを提供してくれます。重要: 私は、後でメンテナンスが簡単にできるように、ルールを簡潔に文書化しています。セキュリティのコンセプトについてもっと知りたい方は、こちらにわかりやすい紹介があります：防護シールドとしてのファイアウォール.

設定の開始：デフォルト・ポリシーを安全に設定する

私は次のように始める。 デフォルト-ポリシー：着信をブロックし、発信を許可する。このようにして、新しいサービスが意図せずアクセスされるのを防いでいる。ループバックを常に許可して、内部プロセスが安定して動くようにしている。キャンセルを避けるため、既存の接続を許可する。このシーケンスにより、ファイアウォールを有効にする際のエラーを最小限に抑えることができる [2][5]。

私はUFWを使って、いくつかのコマンドだけでベースを設定する。それからステータスを細かくチェックして、タイプミスにすぐに気づくようにしている。特に機密性の高いホストに対しては、発信ポートを制限することもしている。これにより、サービスが侵害された場合のデータ漏えいのリスクを減らすことができる。私は以下のコマンドをよく使う：

# UFW: デフォルトルール
sudo ufw default deny incoming
sudo ufw デフォルトの発信許可

# 別の厳しい送信ポリシー
sudo ufw default deny outgoing
sudo ufw allow out 53
sudo ufw allow out 80
sudo ufw 443 を許可する

# ステータスの確認
sudo ufw status verbose

ステートフル・フィルタリング：ステートとシーケンス

きれいな小包の流れは、次のようなものだ。 コントラックは次のように述べている。.私は確立されたコネクションを最初に受け入れ、無効なパケットを早めに破棄し、ループバックをオープンにしておく。こうすることで負荷を軽減し、遅延ドロップによる副作用を防いでいる。iptablesについては、意図的に順番を決めている：

# iptables: 確かな基礎
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# ループバックを常に許可
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# 既存/関連接続を許可する
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# 無効なパケットを早期に廃棄する
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

UFWでは、ESTABLISHED/RELATEDはすでに内部で考慮されている。また、私は ドロップ (サイレント）または拒否 (アクティブ、フェイルオーバーが速い）。内部ネットワークではREJECT、パブリックネットワークでは通常DROPがいい。

ウェブサーバーに不可欠なルール：SSH、HTTP、HTTPS

Iスイッチ SSH そうしないと簡単にロックアウトされてしまう。それからHTTPとHTTPSを許可して、ウェブサーバーにアクセスできるようにする。本当に必要なポートだけを設定する。その後、オプションでレート制限やFail2banを追加して、残忍なログイン試行を抑制する。すべての変更は、statusコマンドかlistコマンドですぐにチェックする。

そのためのコマンドはシンプルにしている。UFWはウェブポートのエイリアスをしゃべることができるので、読みやすさが増した。iptablesを使えば、正確なポートとプロトコルを設定できる。iptablesのルールは再起動後も保存しておく。以下は最小限の手順である：

# SSH
sudo ufw allow 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# http/https
sudo ufw http を許可する
sudo ufw https を許可する
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

安全なSSH：選択的に制限して開く

リリースに加え、私は次のように攻撃を減衰させる。 レート制限 またはホワイトリスト。UFWはシンプルな保護を提供します：

# SSHレート制限 (UFW)
sudo ufw limit 22/tcp comment "SSH レート制限"

私はiptablesでより細かい制限を設定している。これにより、正当な管理者を排除することなく、大規模なパスワードの推測を防ぐことができます：

# SSH: 接続元ごとの接続試行を制限する
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --update --seconds 60 --hitcount 10 -j DROP

可能な限り、SSHは 管理者IPアドレス とSSHキーで作業する。ポートを変えることはセキュリティの代わりにはならないが、ノイズを減らすことはできる。私は例外を文書化し、定期的にチェックしている。

データベースの保護とIPソースの制限

データベースのポートをグローバルに開くことはない。 ローカル または定義された送信元 IP アドレスの場合。これにより、スキャナがMySQL、PostgreSQL、MongoDBのオープンポートを見つけるのを防ぐことができる。ローカルアプリケーションの場合、ターゲットとしては127.0.0.1で十分だ。変更点は、サーバーのwikiなどで簡単に文書化しています。これは監査時の時間の節約になる。

私はプロジェクトで以下の例をよく使います。私は、許可されたIPが正しいかどうかを事前にチェックする。UFWは "from-to "の表記をきれいにすることができるが、iptablesは技術的に同じロジックを実装している。一時的なメンテナンスウィンドウに追加の許可ルールを使い、後で削除する。これでインターフェイスを小さく保つことができる：

# ローカルのみ: MySQL
sudo ufw で 127.0.0.1 から任意のポート 3306 を許可する。
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT

# シングルIPを許可する
sudo ufw allow from 203.0.113.10
iptables -A INPUT -s 203.0.113.10 -j ACCEPT

# 特定のIPのポートを許可する
sudo ufw allow from 10.1.2.3 to any port 4444
iptables -A INPUT -p tcp -s 10.1.2.3 --dport 4444 -j ACCEPT

# 既知の攻撃者をブロックする
sudo ufw deny from 192.0.2.24
iptables -A INPUT -s 192.0.2.24 -j DROP

ロギング、インターフェース、IPv6のクリーンな処理

Iスイッチ ロギング ルールを確認し、目立つトラフィックを認識する。UFWの "on "レベルでほとんどのホストには十分で、それ以上のレベルは選択的にしか使わない。私はjournalctl、fail2ban、SIEMツールを使ってログを分析する。これにより、スキャンやブルートフォースの試行からパターンを認識することができる。異常があった場合は、速やかにルールを調整する[2]。

私はしばしば、ルールを特定の インターフェースなどのパブリック・ネットワークで使用される。これにより、内部ネットワークが不必要に影響を受けるのを防ぐことができる。etc/default/ufwは「eth0から任意のポート80へのアクセスを許可する」ことができ、iptablesは入力インターフェースに-iを使う。IPv6については、/etc/default/ufwの "IPV6=yes "のアクティベーションをチェックし、ネイティブルールにはip6tablesを使っている[2]。このように分離することで、デュアルスタックホストとのギャップを避けることができる。

ICMPとICMPv6：隙間のないアクセシビリティ

必要なものは残す アイシーエムピー-パスMTUの発見、タイムアウト、および診断が機能するようにする。ICMPは敵ではなく、IPプロトコルの中核である。私は過剰なエコーを制限するだけだ。

# IPv4: エコーを制限し、重要な ICMP タイプを許可する
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT

# UFW: ICMP全般を許可 (before.rulesで微調整可能)
sudo ufw allow in proto icmp

時点では アイピーブイシックス ICMPv6は絶対に必要だ（Neighbour Discovery、Router Advertisement）。私はコアタイプを許可し、エコー要求を制限している：

# IPv6 (ip6tables)
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type ルーター広告 -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 近隣探索 -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 近隣広告 -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT

送信制限とNAT/マスカレードを正しく使用する

私は、次のような場合に発信トラフィックを制限している。 リスクプロファイル そしてコンプライアンス。私はDNSとHTTPSを許可し、定義されたターゲット以外はすべてブロックしている。これにより、サービスが乗っ取られた場合の流出データを減らすことができる。アップデートやAPIを必要とするアプリケーションについては、定義された例外を設けている。これらの例外を明確に文書化し、定期的にチェックしている。

ルーティングのセットアップには、UFW-Before-Rulesを使ったNAT/マスカレードか、iptablesを使ったrawを使う。パケットが正しく書き換わるように、チェーンの順番に注意している。変更後は、接続性とレイテンシーをテストします。本番システムの場合は、メンテナンス・ウィンドウを計画し、コンフィギュレーションをバックアップします。これにより、ネットワーク経路を追跡可能に保つことができる[7]。

アウトバウンドの詳細：システムサービスとプロトコル

厳格なアウトバウンド・ポリシーで、私は特に次のことを許可している。 DNS (53/udp）、 HTTPS (443/tcp)および必要に応じて エヌティーピー (メールサーバーについては、25/tcpと587/tcpを追加している。ドメインベースの例外はパッケージレベルでは解決せず、プロキシやアプリケーションロジックで解決している。

# UFW: 典型的なシステムサービス
sudo ufw allow out 123/udp # NTP
sudo ufw allow out 25/tcp # SMTP - メールサーバーの場合のみ
sudo ufw allow out 587/tcp # Submission - 必要な場合のみ

# iptables: 特定の許可
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT

Dockerとファイアウォール：落とし穴の回避

Docker は独自の IPテーブル-私のポリシーに影響を与える可能性のあるルールです。そのため、コンポーザーやデーモンが起動するたびに、NATとFORWARDのチェーンをチェックしている。意図的に公開ポートを解放し、「-p 0.0.0.0:PORT」は避けている。その代わりに、管理IPやリバースプロキシにバインドしている。こうすることで、攻撃ベクトルをより小さく、より見やすくすることができる[1]。

Dockerにもかかわらず、ホストのファイアウォールは有効にしています。また、利用可能であれば、インフラストラクチャレベルでセキュリティグループを制御している。UFWとDockerが競合する場合は、文書化された回避策を使うか、DOCKER-USERでルールを設定します。ホストは常にブロックし、コンテナは明示的にオープンするのみ、というように責任を明確にすることが重要です。この順序によって、無意識のリリースを防ぐことができる。

# DOCKER-USER: Dockerルールの前にグローバルホストポリシーを適用する
iptables -N DOCKER-USER 2>/dev/null || true
iptables -I DOCKER-USER -s 192.0.2.24 -j DROP
iptables -A DOCKER-USER -j RETURN

UFWの細かい設定：シーケンス、プロファイル、ルーティングトラフィック

精度を重視する場合、私は"インサート", "番号"とアプリのプロファイル。このようにして、ルールシーケンスをきれいに保ち、テスト済みのサービス定義を使用している。

# 制御シーケンス
sudo ufw insert 1 deny in from 198.51.100.0/24

# 番号付き表示と対象削除
sudo ufw status numbered
sudo ufw 削除 3

# アプリのプロファイル (Nginx Full など)
sudo ufw app list
sudo ufw app info "Nginx Full"
sudo ufw allow "Nginx Full"

# ルーティングされたトラフィックをデフォルトでブロック（転送）
sudo ufw default deny routed

より複雑な例外は before.ルール それぞれ アフタールール.そこでは、標準ルールの読みやすさを失うことなく、ICMPの微調整やNATを正確に配置することができる。

永続的なルール保存と復元

UFWの規則は しつこい で、自動的にリブートに耐えます。これにより、Debian/Ubuntuホストでの管理が大幅に簡素化される。iptablesでは、変更後にルールを保存し、起動時に復元します。これにはiptables-save/restoreかnetfilter-persistentを使う。これらの手順を踏まないと、再起動後に変更が失われてしまう [5]。

私は持続性を系統的にテストする。再起動をスケジュールし、ステータスをチェックする。カウンターとチェーンが正しければ、コンフィギュレーションはしっかりしている。ルールが欠けていれば、initかsystemdのコンテキストでロードパスを修正する。このルーチンは、メンテナンス中の不測の事態を防ぐ。文書化とルールファイルのバックアップが、この手順の最後を締めくくる。

# Debian/Ubuntu: iptablesの永続化
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save

# 手動バックアップ
sudo iptables-save | sudo tee /etc/iptables/rules.v4
sudo ip6tables-save | sudo tee /etc/iptables/rules.v6

#リストア（必要な場合）
sudo iptables-restore < /etc/iptables/rules.v4
sudo ip6tables-restore < /etc/iptables/rules.v6

パフォーマンスと保護：制限、セット、カーネル・チューニング

負荷が高いときは、コントロールの数を減らし、的を絞った使い方をする。 料金制限.大きなブロックリストについては、ルックアップ時間を短縮するためにipsetを使っている。システムベースの保護メカニズムも使っている：

# SYNフラッドを含む（カーネル）
sudo sysctl -w net.ipv4.tcp_syncookies=1

# ソースIPごとのHTTP接続レートを制限する(例)
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW
  -m hashlimit --hashlimit-name http_rate --hashlimit-above 50/秒
  --hashlimit-burst 100 --hashlimit-mode srcip -j DROP

のサイズを維持している。 コンントラック・テーブル 一目でわかる。同時接続が多い場合は、nf_conntrack_maxを増やすが、事前に効果をテストする。

管理、テスト、エラー防止

私は去る SSH 着信拒否」を有効にする前に。その後、2回目のセッションでアクセスが安定しているかどうかをテストする。ufw status verbose」または「iptables -L -v」で新しいルールをチェックする。これにより、ヒットカウンターを認識し、パケットが期待されるチェーンに着弾しているかどうかを確認することができる。大きな変更をする前に、ファイアウォールのファイルをバックアップしています。

包括的なセキュリティのために、私はファイアウォールとシステムの堅牢化ステップを組み合わせている。これには、安全なSSH設定、パッチ管理、最小限のサービスなどが含まれる。私はチェックリストとして実用的なガイドを使うのが好きだ： Linuxのサーバー強化.私はこれらのチェックを定期的に繰り返し、決まったメンテナンス・ウィンドウを守っている。これにより、私のサーバーは常に安定した状態に保たれています。

高度な検査と観察

外部への影響は ポートスキャン を外部ネットワークから取得し、内部でオープンソケットを検証する。初期段階で誤った結論に気づくために、最初のうちはログを注意深く監視している。

#オープンソケット
ss -lntup

# iptables overview compact
sudo iptables -S
sudo iptables -L -v -n

# UFW: ステータスとログの詳細
sudo ufw status verbose
journalctl -k | grep -i ufw

# 外部チェック (別のホスト/ネットワークから)
nmap -Pn -p 22,80,443  を実行します。

リスクの高い変更については、次のように計画している。 フォールバック・レベル を使っている。私はScreen/Tmuxで作業し、必要であれば、自分自身をロックアウトした場合の時間制御リセットを設定する。テストが成功したら、またフォールバックアクションをキャンセルする。

# 例: 緊急アンカーとしての自動無効化 (使用には注意が必要)
echo "ufw disable" | at now + 2 minutes
# テスト成功後に再度削除: atrm <job-id

ホスティングプロバイダーの比較ファイアウォールの統合に注目

ホスティングについては、私は次のように考えている。 セキュリティ プラットフォームに近い。カスタマイズされたポリシー、素早いルールの展開、そして優れたモニタリングが功を奏している。現在の比較では、webhoster.de はきちんと統合されたファイアウォールオプションと迅速なサポートが印象的だ。パネル・セットアップを好む人には、次のような明確な指示があります。 Pleskファイアウォール.次の表は、主要な基準を分類したものである。

プロバイダ	ファイアウォールの統合	パフォーマンス	サポート	プレースメント
webhoster.de	個別に設定する。	非常に高い	トップ	1
プロバイダーB	スタンダード	高い	良い	2
プロバイダーC	スタンダード	良い	満足	3

実践例テストから本番ルールへ

それぞれのルールセットは スクリーン あるいは2回目のSSHセッションで。そうすることで、操作ミスが発生した場合でも自分を救うことができる。テストホストが正常に動作しているときだけ、本番環境にルールを適用する。リターンパス・ルールとロールバック・プランが、さらなる安全性を与えてくれる。最後に、変更点を変更ログに簡潔に記録する。

SSHを許可する、HTTP/Sを解放する、内部ポートをローカルにバインドする、ログオンする、ICMPを制限する、余計なプロトコルをブロックする。その後、IPv6のミラーリング・ルールに気を配り、ギャップが残らないようにする。Dockerチェーンは独自のパスを設定するため、常に別にチェックしている。最後に、外部チェックとモニタリングでアクセスを検証します。これにより、インターフェイスがクリーンで追跡可能な状態に保たれる[1][2]。

管理者向けまとめ

明確な ルール といくつかのコマンドで、ウェブサーバーを確実にセキュアにしている。デフォルトの着信拒否、SSHファースト、HTTP/Sの有効化 - これが安定した基盤を形成している。データベースのポートはローカルかホワイトリスト経由のみ、ロギングはアクティブ、IPv6の監視、ドッカーチェーンのチェック。永続的なストレージと定期的なテストは、厄介なサプライズを防ぐ。このルーチンはサービスをアクセス可能な状態に保ち、リスクを大幅に軽減する。

UFWを使うにせよiptablesを直接使うにせよ、明確で経済的なポリシーが重要だ。簡潔に文書化し、定期的に検証し、例外を最小限に抑える。アウトバウンドの制限は、不必要な接続を止め、侵害された場合の被害を制限する。ログをよく見ることで、より早く異常を認識し、適切に対応することができます。これにより、ウェブサーバーは回復力を保ち、攻撃対象は小さくなります。