https://www.haskellforall.com/2024/08/firewall-rules-not-as-secure-as-you.html
This post introduces some tricks for jailbreaking hosts behind "secure" enterprise firewalls in order to enable arbitrary inbound and outbound requests over any protocol. You'll probably find the tricks outlined in the post useful if you need to deploy software in a hostile networking environment.
The motivation for these tricks is that you might be a vendor that sells software that runs in a customer's datacenter (a.k.a. on-premises software), so your software has to run inside of a restricted network environment. You (the vendor) can ask the customer to open their firewall for your software to communicate with the outside world (e.g. your own datacenter or third party services), but customers will usually be reluctant to open their firewall more than necessary.
For example, you might want to ssh into your host so that you can service, maintain, or upgrade the host, but if you ask the customer to open their firewall to let you ssh in they'll usually push back on or outright reject the request. Moreover, this isn't one of those situations where you can just ask for forgiveness instead of permission because you can't begin to do anything without explicitly requesting some sort of firewall change on their part.
So I'm about to teach you a bunch of tricks for efficiently tunneling whatever you want over seemingly innocuous openings in a customer's firewall.....
We are not condoning such actions, but you cannot secure your own systems unless you know how the opposition will attack them.
(Score: 4, Insightful) by JoeMerchant on Saturday August 31, @05:13PM (1 child)
In 2012 we were using a commercial solution to tunnel VNC connections over https port 443. You put their agent on your remote system and run a standard VNC server open to connections on local host. Then the remote view/control client connects through a web interface that uses the tunnel (and provides the vendor a way to lock you in...)
Bottom line: if you are letting any data through your firewall, ANY data can pass your firewall.
🌻🌻 [google.com]
(Score: 1, Informative) by Anonymous Coward on Saturday August 31, @07:43PM
There are ways to detect and block different forms of tunneling, but they become increasingly complex and less easily effective the deeper you try to go. Analyzing headers is pretty straightforward and reasonable, but deep packet analysis is straight up black magic. The price:work ratio ends ramps up very quickly and so it all ends up in the domain of reaction rather than mitigation.
(Score: 2, Informative) by shrewdsheep on Saturday August 31, @05:55PM (5 children)
One of the most clever tools I have encountered in the realm of networking:
https://github.com/samyk/pwnat [github.com]
Bottom line: if you do not employ unicorn poo, your network is open as a sieve
(Score: 4, Interesting) by JoeMerchant on Saturday August 31, @06:19PM (1 child)
The commercial pitch was: if the network lets people do online banking, or any other https traffic, then they have no way to tell what is passing through the secured connection. Packet sniffing is useless on end to end encrypted connections.
They can tell the MAC and IP of the endpoint doing the talking, they know the traffic volume over time patterns, but unless you have that unicorn poo in your algorithms, you don't know whether the encrypted data is streaming video, the payroll database, or nuclear launch codes.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Sunday September 01, @08:47AM
That's BS/Unicorn Poo for now[1] though. Since they often have the hostname:
https://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org]
https://www.cloudflare.com/learning/ssl/what-is-sni/ [cloudflare.com]
[1] Unicorn Poo might be on the way: https://www.cloudflare.com/learning/ssl/what-is-encrypted-sni/ [cloudflare.com]
(Score: 5, Funny) by Gaaark on Saturday August 31, @07:56PM
I employed Unicorn Poo for a while, but his Visa got cancelled when he tried straining spaghetti through our network.
:)
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 2, Informative) by Anonymous Coward on Sunday September 01, @08:42AM
Does that work if both hosts are behind FreeBSD NATs? Unlike Linux which does "cone NAT", FreeBSD does "symmetric NAT" (it uses random source ports for outbound stuff). Cone and symmetric NAT are not my terms.
https://serverfault.com/questions/67249/freebsd-nat-via-pf-how-to-change-from-random-udp-ports-to-incremental [serverfault.com]
(Score: 2) by tbuskey on Tuesday September 03, @10:06PM
I've seen the response from non-existant hosts. We had a firewall up but the other end was disconnected.
We kept getting responses from 8.8.8.8, 4.2.2.2 and one other.
The 1st 2 are DNS servers. The other one was an IP that resolved to an internet service providing info for DLNA.
It freaked out the CCNA who set up the firewall, etc. In fairness to him, he was very sleep deprived & had to leave to catch a plane.
I traced it to the UPnP/DLNA client service on Windows 7 Enterprise Pro
I figured out it was trying to get the latest info/schemas for any DLNA/UPnP devices.
It couldn't get the IP for the load balanced DNS name, so it tried to reach well known DNS servers on the internet to do a DNS query.
Finally, it tried the IP of the service. And repeat.
It also chewed up lots of the network capacity with only 6 Win7 desktops and 2 Win 2008 AD servers on the LAN.
Why UPnP/DLNA needs to run by default...
(Score: 4, Informative) by fraxinus-tree on Saturday August 31, @06:54PM
It is still understandable when one has to use these tricks in order to do setup or support. I had to run production data over ssh -R thing with a script that restarted the client side ssh. For years.
(Score: 5, Interesting) by Rosco P. Coltrane on Saturday August 31, @07:40PM (1 child)
Nobody SSH into any of our machines on the intranet. Are you kidding me? Whoever asks this can fuck right off.
We do have some systems that need maintenance sometimes, like complex test equipment that needs calibrating - including some who use TeamViewer to take over the tester's computer and install whatever proprietary software they have going there that needs updating. There's no way on God's green Earth I'm letting a TeamViewer session on a machine on the intranet unprotected.
Also, in this day and age, more often than not, we have to assume the proprietary software we have to install from our vendors *is* the adversarial bit. Vendors love to slurp up data that isn't theirs to take or do telemetry without asking these days, so we tend to sandbox applications, restrict the network hosts they can hit very heavily and demand explanations from the vendors when they try to connect to sketchy stuff. And we sure don't use firewalls running on the same machine too.
It's sad but the enemy is often our business partners and suppliers now, who should be regarded as basically untrustworthy,
(Score: 4, Insightful) by Anonymous Coward on Saturday August 31, @08:01PM
Somehow, we have to depreciate financial motivation in human endeavors. Economics is so primal! And it takes the fun out of sex
We have met the Ferengi, and they are us!