4 ms·

> 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

by gus_ 5y ago

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

LinuxBender 5y ago
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.

by gus_ 5y ago

LinuxBender 5y ago

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.