> Sorry, you don't have permission to visit this site. > Website blocked > Not allowed to browse Shareware Download category > You tried to visit: https://www.valcanbuild.tech/handling-corporate-firewalls/ The irony.
Hah, of course!
How I learned about corporate firewalls
201–204 of 204 posts
Re: How I learned about corporate firewalls
#202Earlier quoted context omitted.
> So these bulk scanners exist, and the issue is a solved problem, but none of the "root" repos for the popular language stacks are using them? I could talk at length about this; unfortunately, I'm on my phone with a shotty connection. The tl;dr is that companies like Snyk make money by requiring companies to pay to check for vulnerabilities once they've been downloaded. There's not necessarily anything wrong with th…
You need money to staff people with security knowledge that constantly keeps product up to date with latest malicious signatures in all codebases. This is why only commercial company can build a great product. The constant cat and mouse game between threat actors and defenders/researchers. Every new malware/trojan/cryptominer strain needs to be found, identified, signature written, and all clients need tk get latest…
> You need money to staff people with security knowledge that constantly keeps product up to date with latest malicious signatures in all codebases.
Of course; it's just funny to think about how much money gets spent detecting and fixing things downstream instead of fixing it at the source.
Re: How I learned about corporate firewalls
#203Earlier quoted context omitted.
Some of these "security" products that MiM TLS traffic allow configurations that objectively reduce your security. You can configure Palo Alto devices to accept a self-signed cert from the Internet, but present your trusted MiM cert to the on-site user. Now the user isn't aware that they are the victim of a second MiM outside the organization. The organization also exposes itself to greater liability. E.g., a rogue e…
> but it doesn't prevent intentional exfiltration It can prevent accidental exfiltration, or deliberate exfiltration by a relative incompetent, which are the majority of such problems. You are right in that they will not stop deliberate actions by a competent disgruntled or a competent external attacker who has access (but you have a much wider set of problems in this latter case). Maybe I'm old-fashioned (I am defin…
If the employer needs to back-door encryption to discover your personal activity, how is it their business what you are doing? Your activities obviously caused them no public issues. If they did, the encryption back-door would not have been necessary for the discovery.
In more civilized areas of the world privacy rights are explicit, and even things like employers snooping on employee email accounts on company owned email servers is illegal. When at work, you are selling your time to your employer, but that doesn't imply that the employer owns you while you are at work.
As to the sibling comment about cameras in workplace bathrooms, yes employers did this and now there are laws prohibiting it. Now, employers just account all your time using bossware leading to e.g., folks at Amazon having to pee in bottles or wear diapers on the job to not get fired. There is no line that some capitalist employer will not cross unless we place limits with consequences to reign them in-- e.g., we no longer have employers forcing small children to crawl into running machine tools to clear a jam while risking a limb being sucked into the mechanism and turned into hamburger meat-- but, we did, it was common-- lives of the poor (especially children) were cheap, but stopping an assembly line was expensive.
Re: How I learned about corporate firewalls
#204Earlier quoted context omitted.
I am afraid you are talking about stuff you have absolutely no idea about. Palo Alto appliance should be configured with both Forward Trust and Forward Untrust CA certificates, and the issue you described will not exist. If some people misconfigure - thats their fault for not following instructions. Secondly, rogue employee doesnt have access to CA key that is stored in Palo Alto appliance. Only your firewall admin w…
You seem to acknowledge that you currently can configure the device in the manner described while simultaneously being extremely aggressive. A conversation I had with PA support gives me the impression that PA didn't have 'Forward Untrust' when they first started back-dooring TLS i.e., the PA support person did not counter my point of negative security implications of their MiM back-door for invalid certificates enco…
Forward Untrust Certificate has been a feature since day one, the earliest document mentioning Forward Untrust I was able to find online is for PANOS 6.0 which is like 8 years ago?
in company of thousands users nobody has the energy to spy on employees - it is simply not worth the effort. Why would company spy on own employees, it is not something that brings profit for the company.
The only purpose of SSL decryption is to decrypt traffic and enforce policies: prevent users from going to shady websites, downloading malware, clicking on phishing links, stop viruses, trojans and hackers' command&control comms. It is because majority of http traffic is TLS encrypted, that security vendors no other choice other than decrypt and inspect.
Nobody is looking over zillions of logs, looking at what pages a random employee is browsing in a given day - aint nobody got time, energy, nor infrastructure to do that.
User identity (also device identity, and app identity) is used as to classify traffic and it is then up to company admins to create policy for enforcement.
Whatever the policy is - it will be enforced, and it is the same policy&terms you agree to by signing employment contract.
Which says something like - your work laptop and corporate Internet connection can only be used for work related stuff and not personal stuff, etc, etc.