Earlier quoted context omitted.
I was on a team that tried to implement this at a bank, using azure. The idea was not at the app level but at machine (vm) level. Machines in the legacy data center didn’t have internet access, and so they didn’t want could machines to have it either. But once we locked down the network so many things broke. Not just user level stuff like doing code builds in maven, but also machine level stuff like enabling drive en…
Google offers a way to access Google services from your VM 1918 IPs so you don't need to use NAT. I wonder if Azure would consider doing the same.
Apache Log4j vulnerability shows the importance of SBOMs of running apps
31–40 of 58 posts
Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps
#32Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps
#33"Oh, just run `node install` and you'll be fine..."
If anything, the log4j problem goes a long way to highlight that the "package hell" of node_modules isn't limited to JS apps. log4j is a problem that affects compiled apps written in a mature language. All of the usual complaints about JS apps apply (lots of dependencies, code that's not been audited, developers just adding things without proper consideration, etc), but without the usual "lol javascript isn't a real…
As a C developer, I disagree with the assertion that Java is a mature language. It's only 26 years old! (And in a practical sense even younger than that, since it has changed a lot since the early versions.)
Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps
#34This is essentially just an ad for their service, no? Why is this being upvoted? I'm surprised "SBOM" is actually an acronym people would recognize enough to upvote without reading the article.
Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps
#35Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible? With everyone using un-curated package managers such as NPM and PiPy there is also the chance of a package being compromised. At least if…
Black hole routing is often used in some more regulated industries (finance):
* https://en.wikipedia.org/wiki/Black_hole_(networking)
There's overhead in setting up proxies and telling all software to use them (browsers can be somewhat automated with proxy auto-config (PAC) files). You could of course just use this technique on your server infrastructure.
But it's a 'non-standard' configuration in a world where everything assumes universal connectivity to everything else.
One interesting idea I've seen mentioned it running a firewall on the system itself on a per-UID basis:
* https://www.cyberciti.biz/tips/block-outgoing-network-access...
So if your have a "www-data" UID that runs the web server, you set up iptables to allow it to answer incoming connections and produce replies, but not generate new connections.
> A web server mostly accepts connections but usually only needs to initiate very few connections itself. Therefore it makes sense to limit the possible outgoing connections to what is actually needed. This makes it much more difficult for an attacker to do harm once he has exploited some web application.
* https://wiki.debian.org/Apache/Hardening#Restrict_outgoing_c...
So if you are compromised with attack code, one of the first things it tends to do is fetch some more advanced code to start rummaging through your system(s): that fetch is potentially blocked because it's a new connection to the malware hosting server (or the C&C server).
Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps
#36Does anyone know why one is protected with higher Java versions? I parsed the vuln as being solely in the log4j library.
Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps
#37Does anyone know why one is protected with higher Java versions? I parsed the vuln as being solely in the log4j library.
Note that non-affected JVMs are still vulnerable to other issues triggered by that resolution process, just not as bad as loading untrusted remote objects. So you should upgrade log4j2 even if you use a non-vulnerable JVM.
Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps
#38Earlier quoted context omitted.
Because then you have to define what the package is going to do and it’s a lot of work. And now you don’t have to do that work. And of course, in this case it only takes one app using this library that has a legitimate use case for unlimited acces. Unless you find a way to limit libraries separately.
“it’s a lot of work” should never be a reason for not securing an system. It’s also invite to solve a problem so it’s not a lot of work. It should be easy to secure your systems from making outbound connection.
The problem is of course with the 99% of apps that do require some outbound connections.
Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps
#39Earlier quoted context omitted.
Sure, on desktop. But for a server app (which you built and manage) where you are only talking to known endpoints everything else should be blocked, but we don’t do it. We all use platforms for our apps where anything we use could be compromised and connect to the outside world!
> where you are only talking to known endpoint everything else should be blocked I just realized that neither the Windows Firewall, nor the Linux one (ufw/iptables at least) allow you to block based on domain names. They only allow IP address rules.
This has a few issues, though, such as the fact that it is impossible to allow one site but not another if they are both hosted at the same IP address. After all, DNS names are basically just aliases for IP addresses unless the application layer protocol assigns them some semantic meaning (as is the case with HTTP and TLS).
If that matters, you do have to resort to something protocol-aware like an intercepting HTTP proxy that inspects the Subject Name Indicator for TLS traffic or the Host header for plaintext HTTP traffic. Or a regular HTTP proxy, if your application supports that configuration.
Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps
#40If your app depends on compiled libraries, then the build-time options used to construct the library are as important as version and checksum information.
I see this a lot on HN and the links here - lots of developers for whom a "dependency" is literally a file of non-compiled code, and thus not subject to changes in behavior unless edited. This is not true for compiled languages (and, for all I know, might not even be true for some non-compiled languages).