Your Distro is Insecure: Ubuntu

Ubuntu Server has one of the cleanest and easiest Linux distribution installers. However, in many cases, its designers choose to ignore security in favor of ease-of-use. The result? An install that is not secure by default.

Post Installation – Network

One of the quickest way for hackers to access systems are to use services that are not well documented or well understood. Once a system is in production, it is often unlikely the system will be further hardened so additional risk is created by not addressing services that are typically not being used.

Ubuntu allows the software sets to be chosen that the sys admin wishes to use; however, a closer look at an abridged version of netstat shows services that are not likely needed or unintended by the sys admin will appear:

root@sparky:~# netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:pop3 *:* LISTEN
tcp 0 0 *:imap2 *:* LISTEN
udp 0 0 *:bootps *:*
udp 0 0 *:bootpc *:*

Ironically the first two entries: the Post Office Protocol version 3 (pop3) and the Internet Message Access Protocol version 2 (imap2) are installed and running despite Ubuntu having installed the more secure versions. Both of these older protocols were needed in years past for interoperability with older mail programs, but all major mail programs now support the more secure versions. (The biggest issues with these older services are clear text passwords; however, POP2 servers have also been vulnerable to root compromises.)

The bootps and bootpc entries are for providing dynamic addressing via the BOOTP and DHCP protocols — and are on by default although static addressing is being used, and will typically be used by a server install. Even if the intent was to provide DHCP services to the network, this option is not covered as part of the install and is hidden under the DNS selection of the install.

Having these unauthorized services running knocks the Ubuntu report card down to a B for authorization.

User Accounts – Keys to the Kingdom

Remote access combined with loose management of user IDs is a recipe for disaster. The key to secure system ID management is limiting the system to only those necessary and not allowing remote shell access to those accounts.

Reviewing Ubuntu’s system accounts show the following:

list:x:38:38:Mailing List Manager:/var/list:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh

With the exception of the sshd, all of the system accounts are provided with an interactive shell session. So when any of these accounts are compromised interactive remote access is most likely the results. For example, a buffer overload for some of the mail processes could result in one of the mail related users (mail, news, uucp, etc.) providing remote access to the system through a shell login. Ubuntu should flag these accounts with the nologin option or possibly /bin/false.

Even of more concern is the fact that there are user IDs that are in use that were not made obvious by the installation process. For example, print server was not chosen, yet the lp user exists and is active. Other suspect accounts are news, uucp, list, irc.

Some arguments are made that the desire for standardization of user IDs across the distribution is more important than not including the user IDs. For example, uucp should always be UID 10. There is value to such a standard; however, a more secure method could be used by including intelligence into the package management and passwd programs. Or, a more simple option, to create the IDs and then to disable them to avoid the UID integer being used by another user ID.

While Ubuntu’s practice is not uncommon, the identity management must be tighter on a distribution aiming at the enterprise market on the server distribution. Therefore, an A- is warranted for standard identity management.


Ubuntu has one of the cleanest and easiest Linux distribution installers; however, its designers choose to ignore security in some areas as shown above. Although these issues can be addressed post install in most cases, the install is not secure by default.

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62