web-dev-qa-db-ja.com

iptablesファイアウォールは、送信元ポート80が許可されている場合にのみインターネットトラフィックを許可します

現在、httpおよびhttpsトラフィックを許可するためだけにiptablesファイアウォールを構成しています。それは機能していますが、特に奇妙なルールの下で-私は80の送信元ポートでの着信接続を許可する必要があります。

着信トラフィックの宛先ポートを80にするべきではないので、それは私には意味がありません。

以下は私の設定の例です。ポート80での着信トラフィックを許可するルールを削除すると、Googleなどにアクセスできなくなり、ルールをアクティブにするとすべて機能します。 Webサーバーはこのポートでリッスンし、ランダムなポートから送信するべきではありませんか？

# Set all major commands to DROP by default
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Allow HTTP and HTTPS
# Need to consider limiting to ESTABLISHED, RELATED for OUTPUT
# consider NEW for INPUT
# configure source ports in range 1024:65535

iptables -A INPUT -i eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m multiport --sports 80,443 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT

# ping from inside to outside
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

# allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Outbound DNS
iptables -A OUTPUT -p udp -o eth0 --dport 53 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --sport 53 -j ACCEPT

# Logging before Drop for troubleshooting
iptables -A INPUT -j LOG
iptables -A INPUT -j LOG
portiptables
3
Rob

Webサーバーがランダムなポートからの要求に応答した場合、OSはそのトラフィックをブラウザーに送信することをどのように認識しますか？

一般的には、次のように機能します。

  1. ブラウザはサーバーへの発信接続を確立しようとしているため、OSにソケットを要求します。
  2. ブラウザが何か変なことをしているのでない限り、取得したソケットがあなたの側でどのポートを使用しているかは気にしないので、OSはランダムに空きポートを割り当てます。
    • この例では、ランダムなブラウザ側のポートとして53904を使用します。
  3. ブラウザは、このソケットをサーバーのIP（通常はDNSによって検出されます）およびリスニングポート（通常はプレーンテキストHTTPの場合は80、HTTPSの場合は443、場合によってはURLで指定されているもの）に接続するようにOSに要求します。
    • この例では、ポート80を介してプレーンテキストHTTPを実行していると想定します。
  4. OSは、指定されたブラウザの宛先にTCP接続（SYN）要求を送信します。詳細は次のとおりです。送信元IP：ネットワークインターフェイスのIP;送信元ポート：53904;宛先IP ：サーバーのIP;宛先ポート：8。
  5. TCPリクエストは、ユーザーとサーバーの間のネットワークを介してルーティングされます。
    • ネットワークアドレス変換（NAT）は、送信元IP（ルーターのIP）とポート（ルーターが受信した元の接続にマップするランダムなもの）を変更する場合がありますが、宛先には影響しません。
    • NATを実行するルーターは、新しい「送信元」ポートでリッスンし、応答トラフィックをコンピューターの元の要求への応答に変換します。
    • 簡単にするために、この例ではこれ以上NATには入りません。あなたのアドレスとサーバーの両方が公に一意であると仮定します-ルーティング可能なIP。
  6. 要求はサーバーのポート80（または443など）に到着します。 Webサーバープロセスは、サーバーのOSに、そのポートでの着信TCP接続をacceptしたいことをすでに伝えています。
  7. サーバーのOSは、応答として確認応答（SYN-ACK）を作成して送信します。送信元と宛先が逆になっていることを除いて、着信パケットと同じ詳細を持っている必要があります：送信元IP：サーバーのIP;送信元ポート：80;宛先IP：あなたのIP;宛先ポート：53904。
  8. この応答は、インターネットを介してコンピュータに戻り、OSはそのIPアドレスからポート53904でSYN-ACKを取得するかどうかを確認します。
    • 「シーケンス番号」や「確認番号」と呼ばれるものもあります。これらは、接続が想定されている接続であることを確認し、他のコンピューターが通信しようとしているサーバーであると偽造するのを防ぐために使用されます。
    • もちろん、サーバーの偽造（なりすまし）に対するこの保護は、攻撃者が送信しているトラフィックを監視/傍受できない場合にのみ機能します。 HTTPSにセキュリティを追加するSSL/TLSの重要な部分は、サーバーを認証するためのより堅牢なメカニズムです。
  9. OSはSYN-ACKを取得し、独自のACKで応答して、ソースと宛先を再度逆にします（または、元のソースと宛先を再利用します。同じことです）。
  10. 接続が両側で確認されると、OSは、ソケットを介してデータを送信できるようになったことをブラウザに通知します。
  11. サーバーのOSは、マシンの確認応答を受信し（そしてシーケンス番号を確認し）、Webサーバーソフトウェアが使用するための新しいソケットを作成します。このソケットは、完了したばかりのTCP接続のトラフィックを通信するために使用され、サーバーのIPのポート80とIPのポート53904にバインドされます; 両方とも受信しますポート8でデータを送信し、そこからデータを送信します。

そこから、ブラウザとWebサーバーはそのTCPチャネルを介して互いにHTTPを話します。ただし、その詳細については説明しません。これはすべて、理由を説明するためだけのものです。サーバーからHTTP応答を取得できるようにする場合は、サーバーのポート80から発信されたインバウンドパケットをファイアウォールで許可する必要があります。

2
CBHacking

あなたが書く

..ポート80での着信トラフィックを許可するルールを削除すると、Googleやその他のものにアクセスできなくなり、ルールをアクティブにするとすべて機能します。 Webサーバーはこのポートでリッスンし、ランダムなポートから送信するべきではありませんか？

いいえ。www.google.comはポート80からランダムなポートに送信します。

同様に、実行するWebサーバーは、ポート80でリッスンするだけでなく、送信元ポートが80のパケットを送信します。

そしてもちろん、あなたのウェブサーバーはグーグルウェブサーバーと通信していません。

したがって、Webサーバーにアクセスする人は誰でも、ランダムなポートを開いてしまいます。

そして、あなたがグーグルにアクセスするとき、あなたはあなたの端を開くランダムなポートを持っています。

あなたの混乱は、INPUTが特に「着信接続」とは関係がないことに気付いていないことです。発信接続から着信するパケットを含む、着信するすべてのパケットです。

したがって、サーバーはポート80と443でリッスンします

私は専門家ではありませんが

「完璧なルールセットに向けて」で説明されているように（またはそれを指す人が使用するように）、共通のセットアップを提供します。

http://inai.de/documents/Perfect_Ruleset.pdf

-すべてを許可する

-すべての確立された関連するものを許可します（関連するものには、FTPが必要とする古いプロトコルなどの新しい接続が含まれます-FTPを使用しているわけではありません。ICMPエラーが含まれます）

-サーバーポートへのすべてのパケットを許可します。

だからあなたのポリシーは

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

-m conntrackの使用は、--ctstateおよび-m stateおよび--stateよりも新しいです。

そして、ポリシーに加えて、あなたのルールは

iptables -A INPUT -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT 

iptables -A INPUT -p tcp -m multiport --sports 80,443 -j ACCEPT

また、あなたが使用し、フォームに合わせて上記で書いたスタイルはコマンドラインスタイルですが、iptablesスクリプトを使用する方がプロフェッショナルだと言う人もいるかもしれません。そして、行はiptables -Ainputではなく-Ainputを読み取ります。そして、iptables-save> fileとiptables-restore <file。

1
barlop

ポート80と443を処理する2つのルール、つまりHTTPが本当に必要です。トラフィックは常にポート80で伝送されますが、2つのルールが必要です...最初のルールでは、リモートページのリクエストを送信できます... 2番目のルールでは、そのリクエストの応答（目的のHTTPサーバーによって送信されます）が返されますお使いのブラウザに。

これらはルールです

iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m multiport --sports 80,443 -m state --state RELATED,ESTABLISHED -j ACCEPT

このルールを消去する必要があります

iptables -A INPUT -i eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT
0
Pat

また、必要なもの：

iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT

また、DNS応答のルールは、実際の応答に制限する必要があります。

iptables -A INPUT -p udp -i eth0 --sport 53 -m state --state ESTABLISHED -j ACCEPT
0
Timothy Baldwin