What Is a Penetration/Vulnerability Test?

These tests or pseudo-attacks are conducted by an objective evaluation team and emulate an attack on one or more computer systems to discover ways to breach the system’s security controls, to obtain sensitive information, to obtain unauthorized services, or to simulate damage to the system by denying service to legitimate users. Security testing comprises a detailed inventory of network assets and a set of controlled attacks intended to find vulnerabilities in those network assets. The words attack and test are used to mean the same in the context of a security assessment.

Penetration tests (pen-tests) usually refer to tests against perimeter defenses, while vulnerability testing refers to tests against specific systems (host, applications, or networks). External assessments can be loosely defined as testing that is launched from outside the perimeter of the private network. This kind of testing emulates the threat from hackers and other external parties and is often concerned with breaching firewalls and other forms of perimeter security. On the other hand, for vulnerability testing the analyst is located somewhere within the perimeter of the private network and emulates the threat experienced from internal staff, consultants, disgruntled employees, or, in the event of unauthorized physical access or a compromise of the perimeter security, a hacker. The general rule of thumb is that internal threats comprise more than 60 percent of the total threat portfolio.

Testing can consist of something as simple as an Nmap or Nessus scan, or it can be as detailed as tests against a multitiered business application architecture requiring months of code review and application testing. The ground rules for testing define successful completion. Testing is successfully concluded when:

• A defined number of flaws are found.
• A set level of penetration time has transpired.
• A dummy target object is accessed by unauthorized means.
• The security policy is violated sufficiently.
• Money and resources are exhausted.
• Internal resources are accessed.
• Transaction data is captured.
• A particular program or transaction is executed.
• Access is gained to any user account.
• Access is gained to a root/administrative account.
• Network management systems are subverted.
• The ability to remotely control resources is demonstrated.

SNMP | Logging

The Simple Network Management Protocol (SNMP) is an application layer protocol that facilitates the exchange of management information between network devices. SNMP messages are encoded as ASN.1 binary using BER encoding, and run over UDP/161 and UDP/162. SNMP enables network administrators to manage network performance and to find and solve network problems. Three versions of SNMP exist: SNMP version 1 (SNMPv1), SNMP version 2 (SNMPv2), and SNMP version 3 (SNMPv3). SNMPv1 and SNMPv2 have a number of features in common, but SNMPv2 offers enhancements, such as additional protocol operations. Neither version provides for any authentication or encryption. SNMPv3 includes, among other things, a model for access control and security as well as for a new architecture. SNMPv3 has yet to attain wide acceptance; thus, SNMPv1 and SNMPv2 still predominate.

An SNMP network normally consists of three key components: managed devices, agents, and network-management systems (NMSs). A managed device is a network node that contains an SNMP agent. Almost every networked device functions as a managed device. An agent is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP An NMS executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. Applications such as HP Openview or Tivoli are examples of NMSs.

Managed devices are monitored and controlled using three basic SNMP commands: read, write, and trap. These commands are defined as follows:

• The read command is used by an NMS to monitor managed devices.
• The write command is used by an NMS to control managed devices.
• The tmp command is used by managed devices to asynchronously report events to the NMS.

Additionally, NMS and other applications (such as GetIF; see www.wtcs.org/snmp4tpc/getif.htm) can read and display the Management Information Base (MIB). A MIB is a (sometimes vendor-supplied) collection of information about the managed device that is organized hierarchically. The MIB contains fields that list all of the data the managed device can make available to the NMS.

SNMP community strings and some device configuration data are often among the first findings in penetration tests or vulnerability assessments. Most administrators forget about this threat or simply ignore it.

The best method for securing SNMP today is to turn it off. In VoIP networks, most IP-enabled telephones use SNMPV1 and SNMPv2 for configuration and performance moni-toring. Thus, it is often impossible to disable this service. If you must run SNMP over your internal networks, then adopt the following practices:

• Immediately change the default read/write community strings
  1. Do not use the default “public” or “private” string.
  2. Do not use a string that would be easy to guess, such as the company’s name or phone number.
  3. Do not use a text-only string; use an alphanumeric string (both text and numerals).
  4. Use both uppercase and lowercase letters (community strings are case-sensitive).
  5. Use a community string that is at least eight characters long.
• Employ ingress and egress filtering at the nearest network border, or limit SNMP to specific management and configuration VLANs.
• Allow SNMP traffic to only a few authorized internal hosts. Only a few network management systems need to initiate SNMP request messages. Thus, administrators can configure SNMP agents to prohibit request messages from unauthorized hosts.

Syslog | Logging

Interestingly, when discussing system logging, tired metaphors seem most apt. System log information “is a goldmine” of useful information, but searching through these data is “like trying to find a needle in a haystack.” Tired metaphor or not, the preceding statement is true. Time-stamped logs generated by servers, gateways, firewalls, proxies, routers, and switches often contain invaluable security-related inforrmation, but system administrators are normally so overwhelmed with other maintenance and configuration chores that analyses of these logs is disregarded. The key to successful log analysis is to adopt the proper tools for your environment to automatically parse, visualize, and report summarized log data. For example, many organizations utilize MRTG (Multi Router Traffic Grapher— http://people.ee.ethz.ch/~oetiker/webtools/mrtg/) to visualize router and switch SNMP network data.

Syslog

In its most simplistic terms, the syslog protocol provides a transport to allow a machine to send event notification messages across IP networks to event message collectors—also known as syslog servers. Syslog is an odd protocol in that it was implemented on many platforms before the protocol was ratified by the IEEE in RFC3164. Rather than begin by defining the protocol, RFC3164 starts with “This document describes the observed behavior of the syslog protocol”

Syslog messages use UDP/514 for transport, increasing the possibility of losing packets and never noticing, and also making it easy for anybody to forge fake packets, either to insert log events, or to flood the server. Syslog, at this time, does not provide for encryption, so the messages are sent in the clear and can be sniffed by anyone on the wire. Recently, a proposed draft has been submitted that describes a mechanism to add origin authentication, message integrity, replay-resistance, message sequencing, and detection of missing syslog niessages, but this is not commonly implemented. Several of the popular syslogd replacements (including syslog-ng) can use TCP for reliable delivery, and some add a checksum and/or cryptographic signature to each log event.

Syslog is native on most UNIX platforms, but is not available natively on Microsoft Windows. The most common Windows syslog daemon is Kiwi Syslog (www.kiwisyslog.com).

Syslog messages (ASCII-based) may be sent to local logs, a local console, a remote syslog server, or a remote syslog relay. The syslog facility collects messages and records them normally in log files in /var/log. A facility is defined as a subsystem which generates messages. What is recorded and where it is placed depends on the facility configuration file (syslog.conf). Syslog also uses severity (or priority to some) to classify log messages by importance. The severity levels, from least to most important, are:

• 0 Emergency: system is unusable
• 1 Alert: action must be taken immediately
• 2 Critical: critical conditions
• 3 Error: error conditions
• 4 Warning: warning conditions
• 5 Notice: normal but significant condition
• 6 Informational: informational messages
• 7 Debug: debug-level messages

There is also a severity of none. A severity of none indicates that all messages should be discarded. Entries in syslog.conf indicate how messages from each facility at the various severity levels should be handled.

Here is a small section of a BSD syslog file:

Jan 9 14:46:50 nsl /kernel: usbl:  on
uhcil
Jan 9 14:46:50 nsl /kernel: usbl: USB revision 1.0
Jan 9 14:46:50 nsl /kernel: uhubl: VIA UHCI root hub, class 9/0, rev
1.00/1.00, addr 1
Jan 9 14:46:50 nsl /kernel: uhubl: 2 ports with 2 removable, self
powered
Jan 9 14:47:00 nsl login: ROOT LOGIN (root) ON ttyv0
Jan 9 14:47:18 nsl /kernel: Connection attempt to UDP
192.168.20.20:162 from 192.168.20.1:24343
Jan 9 14:47:19 nsl /kernel: Connection attempt to TCP
127.0.0.1:16001 from 127.0.0.1:1024

Note that the messages are ASCII based and are composed of three major space-delimited fields: the time and date stamp, the hostname and facility, and a text-based message.

Configuration of syslog and syslog remote logging is trivial. Much more difficult than generating appropriate syslog messages is defining processes that determine how the logs are parsed, who is responsible for parsing, and what type of log entries result in actionable alerts.

In a VoIP environment, IP phones may generate syslog messages and servers almost certainly will. These messages should be sent to a centralized server where they are automatically parsed, and where reports are generated at least on a daily basis. These logs are a valuable and often ignored source of both intrusion detection events and system performance messages. For example, syslog can be configured to report failed logon attempts, sudo (a command that attempts to change a restricted user’s permissions to system level or root privilege) attempts, or any action that interacts with the PAM subsystem (Pluggable Authentication Module—an authentication framework). Any message that refers to one of these events may indicate that an intrusion has occurred.