I was expecting another section about all the other ways a corporate firewall can cause issues. Not all firewalls will give you a 403. Sometimes it will be a 200 with the error in the body. Sometimes you'll just never get a response at all. Sometimes you will get an SSL certificate error, because the error response is signed using the certificate for the firewall vendor's domain instead of yours. And etc.
How I learned about corporate firewalls
91–100 of 204 posts
Re: How I learned about corporate firewalls
#92We once had to fight for stackoverflow access. Security responds: you devs should only require the manual provided by the vendor(in this case: Oracle javadocs)?
As a security guy, we are taught the CIA triad early and it's easy to forget. The A stands for availability and if you don't make things available, you're failing at your own job.
Well, that depends. You certainly want to ensure the availability of the information under your remit isn't compromised by a threat actor, but reducing your attack surface by, say, shutting down external internet access is certainly a valid mitigation in some circumstances.
Re: How I learned about corporate firewalls
#93We once had to fight for stackoverflow access. Security responds: you devs should only require the manual provided by the vendor(in this case: Oracle javadocs)?
There are a number of sites categorized as 'file sharing or download' that we can't get to, here. Ugh. Bad idea when your userbase runs on free software.
Oddly enough, I can get on imgur
Re: How I learned about corporate firewalls
#94I 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…
You won't believe it, but the "one network" came back nowadays. It's called "zero trust", basically treating your internal network as public.
Re: How I learned about corporate firewalls
#95I 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…
> IT absolutely doesn't give a flying ** about developers. They are not paid to. Their performance is judged against how close they get to zero compliance issues, not how close they get to zero times developers were unhappy! > I think they're preventing people from hiding their internet browsing. Without delving into the “do you have the right to privacy even on a company machine”, who would be daft enough to do some…
You’re just arguing for surveillance (by capital or state) with the tired line of you should have nothing to worry about unless you deserve it which is absurd/reactionary
Re: How I learned about corporate firewalls
#96We once had to fight for stackoverflow access. Security responds: you devs should only require the manual provided by the vendor(in this case: Oracle javadocs)?
If anyone is stuck somewhere like this, Stack Overflow has dumps regularly updated on archive.org -- https://archive.org/download/stackexchange/ Dash (or its Windows equivalent, name escapes me) can be used to view and search these dumps (as well as dumps from GitHub, language docs, etc) offline: https://kapeli.com/dash
Archive.org is also blocked in a lot of these places.
Re: How I learned about corporate firewalls
#97Earlier quoted context omitted.
> IT absolutely doesn't give a flying ** about developers. They are not paid to. Their performance is judged against how close they get to zero compliance issues, not how close they get to zero times developers were unhappy! > I think they're preventing people from hiding their internet browsing. Without delving into the “do you have the right to privacy even on a company machine”, who would be daft enough to do some…
You’re just arguing for surveillance (by capital or state) with the tired line of you should have nothing to worry about unless you deserve it which is absurd/reactionary
I'm not saying it is right for people to be monitored, but that I would never trust that I wasn't being so I'd not be daft enough to do something I don't want the company to know about using their resources.
And there are perfectly valid reasons for companies to monitor traffic: data exfiltration, accidental or malicious, is a significant concern for companies that hold and process PII and for the people who have their PII held/processed by those companies. It is not as black & white as “monitoring and surveillance bad” unless you only care about your personal privacy.
Re: How I learned about corporate firewalls
#98I 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…
You won't believe it, but the "one network" came back nowadays. It's called "zero trust", basically treating your internal network as public.
Zero Trust pricniples may implie having a flat underlay but explicitly access to applications and services should be microsegmented, least privilege, and authenticate/authorised on strong identity before any connectivity can be established - i.e., the overlay is closed by default and does not trust the underlay. Ideally you put ZT inside an application so you do not need to have any inbound ports, public DNS, etc etc.
Re: How I learned about corporate firewalls
#99I 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 absolutely doesn't give a flying ** about developers.
Add their cert to system store ? Won't help inside containers tho... without much fuckery
Re: How I learned about corporate firewalls
#100Earlier quoted context omitted.
There's a subjectively legitimate reason to consider blocking POST (but not GET) requests ruder things than "overzealous."
> There's a subjectively legitimate reason to consider blocking POST (but not GET) No, just no. In a world where many website use GraphQL (POST request with content) (or gRPC) that's complete garbage decision. - This kind of brain-dead admin decision is exactly what bring protocol abuse: people would just use GET query with a ton of parameters and violate semantic just to avoid stupid middle box problems. Same goes w…
[deleted]