These days, most network devices use SNMP for remote monitoring and configuration. SNMP is a simple protocol used usually to create monitoring software that can retrieve information such as network traffic, CPU load, disk load, etc., and also to modify configuration of devices such as wireless equipment, broadband routers, etc.
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 way SNMP 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 version 3, 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.

Open Secure Sockets Layer (OpenSSL)

The OpenSSL library is the most popular choice for applications that need cryptographic support in network communications. Such applications are Apache (HTTP secure connections), Sendmail, OpenLDAP, OpenSSH, etc.
Vulnerabilities in one version of the OpenSSL libraries affect all applications that use them and can be exploited through those. Depending on the functions used by the application, vulnerabilities in OpenSSL can be exploited through the application to execute arbitrary code on the server or even to get root privileges.
OpenSSL had some vulnerabilities in the past that did a lot of damage to servers running applications compiled with OpenSSL support, especially Apache, Sendmail and OpenSSH. In the Sendmail case, an exploit that gave the attacker root privileges was published on security mailing lists.
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 http://www.openssl.org.
• 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.

Protect Running Services General Discussion

A network administrator's job is to keep the network running and safe. There are services that don't depend on him or her; for example a web server could be administered by a webmaster. The steps outlined here would make you feel more secure. We will follow this up by actually testing out these steps on a Linux box so that you get a better idea.
1. Identify services that run on every system. Most importantly, identify open ports and the services that opened them.
2. Verify every running service's current version. Update to the latest software version. Search for vulnerabilities for the service at its homepage and at http://nvd.nist.gov/.
3. Verify the configurations and, when you can, create software-based access lists to allow only trusted hosts to use that service. Try changing default usernames and passwords every time. If you can run the software in a chroot jail, do it.
4. If the service doesn't require access from everywhere, create a firewall to limit the access only to trusted hosts.
5. Audit your network! Try to hack into your network. Connect to your network as an outsider and test all running services against known exploits. Search for hacker tools and use them against your own network to see what happens.
6. Create logs for authentication requests. Also try to run a network intrusion detection system such as Snort, available at http://www.snort.org, which produces really good log files.

Not all the steps are required for every service that runs in your network; for example, there are some services for which you allow connections only from localhost and that's it.
Let's take a look at one of the Linux boxes in my network. For security reasons, I will interchange the IP addresses from the real world with reserved IP addresses.

1. First I will identify the opened TCP ports on the server:

So, we have TCP ports 179, 2601, and 2605 listening. For me, those are very well-known ports, but if I forget them, we need to see what services opened those ports:

• Let's identify the versions:

The latest vulnerabilities for Zebra were in version 0.93b; so no knownvulnerabilities here.
3. The next step is to configure the software. For Zebra, port 2601 is for its command line interface, which is very similar to a Cisco router. The same with the BGP for port 2605.

• The router has BGP connections with 10.10.10.1, 10.10.11.13, and with 10.10.15.1. What we want to do is deny access on the TCP port 179, which is used for BGP connections, to anyone except those IP addresses. Also, we want to double the protection we created with the software-based access lists for zebra and bgpd, and allow only localhost to connect to the Zebra and its routing protocol's VTYs.
• 5. Since we don't have software known for vulnerabilities, what we can do is to test and see if our firewall works:

see if we can do this from other locations:

Good! We can't connect from anywhere except localhost on the CLI of zebra and bgpd. Now, we should try to connect on TCP port 179 from one of the BGP neighbors: