解決策 1:
全般:
ファイアウォール構成を表示および変更するには、管理者権限 (root) が必要です ) 制限されたポート番号範囲でサービスを開くようにします。つまり、 root としてログインする必要があります。 または代わりに sudo を使用します root としてコマンドを実行します。オプションの [sudo] でそのようなコマンドをマークしようとします .
内容:
<オール>-I の違い および -A iptables -L -v -n の出力の解釈 1.順序の問題または -I の違い と -A
覚えておくべきことは、ファイアウォール ルールはリストされている順序でチェックされるということです。パケットまたは接続を許可または禁止するルールがトリガーされると、カーネルはチェーンの処理を停止します。
最もよくある間違いだと思います 初心者のファイアウォール管理者にとって重要なことは、以下のような正しい手順に従って新しいポートを開くことです:
<ブロック引用>
[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT
その理由は -A オプションは、すべての既存のルールの後にその新しいルールを追加します また、既存のファイアウォールの最終的なルールは、明示的に許可されていないすべてのトラフィックをブロックするものであることが非常に多いため、
...
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
8 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
または同等の iptables-save:
...
iptables -A INPUT -j REJECT
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
また、TCP ポート 8080 を開く新しいルールに到達することはありません。 (カウンタが頑固に 0 パケットと 0 バイトのままであることからも明らかです)。
-I でルールを挿入することにより 新しいルールはチェーンの最初のルールであり、機能します。
2.現在のファイアウォール構成を表示
ファイアウォール管理者に私がお勧めするのは、使いやすいツールでファイアウォールの問題を診断しようとするのではなく、Linux カーネルが実行している実際の構成を調べることです。多くの場合、根本的な問題を理解すれば、これらのツールでサポートされている問題で簡単に解決できます.
コマンド [sudo] iptables -L -v -n あなたの友達です (ただし、iptables-save が好きな人もいます) より良い）。 --line-numbers オプションも数行に。ルール #X を参照すると、それらについての議論がいくらか容易になります。
注: NAT ルールは iptables-save に含まれています -t nat を追加して個別にリストする必要があります オプション、つまり [sudo] iptables -L -v -n -t nat --line-numbers .
コマンドを複数回実行してカウンターの増加を確認することは、新しいルールが実際にトリガーされるかどうかを確認するための便利なツールです。
[[email protected] ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 784K 65M fail2ban-SSH tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
2 2789K 866M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 15 1384 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num pkts bytes target prot opt in out source destination
Chain fail2ban-SSH (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 117.239.37.150 0.0.0.0/0 reject-with icmp-port-unreachable
2 4 412 REJECT all -- * * 117.253.208.237 0.0.0.0/0 reject-with icmp-port-unreachable
または iptables-save の出力 上記のファイアウォール構成を再生成できるスクリプトを提供します:
[[email protected] ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT
どちらが理解しやすいかは好みの問題です。
3. iptables -L -v -n の出力の解釈
ポリシー 明示的なルールが一致しない場合にチェーンが使用するデフォルトのアクションを設定します。 INPUT で すべてのトラフィックを受け入れるように設定されているチェーン。
INPUT チェーンの最初のルールはすぐに興味深いルールであり、TCP ポート 22 (tcp dpt:22) 宛てのすべてのトラフィック (送信元 0.0.0.0/0 および宛先 0.0.0.0/0) を送信します。 ) カスタム ターゲットへの SSH のデフォルト ポート (fail2ban-SSH) ). 名前が示すように、このルールは fail2ban によって管理されています (とりわけ、システム ログ ファイルをスキャンして悪用の可能性を探し、悪用者の IP アドレスをブロックするセキュリティ製品)。
そのルールは、iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH のような iptables コマンドラインによって作成されます。 または iptables-save as -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH の出力で見つかります .多くの場合、ドキュメントでこれらの表記のいずれかを見つけることができます。
カウンタは、このルールが 784,000 パケットと 65 メガバイトのデータに一致したことを示しています。
この最初のルールに一致するトラフィックは、fail2ban-SSH によって処理されます。 非標準チェーンとして、OUTPUT チェーンの下にリストされるチェーン。
そのチェーンは 2 つのルールで構成され、ブロックされる (reject-with icm-port-unreachable で ).
-A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable
これらのブロックされたホストからのものではない SSH パケットは、まだ許可も拒否もされておらず、カスタム チェーンが完了すると、INPUT チェーンの 2 番目のルールに対してチェックされます。
ポート 22 宛ではないすべてのパケットは、INPUT チェーンの最初のルールを通過し、INPUT ルール #2 でも評価されます。
INPUT ルール番号 2 は、これがステートフル ファイアウォールであることを意図していることを意味します 、接続を追跡します。これにはいくつかの利点があります。新しい接続のパケットのみを完全なルールセットに対してチェックする必要がありますが、一度許可されると、確立された接続または関連する接続に属する追加のパケットは、それ以上のチェックなしで受け入れられます。
入力ルール #2 は、開いているすべての関連する接続と一致し、そのルールに一致するパケットはそれ以上評価する必要はありません。
注: ステートフル ファイアウォールの構成におけるルールの変更は、新しい接続のみに影響し、確立された接続には影響しません。
対照的に、単純なパケット フィルタは、接続状態を追跡せずに、完全なルール セットに対してすべてのパケットをテストします。このようなファイアウォールでは状態はありません
INPUT ルール #3 は非常に退屈で、すべてのトラフィックがループバック (lo) に接続されます。 または 127.0.0.1) インターフェイスが許可されます。
INPUT ルール 4、5、および 6 は、新しい接続へのアクセスを許可することによって、TCP ポート 22、80、および 443 (それぞれの SSH、HTTP、および HTTPS のデフォルト ポート) を開くために使用されます (既存の接続は INPUT ルール 2 によって既に許可されています)。 /P>
ステートレス ファイアウォールでは、これらのルールは状態属性なしで表示されます:
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
または
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
最後の INPUT ルール #7 は、INPUT ルール 1 ～ 7 でアクセスが許可されなかったすべてのトラフィックをブロックするルールです。かなり一般的な規則:許可されていないものはすべて拒否されます。理論的には、デフォルトの POLICY を REJECT に設定することで、このルールを省略できたはずです。
常にチェーン全体を調査してください。
4.環境を知る
4.1 . ソフトウェア ファイアウォールの設定は、ネットワーク内の他の場所で維持されているセキュリティ設定には影響しません。 iptables でネットワーク サービスを開いているにもかかわらず ネットワーク内のルーターまたはその他のファイアウォールの変更されていないアクセス制御リストは、依然としてトラフィックをブロックする可能性があります...
4.2 . リッスンしているサービスがない場合、ファイアウォールの設定に関係なく、接続できず、接続拒否エラーが発生します。したがって:
- サービスが (正しいネットワーク インターフェイス/IP アドレスで) リッスンしており、
[sudo] netstat -plnutで期待するポート番号を使用していることを確認します。 または代わりにss -tnlpを使用します . - サービスがまだ実行されていない場合は、単純なリスナーをたとえば netcat:
[sudo] nc -l -p 123でエミュレートします。 またはopenssl s_server -accept 1234 [options]TLS/SSL リスナーが必要な場合 (man s_serverをチェック) オプション） - サーバー自体、つまり
telnet <IP of Server> 123から接続できることを確認します またはecho "Hello" | nc <IP of Server> 123または TLS/SSL で保護されたサービスopenssl s_client -connect <IP of Server>:1234をテストする場合 、リモート ホストから同じことを試みる前に。
4.3 . サービスで使用されるプロトコルを理解します。十分に理解していないサービスを適切に有効化/無効化することはできません。例:
- (DNS と同様に) TCP または UDP のどちらを使用していますか?
- サービスは固定のデフォルト ポートを使用していますか (たとえば、ウェブサーバーの TCP ポート 80 など)?
- 代わりに、変更可能な動的ポート番号が選択されていますか?
- 悪名高い FTP は 2 つのポートさえ使用します 、パッシブ モードを使用するように構成されている場合、固定ポート番号と動的ポート番号の両方...
/etc/servicesのサービス、ポート、およびプロトコルの説明 ポートを使用した実際のサービスとは必ずしも一致しません。
4.4 . ネットワーク接続を制限する可能性があるのは、カーネル パケット フィルタだけではありません:
- SELinux がネットワーク サービスを制限している可能性もあります。
getenforceSELinux が実行されているかどうかを確認します。 - やや不明瞭になってきていますが、TCP ラッパーは依然としてネットワーク セキュリティを強化するための強力なツールです。
ldd /path/to/service |grep libwrapで確認してください そして/hosts.[allow|deny]制御ファイル
5. INPUT または FORWARD チェーン
チェーンの概念については、こちらで詳しく説明していますが、簡単に説明すると次のとおりです。
INPUT chain は、iptables コマンドを発行するホスト上で、ローカルで実行されているサービスのネットワーク ポートを開閉する場所です。
FORWARD チェーンは、Linux マシンがブリッジ、ルーター、ハイパーバイザーとして機能している場合、および/またはネットワーク アドレス変換を行っている場合に、カーネルによって他のシステム、実際のシステムだけでなく、Docker コンテナーおよび仮想ゲスト サーバー サーバーに転送されるトラフィックをフィルター処理するルールを適用する場所です。とポート転送。
よくある誤解は、docker コンテナーまたは KVM ゲストがローカルで実行されるため、適用されるフィルター規則は INPUT チェーンにあるはずですが、通常はそうではありません。
6.カーネル モジュール
パケット フィルターは Linux カーネル内で実行されるため、実際には複数のモジュールを動的モジュールとしてコンパイルすることもできます。ほとんどのディストリビューションにはモジュールとして netfilter が含まれており、必要な netfilter モジュールは必要に応じてカーネルにロードされますが、一部のモジュールについては、ファイアウォール管理者が手動で確実にロードされるようにする必要があります。これは主に、nf_conntrack_ftp などの接続追跡モジュールに関係します。 insmod でロードできます .
実行中のカーネルに現在ロードされているモジュールは lsmod で表示できます .
再起動後もモジュールが永続的にロードされるようにする方法は、Linux ディストリビューションによって異なります。
解決策 2:
iptables/ファイアウォール「はじめに」
ファイアウォールは、基本的にポリシーベースのネットワーク フィルターです。 Linux ファイアウォールは、Netfilter を中心に構築されています。特定のタスクを実行するいくつかのカーネル モジュールで構成されるカーネルのネットワーク パケット処理フレームワーク:
<オール>ユーザーは、コマンド ラインから iptables を使用して、ファイアウォールのニーズに合わせて Netfilter フレームワークを構成します。 iptables を使用して、IP パケットが Linux ボックスに到着、通過、または送信されるときにカーネルにその処理を指示するルールを定義します。Netfilter の各メイン プロセスは、iptables 用語集のテーブル (FILTER、NAT、MANGLE) で表されます。それらは、ネットワーク パケット フロー マップ上にいくつかの特定のフック ポイントを持ち、カーネルによって呼び出されてその役割を実行します。TABLE 呼び出しの特定の場所にあるシーケンスは、一般的に組み込みチェーンと呼ばれ、PREROUTING、INPUT、FORWARD、OUTPUT、などの名前が付けられます。 TABLE を「プロセスのタイプ」に関連付け、CHAIN をネットワーク パケット フロー マップ上でそれらのプロセスのインスタンスが呼び出される「場所」に関連付けると、覚えやすくなります。
IP パケットはネットワーク インターフェイスで受信されるか、ローカル プロセスによって作成されるため、最終的に配信または破棄されるまで、Netfilter エンジンはネットワーク パケット フロー マップに含まれるルールを順次テストして適用します。 [email protected] ペアで識別される各ブロックで、ユーザーは、IP パケットの一致基準と対応する一連のアクションを含むこれらの連続したルールを 1 つ以上追加できます。複数の TABLE で実行できるアクション (ACCEPT、DROP など) と、TABLE 固有の他のアクション (SNAT、DNAT など) があります。
つまり、IP パケットがネットワーク インターフェイスから到着すると、最初に PREROUTING チェーンによって処理され、MANGLE テーブルのユーザー定義ルールがあればそれを呼び出します。現在のパケットに一致するルールがない場合、対応する [email protected] のデフォルトの行動方針または「ポリシー」が適用されます。この時点でパケットがドロップされなかった場合、プロセスは続行され、PREROUTING チェーン (マップを参照) などで NAT テーブルのルールが呼び出されます。ルールのレイアウトを容易にするために、ユーザーは独自のカスタム チェーンを作成することもできます。そして、彼らが望むように、マップのさまざまなポイントから彼らに「ジャンプ」します。
組み込みのチェーンは、ACCEPT または DROP パケットのユーザー定義ポリシーを持つことができますが、ユーザー定義チェーンには常に、プロセスを続行するための呼び出し元への RETURN の変更不可能なデフォルト ポリシーがあります。
iptables コマンド
iptables のメイン コマンドは、ネットワーク パケット フロー マップに必要な処理ルールを設定します。
一般的な iptables ルールは次のように記述できます:
# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>
次のように読むことができます:
<ブロック引用>
Netfilter (kernel module) please <Add/Insert/Delete> this rule for <table> at <CHAIN> where packets matching <PKT_MATCHING_CRITERIA> have to be <ACTION>ed
<table>
-t filter (the filter table is assumed when omitted)
-t nat
-t mangle
<Add/Insert/Delete>
-A (append rule at the end of the chain list)
-I (insert rule at the begining of the chain list)
-D (Delete rule)
<CHAIN>
PREROUTING
INPUT
FORWARD
OUTPUT
POSTROUTING
USER_DEFINED_CHAIN
<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
-i [!] <if_name> or --in-interface [!] <if_name>
(OUTPUT and POSTROUTING chains cannot match on input interfaces)
-o [!] <if_name> or --out-interface [!] <if_name>
(INPUT and PREROUTING chains cannot match on output interfaces)
-mac-source [!] <xx-xx-xx-xx-xx-xx>
(OUTPUT and POSTROUTING chains cannot match on input interfaces)
ISO Level-3 matching:
-s [!] <src_ip> or --src [!] <src_ip> or --source [!] <src_ip>
-d [!] <dst_ip> or --src [!] <dst_ip> or --destination [!] <dst_ip>
ISO Level-4 matching:
-p [!] <prot_name> or --protocol [!] <prot_name> (udp|tcp|icmp)
Also available when ICMP protocol is defined
--icmp-type [!] <icmp_type>
Also available when UDP protocol is defined
--source-port [!] <udp_src_port> or --sport [!] <udp_src_port>
--destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>
Also available when TCP protocol is defined
--source-port [!] <tcp_src_port> or --sport [!] <tcp_src_port>
--destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
--tcp-flags [!] <tcp_flags> (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
--syn
--tcp-option [!] <tcp_option#>
--state [!] <state>
-m <match> [options]
note: [!] = negation operator
<ACTION> (also called TARGET)
-j ACCEPT (process continues with rules of the next table in map)
-j DROP (discard current packet)
-j REJECT (discard current packet with ICMP notification)
option:
--reject-with <reject_type>
-j USER_DEFINED_CHAIN (start traversing USER_DEFINED_CHAIN rules)
-j RETURN (return from USER_DEFINED_CHAIN)
-j LOG (log to syslog, then process next rule in table)
options:
--log-level <level>
--log-prefix <prefix>
--log-tcp-sequence
--log-tcp-options
--log-ip-options
--log-uid
nat table specific
-j SNAT (rewrite the source IP address of the packet)
option:
--to <ip_address>
-j SAME (idem SNAT; used when more than one source address)
options:
--nodst
--to <a1-a2>
-j MASQUERADE (idem SNAT; used when the replace IP is dynamic)
-j DNAT (rewrite the destination IP address of the packet)
option:
--to <ip_address>
-j REDIRECT (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
option:
–-to-port <port#>
mangle table specific
-j ROUTE (explicitly route packets, valid at PREROUTING)
options:
--iface <iface_name>
--ifindex <iface_idx>
-j MARK (set Netfilter mark values)
options:
--set-mark <value>
--and-mark <value>
--or-mark <value>
-j TOS (set the IP header Type of Service field)
option:
--set-tos <value>
-j DSCP (set the IP header Differentiated Services Field)
options:
--set-dscp <value>
--set-dscp-class <class>
-j TTL (set the IP header Time To Live field)
options:
--ttl-set <value>
--ttl-dec <value>
--ttl-inc <value>
iptables 補助コマンドは、デフォルトの条件の設定、ルールの一覧表示、ルールのフラッシュなどのシナリオを完了します。
#iptables -t <table> -L
(Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>
(Lists the <table> rules in <CHAIN>)
#iptables -t <table> -N <CHAIN>
(Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>
(Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)
#iptables -t <table> -X
(Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
(Deletes user-defined <CHAIN> created for holding <table> rules)
#iptables -t <table> -P <CHAIN> <ACTION> where <ACTION> = ACCEPT|DROP
(Sets the default policy of <table> rules at <CHAIN> to <ACTION>)
#iptables -t <table> -F
(Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
(Flushes (deletes) all <table> rules in <CHAIN>)
#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
(Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>
iptables は、実行時にコマンドを Netfilter エンジンに読み込みます。Netfilter は、読み込まれたルールと設定をすぐに適用しますが、永続的ではありません。再起動すると、以前にロードされたすべての Netfilter ルールと設定が失われます。このため、現在アクティブなルールセットをファイルに保存し、後で再ロードできる iptables ユーティリティがあります。
#iptables-save > fileName
(Save the currently active Netfilter ruleset to fileName)
#iptables-restore < fileName
(Restore Netfilter ruleset to the one saved in fileName)
iptables のまとめ
Netfilter は非常に柔軟で強力なフレームワークですが、それには代償があります。 iptables は複雑です。ユーザーの観点から見ると、TABLE、CHAIN、TARGET などの特定の用語は、それらが表す概念とあまりよく一致せず、最初はあまり意味がありません。トピックは長く、コマンドにはパラメーターの無限のリストがあるようです。さらに悪いことに、Iptables を完全にマスターした本は 1 冊もありません。ほとんどの場合、「レシピ本」または「マンページ本」の 2 つのカテゴリに分類されます。この紹介で、Netfilter/Iptables のランドスケープのスナップショットに加えて、事前に消化されたマンページの必要量が得られると思います。 iptables を初めて使用する場合は、これらの段落を数回読むと、iptables の例を読む準備が整います。少し練習すれば、すぐに独自のルールを作成できるようになります。
ファイアウォール
ファイアウォールは主に、一連のルールに基づいてネットワーク トラフィックを動的に許可または拒否するように設計されています。この時点で、なぜ Linux の Netfilter/Iptables フレームワークがファイアウォールの構築に最適なのかを理解するのは簡単です。 IP 送信元アドレス、IP プロトコル (UDP/TCP)、宛先ポート (80、21、443 など) などに基づいて、特定の IP パケットを受け入れるか、拒否するか、単にドロップするかを決定できます。これは、Web サーバーを不正なネットワーク要求から保護するときに、ファイアウォールが 80% の時間で行うことです。残りの 20% の時間は、ネットワーク パケットの操作 (NAT、MANGLE) です。
ファイアウォールのシナリオ
さまざまなニーズに対応する何百もの異なるファイアウォール レイアウトがありますが、そのうちの 3 つは最も典型的なファイアウォール シナリオと見なすことができます。
<オール>
私はこれを以下のために書きました:http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html
解決策 3:
さまざまなプロトコルでよくある問題
DNS: DNS はデフォルトでポート 53 UDP を使用しますが、単一の UDP データグラムに収まらないメッセージは、代わりに TCP を使用して送信されます (通常はゾーン転送など)。ネームサーバーを実行するときにポート 53 TCP も開く必要があります。 /P>
メール: 多くの消費者向け ISP は SMTP トラフィック (または少なくともデフォルトのポート TCP 25) をブロックしているため、電子メールを直接受信または送信することができず、顧客はすべての送信電子メールに ISP の SMTP リレーを使用することを余儀なくされ、場合によっては受信電子メールにも同様に使用する必要があります。 §1.1.
FTP: 2 という点で、FTP は奇妙なプロトコルです。 接続が使用されます。 1 つ目は制御接続です。デフォルトでは、FTP サーバーは TCP ポート 21 をリッスンします。制御接続は、認証とコマンドの発行に使用されます。実際のファイル転送やディレクトリ リストの出力などは、2 番目の TCP 接続、DATA 接続を経由します。 .アクティブ FTP では、DATA 接続は TCP ポート 20 から FTP サーバーから開始され、FTP クライアントに接続されます。アクティブ FTP は、ファイアウォールや NAT ゲートウェイの背後にあるユーザーではうまく機能しないため、ほとんどの FTP サーバーは使用されなくなりました。代わりにパッシブ FTP をサポートします。パッシブ FTP を使用すると、FTP サーバーは 2 番目のポートで DATA 接続のリスナーを開き、そこに FTP クライアントが接続できます。ファイアウォールの問題は、DATA ポートが 1024 から 65536 の間の使用可能な非特権ポートである可能性があることです。
ステートレス ファイアウォールでは、通常、FTP サーバーが割り当てるパッシブ ポートの数を制限し、それらのポートを明示的に開くことによって解決されます。つまり
iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT
ステートフル ファイアウォールでは、DATA ポートを明示的に開く必要はありません。netfilter ヘルパー モジュールは、割り当てられた動的ポートを認識し、DATA 接続を RELATED としてマークすることにより、正しいクライアントに対してそのポートを動的に開きます。 その後、一般的なルールに一致します:
iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT
これには、正しいカーネル モジュールが必要です FTP の場合は、手動で insmod nf_conntrack_ftp を実行してロードされます。 、再起動後も永続的な依存関係を作成するかどうかは、ディストリビューションによって異なります。
注: 制御接続が暗号化され、nf_conntrack_ftp が PASV 応答を読み取ることができなくなるため、SSL で FTP を使用すると、FTP 接続追跡モジュールは失敗します。
NFS および同様の RPC サービス: RPC サービスの問題は、設計上、特定の固定ポートを使用しないことです。使用可能な任意のポートをランダムに選択でき、RPC Portmap デーモンに登録されます。接続しようとするクライアントは、Portmap デーモンに問い合わせてから、正しいポートに直接接続します。これにより、予約済みポートが不足するという問題が解決されました...
ファイアウォールの観点からは、TCP/UDP ポート 111 と、RPC サービスが現在使用している実際のポートを開く必要があります。ファイアウォールでこのようなランダムなポートを開く問題は、通常、NFS などの RPC サービスを制限することで解決されます。サーバー、事前定義された固定ポートを使用します。