Yep not to mention pushing their SSL root CA to all the clients so they can scan everything without SSL errors.
How I learned about corporate firewalls
11–20 of 204 posts
Re: How I learned about corporate firewalls
#12"Aha, so an overzealous IT network decided to block the request before it even reached my server."
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.
"I had no idea I was ever going to get anything different."
There's an entire list of HTTP status codes. That was your clue that you would get something different. You made a decision to not have handling for them all. Not implementing handling for 418 is understandable, but forbidden and service unavailable responses are common enough.
Re: How I learned about corporate firewalls
#13We 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.
Re: How I learned about corporate firewalls
#14If I want to push to GitHub when I am in the office, I have to VPN out of the office connection because Port 22 is blocked. And they wonder why I prefer to work from home?
My solution was to run an sshd on port 443.
I currently no longer need to do so right this minute, but sometimes people do keep asking me why I still have that.
---
Not sure if this still works on modern corporate networks. These days I tether to a mobile phone with unlimited internet; which is all-around easier to work with.
Re: How I learned about corporate firewalls
#15> It helpfully spits out this HTML response in return but, of course, my frontend code was expecting a JSON response. I had no idea I was ever going to get anything different.
I wish more front-end devs recognized that they're building HTTP clients whenever they make HTTP requests. There's a whole specification written about how to do that well so one doesn't have to learn things like this the hard way. Specs may look old and esoteric, but following them bakes hard-earned wisdom into your apps for free.
Re: How I learned about corporate firewalls
#16We 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)?
About 2003/2004 I was working onsite at a customer that blocked access to Google - that was fun.
As recently as 2015 I was working at a customer site where the web proxies were so misconfigured that Google was effectively blocked. The main page would load about a third of the time after maybe ten or twenty seconds. This was a huge org with 15K users, including dozens of developers and hundreds of general IT staff.
Turns out that a one-checkbox-tick fix was all it took to make that go away. The woman in charge of the web proxies panicked, thinking that this change had "broken something", reverted the change, and then refused to change it back.
Fun times.
Re: How I learned about corporate firewalls
#17If I want to push to GitHub when I am in the office, I have to VPN out of the office connection because Port 22 is blocked. And they wonder why I prefer to work from home?
My solution was to run an sshd on port 443. I currently no longer need to do so right this minute, but sometimes people do keep asking me why I still have that. --- Not sure if this still works on modern corporate networks. These days I tether to a mobile phone with unlimited internet; which is all-around easier to work with.
My wireguard UDP endpoints are available on a high port, 443 and 53. I've often have one of them blocked, very rare to have them all blocked.
Re: How I learned about corporate firewalls
#18"Aha, so an overzealous IT network decided to block the request before it even reached my server." 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. "I had no idea I was ever going to get anything different." There's an entire list of HTTP status codes. That was your clue that you would get something differe…
There's a subjectively legitimate reason to consider blocking POST (but not GET) requests ruder things than "overzealous."
Re: How I learned about corporate firewalls
#19I'm currently in my very first job where running a local silent NTLM proxy is not a vital skill of survival. For similar reasons I somehow always made an opensource sonatype nexus that is doing pypy proxy or similar, so that operators team can actually do meaningful work without triggering security teams daily.
Can you expand on this a bit? I googled "ntlm proxy" and "sonatype nexus" and still have no idea what it is you've done but I'd like to understand.
Re: How I learned about corporate firewalls
#20Earlier quoted context omitted.
Oh god this is horrible! Yeah, I can't believe how stupidly locked down some of these networks are. I once had an employer said they needed a "whitelist" of websites we wanted to visit instead of a "blacklist" of ones we shouldn't. That was an interesting day...
I had exactly this. We run a Saas and someone wrote an email saying that our server was down, and when we'd expect it to be up. Not having had a notification, I double checked from a couple of geographic locations that our application was indeed up and responding. After a bit of investigation, it turns out that they have to whitelist every unique address with their corporate IT. And had only whitelisted our primary c…
I actually deployed several "FireWall ToolKit" firewalls in the '90s for various organizations.
I still maintain one on an internal QA network.
It allows whitelists.
https://avolio.com/fwtk-history/
https://www.ranum.com/security/computer_security/editorials/...