Linux security help: Nagios with BMC Patrol, setting up SSH and more

A Linux security expert describes how to configure Nagios with BMC Patrol, gives non-platform-specific help for setting up Secure Shell (SSH) and more in this interview.

There isn't an easy and automated way to monitor open ports in Red Hat Enterprise Linux 5 (RHEL 5), says the author of Hardening Linux , James Turnbull. However, you can scan with some handy open source tools. Turnbull recommends using hardscan, a Netstat-based tool, if you think you have been compromised.

More Linux security tips:
Firekeeper configuration: Hardening your Firefox browser

Improving Snort performance with Barnyard

In this tip, SearchEnterpriseLinux.com's security expert describes how to configure Nagios with BMC Patrol, non-platform-specific tips for using Secure Shell (SSH) and more.

How can you secure a Linux proxy, Fedora Core 5, from hackers, viruses and attackers?

Turnbull: Generally speaking, a proxy is a little more vulnerable than some other kinds of hosts, and they are often targets of internal users trying to bypass corporate policies and controls. I recommend the following general steps:

  1. Firewall your host carefully and only allow access to those ports you absolutely require.
  2. Only install and run the minimum services needed to perform the proxies function.
  3. Regularly update and patch your host.
  4. Review and check your logs -- both OS and proxy.

More specifically for proxying, I recommend ensuring you scan incoming and outgoing content for viruses and malicious code. There are a number of open source or commercial virus scanners that can work in conjunction with Squid. If you use Squid you can also make use of blacklisting with a tool like SquidGuard and you can find a number of other Squid-related tools.

Lastly, make sure you use some kind of authentication for your proxy users. You will want to make certain that appropriate access control lists (ACLs) are configured in Squid to ensure that only your users can make use of your proxy and, preferably, that users must authenticate against a directory such as LDAP with a username and password.

When using Red Hat Enterprise Linux 5 (RHEL 5), how can you monitor which ports are open on different servers to make sure someone hasn't compromised ports for other uses?

Turnbull: There isn't an easy and automated way to do this from a monitoring environment. Perhaps the best method is regular Nmap or Nessus scans of your hosts (though this has some risks and you will have to ensure that you set up both to scan in a non-intrusive manner) with the output compared a pre-defined baseline. Both tools will also generate a lot of network 'chatter' and if you have an IDS/IPS installed, then this will potentially look like an attack and generate false positives.

If in the event your host may have been compromised there is also hardscan, a netstat replacement for scanning local ports, attempting a handshake and outputting the results. This can often help in identifying a host infected with a rootkit that has ompromised ports open.

In a past question, "Is it possible to integrate Nagios with BMC Patrol," you mentioned that you could do such a thing. What is the process for configuring Nagios to send the information that Nagios gathers from our Linux servers, and have it reported to BMC Patrol?

Turnbull: Here are the instructions:

  1. Configure Nagios to generate SNMP traps for any alerts you wish to send to Patrol. I use the snmptrap application that comes with Net-SNMP to do this, combined with a global or service-specific event handler. Or you could configure Patrol to be one of your standard notification methods, like email, pager or mobile phone. Below is an example of a SNMP trap that combines OIDs and Nagios macros that could be sent to Patrol. This will almost certainly need to be modified to suit your environment.
    define command {
        command_name                       notify-pem-service-trap
        command_line                        /usr/bin/snmptrap -d -v 1 -c
    public pemprod.testing.com .1.3.6.1.4.1.2789.2005 '' 6 ''
     '' .1.3.6.1.4.1.2789.2005.1 s "Notification Type: $NOTIFICATIONTYPE$"
    .1.3.6.1.4.1.2789.2005.2 s "Service: $SERVICEDESC$" .1.3.6.1.4
    .1.2789.2005.3 s "Host: $HOSTALIAS$" .1.3.6.1.4.1.2789.2005.4 s
    "Address: $HOSTADDRESS$" .1.3.6.1.4.1.2789.2005.5 s "State: $SERVICES TATE$" .1.3.6.1.4.1.2789.2005.8 s "DateTime: $SHORTDATETIME$"
    .1.3.6.1.4.1.2789.2005.7 s "Additional Info: $SERVICEOUTPUT$"
    }
    
  2. Configure BMC Patrol to receive and process the incoming trap and assign the data to the relevant host and service being monitored. You will generally need to send at least the hostname, service, service state and any relevant host or service output to BMC Patrol.

What is the difference between the "log" log and the alert logs that show up in the /var/log/snort directory that you refer to in your article, "Improving Snort with Barnyard"?

Turnbull: This is an interesting question. The difference between alert and log comes down to how you write your rules. Rules can have actions associated with them when they trigger. The possible actions are, to quote the Snort manual:

  • alert -- generate an alert using the selected alert method, and then log the packet
  • log -- log the packet
  • pass -- ignore the packet
  • activate -- alert and then turn on another dynamic rule
  • dynamic -- remain idle until activated by an activate rule, then act as a log rule

If a rule is configured to alert, then an alert will be generated and outputted to whatever alert method you have configured, like a file in /var/log/snort. The packet is then logged to your log output method; for example, the snort*.log files. So by processing the log files, you will get all of the entries. The best and clearest answer to this question, however, comes from Marty Roesch himself in this 2002 mailing list post.

Can you offer some tips for setting up an SSH service for secure, remote access to servers?

Turnbull: It would help to know on what platform you'd like to set up SSH on, but I can provide some general tips.

  • Use only SSH V2 -- V1 is vulnerable to compromise. On Linux, this is usually done by default and managed in your /etc/ssh/sshd_config file by the Protocols option.
  • Don't allow root or Administrators to log in directly. Only normal users should be allowed to log in and then if required they can escalate their privileges by using su or sudo. On Linux this is controlled, again in the sshd_config file, by the PermitRootLogin option.
  • Ensure you use suitable authentication, for example passwords or keys.
  • Try to avoid using port 22 for your SSH connections. Automated brute force attack tools are commonly used by attackers to scan port 22 and try to brute usernames and passwords. Changing the port to something else, for example 2222, is a quick and simple way of reducing this risk. Alternatively, if you must use port 22, you can use tools like BlockSSHD (Note: I am the author of this tool) or Fail2Ban to block excessive or inappropriate login attempts.
  • Ensure you have configured suitable logging of your SSH daemon and that you review your logs for illicit login attempts. Ttools like Swatch and SEC can assist with this.
  • Only bind SSH to the addresses required. If you have multiple interfaces in your host, for example an interface on your internal network and another on an external network such as the Internet, then only bind the daemon to the interface through which you need to connect. This is controlled on Linux using the ListenAddress option.
I hope that helps.
This was first published in June 2007

Dig deeper on Linux security risks and threats

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchDataCenter

SearchServerVirtualization

SearchCloudComputing

SearchEnterpriseDesktop

Close