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

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

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

reinerotto
Running squid 4.4 on very limited device, unfortunately quite a lot of
messages: "... SECURITY ALERT: Host header forgery detected ... "  show up.
Unable to eliminate real cause of this issue (even using iptables to redir
all DNS requests to one dnsmasq does not help), these annoying messages tend
to fill up cache.log, which is kept in precious RAM.
Is there an "official" method to suppress these messages ?
Or can you please give a hint, where to apply a (hopefully) simple patch ?





--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: squid on openwrt: Possible to get rid of "... SECURITY ALERT: Host header forgery detected ..." msgs ?

Amos Jeffries
Administrator
On 23/01/19 9:22 pm, reinerotto wrote:
> Running squid 4.4 on very limited device, unfortunately quite a lot of
> messages: "... SECURITY ALERT: Host header forgery detected ... "  show up.
> Unable to eliminate real cause of this issue (even using iptables to redir
> all DNS requests to one dnsmasq does not help), these annoying messages tend
> to fill up cache.log, which is kept in precious RAM.
> Is there an "official" method to suppress these messages ?
> Or can you please give a hint, where to apply a (hopefully) simple patch ?
>

See <https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery>

FYI: There is still active malware out there searching for proxies that
are vulnerable and utilizing them for nefarious uses.


The last person to ask this questio turned out to have a network
infected with that malware.
I thought last year that a decade of fixed Squid being used was long
enough for things to die down and let us loosen up a bit. Then was
informed about yet another ISP being attacked through those methods. So
no, an official patch removing them is not on the book yet.

Almost all the ways we are able to reduce the side effects have been
done and are included in that Squid-4.4

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

Re: squid on openwrt: Possible to get rid of "... SECURITY ALERT: Host header forgery detected ..." msgs ?

reinerotto
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.
There are some "rumours", that not all browsers correctly honor TTL for
cached DNS.


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.




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: squid on openwrt: Possible to get rid of "... SECURITY ALERT: Host header forgery detected ..." msgs ?

Amos Jeffries
Administrator
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: squid on openwrt: Possible to get rid of "... SECURITY ALERT: Host header forgery detected ..." msgs ?

Leonardo Rodrigues Magalhães
In reply to this post by reinerotto
Em 23/01/2019 06:22, reinerotto escreveu:

> Running squid 4.4 on very limited device, unfortunately quite a lot of
> messages: "... SECURITY ALERT: Host header forgery detected ... "  show up.
> Unable to eliminate real cause of this issue (even using iptables to redir
> all DNS requests to one dnsmasq does not help), these annoying messages tend
> to fill up cache.log, which is kept in precious RAM.
> Is there an "official" method to suppress these messages ?
> Or can you please give a hint, where to apply a (hopefully) simple patch ?
>
>
>

     I have some OpenWRT boxes running squid 3.5 and cache_log simply
goes null ... i do have access log enabled, with scripts to rotate,
export to another server (where log analyzis are done) and keep just a
minimum on the box itself, as storage is a big problem on these boxes.



--


        Atenciosamente / Sincerily,
        Leonardo Rodrigues
        Solutti Tecnologia
        http://www.solutti.com.br

        Minha armadilha de SPAM, NÃO mandem email
        [hidden email]
        My SPAMTRAP, do not email it



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

Re: squid on openwrt: Possible to get rid of "... SECURITY ALERT: Host header forgery detected ..." msgs ?

Alex Rousskov
In reply to this post by Amos Jeffries
On 1/23/19 6:44 PM, Amos Jeffries wrote:
> For now all we can do is take the warnings seriously and find ways to
> prevent the network behaviours that cause them.

For the record, the above is an opinion rather than a fact or consensus.
There are, of course, other (and far more realistic/useful) things we
could do. For example, we could give the admin the choice of which
"forgeries" should be classified as false positives and treated
accordingly, and we could improve reporting of the "forgeries" so that
the reporting itself does not become a problem.


> The security issues this detection prevents are so nasty we consider
> the pain worth the price of avoiding those outcomes.

In many cases, it would be possible for admins to suffer virtually no
"pain" while still "preventing security issues" and following best
practices (such as keeping logging enabled).

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