[squid-users] squid on openwrt: Possible to get rid of "... SECURITY ALERT: Host header forgery detected ..." msgs ?

[Amos Jeffries]

On 24/01/19 2:55 am, reinerotto wrote:
> I suspect, these messages, for example, are not caused by any malware, but
> somehow by skype:
> 
> 2019/01/23 13:38:18 kid1| SECURITY ALERT: on URL:
> mobile.pipe.aria.microsoft.com:443
> 2019/01/23 13:38:18 kid1| SECURITY ALERT: Host header forgery detected on
> local=52.114.76.35:443 remote=192.168.182.10:59312 FD 31 flags=33 (local IP
> does not match any domain IP)
> 2019/01/23 13:38:18 kid1| SECURITY ALERT: on URL:
> mobile.pipe.aria.microsoft.com:443
> 2019/01/23 13:39:03 kid1| SECURITY ALERT: Host header forgery detected on
> local=52.114.74.44:443 remote=192.168.182.10:59378 FD 37 flags=33 (local IP
> does not match any domain IP)
> 2019/01/23 13:39:03 kid1| SECURITY ALERT: on URL:
> mobile.pipe.aria.microsoft.com:443
> 
> 
> May be,  some inconsistency of cached DNS in the client and the
> openwrt-device, running squid.


I have checked those domains and their DNS results. Their IPs change
every 30sec to another random IP in a /16 block belonging to a company
which is *not* Microsoft. This is just one /16 out of the 10s of
millions of IPs MS have allocated.

If you can track down any inconsistency in DNS caching that would help
reduce the frequency of false-positive tests and generally improve the
behaviour of all software using that DNS cache.


Meanwhile directly addressing those warnings would be reducing or
removing the use of HTTP persistence on client connections.

 <http://www.squid-cache.org/Doc/config/client_lifetime/>
 <http://www.squid-cache.org/Doc/config/client_persistent_connections/>



> There are some "rumours", that not all browsers correctly honor TTL for
> cached DNS.

Um, I suspect you don't understand what that use of double-quote means:
rumours about rumours existing. Either way that does not matter.


What Browsers do is use persistent connections. Part of HTTP design, and
used in reasonable ways. It's just that DNS TTL may have different
duration - case in point being these Skype connections where the IP is
forced to change every 30sec, persistence is indefinite but usually
several minutes.
Consider having a Skype chat where you close and re-open the app every
30sec versus only doing that once and hour, or once a day. DNS Best
Practice is/was to use 24hr TTLs - the mega corps do their own thing, so
one guess why your logos are so annoying?


With short DNS TTL by the time a second (or third, or Nth) HTTP request
is sent in the connection the origin has all the appearance of having
moved elsewhere and become indistinguishable from an attacker diverting
traffic to get themselves a trivial tunnel into your network.


For now all we can do is take the warnings seriously and find ways to
prevent the network behaviours that cause them. The security issues this
detection prevents are so nasty we consider the pain (monetary costs,
latency and bandwidth - not just log sizes) worth the price of avoiding
those outcomes.


> 
> Anyway, even, in case malware would trigger these messages, then this opens
> the gate to attack resource limited squid-installations, like mine on
> openwrt, by flooding cache.log, kept in RAM, and possibly forcing an
> OOM-crash.
> Simple fix would be to disable cache.log, but I am hesitating to do so, not
> to drop more valuable messages.

That OpenWRT case is exactly what squid.conf "debug_options rotate=N"
option was designed for. Set the N to the number of cache.log files you
want to retain. A log monitor to trigger "squid -k rotate" when the logs
get too large completes the picture for complete control over how much
memory is spent on these logs.
 An older solution is to place a Unix pipe at the cache.log filesystem
path. Sending the log lines either directly to a processor or another
device entirely.

Amos