Section 10.6. Project 10.3. Logging and Controlling VoIP Packets with iptables

10.6. Project 10.3. Logging and Controlling VoIP Packets with iptables

10.6.1.1 What you need for this project:

• A Linux PC capable of running the NetFilter firewall (iptables)

• LAN

When a Linux NetFilter firewall is used to protect a group of VoIP bastion hosts or just as a gateway router for a segment where VoIP is used, a lot of VoIP- related events can be monitored and logged. Logging from the firewall is useful for the security-minded, but it's important for other reasons, too. It lets you get a feel for which remote networks and hosts are communicating with your VoIP services and how often they are. This can improve your understanding of bandwidth consumption and traffic patterns on your network, besides giving you a keener awareness of security.

NetFilter's default configuration provides for no logging. If you want a particular type of packet logged, say, from a specific network or on a specific port, you must tell NetFilter to log it. When a packet is logged, its pertinent information is sent to syslog to be stored. Syslog is the system-wide logging daemon that is a staple in most Unix-variant operating systems.

Logging packets using NetFilter doesn't save the contents of the packetsjust information from the packets' headers! If you want to capture packets, you'll need other software, like Network Associates' Sniffer or the open source tool Snort.

To enable logging, you must set up a rule that specifies which packets you want to log. This rule says to log all packets sent to the machine running the NetFilter firewall (keep in mind, this will eat up tons of storage space fast! ):

 #  iptables -A INPUT -j LOG --log-prefix "Log it all baby."  

The log prefix option allows you to specify what will appear at the beginning of the log entry for each packet. That way, when you comb through lengthy databases of these entries, you can find specifically what you're looking for. The following rule is very broadit captures any and all SIP traffic going through the firewall (FORWARD chain) and logs it:

 #  iptables -A FORWARD -P udp --dest-port 5060,5061 -j LOG --log-prefix "SIP"  

Let's say that you are operating a SIP proxy that facilitates VoIP calling via SIP directly to two other proxies. Let's say all three SIP proxies are in the same organization, and that site-to-site VPN is used to connect them all. The three proxies support three VoIP LANs at separate offices. The LANs they support have network addresses 10.1.0.0/16, 10.2.0.0/16, and 10.3.0.0/16, as in Figure 10-4. The configuration examples given in this section are assumed to be running on the firewall in the 10.1.0.0 network.

Figure 10-4. Packet logging on NetFilter firewalls can be configured to distinguish between traffic based on its destination or origin

Assuming a VoIP WAN like the one in Figure 10-4, it's possible to do some interesting logging and prefixing. Say you want to log SIP traffic by remote network:

 #  iptables -A FORWARD -P udp -s 10.2.0.0/16 --dest-port 5060 -j LOG --log-prefix \ "FromDetroit"  #  iptables -A FORWARD -P udp -d 10.2.0.0/16 --dest-port 5060 -j LOG --log-prefix \  "ToDetroit"  #  iptables -A FORWARD -P udp -s 10.3.0.0/16 --dest-port 5060 -j LOG --log-prefix \  "FromChicago"  #  iptables -A FORWARD -P udp -d 10.3.0.0/16 --dest-port 5060 -j LOG --log-prefix \  "ToChicago"  

The preceding example tags all the Detroit traffic separately from the Chicago traffic, making it easier to discern later on when you're viewing the packet log.

A simple modification to the previous example would allow you to log RTP traffic (port 8000 or whatever your endpoints use). On a strategically placed Linux firewall, this could provide valuable information about bandwidth consumption at the Detroit and Chicago sites in the example.

Another technique is to differentiate VoIP traffic that is to/from the private network from that which is to/from the Internet or another foreign VoIP network:

 #  iptables -A FORWARD -P udp -s 10.0.0.0/8 --dest-port 5060,8000 -j LOG --log-prefix\  "Private VoIP"  #  iptables -A FORWARD -P udp -d 10.0.0.0/8 --dest-port 5060,8000 -j LOG --log-prefix\  "Private VoIP"  #  iptables -A FORWARD -P udp -s 0.0.0.0/0.0.0.0 --dest-port 5060,8000 -j LOG \     --log-prefix "Internet VoIP"  #  iptables -A FORWARD -P udp -d 0.0.0.0/0.0.0.0 --dest-port 5060,8000 -j LOG \     --log-prefix "Internet VoIP"  

In the preceding example, private trafficthat is, traffic to or from a 10.x.x.x host, is tagged separately from Internet traffic, which is indicated by the catchall network address 0.0.0.0.

In a VoIP network that's connected to the Internet but doesn't use the Internet as a call path , it would be a good idea to log all VoIP traffic originating from the Internet. Such traffic could be an indicator of system abuse, just as email systems are abused by spammers. Refer back to Project 10.2 for a list of VoIP-related port numbers .

iptables Quick'n Dirty

iptables is the program used to manipulate the Linux kernel's built-in firewall, NetFilter. iptables uses tables, which are stages of processing for each packet on the host. These tables are called filter , nat , and mangle . The default table, and the one with the most relevance for traffic monitoring, is filter . Each table has chains that represent the general characteristics of each type of traffic. In the filter table, the chains are:

INPUT

The chain that processes packets received by the host from the network. This chain is frequently used to define local firewall policy on Linux-based softPBXs.

FORWARD

The chain that processes packets that the host is routing. This chain is often used to define network policy for a group of hosts being protected by the NetFilter host.

OUTPUT

The chain that processes packets created by the local host that are destined for the network. This chain can be altered to protect other hosts from attacks originating from the NetFilter host or just to minimize network chatter.

While iptables is an exhaustive subject deserving its own volume, here's a synopsis of its syntax.

Syntax:

 iptables [-t table] -[ADCP] chain rule-specification [options] 

Options:

-t

Specifies which table to alter or examine.

-A

Appends a rule to a chain.

-P

Sets the policy for a chain. If no other rule matches the packet, then this policy will be enforced.

-D

Delete the rule from the chain that matches the rule specification.

-L

List the rules. Optionally, supply a chain name , and only that chain's rules will be shown.

-F

Remove all the rules. Optionally, supply a chain name, and only its rules will be removed.

The -A and -P actions always have a filter to match packets on their protocol, destination, port number, and so on. The filters are set up using these options:

-d

Destination network address

-s

Source network address

-p

Protocol, i.e., UDP, ICMP, etc.

-i

The name of the local interface that first processed the packet

-o

The name of the local interface that will process the packet if and when it is routed iptables rules often have a target specified by the -j TARGET option, which tells NetFilter what to do with the packets matched by the rule. Some useful targets are:

LOG

Log the packet according to your system's kernel-logging configuration.

REJECT

Don't accept the matched packet, and send an error packet in response.

DROP

Don't accept the matched packet, and don't send any response.

DSCP

A target used with the mangle table to alter DSCP code points and classes in packets.

TOS

A target used with the mangle table to alter IP Type of Service headers in packets.

There are dozens more options that can help you leverage iptables in Voice over IP. Refer to the iptables manpage for more details.

10.6.1.2 Reading and analyzing packet logs

Once you've used iptables to tell NetFilter to catch some VoIP traffic and log it, the log data is stored in the kernel facility of a syslog database file, where it can be retrieved using the dmesg command on Red Hat Linux. Other operating systems may provide different tools for viewing system logs.

When packets are logged, several bits of information about each packet are stored:

• The protocol of the packet (UDP, TCP, ICMP, etc.)

• The date and time the packet traversed the NetFilter chain where it was logged

• The size of the packet

• The source and destination addresses and ports (sockets)

• The originating MAC hardware address (when the packet comes from an Ethernet interface)

• Of course, the prefix that you specify in the log-prefix option, if any

dmesg 's output is flat text that you can redirect to a file. Suppose you wanted to isolate the traffic prefixed with Chicago into a file by itself:

 #  dmesg  grep Chicago >chicagoVoIP.txt  

Or better yet, email that log to somebody, perhaps so they can import it into a spreadsheet for further analysis. In the following example, pressing Ctrl-C will stop the dmesg application and an email will be sent containing the Chicago entries:

 #  dmesg  grep Chicago  mail [e-mail]  

10.6.2. SNMP

Simple Network Management Protocol is a lightweight method of collecting traffic and performance data from network devices such as servers and switches. Different kinds of data use different parameter schemas, called management information bases, or MIBs. MIBs define how SNMP refers to metafields specific to a certain kind of data, such as Ethernet traffic or DNS-lookup statistics.

MIBs exist for SIP (http://www.iana.org), VOCAL (http://www.vovida.org), MEGACO (http://www.ietf.org), and other VoIP technologies. There are some useful VoIP-related SNMP monitoring tools (OpenNMS, Multirouter Traffic Grapher, etc.) that can be customized to make use of these MIBs, too. There isn't yet a fully integrated SNMP MIB for Asterisk, though, which leaves Asterisk administrators only one performance data-collection option: log reading. Fortunately, Asterisk is very flexible in the logging department.

10.6.3. Project 10.4. Tune Up Asterisk's Logging Configuration

10.6.3.1 What you need for this project:

• Asterisk

Log analysis should be the core of your daily system monitoring and security activities. Like other softPBX servers, Asterisk supports flexible logging, providing several levels of logging detail in several different files. It also supports using syslog.

By default, Asterisk stores its logs in /var/log/asterisk .

Configuration of Asterisk logging is done in the /etc/asterisk/logger.conf file, which Asterisk reads at boot time or whenever it is started. The first section of the file is [general] , where you can assign a value to the dateformat option to specify what date format to use in Asterisk's logs. To figure out the syntax of the date formats, read the manpage for strftime( ) by running man strftime .

The next section, [logfiles] , describes which files should be used for logging output, and how detailed each should be. The syntax for this section is:

 filename => level,level,level... 

Consider the following logging configuration:

 [general]     [logfiles]     messages.log => notice,warning,error     debug.log => notice,warning,error,debug,verbose 

In this example, messages.log will contain a digest version of Asterisk's logging output, while debug.log will get everything in minute detail. Be careful with logs, thoughAsterisk won't start once the logfiles reach 2 GB in size. On a busy system, a file like debug.log , resulting from the previous code, would hit that size pretty quickly, so make sure your logfile rotation includes Asterisk.

10.6.3.2 The console keyword

If you use console as a log filename, Asterisk will assume you mean the console device, not an actual logfile. So, if you added this to the [logfiles] section, the desired level of logging would be output to the console session where Asterisk is launched:

 [logfiles]     console => warning,error 

10.6.3.3 Use a non-default log directory

Some attackers cover their tracks by removing commonly used logfiles that could contain evidence of their tampering with the system. So it's generally a good idea to keep logfiles in a non-default place. This way, if the attacker uses an automated program to remove logfiles, it will be less likely to find and destroy Asterisk's. To change Asterisk's default log location, edit /etc/asterisk/asterisk.conf and change the astlogdir directive to a path of your choosing. (Then make sure that path has appropriate permissions to allow Asterisk to write files in whichever path you choose.) A sample asterisk.conf follows :

 [directories]     astetcdir => /etc/asterisk     astmoddir => /usr/lib/asterisk/modules     astvarlibdir => /var/lib/asterisk     astlogdir => /var/log/asterisk     astagidir => /var/lib/asterisk/agi-bin     astspooldir => /var/spool/asterisk     astrundir => /var/run/asterisk 

10.6.3.4 Enable syslog

syslog can be a target for Asterisk logging output, too. To enable it, use a syslog keyword in the [logfiles] section, similar to the console keyword:

 syslog.local0 => warning,error 

10.6.4. Snort and Nagios

Snort is an open source intrusion-detection system (IDS) and packet-logging apparatus. Unlike NetFilter and syslog, Snort allows more customizable logging of traffic. Instead of merely logging the headers of rule-matched packets, Snort lets you record and store the entire rule-matched packets. It also lets you configure alarms that can be triggered by signature characteristics of known exploit attacks and suspicious conditions.

Like many of the other things we've discussed in this book, Snort is a deep subject in its own right. Indeed, to fully integrate Snort and other security software into your VoIP arsenal, you'll want to read O'Reilly's Managing Security with Snort and IDS Tools .

Nagios (formerly called Netsaint) is an open source network-monitoring suite. Its web-based interface allows network managers to watch activity on a single host or network-wide basis. It uses a combination of an SNMP collection and open Nagios-specific add-ins that make it aware of new vulnerabilities and intrusion signatures. Nagios even offers environmental monitoring interfaces for your server room's HVAC system, so you can be alerted when the temperature gets too high or low. You can find out more about Nagios at http://www.nagios.org.