...
Introduction
Outlined here are the steps to ensure your Ubuntu server has basic security.
| Note |
|---|
A disclaimer here. These are basic steps to securing the box. An actual hardening guide is something that I might write about in the future as a separate article. |
Allow staff Group to sudo
Instead 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.
The staff group by default does not normally have sudo access. To grant sudo access to the staff group,
| Code Block | ||
|---|---|---|
| ||
visudo |
visudo launches your default editor to a special file. Add the following to the bottom of the file,
| Code Block | ||
|---|---|---|
| ||
# Members of this group may gain root privileges
%staff ALL=(ALL) ALL{code}
h2. Create |
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.
...
| Tip |
|---|
Further along these lines, in a more security sensitive environment rather than just one serveradmin, we could setup distinct accounts for running a manual setup of tomcat, manual setup of postgressql etc. {tip} |
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.
...
Add
...
the
...
user
...
and
...
assign
...
a
...
password
...
to
...
that
...
user,
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| =
| }|||||
sudo addgroup --gid 3000 serveradmin
sudo useradd -d /home/serveradmin -m -g serveradmin -u 3000 -c "Admin catch-all" -s /bin/bash serveradmin
sudo passwd serveradmin{code}
h2. Create Staff Users
We will also create *staff* users associated with the built in staff group so we know who is working on the machine. As a policy, our team requires that unless absolutely necessary, staff log in as their own account and then su to serveradmin or use sudo for maintenance work. That way we can have a trail of who does what.
sudo useradd \-d /home/bhitch \-m \-g staff \-u 2002 \-c "Support Bryan Hitch" \-s /bin/bash bhitch
sudo useradd \-d /home/jcassaday \-m \-g staff \-u 2002 \-c "Support John Cassaday" \-s /bin/bash jcassaday
sudo useradd \-d /home/wellis \-m \-g staff \-u 2001 \-c "Support Warren Ellis" \-s /bin/bash wellis
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 between 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
Finally we add to the Staff users the following groups,
* serveradmin - so staff users can work with manually setup apps
* adm - so staff can view logs in apps setup using the sudo command
\\
{code:lang=html} |
Create Staff Users
We will also create staff users associated with the built in staff group so we know who is working on the machine. As a policy, our team requires that unless absolutely necessary, staff log in as their own account and then su to serveradmin or use sudo for maintenance work. That way we can have a trail of who does what.
sudo useradd -d /home/bhitch -m -g staff -u 2002 -c "Support Bryan Hitch" -s /bin/bash bhitch
sudo useradd -d /home/jcassaday -m -g staff -u 2002 -c "Support John Cassaday" -s /bin/bash jcassaday
sudo useradd -d /home/wellis -m -g staff -u 2001 -c "Support Warren Ellis" -s /bin/bash wellis
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 between 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
Finally we add to the Staff users the following groups,
- serveradmin - so staff users can work with manually setup apps
- adm - so staff can view logs in apps setup using the sudo command
| Code Block | ||
|---|---|---|
| ||
sudo usermod -a -G serveradmin,adm bhitch
sudo usermod -a -G serveradmin,adm jcassaday
sudo usermod -a -G serveradmin,adm wellis{code}
\\
{warning}
At this point it is important to logout and log in with your staff account to continue your work.
{warning}
h2. Disable Direct Login as Root Through SSH\\
Normally having permit root login in ssh in Ubuntu is not a security issue. Root is simply disabled in the OS. This is a *hosted* Ubuntu only step where often the root account is enabled. This is dangerous because there are attackers out there looking for Unix/Linux boxes and trying to login via ssh using the username root and then a list of common passwords.
{note}I do not going down the route of disabling the root account as this might break the hosted Ubuntu setup. For example, Slice's or Rackspace special terminal console login might stop working. In any event, the vector of attack is SSH login. To prevent users from using root, well don't provide the root password and provide sudo privileged accounts as shown in this article.
{note}\\
Connect to SSH as a staff user and edit sshd_config,
sudo nano |
| Warning |
|---|
At this point it is important to logout and log in with your staff account to continue your work. |
Disable Direct Login as Root Through SSH
Normally having permit root login in ssh in Ubuntu is not a security issue. Root is simply disabled in the OS. This is a hosted Ubuntu only step where often the root account is enabled. This is dangerous because there are attackers out there looking for Unix/Linux boxes and trying to login via ssh using the username root and then a list of common passwords.
| Note |
|---|
I do not going down the route of disabling the root account as this might break the hosted Ubuntu setup. For example, Slice's or Rackspace special terminal console login might stop working. In any event, the vector of attack is SSH login. To prevent users from using root, well don't provide the root password and provide sudo privileged accounts as shown in this article. |
Connect to SSH as a staff user and edit sshd_config,
sudo nano /etc/ssh/sshd_config
...
Search
...
for
...
the
...
line
...
"PermitRootLogin
...
yes"
...
and
...
change
...
to
...
"PermitRootLogin
...
no"
...
.
...
You
...
can
...
still
...
issue
...
su
...
to
...
go
...
in
...
as
...
root
...
but
...
only
...
after
...
logging
...
in
...
as
...
a
...
user
...
belonging
...
to
...
the
...
admin
...
group.
...
Last
...
restart
...
the
...
SSH
...
service
...
for
...
the
...
changes
...
to
...
take
...
effect.
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| =
| }|||||
sudo /etc/init.d/ssh restart{code}
h2. Prevent SSH Brute Force Dictionary Attacks
As soon as it is on the Internet people will try to brute force attack your server over ssh. Basically they keep on pounding your system trying different passwords. fail2ban makes this kind of attack not worthwhile. After a chosen number of failed login attempts from the same ip address, fail2ban blocks that ip address for a set period of time. As constantly changing ip addresses is not a trivial task, the attacker will move on to another system.
{code:lang=html} |
Prevent SSH Brute Force Dictionary Attacks
As soon as it is on the Internet people will try to brute force attack your server over ssh. Basically they keep on pounding your system trying different passwords. fail2ban makes this kind of attack not worthwhile. After a chosen number of failed login attempts from the same ip address, fail2ban blocks that ip address for a set period of time. As constantly changing ip addresses is not a trivial task, the attacker will move on to another system.
| Code Block | ||
|---|---|---|
| ||
sudo apt-get install fail2ban{code}
|
The
...
fail2ban
...
installer
...
also
...
starts
...
fail2ban
...
as
...
a
...
service
...
right
...
after
...
installation
...
completes.
...
Most
...
of
...
the
...
how
...
fail2ban
...
works
...
is
...
in
...
/etc/fail2ban/jail.conf
...
and
...
here
...
are
...
the
...
highlights,
...
| Code Block | ||
|---|---|---|
| ||
maxretry = 6 {# under the ssh section you are allowed 6 retries} bantime = 600 {# 600 seconds = 10 minutes} ignoreip = 127.0.0.1 {# do not block list, and CIDR list} |
The
...
default
...
settigs
...
of
...
fail2ban
...
are
...
usually
...
good
...
enough
...
but
...
you
...
can
...
also
...
customize
...
fail2ban
...
to
...
suit
...
your
...
needs.
...
After
...
a
...
day
...
or
...
so
...
on
...
the
...
Internet
...
you
...
should
...
start
...
seeing
...
people
...
getting
...
banned
...
in
...
the
...
logs,
...
/var/log/fail2ban.log
...
.
...
Here
...
is
...
an
...
example
...
of
...
an
...
ip
...
getting
...
banned
...
and
...
then
...
after
...
10
...
minutes
...
it
...
unbans,
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| =
| }|||||
2009-02-15 10:29:24,108 fail2ban.actions: WARNING \[ssh\] Ban 59.63.25.158
2009-02-15 10:39:24,137 fail2ban.actions: WARNING \[ssh\] Unban 59.63.25.158{code}
{tip}This section can be improved with instructions on how to unblock yourself if you accidentally ban yourself.{tip}
{tip}This section can be improved with a linked article on how to customize fail2ban to ignore specific ip addresses and subnets.{tip}
Deny Hosts
Another package that should be installed to prevent distributed brute force ssh attacks is [Deny Hosts|http://denyhosts.sourceforge.net/].
{code:lang=html} |
| Tip |
|---|
This section can be improved with instructions on how to unblock yourself if you accidentally ban yourself. |
| Tip |
|---|
This section can be improved with a linked article on how to customize fail2ban to ignore specific ip addresses and subnets. |
Deny Hosts
Another package that should be installed to prevent distributed brute force ssh attacks is Deny Hosts.
| Code Block | ||
|---|---|---|
| ||
sudo apt-get install denyhosts{code}
{tip}
This section can be improved with more details and unlocks similar to fail2ban.
{tip} |
| Tip |
|---|
This section can be improved with more details and unlocks similar to fail2ban. |