ネットワーク上の潜在的に感染する可能性があるWebアプリケーションで疑わしい活動を調査したいと思います。https_portディレクティブでhttpsリクエストを傍受するためにイカを使用したいと思います。
私のネットワーク設定：http / https要求は通常、クライアント側にプロキシを設定せずにゲートウェイホストに送信されます。ゲートウェイでは、iptablesルールを介して元の宛先IP /ポートからプロキシホストにリダイレクトされます。
iptables -t nat -A PREROUTING -p tcp --dport 80 -s CLIENT_IP -j DNAT --to-destination PROXY_IP:3128
iptables -t nat -A PREROUTING -p tcp --dport 443 -s CLIENT_IP -j DNAT --to-destination PROXY_IP:3130
iptables -t nat -A POSTROUTING -d CLIENT_IP -j MASQUERADE
次のオプションを使用して、プロキシサーバーにSquidバージョン4.13をインストールしました。
...
--with-gnutls \
--with-openssl \
--enable-ssl \
--enable-ssl-crtd \
イカの構成：
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet
http_access allow localhost
http_access deny all
http_port 3128
http_port 3129 intercept
https_port 3130 intercept ssl-bump tls-cert=/etc/squid/cert/myCA.pem dynamic_cert_mem_cache_size=16MB generate-host-certificates=on
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/squid/ssl_db -M 16MB
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all
ssl_bump splice all
coredump_dir /var/spool/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
- 今回は、プロキシサーバーに別のリダイレクトルールを追加しました。
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3128 -j REDIRECT --to-port 3129
この固定されたhttpブロックとクライアントからhttp Webサイトへのカールの試みが機能しています。同様の設定はhttpsブロックを変更せず、実際に元のサーバーに到達しませんでした。試してみると、アクセスログの上のイカ設定で次の行を印刷しますcurl -v https://stackexchange.com/。
1692864790.326 5 CLIENT_IP TCP_DENIED/200 0 CONNECT PROXY_IP:3130 - HIER_NONE/- -
1692864790.331 0 CLIENT_IP NONE/403 3791 GET https://stackexchange.com/ - HIER_NONE/- text/html
ポートがhttp_accessルールによって許可されていないために拒否されたことを知っていますが、まったくProxy_ipに移動しないでください。さまざまなssl_bumpディレクティブオプションをテストしましたが、どちらもSSL通信が機能していませんでした。
たとえば、ポート 3130 が許可されるとループが発生します。
1692871715.986 60813 CLIENT_IP NONE/200 0 CONNECT PROXY_IP:3130 - ORIGINAL_DST/PROXY_IP -
1692871715.986 60807 PROXY_IP NONE/200 0 CONNECT PROXY_IP:3130 - ORIGINAL_DST/PROXY_IP -
1692871715.986 60807 PROXY_IP NONE/200 0 CONNECT PROXY_IP:3130 - ORIGINAL_DST/PROXY_IP -
1692871715.986 60807 PROXY_IP NONE/200 0 CONNECT PROXY_IP:3130 - ORIGINAL_DST/PROXY_IP -
1692871715.986 60806 PROXY_IP NONE/200 0 CONNECT PROXY_IP:3130 - ORIGINAL_DST/PROXY_IP -
1692871715.986 60806 PROXY_IP NONE/200 0 CONNECT PROXY_IP:3130 - ORIGINAL_DST/PROXY_IP -
1692871715.986 60806 PROXY_IP NONE/200 0 CONNECT PROXY_IP:3130 - ORIGINAL_DST/PROXY_IP -
1692871715.986 60805 PROXY_IP NONE/200 0 CONNECT PROXY_IP:3130 - ORIGINAL_DST/PROXY_IP -
1692871715.986 60805 PROXY_IP NONE/200 0 CONNECT PROXY_IP:3130 - ORIGINAL_DST/PROXY_IP -
1692871715.986 60805 PROXY_IP NONE/200 0 CONNECT PROXY_IP:3130 -
...
...
https_portリスナーが動作してクライアントが宛先に到達する唯一のケースは、envを使用するときです。クライアント変数：https_proxy=https://PROXY_IP:3130/https_portはデフォルトのフォワードプロキシモード/ ssl-bumpブロック/なしですが、envを使用したくありません。変数を使用するには透明プロキシが必要です。
この問題と質問の私の分析は次のとおりです。
ゲートウェイホストのDNATリダイレクトルールはhttpsパケットの宛先IPを変更し、Squidは元のIPを元の場所にリセットすることはできず、引き続きプロキシIPに送信するため、上記の奇妙なaccess.log履歴が生成されます。 Squidはリダイレクトルールを追加してhttpパケットを変更できますが、httpsは変更できません。
さまざまなフォーラムで同様の質問をたくさん読んで構成を調整してみましたが、問題は解決しませんでした。すべてのチュートリアルでは、クライアントがデフォルトゲートウェイにプロキシに要求を送信するように要求しますが、DNATルールを使用しないためだと思います。私の場合と同じ3番目のホストです。
httpsパケットヘッダーの元の宛先IPを使用し、パケットを変更するために「なりすまし」1つまたは別のオプションを挿入するソリューションがイカにあるかどうかご存知ですか？
洞察力をありがとうございます。