Securing Open Secure Sockets Layer (OpenSSL)

To stay protected, consider the following:

  • Identify the OpenSSL version on each of the servers that has the libraries installed. Check to see if you have the latest version and if your version of OpenSSL has remotely exploitable vulnerabilities.
  • Upgrade your OpenSSL library to the latest version from the OpenSSL website at
  • Identify applications that use the OpenSSL library, and if they require recompilation because of the upgrade, recompile them to use the new libraries.

If applications using OpenSSL don’t require connections from everyone, create a proper firewall to allow connections only from trusted sites.

Securing Simple Network Management Protocol (SNMP)

Most SNMP implementations on those kinds of network devices use version 1 or version 2, which have a very weak authentication method. SNMP version 1 contains a set of bugs in the waySNMP traps and requests messages are handled and decoded that can be exploited in many ways, from denial of service to rewriting the configuration.

SNMP versions 1 and 2 use community strings for authentication. These are sent on UDP port 161 unencrypted; so it is very easy for a man in the middle to sniff the community strings.When you set up SNMP on a device (including a Linux box),you must set up two community strings: one that has read-only access and the default is “public”, and one that has read-write access and the default is “private”. If you don’t change the communities to SNMP-enabled devices, it is very easy in the absence of a firewall to view their configuration and change it.

This is very dangerous for the devices and the network; so here’s what you should try to do:

  • Try not to use SNMP, unless you have to.
  • Whenever possible, use SNMP version3, which has user mode authentication and can do encryption.
  • In any case, if you use SNMP, change the default communities.
  • Create a proper firewall on the device or on a device in front of it, allowing only trusted hosts to connect using SNMP.

For instance, a Cisco router running SNMP with the community string “public” reveals its entire running configuration, including usernames and passwords as well as the enable secret and password. If the router has the SNMP community “private” for write access, you can modify absolutely everything in the configuration. More than that, most Cisco routers have SNMP enabled by default with the default communities and without filters.

Mail Transport Agents (MTA) Vulnerability Issues

The most popular MTA for Linux is Sendmail, which had a lot of security issues including buffer overruns that could be remotely exploited to compromise the MTA server.Popular alternatives to Sendmail are Postix, Qmail, Exim, and Courier-MTA.

MTAs’ most popular problems are the following:

  • Vulnerabilities such as buffer overruns, heap overlows, etc., which can be used by remote or local attackers to compromise the server running the MTA.
  • Missconfiguration of the MTA allowing everyone to use it for sending mail. This is called open relay. Missconfigured MTAs as open relays immediately fall in the hands of spammers, which may cause big damages to your company by having your email server in one of the many email servers blacklists, plus the fact that all the spam consumes your bandwidth. You can check your mail server to see if it is an open relay at, which runs a set of tests to see if there’s any way for a spammer to use your email server to send mail to other people.
  • User-account database disclosure vulnerabilities

Securing Version Control Systems

To protect against these vulnerabilities, consider the following steps:

  • Update CVS to the latest stable release. CVS can be found at
  • Run the CVS server in a chroot jail.
  • Conigure CVS to use the SSH protocol instead of the pserver protocol (which sends the passwords in plaintext).
  • If you don’t allow anonymous access to your CVS server, try iltering port 2401 to allow only trusted hosts to connect to it.
  • Host the CVS server for anonymous read-only access on a stand-alone system.
  • Run the published exploits against your CVS servers.

To protect your subversion server against those vulnerabilities, consider the following steps:

  1. Update your subversion software to the latest stable version from
  2. Configure subversion to use webDAV instead of the svn protocol.
  3. If you don’t allow anonymous access to your subversion server, try filtering the TCP port 3690 to allow only trusted hosts.
  4. Run the published exploits against your subversion server.
  5. Host the subversion server for anonymous read-only access on a stand-alone system.

Securing Apache Web Server

Here is some of my advice on what would provide a more secure Apache server:

  • Patch your server and try to keep it as up to date as possible.
  • Remove all sample scripts of add-on modules (mod_php, mod_cgi, mod_perl, etc.).
  • If running PHP, CGI, and other script languages, consider using suEXEC, a wrapper program called by Apache to allow it to call scripts from a different user ID than the one it uses for Apache.
  • Don’t allow uploads of any scripts into your web server by untrusted parties.
  • Read about all vulnerabilities of any open-source projects that you install, such as PHPBB forums, for example.
  • Don’t run the web server as root. Create a user with minimal rights to run the web server.
  • Modify the response token for your web server. It’s harder for an attacker to bring it down when he or she doesn’t know what web server you are running.

Securing BIND Domain Name System (DNS)

Here is some of my advice on what would provide a more secure BIND:

  • Don’t use the BIND package that comes with your distribution of Linux; download the latest from BIND website (
  • Place BIND in a chroot jail. This is the best thing to do to protect against remotely exploitable vulnerabilities in BIND that allow attackers to get a shell on the server running BIND. If you don’t chroot your version of BIND and such a vulnerability is discovered, your Linux server and all data on it may be compromised before you have the time to upgrade.
  • Always apply patches and upgrade BIND whenever a bug is discovered or a new version comes out.
  • Secure zone transfers between primary and secondary DNS servers using DNS Transaction Signatures (TSIG).
  • Disable recursion and glue fetching to defend against DNS cache poisoning.

Although BIND is more popular and easier to conigure, consider using TinyDNS, as it has proven to be more secure over the years.