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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
