We know some network services and binaries represent the focus on hacking a unix/linux server. Some of them run with root/sudo permissions, against others as itself user perm, like apache (www-data). So i tried to fail login every attempt this way:
/etc/passwd:
root:x:0:0:root:/root:/usr/bin/nologin (very known)
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
and /etc/shadow:
root:!x:19440:0:99999:7::1:/bin/false
proxy:!x:19213:0:99999:7:::/bin/false (squid-proxy network-service)
and typing:
sudo usermod -L -e 1 root
sudo usermod -L -e 1 proxy
So, when i run:
su -, stopped working (great!)sudo su, stopped toosudo su proxy (failed login ;)
The only way a still get login local machine as root is running sudo bash (or any other shell), but we can edit /etc/sudoers file limiting sudo commands.
I have three questions:
- What types of reverse shell can we mitigate with these "strategies"?
- What is the difference between: "This account is not available" or "Failed login"? Both are ok?
- Anyone would like to test if it really functions against these attacks (reverse shell)?
As i can see at this point, escalation root/proxy privilege are denied. My main reason is to protect my localhost dns/cups servers, because are the only servers running.
One more thing. I think are missing some pam modules related to sudo/bash/nano for example, because in my tests allowing nano as root (sudo nano) or any other text editor can compromise anyfile into etc and thus making that "strategy" mentioned before useless against escalation privilege. macOS has an approach called SIP (System Integrity Protection) and i think our distros have much to gain with something like that.
