[squid-users] SSL Bump Issue
Ali Jawad
alijawad1 at gmail.com
Mon Mar 7 03:45:46 UTC 2016
Hi Amos
Thanks for the elaborate reply, I highly appreciate it. I did flush
iptables and re-applied from scratch, see :
[root at kgoDcyTx9 ~]# iptables -nL -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 162.220.xx.xx 0.0.0.0/0 tcp dpt:443
ACCEPT tcp -- 162.220.xx.xx 0.0.0.0/0 tcp dpt:80
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
redir ports 3128
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
redir ports 3129
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root at kgoDcyTx9 ~]# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
The problem is I am still getting the same freaking loop : see below
please, any more input to try please ?
The following error was encountered while trying to retrieve the URL:
https://162.220.xx.xx/* <https://162.220.244.7/*>
*Connection to 162.220.xx.xx failed.*
The system returned: *(111) Connection refused*
On Mon, Mar 7, 2016 at 4:57 AM, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> On 7/03/2016 2:50 p.m., Ali Jawad wrote:
> > Hi
> > Pardon me if I am mistaken but isnt it the case that 1 :
> >
> > iptables -t nat -A PREROUTING -p tcp --dport 443 --destination
> > 162.220.xx.xx -j REDIRECT --to-ports 3129
> > The rule above would only match for the IP of squid and squid should be
> > heading to the actual IP of the site in question which is not on the same
> > server
>
> Squid itself is *never* a valid destination IP on intercepted traffic.
> The purpose of the REDIRECT/DNAT is to make it a destination when it did
> not start that way.
>
> If you meant to write " ! --destination", you would be correct. However
> the difficulty you already had in using the '!' correctly is a good
> reason why we dont demo that way. Its just plain difficult for beginners
> to understand whats going on (and some experts even).
>
> Also, the ! mechanism does not cope well with multiple IPs on the Squid
> machine. In the modern Internet every machine in existence always has a
> minimum of between 3 and 6 IPs, maybe more if the admin active assigns
> multiple global IPs. They all need to be excluded for the protection to
> be fully effective.
>
>
> >
> > and 2 :
> >
> > If Squid is intercepting the PREROUTING chain would not apply anymore, as
> > traffic passing through local daemons goes through OUTPUT and POSTROUTING
> > chains
>
> If the packets stayed within the Squid machine that would be right.
> However outgoing packets with Squid IP as the destination can reach the
> switch to which Squid is plugged in and "bounce" right back in through
> all the normal PREROUTING logics. Infinite loop and very much pain
> trying to figure out what is going on.
>
> >
> > As for
> >
> > iptables -t nat -A PREROUTING -s $SQUIDIP -p tcp --dport 80 -j ACCEPT
> >
>
> Both the -s parameter here and the mangle table rule are pre-emptively
> truncating the NAT loop so that the packets end up being routed normally
> instead of diverted into that Squid intercept port. They also
> simultaneously prevent external attacks on the NAT system (and Squid)
> from remote clients.
>
> As mentioned above the --destination way(s) of doing things both does
> not scale to all the IPs on the current machine, and is far less easy
> for beginners to understand. So it is a multiple-win situation to do it
> the way we demo.
>
> >
> > All traffic set to ACCEPT ..thanks !
>
>
> Not all traffic hopefully. Just the stuff outgoing / generated by Squid
> itself :-P
>
> Amos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160307/96825c09/attachment.html>
More information about the squid-users
mailing list