How to :: Securing SSH: protocol SSH2 and hiding the direct access of root
1) Create a new and unique root access user. Login as root using a ssh connection such as Putty. Make sure you have the latest version of Putty that supports SSH2.
Add a user named ‘admin’ or any name: Quote:
Add user to the wheel group (this is the important step in this ducument) (The Wheel group is a user group that can gain access to root on your server by using the su command. You can add and remove users from that group as required.) Quote:
Quote:
Further the permissions are changed so that root has read write execute permissions (47 rws, as both owner execute and SUID are set x is replaced by s) the group has execute only permissions (5 --x) while all others have no acess to the file (0 ---) Check su command permissions Quote:
Note: the file size and date may be different from the example. Exit and relogin with the new user name admin and test out su command. Quote:
Quote:
Quote:
Quote:
Exit and save. Restart SSH using the following command: Quote:
Note: If you made any mistakes and you are locked out, then you have to connect using telnet and correct the problem. After the problem is corrected, you must change your password, because Telnet may have exposed your password since it transmits log in data using plain text. 3) Have the server e-mail you every time someone logs in as root: Quote:
Quote:
4) Now since everything is working well through SSH, you can disable Telnet: Quote:
Quote:
|
hiding the direct access of root
Exactly wWhat benefit has that knowing everyone knows the box has a root account anyway? ]# getent group wheel /usr/sbin/usermod -G wheel admin Grand. Now everyone uses the admin account to ssh in instead of their own unprivileged account which is by far the better (efficient, controllable, auditable) way. And once they su to root all audit trails are gone. Fix that using Sudo and configure users to su to root to use a wrapper like Rootsh which logs all actions. Yes, it can syslog, so you can have your audit trails *remote*. the permissions are changed so that root has read write execute permissions No need to modify access rights on binaries. Could be ACL'ed through PAM this easy way using a standard PAM module: add line "auth required /lib/security/$ISA/pam_listfile.so item=user sense=allow file=/etc/su.allow onerr=fail" to /etc/pam.d/su, then add usernames, one per line, in /etc/su.allow. Done. Port 7777 Nice. Security by obscurity, which provides NO SECURITY at all. If you want to guard access to SSH it's better (efficient, controllable, auditable) to restrict access (sshd_config, firewall, PAM) to known management IP's or ranges. If you're not able to do that then using one of the methods listed in the Linux - Security forum sticky Failed SSH login attempts should provide better (efficient, controllable, auditable) ways to thwart crackers. Oh, and run a backup SSH from Xinetd on a different port, just in case. Just my thoughts. |
nice one....
|
What is?...
|
All times are GMT -5. The time now is 10:08 PM. |