More host header forgery pain with peek/splice

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

More host header forgery pain with peek/splice

Steve Hill

This one just seems to keep coming up and I'm wondering how other people
are dealing with it:

When you peek and splice a transparently proxied connection, the SNI
goes through the host validation phase.  Squid does a DNS lookup for the
SNI, and if it doesn't resolve to the IP address that the client is
connecting to, Squid drops the connection.

When accessing one of the increasingly common websites that use DNS load
balancing, since the DNS results change on each lookup, Squid and the
client may not get the same DNS results, so Squid drops perfectly good
connections.

Most of this problem goes away if you ensure all the clients use the
same DNS server as squid, but not quite.  Because the TTL on DNS records
only has a resolution of 1 second, there is a period of up to 1 second
when the DNS records Squid knows about doesn't match the ones that the
client knows about.  The client and squid may expire the records up to 1
second apart.

So what's the solution?  (Notably the validation check can't be disabled
without hacking the code).

--
  - Steve Hill
    Technical Director
    Opendium    Online Safety / Web Filtering    http://www.opendium.com

    Enquiries                 Support
    ---------                 -------
    [hidden email]        [hidden email]
    +44-1792-824568           +44-1792-825748
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: More host header forgery pain with peek/splice

reinerotto
Hack the code. Because it is even worse, as firefox for example does not obey to the TTL.
Reply | Threaded
Open this post in threaded view
|

Re: More host header forgery pain with peek/splice

Amos Jeffries
Administrator
On 26/08/2016 6:34 a.m., reinerotto wrote:
> Hack the code. Because it is even worse, as firefox for example does not obey
> to the TTL.
>

It is not that simple. The checks are there for very good reason(s)
related to security of the network using the proxy.

The Host forgery issue being checked for allows network firewall rule
bypass, browser same-origin bypass, and browser sandbox bypass - in a
way which places the attacker in control of what logs you see [aha!
invisible access to the network]. With all the related nasty
side-effects those allow. There is both malware and services for sale
around the 'net that take advantage of the attack to do those bypasses.
=> Simply disabling the check code is a *very* risky thing to do.


The cases where Squid still gets it wrong are where the popular CDN
service(s) in question are performing DNS actions indistinguishable to
those malware attacks. If Squid can't tell the difference between an
attack and normal DNS behaviour the only code change possible is to
disable the check (see above about the risk level).


FYI: I have a plan to reduce the false-positive rate from DNS rotation
effects. But that requires some deep redesign of the DNS code, which I'm
intending to do as part of the Squid-5 roadmap to avoid further
destabilizing 4.x while its in beta.

For now the workarounds are:

* obey the requirement that destination NAT (if any) is performed only
on the Squid machine.

* to tune the lifetime for persistent client connections. That reduces
(but not fully) connections outliving DNS rotation times and thus
causing requests to have different ORIGINAL_DST from what DNS says.

* if wanting Google 8.8.8.8 service as your resolver. Use a local DNS
recursive resolver shared by Squid and client which points to that
service as its parent/forwarded resolver. That removes the issue with
every 8.8.8.8 response having different reply IP values (so client and
Squid doing near simultaneous lookups get different IPs).

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: More host header forgery pain with peek/splice

Amos Jeffries
Administrator
In reply to this post by Steve Hill
On 26/08/2016 4:17 a.m., Steve Hill wrote:

>
> This one just seems to keep coming up and I'm wondering how other people
> are dealing with it:
>
> When you peek and splice a transparently proxied connection, the SNI
> goes through the host validation phase.  Squid does a DNS lookup for the
> SNI, and if it doesn't resolve to the IP address that the client is
> connecting to, Squid drops the connection.
>
> When accessing one of the increasingly common websites that use DNS load
> balancing, since the DNS results change on each lookup, Squid and the
> client may not get the same DNS results, so Squid drops perfectly good
> connections.
>
> Most of this problem goes away if you ensure all the clients use the
> same DNS server as squid, but not quite.  Because the TTL on DNS records
> only has a resolution of 1 second, there is a period of up to 1 second
> when the DNS records Squid knows about doesn't match the ones that the
> client knows about.  The client and squid may expire the records up to 1
> second apart.

FYI: Services sending TTL of just 1 or even a few seconds are abusing
the DNS system. Rotating the order of IPs in the RR record is a
standardized feature and works just fine with how Squid does its checks.

NP: using "8.8.8.8" in both Squid and client does not count as using the
same resolver. Because that service is an entire farm of resolvers that
can and do respond differently to any two requests - even if they are
made simultaneously. Not a single machine using a single cache of DNS data.

>
> So what's the solution?  (Notably the validation check can't be disabled
> without hacking the code).
>

Well, hacking the code. But not necessarily in the obvious way of
disabling checks. Redesign in Squid DNS component is needed. If you want
to sponsor and/or test that work mail me privately. Though its unlikely
to be available for use in the short term .

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: More host header forgery pain with peek/splice

Marcus Kool
In reply to this post by Amos Jeffries
Do I understand it correctly that Squid in normal proxy mode
allows malware to do a CONNECT to any destination, while in
transparent proxy mode does extra security checks which causes
some regular (non-malware) clients to fail?

And philosophical questions: is Squid the right tool
to stop malware?  If yes, is it acceptable that connections
of regular (non-malware) clients are wrongly dropped?

IMO Squid should do all it can to be a secure proxy.
Doing security checks on connections in an attempt
to stop malware sounds like a job for an antivirus / IDS tool.

Marcus


On 08/30/2016 01:01 PM, Amos Jeffries wrote:

> On 26/08/2016 6:34 a.m., reinerotto wrote:
>> Hack the code. Because it is even worse, as firefox for example does not obey
>> to the TTL.
>>
>
> It is not that simple. The checks are there for very good reason(s)
> related to security of the network using the proxy.
>
> The Host forgery issue being checked for allows network firewall rule
> bypass, browser same-origin bypass, and browser sandbox bypass - in a
> way which places the attacker in control of what logs you see [aha!
> invisible access to the network]. With all the related nasty
> side-effects those allow. There is both malware and services for sale
> around the 'net that take advantage of the attack to do those bypasses.
> => Simply disabling the check code is a *very* risky thing to do.
>
>
> The cases where Squid still gets it wrong are where the popular CDN
> service(s) in question are performing DNS actions indistinguishable to
> those malware attacks. If Squid can't tell the difference between an
> attack and normal DNS behaviour the only code change possible is to
> disable the check (see above about the risk level).
>
>
> FYI: I have a plan to reduce the false-positive rate from DNS rotation
> effects. But that requires some deep redesign of the DNS code, which I'm
> intending to do as part of the Squid-5 roadmap to avoid further
> destabilizing 4.x while its in beta.
>
> For now the workarounds are:
>
> * obey the requirement that destination NAT (if any) is performed only
> on the Squid machine.
>
> * to tune the lifetime for persistent client connections. That reduces
> (but not fully) connections outliving DNS rotation times and thus
> causing requests to have different ORIGINAL_DST from what DNS says.
>
> * if wanting Google 8.8.8.8 service as your resolver. Use a local DNS
> recursive resolver shared by Squid and client which points to that
> service as its parent/forwarded resolver. That removes the issue with
> every 8.8.8.8 response having different reply IP values (so client and
> Squid doing near simultaneous lookups get different IPs).
>
> Amos
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: More host header forgery pain with peek/splice

Yuri Voinov

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 


30.08.2016 23:25, Marcus Kool пишет:
> Do I understand it correctly that Squid in normal proxy mode
> allows malware to do a CONNECT to any destination, while in
> transparent proxy mode does extra security checks which causes
> some regular (non-malware) clients to fail?
http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP
>
> And philosophical questions: is Squid the right tool
> to stop malware?  If yes, is it acceptable that connections
> of regular (non-malware) clients are wrongly dropped?
http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP

>
> IMO Squid should do all it can to be a secure proxy.
> Doing security checks on connections in an attempt
> to stop malware sounds like a job for an antivirus / IDS tool.
http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP
http://wiki.squid-cache.org/Features/SslPeekAndSplice


>
> Marcus
>
>
> On 08/30/2016 01:01 PM, Amos Jeffries wrote:
>> On 26/08/2016 6:34 a.m., reinerotto wrote:
>>> Hack the code. Because it is even worse, as firefox for example does
not obey

>>> to the TTL.
>>>
>>
>> It is not that simple. The checks are there for very good reason(s)
>> related to security of the network using the proxy.
>>
>> The Host forgery issue being checked for allows network firewall rule
>> bypass, browser same-origin bypass, and browser sandbox bypass - in a
>> way which places the attacker in control of what logs you see [aha!
>> invisible access to the network]. With all the related nasty
>> side-effects those allow. There is both malware and services for sale
>> around the 'net that take advantage of the attack to do those bypasses.
>> => Simply disabling the check code is a *very* risky thing to do.
>>
>>
>> The cases where Squid still gets it wrong are where the popular CDN
>> service(s) in question are performing DNS actions indistinguishable to
>> those malware attacks. If Squid can't tell the difference between an
>> attack and normal DNS behaviour the only code change possible is to
>> disable the check (see above about the risk level).
>>
>>
>> FYI: I have a plan to reduce the false-positive rate from DNS rotation
>> effects. But that requires some deep redesign of the DNS code, which I'm
>> intending to do as part of the Squid-5 roadmap to avoid further
>> destabilizing 4.x while its in beta.
>>
>> For now the workarounds are:
>>
>> * obey the requirement that destination NAT (if any) is performed only
>> on the Squid machine.
>>
>> * to tune the lifetime for persistent client connections. That reduces
>> (but not fully) connections outliving DNS rotation times and thus
>> causing requests to have different ORIGINAL_DST from what DNS says.
>>
>> * if wanting Google 8.8.8.8 service as your resolver. Use a local DNS
>> recursive resolver shared by Squid and client which points to that
>> service as its parent/forwarded resolver. That removes the issue with
>> every 8.8.8.8 response having different reply IP values (so client and
>> Squid doing near simultaneous lookups get different IPs).
>>
>> Amos
>>
>> _______________________________________________
>> squid-users mailing list
>> [hidden email]
>> http://lists.squid-cache.org/listinfo/squid-users
>>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXxd12AAoJENNXIZxhPexGatAIAMvXwPnEHw5PR+fg+8KdxCQ3
h0fYEFKZHOI2P0b+kk7DRd/RG1mBdM23Hlr6EflqXGSigkuYF8fLGfx4iyo6BaXt
gOO4Z/CEoUCtjF8PPG8WWNaRz5kz4eZcMJM10gGJ0wke8ojDUJ11Z0TXorj7n9Ou
JRG2XuyP4RF2fHxOPsCvQRD1I7yiynMVXa8vsc6PHvlOru56rs/VTd86NX2jBFJf
TpM6UWrJzmZbUAIlrzhgllEPpgfUPzTdJX8eIFKQeVnOyq0i6o5pjc8wdg4CZUkw
naaYNTp/xsx/zfhW75xjKV4UuxCGiZy9zroiKpyu/EjnSUvtnQHVFrWyhvxCJrM=
=mPgV
-----END PGP SIGNATURE-----


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More host header forgery pain with peek/splice

Yuri Voinov

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 


31.08.2016 1:24, Yuri Voinov пишет:
>
>
>
> 30.08.2016 23:25, Marcus Kool пишет:
> > Do I understand it correctly that Squid in normal proxy mode
> > allows malware to do a CONNECT to any destination, while in
> > transparent proxy mode does extra security checks which causes
> > some regular (non-malware) clients to fail?
> http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP
>
> > And philosophical questions: is Squid the right tool
> > to stop malware?  If yes, is it acceptable that connections
> > of regular (non-malware) clients are wrongly dropped?
> http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP

Not stop all. But reduce.
>
>
> > IMO Squid should do all it can to be a secure proxy.
> > Doing security checks on connections in an attempt
> > to stop malware sounds like a job for an antivirus / IDS tool.
> http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP
> http://wiki.squid-cache.org/Features/SslPeekAndSplice
>
>
>
> > Marcus
>
>
> > On 08/30/2016 01:01 PM, Amos Jeffries wrote:
> >> On 26/08/2016 6:34 a.m., reinerotto wrote:
> >>> Hack the code. Because it is even worse, as firefox for example does
> not obey
> >>> to the TTL.
> >>>
> >>
> >> It is not that simple. The checks are there for very good reason(s)
> >> related to security of the network using the proxy.
> >>
> >> The Host forgery issue being checked for allows network firewall rule
> >> bypass, browser same-origin bypass, and browser sandbox bypass - in a
> >> way which places the attacker in control of what logs you see [aha!
> >> invisible access to the network]. With all the related nasty
> >> side-effects those allow. There is both malware and services for sale
> >> around the 'net that take advantage of the attack to do those bypasses.
> >> => Simply disabling the check code is a *very* risky thing to do.
> >>
> >>
> >> The cases where Squid still gets it wrong are where the popular CDN
> >> service(s) in question are performing DNS actions indistinguishable to
> >> those malware attacks. If Squid can't tell the difference between an
> >> attack and normal DNS behaviour the only code change possible is to
> >> disable the check (see above about the risk level).
> >>
> >>
> >> FYI: I have a plan to reduce the false-positive rate from DNS rotation
> >> effects. But that requires some deep redesign of the DNS code, which I'm
> >> intending to do as part of the Squid-5 roadmap to avoid further
> >> destabilizing 4.x while its in beta.
> >>
> >> For now the workarounds are:
> >>
> >> * obey the requirement that destination NAT (if any) is performed only
> >> on the Squid machine.
> >>
> >> * to tune the lifetime for persistent client connections. That reduces
> >> (but not fully) connections outliving DNS rotation times and thus
> >> causing requests to have different ORIGINAL_DST from what DNS says.
> >>
> >> * if wanting Google 8.8.8.8 service as your resolver. Use a local DNS
> >> recursive resolver shared by Squid and client which points to that
> >> service as its parent/forwarded resolver. That removes the issue with
> >> every 8.8.8.8 response having different reply IP values (so client and
> >> Squid doing near simultaneous lookups get different IPs).
> >>
> >> Amos
> >>
> >> _______________________________________________
> >> squid-users mailing list
> >> [hidden email]
> >> http://lists.squid-cache.org/listinfo/squid-users
> >>
> > _______________________________________________
> > squid-users mailing list
> > [hidden email]
> > http://lists.squid-cache.org/listinfo/squid-users
>
>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXxd3bAAoJENNXIZxhPexGUbgH/j4qcbQW7u/zktJpJLlqhed3
+J7Qsr6eXyeC3ryG8q8w5CGAdP/ESoeJO/aA02uW/DEf517oH5kHxMtKdtyl9VNw
suqNAcFsk6F8fYG+9h2+0Zip2IN3IC8u2ArtZcVcd5QO/rruEEFLK6HX3K9cvOBn
guRq9LNa5DvX83cYhxdQIdDJ8eeGGOxcwteyajkeMfwskfx4dLeoDO2B4F56VKLA
ugVA7NBskVe2TiuhgfpZ4fOWslWaiZATma1beM4sa0KOvRUqxKuf0BJlnX+Llyzp
YsD1cPRXs4YftF6t4d/iV4BT+oUYKq4UugHNHgy3PqgKu9VFWoeX/dBmHRMYHQY=
=Siw+
-----END PGP SIGNATURE-----


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More host header forgery pain with peek/splice

Yuri Voinov
In reply to this post by Marcus Kool

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
And this one:

http://wiki.squid-cache.org/ConfigExamples/Intercept/CiscoIOSv15Wccp2

of course.


30.08.2016 23:25, Marcus Kool пишет:

> Do I understand it correctly that Squid in normal proxy mode
> allows malware to do a CONNECT to any destination, while in
> transparent proxy mode does extra security checks which causes
> some regular (non-malware) clients to fail?
>
> And philosophical questions: is Squid the right tool
> to stop malware?  If yes, is it acceptable that connections
> of regular (non-malware) clients are wrongly dropped?
>
> IMO Squid should do all it can to be a secure proxy.
> Doing security checks on connections in an attempt
> to stop malware sounds like a job for an antivirus / IDS tool.
>
> Marcus
>
>
> On 08/30/2016 01:01 PM, Amos Jeffries wrote:
>> On 26/08/2016 6:34 a.m., reinerotto wrote:
>>> Hack the code. Because it is even worse, as firefox for example does
not obey

>>> to the TTL.
>>>
>>
>> It is not that simple. The checks are there for very good reason(s)
>> related to security of the network using the proxy.
>>
>> The Host forgery issue being checked for allows network firewall rule
>> bypass, browser same-origin bypass, and browser sandbox bypass - in a
>> way which places the attacker in control of what logs you see [aha!
>> invisible access to the network]. With all the related nasty
>> side-effects those allow. There is both malware and services for sale
>> around the 'net that take advantage of the attack to do those bypasses.
>> => Simply disabling the check code is a *very* risky thing to do.
>>
>>
>> The cases where Squid still gets it wrong are where the popular CDN
>> service(s) in question are performing DNS actions indistinguishable to
>> those malware attacks. If Squid can't tell the difference between an
>> attack and normal DNS behaviour the only code change possible is to
>> disable the check (see above about the risk level).
>>
>>
>> FYI: I have a plan to reduce the false-positive rate from DNS rotation
>> effects. But that requires some deep redesign of the DNS code, which I'm
>> intending to do as part of the Squid-5 roadmap to avoid further
>> destabilizing 4.x while its in beta.
>>
>> For now the workarounds are:
>>
>> * obey the requirement that destination NAT (if any) is performed only
>> on the Squid machine.
>>
>> * to tune the lifetime for persistent client connections. That reduces
>> (but not fully) connections outliving DNS rotation times and thus
>> causing requests to have different ORIGINAL_DST from what DNS says.
>>
>> * if wanting Google 8.8.8.8 service as your resolver. Use a local DNS
>> recursive resolver shared by Squid and client which points to that
>> service as its parent/forwarded resolver. That removes the issue with
>> every 8.8.8.8 response having different reply IP values (so client and
>> Squid doing near simultaneous lookups get different IPs).
>>
>> Amos
>>
>> _______________________________________________
>> squid-users mailing list
>> [hidden email]
>> http://lists.squid-cache.org/listinfo/squid-users
>>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXxd4/AAoJENNXIZxhPexGwjwH+QHrd7xRMHLr1kTxd7cMoVtS
bMXLslGgtdno0T8hueLY68pCybfFSU/aO3HDg3V8SNvH8cx84ZSndqvUtbro3/Ze
Uzt+JQtvp8R7vyTgrfJFy02UJvxk6jtd88H/FSO0bp4vLNOxDg3H/OvxjyXuHU5C
fACXayHvZbf/IZzpEjyVWt2pKH9TBNK2eB2omqIQupFCGboIk70S2kpeA8L8+YKx
1hWq0QWY9esyi7b8OZwX2QnEU2M+eBYCn+KZHp6BorLfxOTcctpxM37Up3ieOON5
asyOC4MMmOAvqs4NSHgqfGB2Pybd6I0+wZ0yz576rZqscE/zfRxkbaZ3MqKT53s=
=ernf
-----END PGP SIGNATURE-----


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More host header forgery pain with peek/splice

Amos Jeffries
Administrator
In reply to this post by Marcus Kool
On 31/08/2016 5:25 a.m., Marcus Kool wrote:
> Do I understand it correctly that Squid in normal proxy mode
> allows malware to do a CONNECT to any destination, while in
> transparent proxy mode does extra security checks which causes
> some regular (non-malware) clients to fail?


Intercepted traffic has different processing applied, different
assumptions made about the traffic, and different security model
relevant to its messages.

The short answer is "yes", but reality is not that simple black/white.


>
> And philosophical questions: is Squid the right tool
> to stop malware?  If yes, is it acceptable that connections
> of regular (non-malware) clients are wrongly dropped?

No more or less than any software.

Squid manages the HTTP that flows through it. If the malware uses HTTP
messages to communicate then it very much part of Squid's job to prevent
that. Other protocols Squid is not responsible for, except to prevent
itself being a vector of attack.

>
> IMO Squid should do all it can to be a secure proxy.

Which is the case for Host forgery atacks. If Squid did not MITM the
network traffic, there would not be a vulnerability to Host forgery
issues. Therefore an intercept/tproxy Squid is very much responsible for
preventing this particular type of attack which it causes to exist.

A forward-proxy or reverse-proxy does not have that vulnerability,
therefore does not need to check the same things.


> Doing security checks on connections in an attempt
> to stop malware sounds like a job for an antivirus / IDS tool.
>

Additional to what Squid does. Indeed many of those tools use a proxy
service which performs the same or similar checks to what Squid does,
with far more intrusive behaviour, or are themselves also vulnerable to
becoming vectors of the Host attack(s). The Host attack(s) are
vulnerability built into the concept of MITM'ing HTTP(S) traffic. It is
not something specific to Squid.

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: More host header forgery pain with peek/splice

Marcus Kool
Thanks for your reply.

The 13-year old child in me says "I want it fixed yesterday"
since false positives are very painful and cannot always
be prevented since the environment where Squid works is
not always that easy to control.

You mentioned earlier that a fix will probably go in squid 5
which is long due and there is no workaround.  A second
thought is to have an acl that determines for which domains
the check must be skipped, but this is not optimal since
the admin gains an extra job.

My vote goes to re-prioritizing the fix and put it in Squid 4.
Of course I have no idea about the implications.

Thanks
Marcus


On 09/04/2016 01:12 PM, Amos Jeffries wrote:

> On 31/08/2016 5:25 a.m., Marcus Kool wrote:
>> Do I understand it correctly that Squid in normal proxy mode
>> allows malware to do a CONNECT to any destination, while in
>> transparent proxy mode does extra security checks which causes
>> some regular (non-malware) clients to fail?
>
>
> Intercepted traffic has different processing applied, different
> assumptions made about the traffic, and different security model
> relevant to its messages.
>
> The short answer is "yes", but reality is not that simple black/white.
>
>
>>
>> And philosophical questions: is Squid the right tool
>> to stop malware?  If yes, is it acceptable that connections
>> of regular (non-malware) clients are wrongly dropped?
>
> No more or less than any software.
>
> Squid manages the HTTP that flows through it. If the malware uses HTTP
> messages to communicate then it very much part of Squid's job to prevent
> that. Other protocols Squid is not responsible for, except to prevent
> itself being a vector of attack.
>
>>
>> IMO Squid should do all it can to be a secure proxy.
>
> Which is the case for Host forgery atacks. If Squid did not MITM the
> network traffic, there would not be a vulnerability to Host forgery
> issues. Therefore an intercept/tproxy Squid is very much responsible for
> preventing this particular type of attack which it causes to exist.
>
> A forward-proxy or reverse-proxy does not have that vulnerability,
> therefore does not need to check the same things.
>
>
>> Doing security checks on connections in an attempt
>> to stop malware sounds like a job for an antivirus / IDS tool.
>>
>
> Additional to what Squid does. Indeed many of those tools use a proxy
> service which performs the same or similar checks to what Squid does,
> with far more intrusive behaviour, or are themselves also vulnerable to
> becoming vectors of the Host attack(s). The Host attack(s) are
> vulnerability built into the concept of MITM'ing HTTP(S) traffic. It is
> not something specific to Squid.
>
> Amos
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: More host header forgery pain with peek/splice

Amos Jeffries
Administrator
On 5/09/2016 11:35 a.m., Marcus Kool wrote:

> Thanks for your reply.
>
> The 13-year old child in me says "I want it fixed yesterday"
> since false positives are very painful and cannot always
> be prevented since the environment where Squid works is
> not always that easy to control.
>
> You mentioned earlier that a fix will probably go in squid 5
> which is long due and there is no workaround.  A second
> thought is to have an acl that determines for which domains
> the check must be skipped, but this is not optimal since
> the admin gains an extra job.
>
> My vote goes to re-prioritizing the fix and put it in Squid 4.
> Of course I have no idea about the implications.

Resources to work on it would be very welcome. I still think it will
take too long to go into Squid-4 though, since 4.1 is already overdue
for release.

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Transparent Proxy

John Sayce
In reply to this post by Marcus Kool
I'm trying to set up a transparent proxy but I'm fairly sure I'm missing something.

I've followed the instructions on the juniper website along with a couple of other blogs as per:
https://damn.technology/using-squid-juniper-pbr-transparent-proxy
http://davehope.co.uk/Blog/implementing-pbr-and-squid3-as-a-transparent-proxy/
https://kb.juniper.net/InfoCenter/index?id=KB24139&page=content&actp=search


I have a juniper SSG320 firewall setup with policy based routing.  For my chosen subnet this is configured to forward traffic on port 80 to the squid server.

The traffic from my firewall is forwarded to squid.  This appears to be happening.  

The client starts with a syn packet which is forwarded from the firewall to the squid server. The packet is forwarded to the squid server with the source IP address remaining that of the client.  The problem is that the squid server then responds to the client as itself rather than spoofing the address that the client originally requested. So the ACK packet the client receives is from the squid server rather than the remote webserver the client made a request to, which isn't going to work.

So should my firewall be doing something more, or is it my squid server that's not performing as expected?

In addition to forwarding the packet to squid I can enable source translation on the firewall (which isn't in the guides I mentioned) so the source address of the packet sent to squid comes from the firewall, squid then responds to the firewall, which in turn translates the packet back to the client.  This configuration works, however the access log stores the address of the firewall rather than the address of the client.  Is this how it's meant to work, or am I missing something?

Thanks

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Transparent Proxy

Antony Stone
On Wednesday 07 September 2016 at 10:23:02, John Sayce wrote:

> I'm trying to set up a transparent proxy but I'm fairly sure I'm missing
> something.
>
> I've followed the instructions on the juniper website along with a couple
> of other blogs as per:
> https://damn.technology/using-squid-juniper-pbr-transparent-proxy

You *have* applied the iptables rule on the machine running squid as described
on that page, yes?

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port
3128


Antony.

--
This email was created using 100% recycled electrons.

                                                   Please reply to the list;
                                                         please *don't* CC me.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Transparent Proxy

John Sayce
I believe so.  The specific command I used was:

iptables -t nat -A PREROUTING -i ens33 -p tcp --dport 80 -j REDIRECT --to-port 3128

(For some reason my adapter is ens33, I have no idea why it's not eth0.  Squid is set to run on 3128.)

And after running this command port 80 now shows as being open with nmap.

And the output from iptables -t nat -L

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
REDIRECT   tcp  --  anywhere             anywhere             tcp dpt:http redir ports 3128

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination


It's fair to say I have almost no experience with iptables.  Is it iptables that should be doing the address translation? when the packet is sent back to the client?



-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Antony Stone
Sent: 07 September 2016 09:28
To: [hidden email]
Subject: Re: [squid-users] Transparent Proxy

On Wednesday 07 September 2016 at 10:23:02, John Sayce wrote:

> I'm trying to set up a transparent proxy but I'm fairly sure I'm
> missing something.
>
> I've followed the instructions on the juniper website along with a
> couple of other blogs as per:
> https://damn.technology/using-squid-juniper-pbr-transparent-proxy

You *have* applied the iptables rule on the machine running squid as described on that page, yes?

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port
3128


Antony.

--
This email was created using 100% recycled electrons.

                                                   Please reply to the list;
                                                         please *don't* CC me.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Transparent Proxy

Antony Stone
On Wednesday 07 September 2016 at 10:51:49, John Sayce wrote:

> I believe so.  The specific command I used was:
>
> iptables -t nat -A PREROUTING -i ens33 -p tcp --dport 80 -j REDIRECT
> --to-port 3128
>
> (For some reason my adapter is ens33, I have no idea why it's not eth0.
> Squid is set to run on 3128.)

That looks okay, then.

> It's fair to say I have almost no experience with iptables.  Is it iptables
> that should be doing the address translation?

Yes - the rule above tells the machine to take any packet addressed to port 80
on any address and send it instead to the local machine (REDIRECT changes the
destination address to 127.0.0.1, even though that's not obvious) and port
3128.

> when the packet is sent back to the client?

Correct.  IPtables' address translation rules are automatically symmetrical -
when a packet gets translated in one direction, a record is kept that it was
done, and then the reply packet is automatically reverse-translated when it
comes back in the other direction.

This is true no matter whether packets are going *through* the IPtables
machine (ie: it's acting as a router), or whether they're being processed *on*
the IPtables machine (as in this case).

I think we need to know more about your squid setup.

Please tell us which version of squid you are using, and post here your
squid.conf file without comments or blank lines.


Antony.

--
Software development can be quick, high quality, or low cost.

The customer gets to pick any two out of three.

                                                   Please reply to the list;
                                                         please *don't* CC me.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Transparent Proxy

Amos Jeffries
Administrator
On 7/09/2016 9:27 p.m., Antony Stone wrote:
> On Wednesday 07 September 2016 at 10:51:49, John Sayce wrote:
>

FYI: Jon. Please be careful about yoru use of teh word "forward" and
"forwarding". Both NAT and routing  are methods of forwarding, but which
one is used at each particular step of the packets path through your
network from client to Squid matters A LOT.

Some routers offer "forwarding" options / settings, which actually NAT.
That will break MITM Squid installations which require routing only
outside the Squid machine.


>> I believe so.  The specific command I used was:
>>
>> iptables -t nat -A PREROUTING -i ens33 -p tcp --dport 80 -j REDIRECT
>> --to-port 3128
>>
>> (For some reason my adapter is ens33, I have no idea why it's not eth0.
>> Squid is set to run on 3128.)
>
> That looks okay, then.
>
>> It's fair to say I have almost no experience with iptables.  Is it iptables
>> that should be doing the address translation?
>
> Yes - the rule above tells the machine to take any packet addressed to port 80
> on any address and send it instead to the local machine (REDIRECT changes the
> destination address to 127.0.0.1, even though that's not obvious) and port
> 3128.

No it does not change the IP to localhost. It changes the address to the
machines primary IP. If that is localhost IP then something is wrong in
the machines network interface configuration - which may lead to trouble.


>
>> when the packet is sent back to the client?
>
> Correct.  IPtables' address translation rules are automatically symmetrical -
> when a packet gets translated in one direction, a record is kept that it was
> done, and then the reply packet is automatically reverse-translated when it
> comes back in the other direction.
>
> This is true no matter whether packets are going *through* the IPtables
> machine (ie: it's acting as a router), or whether they're being processed *on*
> the IPtables machine (as in this case).
>
> I think we need to know more about your squid setup.
>
> Please tell us which version of squid you are using, and post here your
> squid.conf file without comments or blank lines.
>


Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Transparent Proxy

John Sayce
In reply to this post by Antony Stone
For testing purposes I've reduced it to the following:

http_port 3128 intercept
#dns_v4_first on
dns_nameservers 10.8.2.3 194.168.4.100 10.8.2.2 8.8.8.8
acl wifi src 10.8.14.0/24
acl all src all
http_access allow all
maximum_object_size 1 GB
minimum_object_size 0 KB
maximum_object_size_in_memory 4 MB
cache_mem 1700 MB
cache_dir aufs /var/cache/squid 40000 32 512
coredump_dir /var/cache/squid
access_log /var/log/squid/access.log squid
cache_log /var/log/squid/cache.log
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
cache_effective_user asd
cache_effective_group asd
cache_mgr [hidden email]
forwarded_for off

The version is 3.5.12

Okay.  Sorry, to clarify with a specific example.  Lets say I'm contacting http://1.1.1.1/ then the ack packet starts off with the client with ip address 10.8.14.9 in subnet 10.8.14.9/24 with default gateway 10.8.14.1.  It's routed through my core switch to my my firewall with ip 10.8.1.1.  My firewall recognises that the packet has a destination port 80 and is in subnet 10.8.14.0/24 and changes the destination address to be that of my proxy server 10.8.2.11.  So now the ack packet has source 10.8.14.9 and destination 10.8.2.11.  How does iptables know to reply to my client 10.8.14.9 with source address 1.1.1.1?  Does iptables know to read the header?

Thanks


-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Antony Stone
Sent: 07 September 2016 10:27
To: '[hidden email]'
Subject: Re: [squid-users] Transparent Proxy

On Wednesday 07 September 2016 at 10:51:49, John Sayce wrote:

> I believe so.  The specific command I used was:
>
> iptables -t nat -A PREROUTING -i ens33 -p tcp --dport 80 -j REDIRECT
> --to-port 3128
>
> (For some reason my adapter is ens33, I have no idea why it's not eth0.
> Squid is set to run on 3128.)

That looks okay, then.

> It's fair to say I have almost no experience with iptables.  Is it
> iptables that should be doing the address translation?

Yes - the rule above tells the machine to take any packet addressed to port 80 on any address and send it instead to the local machine (REDIRECT changes the destination address to 127.0.0.1, even though that's not obvious) and port 3128.

> when the packet is sent back to the client?

Correct.  IPtables' address translation rules are automatically symmetrical - when a packet gets translated in one direction, a record is kept that it was done, and then the reply packet is automatically reverse-translated when it comes back in the other direction.

This is true no matter whether packets are going *through* the IPtables machine (ie: it's acting as a router), or whether they're being processed *on* the IPtables machine (as in this case).

I think we need to know more about your squid setup.

Please tell us which version of squid you are using, and post here your squid.conf file without comments or blank lines.


Antony.

--
Software development can be quick, high quality, or low cost.

The customer gets to pick any two out of three.

                                                   Please reply to the list;
                                                         please *don't* CC me.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Transparent Proxy

Antony Stone
On Thursday 08 September 2016 at 10:12:48, John Sayce wrote:

> For testing purposes I've reduced it to the following:
>
> http_port 3128 intercept
> #dns_v4_first on
> dns_nameservers 10.8.2.3 194.168.4.100 10.8.2.2 8.8.8.8
> acl wifi src 10.8.14.0/24
> acl all src all
> http_access allow all
> maximum_object_size 1 GB
> minimum_object_size 0 KB
> maximum_object_size_in_memory 4 MB
> cache_mem 1700 MB
> cache_dir aufs /var/cache/squid 40000 32 512
> coredump_dir /var/cache/squid
> access_log /var/log/squid/access.log squid
> cache_log /var/log/squid/cache.log
> 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
> cache_effective_user asd
> cache_effective_group asd
> cache_mgr [hidden email]
> forwarded_for off
>
> The version is 3.5.12
>
> Okay.  Sorry, to clarify with a specific example.

Don't apologise - specific examples are good, because it makes sure we're both
talking about the same thing (and sometimes, as below, reveals little details
about the network arrangement which weren't previously clear).

> Lets say I'm contacting http://1.1.1.1/ then the ack packet starts off with
> the client with ip address 10.8.14.9

So, source IP = 10.8.14.9 : destination IP = 1.1.11

> in subnet 10.8.14.9/24 with default gateway 10.8.14.1.
> It's routed through my core switch to my my firewall with ip 10.8.1.1.

So that's a router, not just a switch?  It has one interface 10.8.14.1 on
subnet 10.8.14.0/24 and another interface on (presumably) 10.8.1.0/24 pointing
at 10.8.1.1 as the next-hop route towards 1.1.1.1

> My firewall recognises that the packet has a destination port 80 and is in
> subnet 10.8.14.0/24

The source address is in that subnet, yes.

> and changes the destination address to be that of my proxy server 10.8.2.11.

No - see below.

> So now the ack packet has source 10.8.14.9 and destination 10.8.2.11.

No, it doesn't.  When a packet goes via a router, its destination IP address
is not changed to the address of the next-hop router (otherwise things would
never work across the Internet).

It's only the destination MAC address in the encapsulating ethernet frame
which gets changed to that of the next-hop router.  The source and destination
IP addresses inside are not touched.

> How does iptables know to reply to my client 10.8.14.9 with source address
> 1.1.1.1?  Does iptables know to read the header?

TCP header, yes.

HTTP header, no.

Just think about the very first link between the client and its default
gateway:

Packet with source address = 10.8.14.9, destinatoin address = 1.1.1.1

How does that packet get to the default router 10.8.14.1?  Its destination IP
is 1.1.1.1, so that doesn't help.

It's because the destination MAC address in the ethernet frame containing that
IP packet is the MAC address of 10.8.14.1.

A few minutes playing around with wireshark on your network could be quite
enlightening :)



Regards,


Antony.

--
I think broken pencils are pointless.

                                                   Please reply to the list;
                                                         please *don't* CC me.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Transparent Proxy

John Sayce
After I wrote this I realised it should be changing the mac not the ip, which is not what’s happeneing.  I think it's my firewall configuration that's wrong.

Thanks



-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Antony Stone
Sent: 08 September 2016 09:36
To: [hidden email]
Subject: Re: [squid-users] Transparent Proxy

On Thursday 08 September 2016 at 10:12:48, John Sayce wrote:

> For testing purposes I've reduced it to the following:
>
> http_port 3128 intercept
> #dns_v4_first on
> dns_nameservers 10.8.2.3 194.168.4.100 10.8.2.2 8.8.8.8 acl wifi src
> 10.8.14.0/24 acl all src all http_access allow all maximum_object_size
> 1 GB minimum_object_size 0 KB maximum_object_size_in_memory 4 MB
> cache_mem 1700 MB cache_dir aufs /var/cache/squid 40000 32 512
> coredump_dir /var/cache/squid access_log /var/log/squid/access.log
> squid cache_log /var/log/squid/cache.log
> 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
> cache_effective_user asd
> cache_effective_group asd
> cache_mgr [hidden email]
> forwarded_for off
>
> The version is 3.5.12
>
> Okay.  Sorry, to clarify with a specific example.

Don't apologise - specific examples are good, because it makes sure we're both talking about the same thing (and sometimes, as below, reveals little details about the network arrangement which weren't previously clear).

> Lets say I'm contacting http://1.1.1.1/ then the ack packet starts off
> with the client with ip address 10.8.14.9

So, source IP = 10.8.14.9 : destination IP = 1.1.11

> in subnet 10.8.14.9/24 with default gateway 10.8.14.1.
> It's routed through my core switch to my my firewall with ip 10.8.1.1.

So that's a router, not just a switch?  It has one interface 10.8.14.1 on subnet 10.8.14.0/24 and another interface on (presumably) 10.8.1.0/24 pointing at 10.8.1.1 as the next-hop route towards 1.1.1.1

> My firewall recognises that the packet has a destination port 80 and
> is in subnet 10.8.14.0/24

The source address is in that subnet, yes.

> and changes the destination address to be that of my proxy server 10.8.2.11.

No - see below.

> So now the ack packet has source 10.8.14.9 and destination 10.8.2.11.

No, it doesn't.  When a packet goes via a router, its destination IP address is not changed to the address of the next-hop router (otherwise things would never work across the Internet).

It's only the destination MAC address in the encapsulating ethernet frame which gets changed to that of the next-hop router.  The source and destination IP addresses inside are not touched.

> How does iptables know to reply to my client 10.8.14.9 with source
> address 1.1.1.1?  Does iptables know to read the header?

TCP header, yes.

HTTP header, no.

Just think about the very first link between the client and its default
gateway:

Packet with source address = 10.8.14.9, destinatoin address = 1.1.1.1

How does that packet get to the default router 10.8.14.1?  Its destination IP is 1.1.1.1, so that doesn't help.

It's because the destination MAC address in the ethernet frame containing that IP packet is the MAC address of 10.8.14.1.

A few minutes playing around with wireshark on your network could be quite enlightening :)



Regards,


Antony.

--
I think broken pencils are pointless.

                                                   Please reply to the list;
                                                         please *don't* CC me.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Transparent Proxy

Antony Stone
On Thursday 08 September 2016 at 10:44:12, John Sayce wrote:

> After I wrote this I realised it should be changing the mac not the ip,
> which is not what’s happeneing.  I think it's my firewall configuration
> that's wrong.

In that case your firewall is doing NAT instead of policy routing.

Regards,


Antony.

> -----Original Message-----
> From: squid-users [mailto:[hidden email]] On
> Behalf Of Antony Stone Sent: 08 September 2016 09:36
> To: [hidden email]
> Subject: Re: [squid-users] Transparent Proxy
>
> On Thursday 08 September 2016 at 10:12:48, John Sayce wrote:
> > For testing purposes I've reduced it to the following:
> >
> > http_port 3128 intercept
> > #dns_v4_first on
> > dns_nameservers 10.8.2.3 194.168.4.100 10.8.2.2 8.8.8.8 acl wifi src
> > 10.8.14.0/24 acl all src all http_access allow all maximum_object_size
> > 1 GB minimum_object_size 0 KB maximum_object_size_in_memory 4 MB
> > cache_mem 1700 MB cache_dir aufs /var/cache/squid 40000 32 512
> > coredump_dir /var/cache/squid access_log /var/log/squid/access.log
> > squid cache_log /var/log/squid/cache.log
> > 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
> > cache_effective_user asd
> > cache_effective_group asd
> > cache_mgr [hidden email]
> > forwarded_for off
> >
> > The version is 3.5.12
> >
> > Okay.  Sorry, to clarify with a specific example.
>
> Don't apologise - specific examples are good, because it makes sure we're
> both talking about the same thing (and sometimes, as below, reveals little
> details about the network arrangement which weren't previously clear).
>
> > Lets say I'm contacting http://1.1.1.1/ then the ack packet starts off
> > with the client with ip address 10.8.14.9
>
> So, source IP = 10.8.14.9 : destination IP = 1.1.11
>
> > in subnet 10.8.14.9/24 with default gateway 10.8.14.1.
> > It's routed through my core switch to my my firewall with ip 10.8.1.1.
>
> So that's a router, not just a switch?  It has one interface 10.8.14.1 on
> subnet 10.8.14.0/24 and another interface on (presumably) 10.8.1.0/24
> pointing at 10.8.1.1 as the next-hop route towards 1.1.1.1
>
> > My firewall recognises that the packet has a destination port 80 and
> > is in subnet 10.8.14.0/24
>
> The source address is in that subnet, yes.
>
> > and changes the destination address to be that of my proxy server
> > 10.8.2.11.
>
> No - see below.
>
> > So now the ack packet has source 10.8.14.9 and destination 10.8.2.11.
>
> No, it doesn't.  When a packet goes via a router, its destination IP
> address is not changed to the address of the next-hop router (otherwise
> things would never work across the Internet).
>
> It's only the destination MAC address in the encapsulating ethernet frame
> which gets changed to that of the next-hop router.  The source and
> destination IP addresses inside are not touched.
>
> > How does iptables know to reply to my client 10.8.14.9 with source
> > address 1.1.1.1?  Does iptables know to read the header?
>
> TCP header, yes.
>
> HTTP header, no.
>
> Just think about the very first link between the client and its default
> gateway:
>
> Packet with source address = 10.8.14.9, destinatoin address = 1.1.1.1
>
> How does that packet get to the default router 10.8.14.1?  Its destination
> IP is 1.1.1.1, so that doesn't help.
>
> It's because the destination MAC address in the ethernet frame containing
> that IP packet is the MAC address of 10.8.14.1.
>
> A few minutes playing around with wireshark on your network could be quite
> enlightening :)
>
>
>
> Regards,
>
>
> Antony.

--
"Reports that say that something hasn't happened are always interesting to me,
because as we know, there are known knowns; there are things we know we know.
We also know there are known unknowns; that is to say we know there are some
things we do not know. But there are also unknown unknowns - the ones we don't
know we don't know."

 - Donald Rumsfeld, US Secretary of Defence

                                                   Please reply to the list;
                                                         please *don't* CC me.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
12