How I learned about corporate firewalls • Hacker News Board

Re: How I learned about corporate firewalls

#71

Post by jeroenhd » Wed, Oct 05, 2022, 2:40 PM UTC

cheschire wrote: post #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 differe…

Allowing this person's gift card shop but not allowing POST requests is clearly overzealous in my book.

I understand that some companies want to block certain websites. However, if you're in such a restricted network, I wouldn't expect a website like "Thankbox" to work at all.

An overzealous filter like this prevents normal POST requests (logging in to websites, etc.), lets through random websites (gift card website) and allows all manner of data exfiltration and other nasty stuff. The goal is laudable, the implementation is laughable.

Re: How I learned about corporate firewalls

#72

Post by bombcar » Wed, Oct 05, 2022, 2:41 PM UTC

huy-nguyen wrote: post #64

I 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…

That first one indicates something is being injected and the checksums are failing, that's ... worrying.

Or npm and pip use their own certificate stacks and refuse the firewall's cert, which is ... good I guess.

Re: How I learned about corporate firewalls

#73

Post by denton-scratch » Wed, Oct 05, 2022, 2:43 PM UTC

raxxorraxor wrote: post #50

Neil44 wrote: post #11

Yep not to mention pushing their SSL root CA to all the clients so they can scan everything without SSL errors.

Sensible for the users that really download and execute attachments from the most obvious spam mails. The only protection you have is to put these high threat users in a separate subnet and use some antivirus to scan everything they download. At least that offers some protection. Not possible to scan downloads with TLS. Although I still think that breaking it up is a very bad idea in general and it is appalling that…

> put these high threat users in a separate subnet

Ideally a subnet belonging to one of your competitors? I thought that nowadays only very ignorant people follow links or open attachments in spam emails. Certainly all the spam I've seen for a few years has been as plain as the nose on your face: only an ignorant person would mistake it for ham.

Re: How I learned about corporate firewalls

#74

Post by thaeli » Wed, Oct 05, 2022, 2:43 PM UTC

huy-nguyen wrote: post #64

I 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.

Re: How I learned about corporate firewalls

#75

Post by HPsquared » Wed, Oct 05, 2022, 2:49 PM UTC

pilif wrote: post #47

My 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.

Re: How I learned about corporate firewalls

#76

Post by deathanatos » Wed, Oct 05, 2022, 2:49 PM UTC

hyperman1 wrote: post #4

We 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)?

A previous employer of my blocked the XTerm escape sequence reference. Like, okay, may your terminal output be plain and boring, I guess.

Also, the link to "request an exception" lead to a 404 and the IT team responsible for the blocking didn't respond to email.

Re: How I learned about corporate firewalls

#77

Post by adev_ » Wed, Oct 05, 2022, 2:50 PM UTC

jjoonathan wrote: post #18

cheschire wrote: post #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 differe…

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 with TLS which is used everywhere (even in VPN) just to bypass the crappiness of corporate firewall and stupid managerial decisions.

Re: How I learned about corporate firewalls

#78

Post by youainti » Wed, Oct 05, 2022, 2:51 PM UTC

ravio64 wrote: post #43

easton wrote: post #27

Earlier quoted context omitted.

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

Windows equilevant is zeal, which dash is a mac version of :)

zeal also has a linux version

Re: How I learned about corporate firewalls

#79

Post by nightpool » Wed, Oct 05, 2022, 2:51 PM UTC

BizarroLand wrote: post #5

hyperman1 wrote: post #4

We 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 would have taken that as my queue to start finding another job. Not that I can't puzzle everything out from scratch every single time I need to do anything, but why should I reinvent the wheel when off-the-shelf is both faster and higher quality?

(cue, as in "a signal (such as a word, phrase, or bit of stage business) to a performer to begin a specific speech or action", e.g. "That last line is your cue to exit the stage". See https://www.merriam-webster.com/dictionary/cue)

Re: How I learned about corporate firewalls

#80

Post by SSLy » Wed, Oct 05, 2022, 2:55 PM UTC

thaeli wrote: post #74

huy-nguyen wrote: post #64

I 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.

Bold of you to assume the developers were given a budget and staff to run on-prem repo mirror.