injections shell
C’est tout à fait possible de faire un user pas privilégié avec des commandes sudo/doas spécifiques. C’est même la conf que j’avais fait sur mon serveur au début.
Mais au final ça ajoutait beaucoup de complexité à mon goût, du coup j’ai arrêté. Et ça fait beaucoup de logs de ce type aussi :
Jul 23 21:01:49 musi doas[2864446]: pam_unix(doas:session): session opened for user root(uid=0) by reaction(uid=800)
Mais c’est tout à fait possible. Avec quelques essais-erreurs, je pense que tu pourrais activer pas mal d’options de sandboxing de systemd (mais typiquement pas NoNewPrivileges parce qu’il faut bien escalader en root à un moment)
Pour ce qui est des injections shell en elles-mêmes, elles sont totalement évitables si tu ne lances pas de scripts shell dans tes actions :
{
streams: {
// Ban hosts failing to connect via ssh
ssh: {
// Use systemd's `journalctl` to tail logs
cmd: [' journalctl', '-fn0', '-u', 'sshd.service'],
// may also be ↑ ssh.service, depends on the distribution
filters: {
failedlogin: {
regex: [
// Auth fail
@'authentication failure;.*rhost=<ip>',
// Client disconnects during authentication
@'Connection (reset|closed) by (authenticating|invalid) user .* <ip>',
// More specific auth fail
@'Failed password for .* from <ip>',
],
retry: 3,
retryperiod: '6h',
actions: ban: {
cmd: ['ip46tables', '-w', '-A', 'reaction', '-s', '<ip>', '-j', 'DROP'],
},
unban: {
cmd: ['ip46tables', '-w', '-D', 'reaction', '-s', '<ip>', '-j', 'DROP'],
after: '3h',
},
},
},
},
},
}
Ici les arguments des actions de ban et d’unban sont directement envoyées au noyau : pas d’expansion shell possible parce que pas de shell entré en jeu.
J’espère avoir bien expliqué ça dans Security - Reaction wiki, mais si c’est pas le cas, n’hésitez pas à me dire ce qui manque !
