VoIPowering Your Office with Asterisk: Securing Your Server, Part 2

By Carla Schroder | May 1, 2006 | Print this Page
http://www.enterprisenetworkingplanet.com/unified_communications/VoIPowering-Your-Office-with-Asterisk-Securing-Your-Server-Part-2-3602726.htm
Last week in part 1 we changed a bale of passwords. Today we'll take two more important steps to lock down our Asterisk@Home server: make sure that all Web administration traffic is encrypted, and lock down OpenSSH more tightly.

Locking down OpenSSH
By default, Asterisk@Home sets up OpenSSH to run after installation, and to accept root logins. Accepting remote root logins is not the best security practice, because it leaves the door open for brute-force attacks on the root account.

If you're thinking that you don't need to worry about these things because your Asterisk server is safely tucked behind your stout firewall, using a non-routable private IP, you are right that this reduces the potential for attacks from the Internet. However, should a remote attacker succeed in getting behind your firewall, it's better for them to find more barriers, rather than a wide-open welcome. And don't forget that most security breaches are inside jobs, rather than silly Hollywood-type break-ins from the outside.

There are a couple of different ways to make OpenSSH more secure. A simple way is to create an ordinary, unprivileged user on the Asterisk server, use this account for remote logins, then disable remote root logins. To set this up, log into the server from another PC on your LAN and create this user, using any name you like:

carla@windbag:~$ ssh root@192.168.1.25
Last login: Tue Apr 25 13:13:35 2006 from 192.168.1.10
Welcome to Asterisk@Home
-------------------------------------------------
For access to the Asterisk@Home web GUI use this URL
http://
For help on Asterisk@Home commands you can use from this
command shell type help-aah.

[root@asterisk1 ~]# useradd freduser
[root@asterisk1 ~]# passwd freduser

Changing password for user freduser.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
[root@asterisk1 ~]#

Now exit the root login, then login as your new user:

[root@asterisk1 ~]# exit
Connection to 192.168.1.25 closed.
carla@windbag:~$ ssh freduser@192.168.1.25

After you are logged in, use the su (switch user) command to become root:

[freduser@asterisk1 ~]$ su
Password:
[root@asterisk1 freduser]#

Excellent! It works. Now open /etc/ssh/sshd_config, and add these lines:

[root@asterisk1 freduser]# nano /etc/ssh/sshd_config
PermitRootLogin No
AllowUsers freduser
Protocol 2

Then restart OpenSSH:

[root@asterisk1 freduser]# /etc/init.d/sshd restart

The AllowUsers directive is a nice way to preserve the flexibility of logging in from random remote hosts on your LAN, while blocking unauthorized users and brute-force attacks on the other Asterisk system accounts.

OpenSSH supports two ssh protocols, 1 and 2. ssh1 is obsolete and weak, so it's important to limit your SSH sessions to Protocol 2 only.

This makes SSH logins a two-step process, which is a bit inconvenient, but it adds a significant measure of security. Our little "freduser" has no power to do anything on the server, so even if an attacker succeeded in cracking freduser's account, the attacker would have to escalate to the root user to do any damage. This is called "privilege escalation". Privilege escalation is a fundamental tactic in any Linux intrusion attempt, because an attacker can't touch system files without rootly powers. This is why old Linux/Unix admins always nag about "don't do anything as root except what you really really have to." Strong passwords work, so make sure freduser has one. (See last week's article for information on password management.)

Using Public Key authentication
A second way to tighten up remote SSH access is to use public-key authentication. This protects your system passwords because you authenticate with a cryptographic key, instead of using a login/password. (See Resources to learn how to do this.) In addition to disabling root logins, you should also disable password authentication with this line in /etc/ssh/sshd_config:

PasswordAuthentication no

Now you can sit back and laugh at brute-force SSH attacks, because they simply won't work.

Why remote administration?
If you're wondering why you can't just sit down at your Asterisk server to do all your command-line chores, the answer is you can. So, if you don't need SSH access, you should turn it off entirely. Use the chkconfig command to do this:

# /sbin/chkconfig --del sshd

This doesn't turn off a running SSH session, but only prevents it from starting up at boot, so you need to shut it down:

# /etc/init.d/sshd stop

Securing AMP traffic
Any server administration done over a Web interface is transmitted in cleartext, unless you enable HTTPS. HTTPS is SSL over http: a nice easy way to encrypt HTTP traffic. To activate it on your Asterisk server all you need to do is install the Apache SSL module, then restart Apache (Apache is the Web server included in Asterisk@Home):

# yum -y install mod_ssl
# /etc/init.d/httpd restart

Then all you have to do is remember to point your Web browser to https://[asterisk-server].

Asterisk@Home is a complex package, so there may yet be the odd security hole somewhere. But you should be in pretty good shape now. Please visit the previous "VoIPowering Your Office" articles in this series if you're feeling a bit lost, as everything is laid out sequentially, and come back next week for more tasty Asterisk how-tos.

Resources
The (Practically) Ultimate OpenSSH/Keychain Howto
Asterisk@Home