10.6. Project 10.3. Logging and Controlling VoIP Packets with iptables
10.6.1.1 What you need for this project:
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.
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 .
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:
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 chicagoVoIPadmin@oreilly.com
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:
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.
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.