Hack84.Log VoIP Traffic

Hack 84. Log VoIP Traffic

A Linux PC's built-in IP router and firewall, NetFilter, can be a useful tool for logging VoIP traffic.

In a scenario where several satellite offices on a WAN (or the Internet) are linked together as an IP telephony network, origin- and destination-based logging is crucial, because it will tell you which office is using the most VoIP capacity, which is using the least, and when it's all being used.

When a Linux NetFilter firewall is used to protect a group of enterprise VoIP servers 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 doing this. This will improve your understanding of bandwidth consumption and traffic patterns on your network, besides giving you a keener awareness of security.

6.14.1. Logging with NetFilter

NetFilter's default configuration provides for no logging. If you want a particular type of packet loggedsay, from a specific network or on a specific portyou 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. The following rule says to log all packets sent to the machine running the NetFilter firewall (keep in mind that this will eat up tons of storage space fast!):

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

The log prefix options 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 broad; it 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 also say that all three SIP proxies are in the same organization and that a 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 the network addresses 10.1.0.0/16, 10.2.0.0/16, and 10.3.0.0/16, as in Figure 6-13. The configuration examples given in this section are assumed to be running on the firewall in the 10.1.0.0 network.

Figure 6-13. Three physically separate softPBXs connected by an Internet VPN

Assuming a VoIP WAN like the one in Figure 6-13, it's possible to do some interesting logging and prefixing. Say you want to log SIP traffic by remote network. You can use the following commands to tag inbound and outbound traffic:

  # 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"  

This 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 this example, private trafficthat is, traffic to or from a 10.x.x.x hostis tagged separately from Internet traffic, which is indicated by the catch-all 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. Logging this type of traffic would tip you off to somebody trying to originate long-distance phone calls from your systemsomething I've encountered in the field myself.

To dig into your VoIP traffic, consult Table 6-2, which is a list of commonly used VoIP port numbers, by protocol.

Table 6-2. Commonly used VoIP ports

Service	Standard port numbers
SIP	5060, 5061 (usually UDP)
H.323	2099, 2517, and 2979 UDP and TCP
MEGACO/H.248	2944 and 2945 TCP and UDP
TFTP	69 TCP and sometimes UDP
Asterisk Manager API	5038 TCP
RTP	Varies often among 5000, 5001, 10000, and 10001; always UDP
IAX	5036 and 4569 UDP

6.14.2. Read and Analyze VoIP Traffic 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 might 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, an application for reading kernel logging messages like the ones you captured earlier, provides flat text output that you can redirect to a file or pipe into another application for further filteringlike grep. Suppose you want to isolate the traffic prefixed with "Chicago" into a file by itself. You can use this command:

 # dmesg | grep Chicago >chicagoVoIP.txt 

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

 # dmesg | grep Chicago | mail  [e-mail]  

By combining good logging with good, high-level network traffic assessment [Hack #75], you'll have an excellent grip on what's happening beneath the application layer on your VoIP network. You'll know how it all works, because you'll have many techniques to observe VoIP packet flow, including the packet logging I've just described.

6.14.3. See Also

• "Graph Latency and Jitter" [Hack #75]

• "Peek Inside of SIP Packets" [Hack #81]

• "Sniff Out Jittery Calls with Ethereal" [Hack #83]