No post body was provided.
How I learned about corporate firewalls
61–70 of 204 posts
Re: How I learned about corporate firewalls
#62We 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)?
I was recently told by an old-timer at my current company that at one point security tried to remove Visual Studio from developers machines because it had reported security incidents.
The problem with security people is that they think security is the most important thing.
Re: How I learned about corporate firewalls
#63If 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.
That worked for me for awhile but then the proxy started checking that all traffic was HTTP. Eventually I used ssh over websocket.
Re: How I learned about corporate firewalls
#64I 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 to get off the VPN every time I need to run these simple commands. IT absolutely doesn't give a flying **** about developers.
2) They ban all non-Chrome browsers from being installed. As in, if you install such a browser and try to launch it, the system will say "browser X is banned. Contact IT." They would have banned Safari too had it not been part of the OS. Furthermore, they also disabled private browsing in Chrome (probably the ability to do this is why they allow Chrome). I think they're preventing people from hiding their internet browsing.
Re: How I learned about corporate firewalls
#65tldr: do error handling.
Re: How I learned about corporate firewalls
#66I have a government client that has locked down all outgoing access for a web server except though a socks proxy. It makes simple things really hard - like a links checker, package dependencies, remote servers or integrations with Google. We can't even run test scenarios on the machine because we're also locked _out_ of the server. Instead, we rely on their IT department to run test scripts that we send them via emai…
> I have a government client that has locked down all outgoing access for a web server except though a socks proxy.
If you're running Linux, there's a utility called "tsocks" which wraps any other command and redirects all network servers through a SOCKS proxy defined in /etc/tsocks.conf, e.g.:
tsocks pip install somepackage
Re: How I learned about corporate firewalls
#67> 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 loo…
Isn't there some kind of library to handle this without having to code it each time?
There is a HTTP status code in any response and a 403 like in this case should already inform you about the problem. Pretty high level already.
I prefer to let the users actually see such errors, although that seems to be an anti-pattern today.
Usually any message receiver should first check the status code and only proceed if it is 2xx and handle errors in any other case.
But such edge case errors (a 403 usually isn't an edge case) getting swallowed still happens on the most prominent on thoroughly tested sites. Had similar stuff on Amazon and Microsoft pages for example. Saw the errors in the console but they weren't displayed to the user.
Re: How I learned about corporate firewalls
#68If 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.
As an example, best practice for Palo Alto firewall setup is to create a rule that allows the "application" known as "SSL" and then use "application-default" as the setting for which ports to allow it on. This would inspect the traffic to determine that it is SSL (actually TLS in most cases I guess) and then allow it if on port 443.
If you don't have other relevant allow rules, your sshd traffic would just be dropped, regardless of port.
If the firewall administrator does things poorly, they will create an allow rule for port 443 and your sshd traffic on port 443 would be allowed (no inspection of traffic to determine if it is SSL or SSH).
BTW this is inspection, not decryption. Two very different things.
The business of developing algorithms to effectively detect various applications must be very interesting. You can see all the different "applications" here: https://applipedia.paloaltonetworks.com/
Re: How I learned about corporate firewalls
#69We 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)?
I was recently told by an old-timer at my current company that at one point security tried to remove Visual Studio from developers machines because it had reported security incidents. The problem with security people is that they think security is the most important thing.
Well, for them, it is and should be the most important thing. The problem bites when management shares that view.