...
Outlined here are the minimal security steps the Bonsa Framework uses in server builds.
Allow staff Group to sudo
Use account names associated with a user. For this example, I will be designating adminstrative users under the staff group. To see the list of groups available to you use the command, cat /etc/group.
Note |
---|
These steps are assuming that you are logged in with the initial Ubuntu user which as sudo access. If you are using root instead, then you do not need to prefix any command with sudo. |
The staff group by default does not normally have sudo access. To grant sudo access to the staff group,
Code Block | ||
---|---|---|
| ||
sudo visudo |
visudo launches your default editor to a special file. Add the following to the bottom of the file,
...
language | bash |
---|
...
Given that these account names are on the Internet you may want to change them. However, this may be greatly mitigated with RSA SSH key based authentication.
Naming Convention
You may want to understand the naming convention used here if you want to build your own. Otherwise, the examples are self-explanatory and have not encountered any issues.
Create Catch-All serveradmin user
The purpose of serveradmin is the catch-all place to setup things like scripts. It may also, depending on requirements for your organization be used to manually setup software like application servers.
...
Our user convention is firstName.lastName, however, we chose to user serveradmin rather than server.admin for fast typing as this and similar accounts are often used via sudo.
Tip |
---|
In a more security sensitive environment rather than just one serveradmin, we could setup consider distinct accounts ie for running a manual setup of tomcat, manual setup of postgressql etcapplications (ie tomcatadmin). |
Also, the serveradmin account is limited in that it can not use sudo. If an attacker compromises the application, sudo is still out of reach.
Finally, in order to easily use Zero Footprint, create serveradmin consistently (same GID's and name) across all your systems.
Add the user and assign a password to that user,
...
Code Block | ||
---|---|---|
| ||
sudo useradd -d /home/bhitchbrian.hitch -m -g staff -u 2000 -c "Support Bryan Hitch" -s /bin/bash bhitchbrian.hitch sudo useradd -d /home/jcassadayjohn.cassaday -m -g staff -u 2001 -c "Support John Cassaday" -s /bin/bash jcassadayjohn.cassaday sudo useradd -d /home/welliswarren.ellis -m -g staff -u 2002 -c "Support Warren Ellis" -s /bin/bash welliswarren.ellis |
Note |
---|
When adding an existing user to an existing group the user must log out and log back in for changes to take effect. |
Expand | ||
---|---|---|
| ||
-b, --base-dir BASE_DIR base directory for the home directory of the new account -c, --comment COMMENT GECOS field of the new account -d, --home-dir HOME_DIR home directory of the new account -D, --defaults print or change default useradd configuration -e, --expiredate EXPIRE_DATE expiration date of the new account -f, --inactive INACTIVE password inactivity period of the new account -g, --gid GROUP name or ID of the primary group of the new account -G, --groups GROUPS list of supplementary groups of the new account -h, --help display this help message and exit -k, --skel SKEL_DIR use this alternative skeleton directory -K, --key KEY=VALUE override /etc/login.defs defaults -l, --no-log-init do not add the user to the lastlog and faillog databases -m, --create-home create the user's home directory -M, --no-create-home do not create the user's home directory -N, --no-user-group do not create a group with the same name as the user -o, --non-unique allow to create users with duplicate (non-unique) UID -p, --password PASSWORD encrypted password of the new account -r, --system create a system account -R, --root CHROOT_DIR directory to chroot into -s, --shell SHELL login shell of the new account -u, --uid UID user ID of the new account -U, --user-group create a group with the same name as the user -Z, --selinux-user SEUSER use a specific SEUSER for the SELinux user mapping --extrausers Use the extra users database |
Notice the -u which set's the user's GUIDs. We found it essential to standardize on the GUID of the accounts across all our systems consistently. Not doing so causes problems when it comes to cloning systems or moving programs across different environments. As a practice, we use the following GUID's ranges,
- Staff 2000-2499
- Guest Staff Users 2500-2999
Custom services 3000 - 3999
Additionally, we use the following group GUID ranges,
- Custom services 3000 - 3999
- I further broke up my custom services with Web Groups for website management - 3100-3199
GUID range 4000-4999 for clients who would send in staff to work on the servers. Since the number of users with this kind of access should not be too large we can make the group blocks match the user blocks,
Group | Users |
---|---|
4000 | RedClient1 = 4000 |
4010 | BlueClient1 = 4010 BlueClient2 = 4011 |
4020 | GreenClient1 = 4020 GreenClient2 = 4021 GreenClient3 = 4022 |
Next, we add to the Staff users the following groups,
...
Code Block | ||
---|---|---|
| ||
sudo usermod -a -G adm bhitchbrian.hitch sudo usermod -a -G adm jcassadayjohn.cassaday sudo usermod -a -G adm welliswarren.ellis |
Note |
---|
When adding an existing user to an existing group the user must log out and log back in for changes to take effect. |
Info |
---|
The above step could have been done on user create. However, this illustrates user modification as part of the tutorial. |
...
Code Block | ||
---|---|---|
| ||
sudo passwd bhitchbrian.hitch Enter new Unix password: Reenter new Unix password: passwd: password updated successfully sudo passwd jcassadayjohn.cassaday sudo passwd welliswarren.ellis |
Allow staff Group to sudo
Rather then editing the /etc/sudoers using visudo, this approach ensures that system upgrades will not overwrite your changes.
Download File Using tscripts
Download tscripts,
Code Block | ||
---|---|---|
| ||
sudo su - root
cd /etc/sudoers.d/
sudo wget www.bonsaiframework.com/tscripts/01_enable_sudo_for_staff
sudo chmod o-r /etc/sudoers.d/01_enable_sudo_for_staff
exit |
Manual Method
If you want to create the file manually,
Code Block | ||
---|---|---|
| ||
# Locks the file for single user access (important in a multi-user system) and validates for syntax errors.
sudo visudo -f /etc/sudoers.d/01_bonsai_disable_password_auth |
visudo launches your default editor to a special file. Add the following to the file,
Code Block | ||
---|---|---|
| ||
# Members of the staff group may gain root privileges.
%staff ALL=(ALL) ALL |
Going forward, make sure to use visudo to edit the 01_bonsai_disable_password_auth file to ensure proper permissions and locking,
Warning |
---|
At this point it is important to log out and log in with your staff account to continue any new work. This will allow for a proper audit trail of the system from this point forward. |
Create Auxiliary Users
If you want to make this into a truly enterprise system we will also need a few more users.
remotebackup - User to create remote backups. The assigned UID will be 3001.
Code Block | ||
---|---|---|
| ||
sudo useradd -d /home/remotebackup -m -g backup -u 3001 -c "Remote Backup" -s /bin/bash remotebackup |
Create regular Users
If you would like to add regular users without giving them sudo access then follow below instructions
Create regular group
Code Block | ||
---|---|---|
| ||
sudo addgroup support |
Create users and add them to group "support"
Code Block | ||
---|---|---|
| ||
sudo useradd -d /home/tom.hitch -m -g support -u 2500 -c "Support Tom Hitch" -s /bin/bash tom.hitch
sudo useradd -d /home/rohan.cassaday -m -g support -u 2501 -c "Support Rohan Cassaday" -s /bin/bash rohan.cassaday
sudo useradd -d /home/dennis.ellis -m -g support -u 2502 -c "Support Dennis Ellis" -s /bin/bash dennis.ellis |
Granting Non-staff User to use sudo with Certain Commands
In some cases you might want a non-staff user (Roderick can we do group too, it would be better) to certain commands. Usual scenarios are to restart services that require root such as Apache (that would be a better example here)
Code Block | ||
---|---|---|
| ||
sudo visudo |
Scroll to the bottom and enter the username in this case we use the name bob and enter the commands you would like bob to be able to sudo with, in this case we want bob to be able to create directories
Code Block | ||
---|---|---|
| ||
bob ALL=(root) /bin/mkdir |
Now test the command
Code Block | ||
---|---|---|
| ||
sudo mkdir bob |
Lets use the find command if you do not know what to add the error message tells you the path that needs to be added to the file as an example lets display the find command error
Code Block | ||
---|---|---|
| ||
Sorry, user bob is not allowed to execute '/usr/bin/find something' as root on prodserver |
Now that we have the command path just add that to bob in the visudo file and test. For multiple commands separate with a comma
Code Block | ||
---|---|---|
| ||
bob ALL=(root) /bin/mkdir, /usr/bin/find |
To use sudo without being prompted for a password add NOPASSWD:
Code Block | ||
---|---|---|
| ||
bob ALL=(root) NOPASSWD: /bin/mkdir, /usr/bin/find |