내 네트워크에 있는 잠재적으로 감염될 수 있는 웹 애플리케이션에서 의심스러운 활동을 조사하고 싶습니다. 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 웹 사이트로의 컬 시도가 작동하고 있습니다. 유사한 설정은 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 규칙을 사용하지 않기 때문이라고 생각합니다. 제 경우와 같은 세 번째 호스트입니다.
https 패킷 헤더의 원래 대상 IP를 사용하고 패킷을 수정하기 위해 "스푸핑" 하나 또는 다른 옵션을 삽입하는 솔루션이 오징어에 있는지 알고 계십니까?
통찰력을 가져 주셔서 감사합니다.