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

Last week in part 1 we changed a bale of passwords. Today we’ll take two more important steps to lock down our [email protected] server: make sure that all Web administration traffic is encrypted, and lock down OpenSSH more tightly.

Locking down OpenSSH
By default, [email protected] 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:

[email protected]:~$ ssh [email protected]
Last login: Tue Apr 25 13:13:35 2006 from
Welcome to [email protected]
For access to the [email protected] web GUI use this URL
For help on [email protected] commands you can use from this
command shell type help-aah.

[[email protected] ~]# useradd freduser
[[email protected] ~]# passwd freduser

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

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

[[email protected] ~]# exit
Connection to closed.
[email protected]:~$ ssh [email protected]

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

[[email protected] ~]$ su
[[email protected] freduser]#

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

[[email protected] freduser]# nano /etc/ssh/sshd_config
PermitRootLogin No
AllowUsers freduser
Protocol 2

Then restart OpenSSH:

[[email protected] 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 [email protected]):

# 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].

[email protected] 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
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.

(Practically) Ultimate OpenSSH/Keychain Howto

[email protected]

Latest Articles

Follow Us On Social Media

Explore More