NethServer Version: 7.9.2009
Module: Web Proxy & Filter
Hi, I have Nethserver installed in a secodary school with transparent HTTPS proxy on. I have some blacklists enabled and direct connection to IP address through squid are disabled.
Recently I’ve detected some strange behaviours in ligthsquid reports. For some students there is a lot of data downloaded from legit domains like mozilla.org (up to 6GB for one user in a single day). Looking with more detail in the access.log files from squid I’ve seen that the destinations IP address of this connections doesn’t belong to mozilla.org, for instance:
1611760695.333 2370505 192.168.171.31 TCP_TUNNEL/200 10782129 CONNECT mozilla.org:443 ORIGINAL_DST/185.209.178.203 -
dig +noall +answer mozilla.org
mozilla.org. 1497 IN A 44.236.48.31
mozilla.org. 1497 IN A 44.235.246.155
mozilla.org. 1497 IN A 44.236.72.93
I suspect that it is some kind of browser plugin that spoofs TLS handshake to set a VPN trough squid by setting a harmless domain in the SNI field while connecting to a different IP address. Correct if I’m wrong, but I think that the squid build included in Nethserver, unlike the official version, doesn’t check that the SNI corresponds to the destination IP address, right?
That’s ok, and it’s the main reason why I moved from a custom build firewall/proxy to Nethserver, because for big sites like google that use DNS records with a TTL of 0 seconds, SSLBump was a nightware.
I’ve found that ufdbguard has two settings that in its documentation are recommended to be left on, but in Nethserver default configuration they are disabled: enforce-https-with-hostname and enforce-https-official-certificate. This morning I’ve set them to on with a custom template and I will check squid logs to see if they are enough to block this connections.
Does someone else detected this kind of connections?
I can’t find similar lines in my logs.
I don’t remember the details, but setting the enforce options could break some site/app. And I don’t think they will help in your case.
I’ll try to have a deeper look at my notes on ufdbguard, please keep me updated.
Hi Filippo.
Sadly, these settings didn’t block the connections. I suposed that the first one, enforce-https-with-hostname, was not useful in this case, as the request include the forged SNI, but the second one, enforce-https-official-certificate, wasn’t useful either.
It seems that some applications, like Hotspot Shield, exploit this vulnerability to establish an VPN to circumvent any kind of filter, as it is mentioned in this reddit post:
I’ve being searching in Threat Shield ipsets if some the suspicious IP addresses are included in any list, so I could activate one that could block the connections, but only a few of them are.
I’m afraid that if there isn’t any better solution I will have to go back to a standard proxy configuration and leave aside the transparent HTTPS funcionality.
You may have one more chance: nDPI should detect Hotspot Shield.
Hi Filippo, I’ve just installed it and I will check next Monday if it is able to detect and block it.
Thanks for your help.
Sadly, nDPI hasn’t been able to block the connections. I’ve been checking all morning and users are still going through squid with the spoofed SNI.
I’m not sure if the reason is that nDPI is not able to detect this kind of traffic or maybe is the order in which the rules are processed. I added a rule to drop service hotspotshield from ANY to ANY at the top. I’ve seen that in the FORWARD chain there is a rule for ndpi. However, as transparent https proxy is enabled, in the PREROUTING chain all web traffic is redirected to the local squid, so maybe nDPI is never called? I tried to add the rule into local rules and try to block the connections leaving or entering squid, but there is no option to select hotspotshield as service
Could you check if the nDPI engine has detected any hotspot shield traffic?
(click Details in the Services nDPI section of the firewall dashboard)
Could you also post the output of iptables -vnL?
Hi Filippo,
the counter for Hotspotshield shows 0 matches, but for other applications the counter goes up, so it seems that either it is not detecting Hotspotshield or the students are using a different application.
Here is the output from iptables -vnL (I’ve removed public addresses):
https://drive.google.com/file/d/1bwWJwjWmMXu1EfyxLc_xtfE00c6E2gvN/view?usp=sharing
I’ve noticed that it doesn’t show the rules I added for services related to nDPI (included screenshot).
nDPI rules are in the mangle table.
But you are right: maybe, hotspot shield is no longer recognized by nDPI or the students are using something else. You can remove the rule.
You could capture some traffic to analyze it, but it may still be hard to detect and block the unwanted traffic.
I’ve captured some of the traffic and I’ve seen that in TLS handshake the destination servers are sending invalids certificates for the pretended domains.
Maybe there is a way to block this? I tried with the option “enforce-https-official-certificate” of ufdbguard at the beginning but I think that it didn’t work.
@Juan_Martin
Hi Juan Martin
A simple fix, at least if you have a list of the attempted accesses to the real IPs…
Create a route to that host / network pointing to a non existant router in your LAN.
If your NethServer is your Gateway, then add in the route eg:
Route 185.209.178.203 Gateway: 192.168.1.253 (Non existing!)
Even Squid will point any traffic there, so will any attempted direct access from any clients…
This is called “null-routing”…
My 2 cents
Andy
Thanks Andy, but it’s not an option in this case, because I’ve detected more than a hundred of suspicious IPs addresses that are being used by this kind of vpn.
I thought about creating an ipset and load it in Threat Shield, but I don’t know if I will be blocking some legit servers or if new IP addresses will be used, as the application seems to be adaptative.
1 Like
I think that it should work. I suggest to use ufdb-debug-filter on and ask on the mailing list.
Thanks again Filippo.
I tried re-enabling these options on ufdbguard but it didn’t work, the connections are not blocked. The debug output didn’t show any check of the forged servers certificates, maybe because it was cached, as it is not using the destination IP address to request the certicate, just the SNI.
I checked ufdbguard manual and squid.conf and for what I’ve seen, the destination IP address is never supplied to ufdbguard (should be ‘<a’), only the SNI:
url_rewrite_extras "%>a/%>A %un %>rm bump_mode=%ssl::bump_mode sni=\"%ssl::>sni\" referer=\"%{Referer}>h\""
So, other than my idea of building a ipset with the addresses that I’ve collected, the only solution would be disabling transparent https.
About Thread Shield, would it be enough to add a text file with the ip address in /usr/share/nethserver-blacklist/ipsets/ and add the category to the db?
ipsets are a common way to block such VPN tools. 
Yes.
Thanks for all your help Filippo.
I had some problems adding a custom blacklist to Threat Shield, but I will open a new thread as it is not related to the original subject of this one.
