web-dev-qa-db-ja.com

OpenWrtでiptablesチェーン構成を理解する方法

これは、OpenWrt（ルーターデバイス用の簡素化されたLinux）を実行している一般的なホームルーターのiptablesデフォルト構成にあるチェーンを理解する方法についてです。しかし、これは最終的にはその特定のシステムに固有ではない可能性があります。

ここではINPUTメインチェーンに焦点を当て、同じ テーブルからのFORWARDとOUTPUTを無視しましょう 、およびPREROUTINGテーブルのPOSTROUTINGとnat。

iptables -L -t filterを実行すると、多数のルールが表示されます。以下の出力を再配置して、威圧感を少なくし、理解を妨げる部分を特定しようとしています。

filterテーブルには3つの組み込みチェーンがあり、出力の上部に表示されます。 （-vを指定したのは、 混乱が少ない であることがわかったためです。）

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1260  133K ACCEPT     all  --  any    any     anywhere             anywhere            ctstate RELATED,ESTABLISHED
    8   544 ACCEPT     all  --  lo     any     anywhere             anywhere
  787 41632 syn_flood  tcp  --  any    any     anywhere             anywhere            tcp flags:FIN,SYN,RST,ACK/SYN
13012 1249K input_rule  all  --  any    any     anywhere             anywhere
13012 1249K input      all  --  any    any     anywhere             anywhere

Chain FORWARD … # not considering this chain here
Chain OUTPUT …  # not considering either

ご覧のとおり、FORWARDに焦点を合わせるために、OUTPUTとINPUTから参照されているチェーンを切り取りました。 （他の2つは同様の方法で構築されているため、いずれかを選択できます。）

INPUTにはACCEPTのポリシーがあり、5つのルールを指定します。最初の3つは私には明らかです。まず、「確立された」または「関連した」ものを受け入れます。 （たとえば、私が行ったHTTPまたはDNS要求からの応答を受け入れます。）次に、ループバックデバイス（127.0.0.1）に送られるすべてのものを受け入れます。 （これはローカルホスト自体からのみ発生する可能性があり、それを機能させたいと思います。それ以外の場合は意味がありません。）3番目に、synflood保護を使用します。 （特定の種類の攻撃から保護します。）

Chain syn_flood (1 references)
 pkts bytes target     prot opt in     out     source               destination
  787 41632 RETURN     tcp  --  any    any     anywhere             anywhere            tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50
    0     0 DROP       all  --  any    any     anywhere             anywhere

しかし、次に、inputとinput_ruleという2つのチェーンに分岐する2つのルールがあります。問題は、なぜ2つあるのか、そしてどちらを何に使用するのかということです。

それらのルールのジャンプスタックをドリルダウンしてみましょう。

Chain input_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination

ここにはまだ何もありません。ルールを追加するためのものです。しかし、どのようなルールですか？

Chain input (1 references)
 pkts bytes target     prot opt in     out     source               destination
 6315  482K zone_lan   all  --  br-lan any     anywhere             anywhere
 6697  767K zone_wan   all  --  pppoe-wan any     anywhere             anywhere

さて、これには何かがあり、LANとWANにさらにジャンプします。これは、ホームルーターにとって意味があります。

Chain zone_lan (1 references)
 pkts bytes target     prot opt in     out     source               destination
 6315  482K input_lan  all  --  any    any     anywhere             anywhere
 6315  482K zone_lan_ACCEPT  all  --  any    any     anywhere             anywhere

Chain zone_wan (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere            udp dpt:bootpc
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            icmp echo-request
 6697  767K input_wan  all  --  any    any     anywhere             anywhere
 6697  767K zone_wan_REJECT  all  --  any    any     anywhere             anywhere

ご覧のとおり、これらのルールはそれぞれ、スタックをさらに下って、よりユーザー定義のルールにジャンプします。

Chain input_lan (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain zone_lan_ACCEPT (2 references)
 pkts bytes target     prot opt in     out     source               destination
    4  1322 ACCEPT     all  --  any    br-lan  anywhere             anywhere
 6315  482K ACCEPT     all  --  br-lan any     anywhere             anywhere

input_lanの目的は何ですか？もう1つはおそらくパケットを受け入れることですが、不思議に思います…INPUTのポリシーはACCEPTなので、なぜここでACCEPTを繰り返すのでしょうか。

さて、WANからの入力。上にスクロールすると、UDPおよびICMPのものが受け入れられていることがわかります。これはDHCP用であり、基本的にはpingです。それだけは明らかです。繰り返しになりますが、あまり明確ではないのは、これらのルールに従った部分的に空のものです。

Chain input_wan (1 references)
 pkts bytes target     prot opt in     out     source               destination

input_lanと同じ質問。

Chain zone_wan_REJECT (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 reject     all  --  any    pppoe-wan  anywhere             anywhere
 6697  767K reject     all  --  pppoe-wan any     anywhere             anywhere

さて、それはWAN（確立または関連していない）からの入力です、そしてはい、おそらくそれを拒否したいと思います、そして今ここで2種類の拒否があります、1つはソケットを閉じます（tcp-reset） TCP接続の試行、およびICMPメッセージのICMP応答（icmp-port-unreachable）を介した別の試行（pingを考えてください）の場合。

Chain reject (5 references)
 pkts bytes target     prot opt in     out     source               destination
  595 31817 REJECT     tcp  --  any    any     anywhere             anywhere            reject-with tcp-reset
 4858  582K REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-port-unreachable

この最後のものはキャッチオールです。したがって、ここでは何も受け入れられません。

最後に、filterテーブルの組み込みのINPUTチェーンから参照されていない、netテーブルにある他のチェーンのリストを次に示します。完全を期すため、そしてそれらが類似の構造を持っているように見えることを確認するためです。

# other chains, not reached from the INPUT chain, so truncated and moved here
Chain forward (1 references)
Chain forwarding_lan (1 references)
Chain forwarding_rule (1 references)
Chain forwarding_wan (1 references)
Chain nat_reflection_fwd (1 references)
Chain output (1 references)
Chain output_rule (1 references)
Chain reject (5 references)
Chain zone_lan_DROP (0 references)
Chain zone_lan_REJECT (1 references)
Chain zone_lan_forward (1 references)
Chain zone_wan_ACCEPT (2 references)
Chain zone_wan_DROP (0 references)
Chain zone_wan_forward (1 references)

非常にうまく。この長い投稿でごめんなさい。途中でいくつか質問がありました。これをもっと簡単に、またはもっと短くする方法がわかりません。このiptables構成は、あちこちに不明確な詳細が広がっているため、正確に把握するのは簡単ではありません。これを明確にし、根本的な理論的根拠を説明できることを願っています。ご清聴ありがとうございました。

iptablesopenwrtrouter
4
Lumi

私の知る限り、ファイアウォールはopenwrtの高レベルの構成ファイルから生成されます。多くの異なる可能性をサポートする必要があるため、実際に生成されるルールは最適化されておらず、したがって、不要/未使用/空のチェーンが含まれている可能性があります。詳細については、OpenWRTの wiki記事 を参照してください。

あなたの質問のいくつかに答えるために

  • 「input_rule」が空である理由

    あなたが言ったように、それはユーザーがカスタムルールを簡単に挿入できる場所かもしれません。もう1つの可能性は、「input」が元々「input_rule」であり、「input_rule」が古いスクリプトとの下位互換性のためにまだ作成されていることです。

  • Input_lan/input_wanの目的は何ですか？

    そこで、LAN上の内部ホストからルーターへのトラフィックをブロックしたり（たとえば、構成インターフェースを保護するために）、外部からのアクセスを有効にしたりできます。

  • INPUTのデフォルトはACCEPTですが、なぜここでACCEPTを繰り返すのですか？

    お気づきのとおり、ここでは必要ありません。しかし、zone_lan_REJECTが存在するため、スクリプトはポリシーから独立したいと考えているようです。

1
jofel

これは関心の分離です。 WANへのアクセスとLANからのアクセスのルールは、LANのルールとは異なる必要があります。

デフォルト構成では、ネットワークで必ずしも提供されていないサービスの受け入れルールは提供されません。通常、ほとんどのユーザーはインターネットにサービスを提供しないでください。適切なルールセットに適切なルールを追加すると、サービスが有効になります。 OpenWrt Webインターフェースは、ドロップダウンを介して支援を提供する必要があります。

Shorewall Basic Two-Interace Firewall のドキュメントは、何が起こっているのか、何が起こっているのかをよく理解しているはずです。 OpenWrtファイアウォールをShorewall-liteファイアウォールに置き換えることは可能ですが、基本的なファイアウォールの場合は既存のファイアウォールで十分です。一部のパッケージは、デフォルトのファイアウォールで動作していると想定し、動作していない場合は動作します。

2
BillThor

私は このタスクのための正確なツール を書きました。再フォーマットしますiptables -S適用されているチェーンのツリーに出力します。

その出力を分析することにより、私は_ruleチェーンは、手動で追加されたルールを対象としています。

このツールは、ルールの診断にも役立ちます。ルールカウンターをリセットし、ネットワークテストを行ってから、パケットカウンターを出力にフィードすると、テストトラフィックがツリー内でどの方向に進んだかを確認できます。

1
ivan_pozdeev

私はjofelに同意します。

input_rule、input_lan、およびinput_wanは、古いスクリプトとの下位互換性のためのものです。

新しいUCIへのより良いパケット統計のために、zone_lanにあなたのルールを置いてください、そして、zone_wanはより良いはずです。また、zone_lan_acceptは、おそらくインパケットカウントとアウトパケットカウントに使用されます。

0
Flyingfish

実際、openwrtiptablesのルールはよく整理されています。

たとえば、delegate_inputを取り上げます（他のチェーンも同様の構造です）。

  • 2つのACCEPT：loおよびtcp RELATED、ESTABLISHEDトラフィックを受け入れます
  • syn_flood：synフラッドトラフィックをドロップします
  • input_rule：LANトラフィックとWANトラフィックの両方からの入力を処理します
  • zone_lan：lanからの入力のみを処理し、一致しないトラフィックを受け入れます
  • zone_wan：wanからの入力のみを処理し、一致しないトラフィックを拒否します
0
flz