Host header forgery detected on domain: mobile.pipe.aria.microsoft.com

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Host header forgery detected on domain: mobile.pipe.aria.microsoft.com

Eliezer Croitoru-3
I'm testing SSL BUMP in 5.0.4 and it's working pretty well despite some
hiccups.

I am trying to think about the right solution for the next issue:
SECURITY ALERT: Host header forgery detected on conn18767
local=52.114.32.24:443 remote=192.168.189.52:65107 FD 15 flags=33 (local IP
does not match any domain IP)
                                                   current master
transaction: master12927

The main issue is that the DNS service changes address every 10 ~ seconds.
An example:
### DRILL START
# drill mobile.pipe.aria.microsoft.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 23399
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; mobile.pipe.aria.microsoft.com.      IN      A

;; ANSWER SECTION:
mobile.pipe.aria.microsoft.com. 3066    IN      CNAME
mobile.events.data.trafficmanager.net.
mobile.events.data.trafficmanager.net.  43      IN      CNAME
skypedataprdcolcus06.cloudapp.net.
skypedataprdcolcus06.cloudapp.net.      1       IN      A
52.114.128.69

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 3 msec
;; SERVER: 192.168.200.1
;; WHEN: Wed Jan  6 20:22:28 2021
;; MSG SIZE  rcvd: 159
### DRILL END

### DRILL START
# drill mobile.pipe.aria.microsoft.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 15462
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; mobile.pipe.aria.microsoft.com.      IN      A

;; ANSWER SECTION:
mobile.pipe.aria.microsoft.com. 3065    IN      CNAME
mobile.events.data.trafficmanager.net.
mobile.events.data.trafficmanager.net.  42      IN      CNAME
skypedataprdcolcus06.cloudapp.net.
skypedataprdcolcus06.cloudapp.net.      0       IN      A
52.114.128.69

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 23 msec
;; SERVER: 192.168.200.1
;; WHEN: Wed Jan  6 20:22:29 2021
;; MSG SIZE  rcvd: 159
[root@px1 bin]# drill mobile.pipe.aria.microsoft.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 31545
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; mobile.pipe.aria.microsoft.com.      IN      A

;; ANSWER SECTION:
mobile.pipe.aria.microsoft.com. 2993    IN      CNAME
mobile.events.data.trafficmanager.net.
mobile.events.data.trafficmanager.net.  22      IN      CNAME
skypedataprdcoleus14.cloudapp.net.
skypedataprdcoleus14.cloudapp.net.      4       IN      A       52.170.57.27

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 13 msec
;; SERVER: 192.168.200.1
;; WHEN: Wed Jan  6 20:22:30 2021
;; MSG SIZE  rcvd: 159
### DRILL END

All of the hosts use the same DNS service in the LAN however for some reason
both squid and the client are resolving different addresses
in a period of  10  Seconds.

The solution I am thinking is to force a minimum of 60 seconds caching using
dnsmasq or another caching service.
* https://unix.stackexchange.com/a/287908

Can we teach (theoretically) squid a way to look at these short TTLs as
something to decide by an ACL?

Thanks,
Eliezer

----
Eliezer Croitoru
Tech Support
Mobile: +972-5-28704261
Email: [hidden email]
Zoom: Coming soon



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

Re: Host header forgery detected on domain: mobile.pipe.aria.microsoft.com

Amos Jeffries
Administrator
FYI my long term plan is to extend squids internal representation of DNS results to include the TTL for each address, and set pass-thru client connection lifetimes to the TTL of the IP they are using. That will solve all the issues with pipelined traffic and expired TTLs which is a huge chunk of the current false positives.


If you (or anyone) wants to assist with coding please get in touch on squid-dev

Amos


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

Re: Host header forgery detected on domain: mobile.pipe.aria.microsoft.com

Alex Rousskov
In reply to this post by Eliezer Croitoru-3
On 1/6/21 2:49 PM, Eliezer Croitoru wrote:

> I am trying to think about the right solution for the next issue:
> SECURITY ALERT: Host header forgery detected on conn18767
> local=52.114.32.24:443 remote=192.168.189.52:65107 FD 15 flags=33 (local IP
> does not match any domain IP)

As you know, this has been discussed many times on this list before,
including recently[1]. I doubt anything has changed since then.

[1]
http://lists.squid-cache.org/pipermail/squid-users/2020-November/022912.html


> All of the hosts use the same DNS service in the LAN however for some reason
> both squid and the client are resolving different addresses
> in a period of  10  Seconds.

The "however for some reason" part feels misleading to me -- what you
observe is the direct, expected consequence of the low-TTL environment
you have described. There is no contradiction or uncertainty here AFAICT.


> The solution I am thinking is to force a minimum of 60 seconds caching using
> dnsmasq or another caching service.

FTR: Increasing DNS response TTL will reduce the number/probability of
false positives in forged Host header detection. No more. No less.


> Can we teach (theoretically) squid a way to look at these short TTLs as
> something to decide by an ACL?

Yes, it is possible. There is positive_dns_ttl already which specifies
an upper bound. One could add a similar positive_dns_ttl_min option that
would specify the lower bound. Like virtually any Squid directive, it
can be made conditional on ACLs.

IMO, violating DNS TTLs is not the right solution for this problem
though. See my response on the [1] thread for a better medium-term solution.


HTH,

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

Re: Host header forgery detected on domain: mobile.pipe.aria.microsoft.com

Eliezer Croitoru-3
Hey Alex,

The main issue now is the extensive logging.
For a tiny server with a single desktop client the cache.log  are expending a *lot*.
I have a problem with discarding these logs but for this specific case where the ttl is very low ie: lower < 30/20/10 seconds
We can expect for this to happen so we can disable the logs since the service continue to work with this low ttl.
The only and main issue is the extensive logging which is wrong.

Should we continue this on Squid-dev?

Eliezer

----
Eliezer Croitoru
Tech Support
Mobile: +972-5-28704261
Email: [hidden email]
Zoom: Coming soon


-----Original Message-----
From: Alex Rousskov <[hidden email]>
Sent: Wednesday, January 6, 2021 10:42 PM
To: [hidden email]
Cc: Eliezer Croitoru <[hidden email]>
Subject: Re: [squid-users] Host header forgery detected on domain: mobile.pipe.aria.microsoft.com

On 1/6/21 2:49 PM, Eliezer Croitoru wrote:

> I am trying to think about the right solution for the next issue:
> SECURITY ALERT: Host header forgery detected on conn18767
> local=52.114.32.24:443 remote=192.168.189.52:65107 FD 15 flags=33 (local IP
> does not match any domain IP)

As you know, this has been discussed many times on this list before,
including recently[1]. I doubt anything has changed since then.

[1]
http://lists.squid-cache.org/pipermail/squid-users/2020-November/022912.html


> All of the hosts use the same DNS service in the LAN however for some reason
> both squid and the client are resolving different addresses
> in a period of  10  Seconds.

The "however for some reason" part feels misleading to me -- what you
observe is the direct, expected consequence of the low-TTL environment
you have described. There is no contradiction or uncertainty here AFAICT.


> The solution I am thinking is to force a minimum of 60 seconds caching using
> dnsmasq or another caching service.

FTR: Increasing DNS response TTL will reduce the number/probability of
false positives in forged Host header detection. No more. No less.


> Can we teach (theoretically) squid a way to look at these short TTLs as
> something to decide by an ACL?

Yes, it is possible. There is positive_dns_ttl already which specifies
an upper bound. One could add a similar positive_dns_ttl_min option that
would specify the lower bound. Like virtually any Squid directive, it
can be made conditional on ACLs.

IMO, violating DNS TTLs is not the right solution for this problem
though. See my response on the [1] thread for a better medium-term solution.


HTH,

Alex.

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

Re: Host header forgery detected on domain: mobile.pipe.aria.microsoft.com

Alex Rousskov
On 1/6/21 10:26 PM, Eliezer Croitoru wrote:

> The main issue now is the extensive logging.

Please note that excessive logging may be the main issue for you and
_some_ Squid admins. For many, the main issue is denied transactions.
For some, it is cache misses. For some, it is a combination of things.
These facts make any single simple solution inapplicable to some use cases.

For example, you can trivially decrease the number (or, with a few more
code lines, frequency) of these messages, but it will not help with the
other problems I mentioned. FWIW, Factory is working on making all
level-0/1 messages configurable that way, but we need more time to
finish that project.

This does not mean that any simple partial solution is going to be
rejected, but please be very careful/specific in defining the problem
when proposing (or asking for) a solution.


> Should we continue this on Squid-dev?

IMO, if you are going to discuss the problem and possible
functionality-level solutions, then squid-users may be the best place
for that. If you are going to discuss code changes and similar
developer-level issues, use squid-dev.

Alex.


> -----Original Message-----
> From: Alex Rousskov <[hidden email]>
> Sent: Wednesday, January 6, 2021 10:42 PM
> To: [hidden email]
> Cc: Eliezer Croitoru <[hidden email]>
> Subject: Re: [squid-users] Host header forgery detected on domain: mobile.pipe.aria.microsoft.com
>
> On 1/6/21 2:49 PM, Eliezer Croitoru wrote:
>
>> I am trying to think about the right solution for the next issue:
>> SECURITY ALERT: Host header forgery detected on conn18767
>> local=52.114.32.24:443 remote=192.168.189.52:65107 FD 15 flags=33 (local IP
>> does not match any domain IP)
>
> As you know, this has been discussed many times on this list before,
> including recently[1]. I doubt anything has changed since then.
>
> [1]
> http://lists.squid-cache.org/pipermail/squid-users/2020-November/022912.html
>
>
>> All of the hosts use the same DNS service in the LAN however for some reason
>> both squid and the client are resolving different addresses
>> in a period of  10  Seconds.
>
> The "however for some reason" part feels misleading to me -- what you
> observe is the direct, expected consequence of the low-TTL environment
> you have described. There is no contradiction or uncertainty here AFAICT.
>
>
>> The solution I am thinking is to force a minimum of 60 seconds caching using
>> dnsmasq or another caching service.
>
> FTR: Increasing DNS response TTL will reduce the number/probability of
> false positives in forged Host header detection. No more. No less.
>
>
>> Can we teach (theoretically) squid a way to look at these short TTLs as
>> something to decide by an ACL?
>
> Yes, it is possible. There is positive_dns_ttl already which specifies
> an upper bound. One could add a similar positive_dns_ttl_min option that
> would specify the lower bound. Like virtually any Squid directive, it
> can be made conditional on ACLs.
>
> IMO, violating DNS TTLs is not the right solution for this problem
> though. See my response on the [1] thread for a better medium-term solution.
>
>
> HTH,
>
> Alex.
>
> _______________________________________________
> 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: Host header forgery detected on domain: mobile.pipe.aria.microsoft.com

Eliezer Croitoru-3
Thanks Alex,

For now staying on the admin level.
I understand that the issues are affecting and that a solution will affect functionality.
I will try to take two scenarios:
- short ttl
- nxdomain

With the short ttl it's probably ok in many of the setups to have different resolution between the client and the proxy.
It might affect some connections (which is bad from the service provider side..) but else then cache misses it's acceptable
for application level services.
For content services it's a whole new story.

About the nxdomain case, there are couple options:
- What happen when there is no domain at all, will squid allow it? A default allow/deny and ACL based might be a good solution.
- When the client is using an internal DNS via ssl VPN while the actual end point is on the internet on the public WWW.

I have seen a scenario which the proxy resolves to another domain and IP and for this it would be smart to allow by ACLS
an override for the host header forgery.

I do not expect things to be done in a second since these in most of the cases are a "patch" not a solution.

I would like to hear what do you think about these real world scenarios which are far more important
then basic caching while not lowering the caching as important as the service itself.

Eliezer

----
Eliezer Croitoru
Tech Support
Mobile: +972-5-28704261
Email: [hidden email]
Zoom: Coming soon


-----Original Message-----
From: Alex Rousskov <[hidden email]>
Sent: Thursday, January 7, 2021 6:08 PM
To: Eliezer Croitoru <[hidden email]>; [hidden email]
Cc: [hidden email]
Subject: Re: [squid-users] Host header forgery detected on domain: mobile.pipe.aria.microsoft.com

On 1/6/21 10:26 PM, Eliezer Croitoru wrote:

> The main issue now is the extensive logging.

Please note that excessive logging may be the main issue for you and
_some_ Squid admins. For many, the main issue is denied transactions.
For some, it is cache misses. For some, it is a combination of things.
These facts make any single simple solution inapplicable to some use cases.

For example, you can trivially decrease the number (or, with a few more
code lines, frequency) of these messages, but it will not help with the
other problems I mentioned. FWIW, Factory is working on making all
level-0/1 messages configurable that way, but we need more time to
finish that project.

This does not mean that any simple partial solution is going to be
rejected, but please be very careful/specific in defining the problem
when proposing (or asking for) a solution.


> Should we continue this on Squid-dev?

IMO, if you are going to discuss the problem and possible
functionality-level solutions, then squid-users may be the best place
for that. If you are going to discuss code changes and similar
developer-level issues, use squid-dev.

Alex.


> -----Original Message-----
> From: Alex Rousskov <[hidden email]>
> Sent: Wednesday, January 6, 2021 10:42 PM
> To: [hidden email]
> Cc: Eliezer Croitoru <[hidden email]>
> Subject: Re: [squid-users] Host header forgery detected on domain: mobile.pipe.aria.microsoft.com
>
> On 1/6/21 2:49 PM, Eliezer Croitoru wrote:
>
>> I am trying to think about the right solution for the next issue:
>> SECURITY ALERT: Host header forgery detected on conn18767
>> local=52.114.32.24:443 remote=192.168.189.52:65107 FD 15 flags=33 (local IP
>> does not match any domain IP)
>
> As you know, this has been discussed many times on this list before,
> including recently[1]. I doubt anything has changed since then.
>
> [1]
> http://lists.squid-cache.org/pipermail/squid-users/2020-November/022912.html
>
>
>> All of the hosts use the same DNS service in the LAN however for some reason
>> both squid and the client are resolving different addresses
>> in a period of  10  Seconds.
>
> The "however for some reason" part feels misleading to me -- what you
> observe is the direct, expected consequence of the low-TTL environment
> you have described. There is no contradiction or uncertainty here AFAICT.
>
>
>> The solution I am thinking is to force a minimum of 60 seconds caching using
>> dnsmasq or another caching service.
>
> FTR: Increasing DNS response TTL will reduce the number/probability of
> false positives in forged Host header detection. No more. No less.
>
>
>> Can we teach (theoretically) squid a way to look at these short TTLs as
>> something to decide by an ACL?
>
> Yes, it is possible. There is positive_dns_ttl already which specifies
> an upper bound. One could add a similar positive_dns_ttl_min option that
> would specify the lower bound. Like virtually any Squid directive, it
> can be made conditional on ACLs.
>
> IMO, violating DNS TTLs is not the right solution for this problem
> though. See my response on the [1] thread for a better medium-term solution.
>
>
> HTH,
>
> Alex.
>
> _______________________________________________
> 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