Ask HN: In light of Log4J why don’t we use outbound firewalls? | Hacker News Reader

Ask HN: In light of Log4J why don’t we use outbound firewalls?

9 pointssamwillis7 comments

With the Log4J vulnerability it got me thinking out how to secure my apps from similar problems in the future. I already use a WAF such as CloudFlare as an inbound firewall, but what I want is an outbound firewall, like Little Snitch.

Also, when building with un-curated package managers such as NPM and PyPi, it’s virtually impossible to audit all dependencies. We now regularly hear news of packages being replaced with backdoored versions makes me very nervous. These could make outbound connections to exfiltrate data with not outside input.

I would love it if PAASs (with I prefer) such as Heroku and Fly.io had configurable outbound firewalls. Being able to whitelist what outbound connections were aloud would help enormously, even though it would not solve all potential exploits.

Does anyone know of one (I can’t find one)? Why do PAAS (and to some extent IAAS) not have this functionality built in?

(Obviously with your own infrastructure this is possible with normal firewalls)

I actually just spent the last few months working on a new program called picosnitch that does almost exactly what you're looking for. And as you can probably tell from the name, it was inspired by Little Snitch.

It watches your system for new executables that connect to the internet, and notifies you whenever it detects the first connection from one, or when the hash changes for one it has seen before. It can also automatically check the hashes with VirusTotal. And unlike any of the other existing tools (that I know of), it can also properly detect connections from executables inside containers, although the reported exe path may be useless due to namespaces, it will still give you the correct hash.

However, where it is lacking when compared to Little Snitch is that it does not block anything, since I wanted to focus on doing performance and reliability really well, and my time is finite. Although I am open to making it easier to use in conjunction with something like fail2ban or your own custom scripts, modularity is a good thing.

I just recently got this program into a state where I feel it is ready to share, so I'd really appreciate any feedback, and am happy to discuss it further.

I've seen a few Linux implementations of something like Little Snitch but I would not consider any of them production datacenter ready. A balanced approach might be to do something as simple as using the "owner" module in iptables to create rules saying what service accounts on your servers are permitted to talk outbound and to where and on what ports. This example does not limit by application but you can deploy your applications to use different service accounts accomplishing essentially the same thing.

Mail server example:

  iptables -I OUTPUT -o eth0 -m owner --uid-owner postfix -p tcp --syn --dport 25 -j ACCEPT

To answer your question, here is a desktop firewall for Linux that operates like Little Snitch [1] This is not meant to be used in your server deployments.

[1] - https://github.com/evilsocket/opensnitch

> I would not consider any of them production datacenter ready.

Could you explain why? Any experience/benchmark to share?

By the way, [1] has a GUI, but you can install only the daemon on the servers.

Limiting to what IPs/domains/ports an application connects to might be useful. But blocking unknown binaries is where this apps really shine (reverse shells, miners...), not because they stop them, but because they'll tell you what app tried to establish a connection, where it is on the disk, etc.

Could you explain why? Any experience/benchmark to share?

I am not aware of anyone anywhere doing this in production, load testing this application in a way that matches production server traffic or ever having used this outside of a desktop. That is the point really. You would be one of the first to tickle any bugs. If you can find a community of people doing this that could help when you run into problems, then you might not be the first to do this. I am never against bending applications to do something they were not intended, it's in my name.. but I am also very familiar with sitting in front of a room full of executives that want an explanation for why the outage occurred and how to keep it from occurring again.

By the way, [1] has a GUI, but you can install only the daemon on the servers.

Correct it was not intended for servers.

Limiting to what IPs/domains/ports an application connects to might be useful. But blocking unknown binaries is where this apps really shine (reverse shells, miners...), not because they stop them, but because they'll tell you what app tried to establish a connection, where it is on the disk, etc.

This is less of a problem on servers. You would not deploy applications that have not been QA tested, benchmarked, code security reviewed and approved for deployment. If that is happening outside of your control that is an issue that needs to be brought up with the leadership of your development teams. Encourage them to use distroless containers and strip out applications that have not been approved. Your web daemons need to only have access to applications they are approved to use. You can enforce mandatory access controls in AppArmor/SELinux though I acknowledge people get overwhelmed by this and just disable it or use the default targeted rules that come with the OS which is barely useful at all.

I summary, if you want to be one of the first organizations to use this in a production datacenter setting that is great but you will be the first to experience all the "it wasn't supposed to do that" moments. If you do this, please document all the issues that you run into so that others can learn from your experience and go easy on the developers of this code as it was not intended to be used this way.

I've used outbound firewalls and it's painful. Your provider for some API changes IPs for whatever reason and now you need to change your firewall, etc.

If you use an outbound http/socks proxy, it's a bit more tenable. You can set rules based on hostnames, but you're also on the hook for running a production proxy cluster. Hopefully you don't need outbound UDP.

The majority of backend web apps only talk to a limited few services; db’s, internal queues, external apis. My main app talks to two internal db’s, and maybe 4 external apis. It should be possibles to specify the host names of these services and block everything else, certainly on a PAAS such a Heroku (they even know what internal services you are using), but that functionality isn’t there… I simply don’t understand why not.

It should be possible to build this sort of firewall based on hostnames not IP addresses? Maybe with a custom DNS server? And to be honest I would take the configuration complexity if it made my apps more secure.

There will be apps that talk to more, and as you said use UDP etc. but these will be the minority.

it needs to be significantly more than just hostname / IP / DNS.

a common attack i see for exfil behind FW is to sign up for a free account on heroku, fastly, cloudflare, etc so that your outbound destination is to a "good" IP. you can resolve api.legitimatecompany.example and then send the actual request to that IP (which is a CDN), with an encrypted Host: header of your own endpoint, for example.

Reply on news.ycombinator.com