Ah, yes, the old "the most secure device is one that is not working", or in this case that is blocked from working. :-)
Think inside the box!
How I learned about corporate firewalls
111–120 of 204 posts
Re: How I learned about corporate firewalls
#112I work at a government agency and here are my tales. 1) They install a root certificate on all machines and use that to MITM all TLS connections using a firewall appliance. They turn this MITM on one day without notifying any developer. Overnight, all our builds (run on-prem) fail because npm install, pip install etc fail and we spent a long time trying to figure it out. They are still failing to this day and I have…
Why are they allowing you to run npm, pip, etc from public repositories at all? That's a huge supply chain risk. If builds are worth doing on prem they also need to be pulling solely from internal, vetted repositories.
This is a big worry of mine.
I've worked in various places from big finance, public sector, to privately owned. It was only the big finance institution (the biggest) that actually seemed to care about supply chain attacks. Everything was locked down super well and you could not! use a random library without it getting vetted by a central team. In fact, we were even locked down to specific versions of programming languages.
People see this as annoying and in the way of developers, but it really is the only way to secure your development "supply chain". When people cry about this I always ask: do you really want the entire financial industry grinding to a halt because someone took down left-pad?
Re: How I learned about corporate firewalls
#113My favourite issue caused by a corporate firewall was when it altered an AJAX request to replace a specific combination of digits (in a long product ID) by asterisks. Turns out that a substring of that product ID matched the client company's phone number and their security theatre intercepting proxy was replacing all occurrences of "sensitive" strings sent to the internet with asterisks. The irony is, of course, that…
Did you let them know? They of course need to patch this vulnerability by blocking anything containing 11 consecutive digits.
That's crazy!
The right thing would be to add a lookup function to first verify the phone number is in use and then call the number to ask for permission to use it; followed by a webhook to send a confirmation back to the database to cache that info because this needs to be efficient!
/s
Re: How I learned about corporate firewalls
#114Firewalls from security vendors with L7 decryption (using MITM root certificates from a company-wide PKI) is pretty standard in any business that needs to care about "cyber security".
I always hear people cry and moan about this but having worked on that side of the fence I would like you to know that I know of instances where people have been downloading illegal material (involving children) and running tor. That's not to mention the 75% of staff who willing give details during phishing campaigns.
Saying that, I find 60%+ of cyber businesses to be a waste of time at best, and at worse just frauds. Core firewalls with L7 capabilities from vendors such as Palo Alto and CheckPoint are legitimate security devices, especially suited for enterprise networks.
I do think it's pretty pointless running those in the cloud though, unless you have admin VMs on vnets for your production resources. But that way lies madness anyway.
Re: How I learned about corporate firewalls
#115While I am sympathetic with the developer, a large part of fault lies with them. Firewall actually behaved very nicely.
Always check status codes. Don't assume that backend (even if it is your own server) behaves as you think it should - complain when the response is not what you would have expected.
This is why I hate those error responses that encode the error message into JSON and return status 200. Gee, thanks - your backend is so special that it is an honor to write custom error handling for it. /s
Glad OP solved it in the end, but I would suggest reacting to all 4xx and 5xx statuses. It's a standard, if you get 418 you know what "your" backend is saying.
Re: How I learned about corporate firewalls
#116I worked in a financial company in mid 2000s where the network head did not believe in internal firewalls so that all internal users were on the same network as all the web app servers and database servers. If someone was downloading a movie then customer web access slowed; since everyone used Windows everyone was required to run virus scanners on their computers and that included the app and database server machines…
This sounds like most of the early ISPs I worked at. No firewalls, and switches weren't popular yet, so we had hubs. The "backbone" of the ISP network was the same as the main office network. Any employee could just tcpdump all the traffic. Actually, we had a couple of customer-owned servers that were colocated, that could also dump all the traffic. Eventually someone set up a firewall (Linux box with dual ethernets) to segment the colo traffic.
Re: How I learned about corporate firewalls
#117I work at a government agency and here are my tales. 1) They install a root certificate on all machines and use that to MITM all TLS connections using a firewall appliance. They turn this MITM on one day without notifying any developer. Overnight, all our builds (run on-prem) fail because npm install, pip install etc fail and we spent a long time trying to figure it out. They are still failing to this day and I have…
For good reason. Stuff like that is a really high risk and won’t meet audit standards.
I’m in charge of the IT goons somewhere. We aspire to provide a better level of service and maintain local repos of things you’re allowed to use. Stuff like Node isn’t allowed near anything important though.
I would be careful. An agency doing stuff like that is probably running an EDR that will detect and report on what you’re doing. If it catches what you’re up to, you’ll be jammed up.
Re: How I learned about corporate firewalls
#118I work at a government agency and here are my tales. 1) They install a root certificate on all machines and use that to MITM all TLS connections using a firewall appliance. They turn this MITM on one day without notifying any developer. Overnight, all our builds (run on-prem) fail because npm install, pip install etc fail and we spent a long time trying to figure it out. They are still failing to this day and I have…
And that kids is how it looks when security team just sits in their ivory tower and shits on everyone else in name of security theathre they're paid to play > Overnight, all our builds (run on-prem) fail because npm install, pip install etc fail and we spent a long time trying to figure it out. They are still failing to this day and I have to get off the VPN every time I need to run these simple commands. IT absolute…
Why not? Just mount a volume with certs and you're good to go. In every container, of course.
Re: How I learned about corporate firewalls
#119Earlier quoted context omitted.
> What classifies this as an "overzealous" act of network configuration? There may be a subjectively legitimate reason the user's network was configured this way. Worked at a large FI. Our corporate firewall used to block any website or payload that contained the word "hack". At one point, the security team decided to roll out a change that blocked all verbs except GET and POST without telling anyone. I could go on.
And the nearby Burger Shack wondered why their online orders plummeted.
They were using PUT instead of POST for orders?
Re: How I learned about corporate firewalls
#120My favourite issue caused by a corporate firewall was when it altered an AJAX request to replace a specific combination of digits (in a long product ID) by asterisks. Turns out that a substring of that product ID matched the client company's phone number and their security theatre intercepting proxy was replacing all occurrences of "sensitive" strings sent to the internet with asterisks. The irony is, of course, that…
[deleted]