This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
238
|
Chapter 10: Security and Monitoring
telephony apps. That would not be a good situation anywhere: voice is expected to
work 100 percent of the time.
But rather than respond to threats after you’ve already become a victim, you can use
a few techniques to proactively monitor for problems. These techniques are applied
at places where network traffic is concentrated: routers and softPBX servers.
Project 10.3. Logging and Controlling VoIP Packets
with iptables
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 secu-
rity-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.
PSTN-to-IP Attack?
Some sysadmins and VoIP skeptics are concerned that a perpetrator might try to gain
access to a private IP network through the PSTN. Even if it were possible for an
attacker to fatally exploit a bug in the VoIP infrastructure—say, a codec—her only
means of transmitting data into the compromised host would be through the analog or
TDM connection to the PSTN.
Once compromised, it is possible this connection wouldn’t be running any longer,
thus cutting off the attacker’s pathway into the network. The attacker’s available band-
width would be less than 64 kbps, and he would have no means of sending IP traffic,
because his pathway into the system wouldn’t even be TCP/IP-enabled. Even if he
could crash the host, he couldn’t transmit any data to it through the PSTN. So, aside
from a denial of service due to an exploited bug somewhere in the VoIP network, the
threat here is understandably low.
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
Intrusion Prevention and Monitoring
|
239
Logging packets using NetFilter doesn’t save the contents of the pack-
ets—just information from the packets’ headers! If you want to cap-
ture 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 fire-
wall (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 broad—it captures any and all SIP traffic going through the firewall (FOR-
WARD 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.
Assuming a VoIP WAN like the one in Figure 10-4, it’s possible to do some interest-
ing 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"
Figure 10-4. Packet logging on NetFilter firewalls can be configured to distinguish between traffic
based on its destination or origin
Internet
(VPN)
Cleveland
SoftPBX
10.1.1.16
Chicago
SoftPBX
10.3.1.16
Detroit
SoftPBX
10.2.1.16

Get Switching to VoIP now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.