You are on page 1of 38

VPNs in the distributed enterprise: security begins with the firewall.

(Network Management).

Communications News; 11/1/2002; Hulett, Stewart

Although larger companies may be able to address the need for security in a disributed
network by linking their various locations with leased lines, this approach is expensive
and not affordable for many midsize and smaller companies that still favor a distributed
enterprise business model. With the latter, these companies understand that they can
attract and retain productive employees, while minimizing real estate costs and taking
advantage of local resources.

The key to efficient and successful distributed computing is creating a virtual private
network (VPN) by maintaining always-on connections to the Internet--and protecting
these connections with a firewall to prevent unauthorized access to private corporate
resources over the public network.

Many companies clamp down, and do not allow communication over the public
network for any company-related matter. Dial-up is a secure option, but the 56-kbps
speed does not meet today's business needs. Often, companies will beef up security at
the corporate headquarters, but leave remote employees with few options. This
approach fragments the corporation and can have repercussions on the company's
performance. Working as a seamless, single organization is essential to rapidly respond
to market demands and stay competitive.

Take a company that has protected its corporate headquarters LAN, but has not yet
implemented the network, management and data security required for a secure VPN
between this LAN and a remote branch office or a telecommuter. Each time a remote
employee accesses the corporate LAN, the entire network is exposed to a security risk.
Why? To gain access to all corporate resources, all a hacker has to do is access the branch
office LAN, then use this position to step across to the headquarters LAN.

THE WEAKEST LINK

Distributed enterprises should also be aware that as the number of branch offices and
telecommuters increases, so does the risk of exposure to this type of security breach--
unless each and every point of access to the LAN is secured over a VPN that supports
dedicated private links between distributed sites. The security in a distributed
enterprise is only as strong as its weakest link, because, lacking a VPN, the weak link
can always be exploited to gain full access to the entire network.

This risk is not eliminated with network address translation (NAT) systems. With NAT,
ports are dynamically opened and closed to create links between remote sites; but the
ports, once opened, are not always closed as soon as the communication ends. During
this delay, a hacker can gain access and re-establish the link.

A secure VPN is also essential for fostering strong business-to-business and peer-to-peer
relationships. No potential trading partner would want to engage in Web-based
transactions unless absolutely sure that these transactions would not present an
opportunity for a hacker to gain access to its own network.

With this perspective, securing links in a distributed enterprise can be viewed as a


market imperative--and a marketing advantage. A company with a highly secure VPN
linking its entire distributed enterprise--with a high level of security protection at every
site--is surely far more attractive than one that relies on NAT, or no security at all, to
prevent unauthorized access.

Good security that relies on VPNs begins with a firewall, a device that is located
between the private LAN and the Internet. A firewall permits only the passage of
packets authorized on the basis of several parameters, including packet filtering, address
translation, access control lists, stateful inspection and content filtering. Firewalls must
be located at every node on the distributed enterprise and can be personal (i.e.,
dedicated to a single workstation) or shared among several workstations.

ADDITIONAL PROTECTION

Firewalls are available as stand-alone devices or as integrated elements in the router


platform that provides VPN functionality and full data security through support of
additional security components, such as encryption and authentication algorithms.
Encryption algorithms ensure that data is protected while traveling on the public
network by preventing unauthorized snooping. Authentication algorithms ensure that
only authorized users gain access to the network.

Routers that support industry-standard algorithms enable greater flexibility in


configuring the security infrastructure and VPNs in a distributed enterprise because
they can seamlessly interface with "big iron" corporate routers. This enables leveraging
of existing firewall investments when adding remote facilities. With support for
industry standards, routers at remote facilities can be linked to the corporate LAN
through secure tunnels.

Another important factor to consider when creating VPNs in a secure distributed


enterprise network is management. Because firewalls and routers are both manageable,
they can be configured and customized to suit diverse network environments. Once
configured, however, the security of the entire network is dependent on the security of
the management interface. If an attacker gained access to the management interface of
the firewall, the settings could be changed to suit the attacker's needs.

As a result, all management interfaces to firewalls and routers--including Web-based


management (HTTP), Telnet-based management, simple network management protocol
management, and RS-232 (local console)--must all be controlled using any, or all, of the
following:

* A user must know the password to "log in" to the management interface.

* Specific management interfaces can be closed down to minimize the number of


different potential points of attack.

* Management is accessible on a different IP address than that used to operate the


routers or firewalls.

* Management can be performed only from specific workstations on the LAN or WAN.

VPN management security can be further enhanced by centralizing control through a


single Web-based interface. With fewer points of management access, risks are reduced,
and so is the need to hire IT managers for each of these sites.

A solution to support the security requirements of a distributed enterprise should also


provide the high availability demanded of a business-critical infrastructure. This can be
achieved with a routing platform that supports dual paths; if one access method fails for
any reason, communications can be transparently handed off to another path. With a
communications platform that offers optimized network, data and management
security, a distributed enterprise can create a VPN-based infrastructure that provides
the best possible protection and privacy for all corporate resources.

For more information from Efficient Networks: www.rsleads.com/211cn-251

RELATED ARTICLE: 10 steps to VPN security.

1. Do not skimp on assessment. Take time to do a thorough analysis of security needs,


and write a security policy document--remember to consider internal, as well as external
threats--before deciding on products and solutions.

2. Do not forget client systems. Consider the mobile workforce as an extension of the
corporate network, and secure each device accordingly, including PDAs and hand-held
devices.

3. Centralize security management, which guarantees that up-to-date security is always


implemented.

4. Integrate the VPN and the firewall to warrant VPN traffic is subject to network access
control, in addition to several other important benefits.

5. Take a layered security approach. Security is more than a firewall. Evaluate


complementary security products, such as intrusion detection and virus scanning. Make
sure that complementary solutions can be integrated with existing security solutions.
6. If quality of service (QoS) plays a role in the network, choose a solution that allows
integration of QoS with VPN/security infrastructure. An integrated solution makes
certain that traffic can be inspected and prioritized.

7. Invest in training. Software is only as good as the people implementing and


managing it.

8. Upgrade security software on a regular basis. New security threats crop up


continuously.

9. Consider outsourcing security.

10. Put a system in place to measure results of security efforts. Audits and reporting
solutions can help.

5 VPN QoS tips to consider

1. Integrate VPN and QoS--an integrated solution ensures that traffic is both inspected
and prioritized, and is the only way to make sure that both the QoS device and the VPN
function optimally.

2. Undertake a thorough analysis of which types of network traffic are most important to
the business, then develop a QoS policy--with priorities, guarantees and limits--that
safeguards the best performance and reliable delivery for specific types of network
traffic.

3. Do not place a QoS device on the WAN side of the firewall/VPN--the QoS device
faces potential denial of service attacks and cannot prioritize encrypted traffic.

4. Do not place a QoS device on the LAN side of the firewall/VPN--the link can flood
inadvertently because encryption software frequently increases packet size.

5. Incorporate a QoS device that utilizes stateful inspection; because stateful inspection
looks at packets down to the application level, priority levels can be set based on file
types.

For more information from CheckPoint: www.rsleads.com/211cn-257

COPYRIGHT 2002 Nelson Publishing

Firewalls face next-gen challenges: most firewalls weren't


designed for voice or any other real-time traffic. Can
vendors turn this problem into an opportunity?
Business Communications Review; 4/1/2003; Krapf, Eric

Many enterprise managers now realize that their firewalls can potentially binder voice
over IP (VOIP) and other real-time traffic, but it hasn't become a major issue--yet. VOIP
adoption has been slow, and most VOW deployments to date generally don't bring the
firewall issue to the fore.

That's because a firewall only comes into play when traffic moves between an untrusted
network--i.e., the public Internet--and a trusted network--i.e., the corporate
LAN/campus. For the most part, VOIP implementations have either been restricted to
"islands" of LAN deployments or, at most, have connected these islands via dedicated,
private wide-area links.

But, eventually, many hope that the public Internet will be used for at least some VOW
connectivity. There's a long-term vision in which the Internet replaces the public
switched telephone network and carries a mix of voice, video and data. In such an
environment, firewalls will play a crucial role.

VOIP poses two main challenges for firewalls: The need to deal with Network Address
Translation (NAT), and the need to open lots of firewall ports to let VOIP through. The
leading manufacturers of traditional firewalls--Check Point, Cisco and NetScreen--claim
they've begun dealing with these issues, but a new group of companies, including Acme
Packet, Ingate, Jasomi, Kagoor, Netrake, NexTone and Ridgeway, is also taking on the
challenge, each with its own solution. In addition, another vendor, SecureLogix, is
attacking the VOW security problem by focusing its firewall solutions equally on the
legacy TDM network and the converging IP network.

The NAT Problem

The first firewall-related VOIP problem is simply getting the traffic where it's going.
Most enterprises use Network Address Translation (NAT) at the public-private
boundary, which enables them to consume fewer public IP addresses and to mask their
internal networks from the outside world's view. However, using private IP addresses
means outside parties that want to reach an endpoint within an enterprise don't know
where to address their VOIP H323 or Session Initiation Protocol (SIP) signaling
messages.

One of the most common solutions developed by the newer vendors is for the firewall
or a colo-cated auxiliary device to perform an adjunct function within the enterprise
demilitarized zone (DMZ). This adjunct function resides behind the firewall, physically
if it's a separate device, logically if the functionality is incorporated within the firewall.
The firewall or firewall/adjunct box has a public IP address, and Port 1720 (the port for
H.323 signaling) or 5060 (for SIP) is left open on the firewall, to allow call initiation
messages in. Every VOIP endpoint served by the adjunct registers its private IP address
with this device.
Figure 1 shows how inbound calls move across the boundary using this firewall/adjunct
configuration. In the figure, "Jason," an external user, needs to call "Tina," who's inside
the enterprise, but he doesn't know her IP address, since she only has a non-unique
private address. But Jason does know the public IP address for Tina's corporate firewall,
so he contacts this firewall (which in this example also contains the adjunct function).
Since Tina's phone has registered its private IP address with the firewall, the firewall
knows where to forward Jason's signaling packets to set up the call.

Seems simple enough, but the process becomes more complicated when someone
behind a firewall tries to make an outbound call (Figure 2). On an outgoing call, NAT
changes the source address from the endpoint's private IP to the firewall's public IP. But
it doesn't do anything to tell the called party how to send media back to the calling
party, explained Steve Davies, chief technical officer at Ridgeway.

For example, Davies explained, when an endpoint sends out a request to set up a
connection, the NATing within the firewall will change the endpoint's private IP
address to a public address in the packet header. A "NAT binding" is created between
the private address, say 10.1.1.20 Port 1273 and the public address, say 192.15.11.234 Port
768.

That takes care of the signaling traffic. But what about the media traffic--i.e., the actual
audio packets? They can't come back to Port 768 on the public side of the firewall,
because that port has been set aside for signaling. So which port do they go to?

Therein lies the problem. The originating endpoint can't instruct the far-end device to
send media to a particular public port on the firewall, because the endpoint doesn't
know anything about the firewall--it only knows about its own private address.

The firewall can't solve this dilemma, either. Even if the firewall could select one of its
own public ports on which to receive media from the far end, there'd still be a problem:
The firewall doesn't know where--i.e., what port on the endpoint--to relay the media
traffic. In the Figure 2 example, the endpoint requested that media be sent to Port 5276
on its private IP address--but the firewall doesn't know about this request, because the
information is carried inside the packet contents, and the firewall's NATing function
only looks at the packet header. Therefore, it is unable to create a "NAT binding" from a
port on the firewall to the ultimate destination Port 5276 (also called the "listen" port) on
the endpoint.

The most obvious solution would be to enable the firewall--or adjunct device to read
packet contents as well as headers. But that has proved easier said than done.

There have been various attempts to solve these problems through proposed IETF
standards such as MIDCOM (RFC 3303) and an Internet Draft for a protocol called
Simple Traversal of UDP Through Network Address Translators (STUN). The original
MIDCOM concept was for an intelligent box (a "middlebox") that would control the
firewall and create the necessary NAT bindings via a "firewall control protocol."
As Steve Davies explained, the "middlebox" would be "an intelligent box within a
network that would look at all the external calls going out or coming in and send a
command to the firewall that says: Create a NAT binding, such that I can use a proper
address, rather than a non-unique address."

The MIDCOM effort has yet to bear fruit, however, which has led companies such as
Ridgeway and Jasomi to develop proprietary ways of getting around the NAT problem.
Jasomi, for example, uses a "back-to-back user agent" in its PeerPoint products. "To each
end of the call, the back-to-back agent looks like the other end of the call. And because of
that, it has full access to all the fields and data that are passing back and forth between
both ends of the call, and it can manipulate the contents of those packets," Jasomi CEO
Dan Freedman explained. "We process those messages, do the translation of the packet
contents and send it on its way."

Ridgeway's IP Freedom system uses essentially the same technique, though with a
different architecture. It interposes a "traversal server" as the agent in the middle to do
the translation function--endpoints sit behind a "traversal client" at each site, and the
client tunnels endpoint signaling and traffic; the tunnel masks the private IP addresses
and "listen" information until they can get to the server for translation. All the voice
traffic, therefore, gets funneled through the "traversal server," which has a public IP
address and uses well-known ports (2776 and 2777) on the firewall, so it doesn't suffer
from a NAT problem. "Effectively, the traversal server breaks the call into two halves,"
Davies explained.

Opening Up To Voice

Assuming these NAT issues get solved in a widely accepted way, there remains a closely
related problem: Instead of firewall ports being left open or closed on a static basis, they
must be able to open or close dynamically. That's because VOIP media traffic can use
any one of thousands of ports; leaving all these ports open all the time would represent
an unacceptable security risk. So the firewall must be able to open a port as traffic
arrives on it, and then close it as soon as the conversation is done.

Moreover, these operations need to be carried out extremely quickly, so they don't
introduce delay and latency for the voice traffic, and securely, so that the firewall only
opens ports for legitimate traffic. As Jasomi's Dan Freedman points out, from the
firewall's perspective, an inbound H.323 or SIP call "appears to be a message arriving
out of the blue that really isn't related to you in any way, but needs to be sent to your
computer. And another word for that in firewall language is an attack.

"The box that makes the decision as to whether those packets should be allowed in or
not needs to understand phone calls, and to understand whether a call is in progress...
[and] whether it's in progress not only to you but from the guy that's sending all these
packets. It should also understand whether the rate of arriving packets is consistent with
what it understands about the call," Freedman continued. "For example, if a call is
supposed to have 50 incoming audio packets per second, and suddenly there are 500
coming in, something's wrong and it should not let those in. A complex, deep-packet
inspection function has to occur on these boxes, and it's an awful lot of work and an
awful lot of state for a firewall to be undertaking by itself."

Added to this processing load is the need to do the much more detailed packet
inspection and manipulation required to overcome the NAT problem described above.
This leads Freedman to an unsurprising conclusion: These functions should run on a
dedicated box. All the other new vendors in this space are, likewise, building boxes that
serve as an adjunct to a traditional firewall, although Ingate offers both an adjunct box,
called the SIParator, and a complete firewall that incorporates the adjunct's
functionality.

Freedman draws a parallel to anti-virus engines, which firewall vendors have opted not
to include in their products, instead relying on adjuncts. "Voice over IP's not quite the
same as antivirus, but it has some characteristics in common, not the least of which is the
fact that it's still a pretty fluid field in which the protocols and features, in the next two
or three years at least, are not going to settle down," he said.

Shai Mohaban, CTO of Kagoor, agrees that voice protocols are complex, and he insists
that adding voice capabilities to existing firewalls won't be easy. "With all the legacy
code in there and the need to keep everything else secure and going through all the
regression tests that they're doing today, I don't think they'll be able to support it any
time soon, until the protocols become really, really stable, which can take a decade or
even more," he said.

Naturally, the traditional firewall vendors couldn't disagree more. Both Check Point
and Cisco say their latest software releases support H.323 and SIP and can handle the
new challenges at least as well as the newer companies' products. And Mike Lee, senior
product marketing manager at Check Point, said that, far from offloading the new voice-
oriented functionalities onto another device, "This is an area where a firewall can
differentiate itself from another firewall."

Lee doesn't deny that there's an additional processing load to handle. For one thing, he
pointed out, voice packets tend to be minimum-size (64-byte), so for a given bandwidth,
the firewall will process many more packets with voice than data.

And he agreed with the upstart vendors about the difficulty the new protocols pose:
"The big challenge is, quite frankly, the R&D effort involved with understanding all the
details of the protocols, all the various implementations of the protocols, the quality
assurance (QA) and all underlying features that surround, for example, just the base
RFCs. We really have to devote a significant amount of R&D resources to staying up to
date with these products."

But ultimately, the traditional firewall vendors say their current offerings can handle the
job from a performance perspective. Michael Jones, product line manager for Cisco's PIX
firewall, said lab testing has shown "a very minimal impact on the traffic. It's nearly
imperceptible." Check Point's Mike Lee puts the performance hit for the additional
processing in the microseconds--not much in the context of a 100-150-millisecond delay
budget for an end-to-end voice connection.

In the case of a software firewall like Check Point, supporting voice might not even
require a CPU upgrade, Lee said. "If you bought a firewall in the past few years, I don't
expect voice to be the application that pushes you over the performance barrier," he said.
"A lot of other things we do are more process-intensive, [such as] encryption. Voice isn't
a big deal relative to some of those things."

One Box Or Two?

A variation on the two-box solution is being proposed by SecureLogix, which has sold
heavily into the military, and which focuses on protecting both converged IP and legacy
TDM voice networks. Its TeleVPN product encrypts circuit-switched traffic, while its
TeleWall firewall blocks hackers from accessing the TDM phone network and using it as
a "back door" into the data network via unauthorized modems that employees may have
deployed.

SecureLogix CTO Mark Collier insists that most enterprises will wind up deploying
multiple firewalls--either adding a next-gen box from a newer company, or simply
deploying an additional "data" firewall that is optimized to handle VOIP traffic. He
contends that enterprises will end up either with two boxes or with two discrete blades
in a single box (Figure 3).

Collier's reasoning doesn't relate only to technology issues; he believes that


organizational issues are also key. "Who's going to provide security in a converged
world?" he asked. "We think a voice manager is going to want to manage security in a
way that's familiar to them."

The SecureLogix vision is that the voice side of the house will deploy a firewall that
protects its network, and whose capabilities evolve as the voice network migrates from
TDM to hybrid to all-IP. Meanwhile, a data firewall will continue to protect data
applications.

Ingate CEO Olle Westerberg agreed that non-technical issues will play a critical role in
how his company's firewall adjunct, the SIParator, will be deployed. He envisions
enterprises wanting to hang the SIParator off the firewall in a "one-armed" fashion--i.e.,
traffic comes off the Internet, passes through the firewall, then is processed by the
SIParator and goes back through the firewall to its final destination: "This is probably
the most likely configuration scenario, as it creates the least concern for those
responsible for IT security. They can continue to trust their existing firewall product."
He also believes that as enterprises grow more comfortable with adjunct boxes, they'll be
more willing to create parallel paths across the public-private boundary.

But Cisco's director of marketing for VPN and security, Tom Russell, scoffs at the notion
of adding discrete boxes to handle new applications like voice. "Your overall operations
cost would go through the roof if you start to need a firewall for voice and a firewall for
storage and a firewall for legacy," he said. "Where does it stop?"

Conclusion

As noted at the outset of this article, to a certain extent, much of this discussion is
academic, at least for now. The traditional firewall vendors, while working on the
issues, clearly don't see many customers ready to implement solutions.

"I wouldn't call this a huge deal in the market today," said Check Point's Mike Lee. "It
comes up with some customers, and for those customers, it's a big deal. But I can't tell
you that we're going to sell a massive number of firewalls based on this feature."

Chris Roeckl, director of corporate marketing at NetScreen, echoes Lee's comments. "We
don't see a really huge demand for voice-over-IP technology in the enterprise, but that
said, we are working to address the voice-over-IP space and other multimedia
environments, and to ensure that the things we're developing are able to accommodate
the requirements."

Even the next-gen solutions are finding that VOIP isn't the only emphasis for their
technology. Steve Davies points out that most of Ridgeway's deployments have been for
customers implementing video over IP, while both SecureLogix and Kagoor note that
their systems offer new management features that some network administrators find
just as appealing as the security aspect.

"We're using the VoiceFlow device to see the status of the phone," explained Kagoor's
Shai Mohaban. "You can ping the phone, look at the current status and really debug the
thing without having to send someone on site. And that's the sort of application you'll
never get from a firewall, because it's way beyond simple security."

Companies Mentioned In This Article

Acme Packet (www.acmepacket.com)

Check Point (www.checkpoint.com)

Cisco (www.cisco.com)

Ingate (www.ingate.com)

Jasomi (www.jasomi.com)

Kagoor (www.kagoor.com)

Netrake (www.netrake.com)

NetScreen (www.netscreen.com)
NexTone (www.nextone.com)

Ridgeway (www.ridgewaysystems.com)

SecureLogix (www.securelogix.com)

Eric Krapf is BCR's managing editor.

COPYRIGHT 2003 BCR Enterprises, Inc.

This material is published under license from the publisher through the Gale Group,
Farmington Hills, Michigan. All inquiries regarding rights should be directed to the
Gale Group.

The Border Patrol: firewalls for VOIP; can your data-oriented firewall
handle packet voice traffic? What if it can't?(Security)

Business Communications Review; 10/1/2003; Audin, Gary

Firewalls provide security by blocking intrusions into an enterprise network. By


allowing certain traffic in while blocking other kinds, they represent the physical
implementation of an enterprise's security policies.

But firewalls also produce performance problems and cause delay. Most firewalls are
designed for data applications and are not application specific, though some firewall
vendors (such as Checkpoint, Jasomi, Datapower, F5 and Sarvega) are moving toward
packet content analysis (called deep packet inspection). This is a move to more
application-specific security, though even it does not yet cover voice over IP (VOIP)
packet analysis.

A recent Gartner Research Note, titled "Four Paths to True Network Security," describes
both present and next-gen devices this way: "The underlying 'secret sauce' is a generic
engine that performs packet assembly and compares the contents to a list of rules and
lots of memory to cache the packet stream." The note defines four approaches (Figure 1):

[FIGURE 1 OMITTED]

1. Intrusion detection vs. prevention (IDS/IPS).

2. Content switching (also called "application switch") products.

3. Application-specific firewalls.

4. Traditional firewalls.
IDS devices passively report probable security intrusions, but they have proved
frustrating to users; IDSs tend to produce many false positives, prompting users to
either turn off rules or ignore the reports.

IPSs, the next-gen evolution of IDS, are more active devices that sit on the boundary
between the internal and external networks and use an extensive set of rules to stop
attacks that pass through the firewall. The rules must be implemented at the very
beginning of the attack, and the subsequently received packets must be blocked. The IPS
requires considerable processing power if it is to relay real-time voice and video traffic
and avoid performance problems.

Content switching devices perform deep packet inspection to load-balance across


multiple servers. These products could evolve into security systems, but are not yet
designed to block traffic for security purposes.

Application-specific firewalls are targeted toward data and Web server environments,
not real-time voice or video traffic. Gartner believes that "software running on hardened
Unix platforms can handle application defense, but the demands on this technology
quickly will escalate to the point where specialized hardware acceleration is required."

Traditional firewalls are those that have been on the market for some time; they are
typically software-based. A few firewalls are hardware based, and these likely will
require hardware changes to support VOIP traffic. In general, traditional firewalls will
have a difficult time supporting the short delay, jitter and throughput that application-
specific firewalls will demand.

VOIP And Firewalls

VOIP traffic requires real-time delivery, short delay, low jitter and low packet loss across
networks. Data firewalls are not designed for real-time applications. Among other
issues, they have difficulty dealing with Network Address Translation (NAT) and VOIP
signaling (see BCR, April 2003, pp. 55-58).

Besides these challenges, other performance and control issues arise when voice passes
through a firewall. Next-generation firewalls will have to understand the concept of a
"call" in order to do voice traffic analysis.

These complexities point toward the central question: What is the best way for
enterprises to deploy firewall capabilities in converged voice/data networks?

Traditional Data Firewalls

Put up a firewall and it solves security problems. That's a nice image, but it's not reality.
The firewall is necessary for security, but so are other devices such as intrusion
detection and prevention systems (IDS/IPS).
Firewalls can provide a false sense of security. They do not protect the internal private
network from rogue authorized users (employees), who are more likely than outsiders
to be the source of security problems. Firewalls also introduce performance issues for
real-time traffic (Table 1). What's more, they can be cumbersome to install and use, they
add a bottleneck between the private and public networks, sometimes deny access when
they should allow it and can impair network performance.

The goal of firewalls, IDSs and IPSs is to detect and stop attacks, which come in many
forms, including:

* Denial of service.

* Virus/Worms.

* Unauthorized access (hackers and crackers).

* Unauthorized data transfer.

Another major factor when dealing with security systems is their management and
reporting capabilities. Next-generation security systems must detect attacks and
intrusions and report on these while they're occurring, rather than after the fact. The
system should then automatically block future traffic based on its knowledge of past
improper access.

Finally, the security system should constantly review temporary security policy changes,
such as opening a port for a one-time transfer, because a temporarily opened port
frequently winds up being left open permanently.

A firewall that possessed such powerful reporting and management functions could
evolve into a broader traffic-management tool. Since firewalls process all the traffic at
the enterprise network edge, they could provide valuable, detailed traffic statistics and
relate the traffic to the applications used, addresses in use, packet characteristics,
diagnostic and troubleshooting transmissions and patterns of traffic.

At the low end of the spectrum, a newer class of product is software or desktop firewalls
for teleworkers. These are more limited and, therefore, more vulnerable to attack than
enterprise-class firewalls.

Like their larger-scale cousins, desktop firewalls will be called upon to support real time
voice and video applications. Unfortunately, desktop firewalls may actually block VOIP
traffic. In one case, the installation of a common home firewall/router translated the
UDP port numbers assigned to voice traffic traversing the firewall. The call processing
was successful, but the speech path was closed. (The "Changing Policies" section below
explains just why this happens.)
The instructions included with the teleworker firewall product never mentioned the
port number translation. The lesson: Deploying teleworker firewalls could be a real
headache.

Protecting And Passing VOIP Traffic

As the previous example illustrates, VOIP creates a whole new set of firewall problems.
To understand these problems, we first have to understand how VOIP traffic crosses the
firewall perimeter.

A VOIP call uses either the TCP or UDP protocol with well-known application ports to
set up a call. TCP port 1720 is used as the primary port for H.323, and UDP port 5060 is
used for SIP (which rarely employs TCP--though the latest version of the standard
recommends that TCP be used with SIP in the future).

VOIP also requires one or two additional UDP ports to be opened for each individual
voice traffic stream. One port is used for the Real-Time Protocol (RTP) traffic that carries
the voice packets, and a second optional port may be assigned to monitor the
performance of the RTP call, using the Real-Time Control Protocol (RTCP). This means
that three UDP ports are required for a SIP-based call (for call control, monitoring, and
the voice payload itself). The early version of H.323 required two UDP ports for RTP and
two UDP ports for RTCP.

The UDP ports should be opened only for the duration of the call. Static UDP port
assignment--that is, keeping ports open permanently--essentially leaves the firewall
open and not really secure. And not only does the firewall have to open the UDP ports
dynamically, it must do it rapidly, for multiple calls simultaneously, with short delay
and without introducing jitter or packet loss. Cheaper and older firewall products lack
this dynamic UDP port assignment capability.

One possible VOIP-specific solution is to embed security functions in VOIP gateways, as


we saw in Avaya's July announcement of its Security Gateway product line (see BCR,
September 2003, p. 62). The Avaya gateway integrates VOIP firewall protection, virtual
private network (VPN) functionality and IP-telephony support. It also includes a
bandwidth manager to provide QOS for the voice traffic.

"The mobility and dynamic nature of [VOIP] technology introduces not only new
security issues related to VOIP support, but just as importantly, significant configuration
and management concerns that can become significant obstacles to deployment," said
Jorge Blanco, VP, products and solutions marketing at Avaya. "The logical step is to
integrate security within the communications infrastructure and applications such that it
becomes part of an overall trusted communications framework.

"In this model, security is ... an integral feature that becomes part of a simplified
communications deployment process, whether in the enterprise, within a branch office
location, or distributed to a DSL-connected home telecommuter using an IP phone,"
Blanco said.
Changing Policies

As noted earlier, the firewall implementation represents the physical manifestation of


the company's security policies. These policies will need to be revised as data firewalls
are modified to accommodate VOIP traffic.

For a start, many firewall installers use the product's default settings, but these aren't
adequate for handling VOIP, since the characteristics of packet voice traffic do not
resemble those of data traffic. The following conditions must be considered when
making policy changes in the data firewall to accommodate voice:

* VOIP packets are small (64-100 bytes), with near-constant length.

* The packet rate is about 25 to 200 packets per second, most commonly 50 packets per
second. Firewalls should recognize different types of realtime media to determine if the
packet rate is reasonable for a given application type. High packet rates could be a sign
of a denial-of-service attack.

* If silence suppression is used, the packet streams will alternate: One direction will
carry packetized voice while the other direction will carry no packets at all. Without
silence suppression, the packet streams will be constant in both directions.

* The average length of a telephone call is three to five minutes, so the UDP ports will
have to open and close at that rate. Voice mail calls average about 30 to 45 seconds.
These are normal call patterns that must be provided for in the firewall rules as
implemented by the enterprise.

* During a conference call, the packet flow will be predominantly one direction. If the
conference call is supporting a Webcast or on-line lecture or presentation, the packet
flow will be exclusively in one direction, behaving like software distribution without
any acknowledgments which is unusual in legacy applications.

* You'll have to allocate a set number of UDP ports up-front for VOIP, and this will
restrict the number of simultaneous calls that can be set up through the firewall. For
example, if 512 UDP ports are set aside for VOIP, then at most only 256 calls can be
carried, since each call requires a minimum of two UDP ports. Thus, the firewall can
become a call-blocking point in the network.

* The TCP (for H.323) and UDP (for SIP) signaling ports may be left open 24/7,
otherwise they will have to be opened for each call. If left open, the signaling ports also
will be idle for long periods when no calls are made, such as on nights and weekends. A
firewall may normally be configured to shut down these ports if they remain idle for a
specified time, to increase security. But that practice has a major drawback with VOIP,
because employees who work or access voice mail on the weekends won't be able to get
through if the signaling ports are closed.
* Endpoints may not be aware of port number translation occurring at the firewall,
which will cause the speech (RTP) path through UDP to fail even though the signaling
operation succeeded. This has happened with some home firewalls, as described above.
The fix is for the firewall to edit the text of the signaling packets and modify the
RTP/UDP port numbers so that they translate properly, ensuring that the telephones
connect to the translated UDP ports. This type of function is not commonly supported
by data firewalls.

* If the firewall can support quality of service (QOS), then both the signaling and voice
packets must be given a high QOS level, with the voice packets provided the highest
level.

Some of the above items concern identifying abnormal packet patterns. If your firewall
can be configured to detect abnormal packet patterns. then these modifications will
probably be required. If your firewall cannot detect these abnormalities, you should
look for one that does before you implement VOIP through a firewall.

Real-Time Firewalls

To deal with these issues, a few vendors have created a new class of product, the real-
time firewall (RTF), specifically designed to handle both data and real-time applications
like voice and video over IP (Table 2). The significant difference between data and real-
time firewalls is their performance for voice traffic.

Deep packet inspection looks into the content of a TCP or UDP packet for a thorough,
all-encompassing view, including such crucial information as the IP address of the
destination device. This inspection is performed by disassembling and reassembling the
IP packets (called data grams), as well as the TCP and UDP streams as they pass through
the firewall. All of this extra processing requires significantly more computing power
than most smaller and software-driven firewalls possess.

The key areas that must be addressed by all solutions, regardless of vendor, include:

* Compatibility issues with NAT.

* Control of dynamic voice sessions.

* Call admission control.

* Invalid signaling and voice stream challenges.

* Network latency and jitter.

* Visibility and control over legacy voice and resulting cross-network connections.

"A solution to the signaling and the UDP port-assignment problem is to provide a
signaling filter resident in the RTF firewall," recommends Mark Collier, CTO of
SecureLogix. "This filter would terminate and regenerate all signaling requests. The filter
can then monitor for valid call requests and dynamically open and close the appropriate
ports. It can ensure that the UDP ports are open by the time the call has been
established. It can also interact with other components in the network to provide
authentication and encryption of signaling requests.

"The signaling filter can work with the NAT to rewrite the addresses in the signaling
stream and provide NAT pathways for the voice stream," he added. "If these translations
are incorrect, the voice stream will be blocked by the firewall."

A second, more complex approach is called a back-to-back user agent (B2BUA), which
supports encryption as well as the other features of a signaling filter. A combination of
both approaches provides the most comprehensive approach to security, according to
Collier.

VOIP Performance And Firewalls

Five factors impair the performance of VOIP calls that pass through any network or
device: delay, jitter(delay variance), errors, packet loss and packet out-of-sequence
delivery. These factors may also affect call setup/teardown time for signaling.

Delay through a firewall is caused by the packet store-and-forward processing and


analysis of each packet. VOIP packets are very short (tens of bytes), therefore the store-
and-forward delay is short. Packet analysis delay, which is in addition to the store and
forward delay, may be caused by factors including:

* Too much time spent in policy enforcement.

* Slow firewall processing speed.

* Packet headers/trailers that require excessive analysis.

* Limited bandwidth at the existing network port.

The first two problems are affected by the firewall product design, while the second two
can be problems for any firewall, regardless of design. Inadequate bandwidth causes
congestion; heavy congestion adds delay, jitter and packet loss.

Jitter, or delay variance, will fluctuate depending on the number of packets ahead of the
VOIP packets in the output queue. This may become an issue because data-only
firewalls can have a large output queue and still satisfy user expectations--a few
hundred more milliseconds' delay does not affect the operation of most data streams. In
contrast, even 100 milliseconds of jitter is intolerable for VOIP.

Another factor that causes jitter is packet length. Data packets come in all sizes, but the
largest ones--such as FTP and e-mail--can be 10 to 40 times longer than a VOIP packet.
Longer packets cause longer queue delays, and variable size data packets cause jitter.
Mixing VOIP and data packets through a common firewall penalizes the voice packets
but not the data packets. The jitter introduced by a dedicated VOIP firewall would be
far less than the mixed VOIP/data firewall, since the jitter would only be a factor of
congestion, not packet size variations.

Packet loss occurs when the existing network bandwidth is less than required for the
incoming packet load. This is a congestion problem. Packet size also affects packet loss.
When congestion is heavy, long packets take longer to deliver, thereby relieving the
congestion problem more slowly and making packet loss more likely. Data firewalls
often add buffering causes delay, again affecting voice quality.

Short VOIP packets can be delivered faster because of their small size. Congestion is
then relieved faster, producing less opportunity for packet loss. Again, mixing VOIP and
data packets in a common firewall penalizes the VOIP packets, not the data packets.

It is very unlikely that a firewall will introduce errors. Errors are usually the result of a
transmission problem. A firewall will discard faulty VOIP and data packets equally. The
firewall sees no difference between the two.

Out-of-sequence packet delivery occurs when there are multiple router paths to a
destination. As congestion over the first route increases beyond the limits set in the
router, an alternate path with less congestion is chosen. Packets entering later may
actually be delivered sooner, causing the out-of-sequence delivery problem. Firewalls do
not cause this out-of-sequence delivery, nor can they fix the problem. They must be
tolerant of this condition when they check sequence numbers for validity.

Finally, data firewalls were not designed for dynamic port assignment, because before
VOIP, only static port assignments were required. Newer data-oriented firewalls can
perform dynamic port assignment.

The way that the firewall handles dynamic port assignment will affect voice quality on a
VOIP call. Configuring UDP ports dynamically takes time. Because signaling is done
over statically configured ports, the call may be established between the end points (the
telephones) and speech may start before the dynamically configured UDP ports are
operational. This means packets are lost at the beginning of a call. This lost packet
problem is worsened when the firewall has to set up many UDP port assignments
simultaneously, as in a large office or call center, or during an emergency.

Conclusion

Where is all of this leading? For many enterprises, the solution may be a separate
application-specific real-time firewall (RTF) running in parallel to the existing data
firewall, a hardware-rather than software-based device. In this way, the VOIP traffic
passes through a firewall specifically designed for its needs, while blocking data traffic.
At the same time, the data firewall blocks VOIP signaling and traffic without penalizing
the VOIP traffic. You get the best of both worlds.
TABLE 1 Firewall Performance Issues

Data-Only Real Time


Firewall Firewall

Delay More Less


Jitter More Less
Rapid Dynamic UDP Port Assignment Rare Fast
Packet Rate Moderate High
Data Throughput High Moderate
Simultaneous Dynamic Port Assignment Slow Fast
NAT Fast Very Fast
Simultaneous Dynamic UDP Port Assignment Rare Fast
Signaling Delay Longer Shorter
Application Aware No Yes
Packet Inspection for Attack HTTP and TCP SIP and RTP

TABLE 2 Firewall Security Features/Functions

Data Real Time

Denial of Service [Square root] [Square root]


Intrusion Detection [Square root] [Square root]
Intrusion Prevention Usually [Square root]
Virus Scanning [Square root] [Square root]
VPN [Square root] Some
Dynamic Port Assignment Usually [Square root]
IP Security [Square root] [Square root]
Encryption [Square root] [Square root]
Malicious Behavior Blockage Some [Square root]
Network Address/Port Translation [Square root] [Square root]
Application Awareness Few [Square root]

RELATED ARTICLE: Companies Mentioned In This Article

Avaya (www.avaya.com)

Checkpoint (www.checkpoint.com)

Datapower (www.datapower.com)

F5 Networks (www.f5networks.com)

Jasomi (www.jasomi.com)

Sarvega (www.sarvega.com)

SecureLogix (www.securelogix.com)

Gary Audin is president of Delphi, Inc., an independent consulting and training firm. He
can be reached at delphiinc@worldnet.att.net.
COPYRIGHT 2003 MediaLive International/BCR Events, Inc.

This material is published under license from the publisher through the Gale Group,
Farmington Hills, Michigan. All inquiries regarding rights should be directed to the
Gale Group.

Enemy at the gates: the evolution of network security; Lights, camera,


action! Firewalls, appliances and routers take center stage in the never-
ending battle for network security.(SECURITY)

Business Communications Review; 12/1/2004; Wilson, Jeff

In the beginning there were good guys and bad guys. The bad guys, the Hackers, hid
out in a secret fortress called "the cloud," launching attacks on the good guys. Defending
the good guys were the IT Security Elites, clever as the Hackers, but using their powers
for good to code their own firewalls with complex software toolkits. The good guys
almost always won, thanks to the amazing and cryptic counter-cyber-terror skills of the
Elites. Despite battle after battle, the world was kept mostly safe for network traffic.

Does this sound like the premise for a good action movie? If it does, you may need to
step outside, turn off your beeper, and get some fresh air. Protecting the average
corporate network from attacks used to be nearly as complicated (and expensive) as
producing a blockbuster Hollywood film, but those days are over.

By the mid 1990s, complex toolkits had been supplanted by firewall software packages
and intrusion detection systems (IDSs). As performance and usability requirements
increased, software capabilities moved to hardware, and by 2000, the number of
companies buying and deploying perimeter security skyrocketed. Features were
integrated, costs came down, technologies improved, and today you can buy a top-of-
the-line, stateful-inspection firewall at the local home electronics store along with, yes,
the latest action movie on DVD--and the firewall doesn't cost much more than the
movie.

So we've stopped worrying about security, right? Everything is secure now, right? I'm
sure you see where I'm going with this ...

Trouble With The Script

Any decent action movie has plot twists. Twists build tension and increase our
attachment to the main characters. In the story of network security, three big twists
continue to drive the need for new technologies and products.

First twist: the bad guys aren't all outside. There's someone on the inside, someone that
you trust, and he's stealing information and feeding it to the bad guys. This has always
been the case: Year after year the CSI/FBI Computer Crime survey shows that
organizations experience about the same number of external attacks as internal attacks
(see Figure 12 at http://i.cmpnet.com/gocsi/db_area/pdfs/fbi/FBI2004.pdf). And yet,
the makers of early network security products largely ignored threats from the inside,
because there were no easy, product-based solutions. Instead, they targeted the
boundary between the corporate LAN and the Internet, because they could build
products to do that, and because this was the most obvious point at which to defend
against attacks from the outside.

Second twist: the bad guys are smart ... much smarter than most action movie bad guys.
And they are too proud to rest on their laurels, so when one attack stops working, they
develop another, and another, and another. The flood of new attacks and attack types
seems endless, and it has at least one easily identifiable trend: Attack profiles are
moving up the OSI stack. In fact, successful attacks rarely target the network level any
more, because most organizations have found ways--with firewalls, intrusion detection
devices and secure routers--to protect themselves from network attacks. Now hackers
target specific applications, and embed malicious content into otherwise benign traffic
(Web, email, database, instant messaging, peer to peer, etc.).

Final twist: the perimeter is gone. Dealing with the fact that there are no borders and the
enemy is among us may be the biggest challenge yet.

Businesses rely on networks to generate revenue, increase productivity and reduce cost.
Employees rely on access to networks to get their jobs done. Customers, partners and
suppliers rely on networks to keep business moving and keep an edge over the
competition. As this dependency increases, so does the need to extend network access to
more users, customers, partners and suppliers. Companies deploy VPNs. Web-based
applications, wireless LANs, guest access from within their own networks, hand-held
devices and extranets--all to increase the flow of information, increase efficiency and
increase revenue. The unfortunate side effect--that security decreases exponentially with
every additional network entry point--makes protecting these vital networks a very
tough job.

Tools For The 21st Century Hero

Today's IT security elites have an arsenal of network security tools that would make
James Bond green with envy. The arsenal can be broken into two primary categories:
Standalone security and network-integrated security, and those categories can be further
sub-divided. Network-integrated security products are routers and switches with
integrated security capabilities (firewalls, intrusion detection, etc.). Standalone security
products are purpose-built for security and have no (or limited) networking functions.

In our recent study, User Plans for Security Products and Services, North America 2004,
for which we surveyed 240 organizations about their plans for purchasing and
deploying network security, we found that security professionals typically deploy a mix
of standalone and network-integrated products. As shown in Figure 1, the percentages
of respondents planning to deploy security appliances and secure routers were roughly
even. Secure switches are lagging behind, but making up some ground by 2006; switch
growth is stronger because it's starting from a smaller installed base, and secure switch
products are just becoming available.

In the same study, we also asked respondents what types of products they would use to
secure the boundary between the Internet and the corporate LAN. As shown in Figure 2,
when you combine the percentages for multifunction and single-function security
appliances, you can see that appliances are ahead of routers.

Standalone Security Products

Security products were born out of specialized toolkits that evolved into standalone
products as users figured out which features and configurations worked best, and as
entrepreneurs discovered good money could be made productizing network security.
The "firewall" market is currently a multibillion dollar industry, but firewalls
themselves keep changing, incorporating many new network security technologies.
Other standalone products also have appeared over the last 10 years; all are competing
for the money enterprises spend to secure their networks.

Traditional firewalls like the venerable Cisco Pix and Check Point Firewall-1 were
designed to filter, analyze and secure traffic at the network layer, and they do a good job
of that. IDS products, such as ISS RealSecure and Enterasys Dragon, were developed to
help customers identify attacks and develop ways to stop them. IDS and firewalls are
complementary; IDS products can identify attacks and feed the appropriate information
to a firewall so it can generate or alter a rule, thus stopping that attack in the future.

The dynamic duo of firewall and IDS were the security staple for many large and
security-conscious organizations, but they proved to be too expensive and cumbersome
for the small and medium organizations that were dragged into the world of network
security by their use of cheap high-speed Internet connectivity. In fact, widespread
Internet connectivity was the primary driver for the creation of affordable integrated
security appliances, including products from vendors like NetScreen, SonicWALL and
Watchguard. These and other vendors typically combined VPN and firewall
functionality (but not IDS capabilities) into the same product, making an appealing
combination for small and medium organizations, and enabling many of them to deploy
security for the first time.

Meanwhile, as the hackers discovered that many of their victims had some network
security in place, they started developing attacks that targeted specific business
applications. These new attacks drove the need for products that could provide
application-level security, such as Web security gateways, gateway anti-virus (AV)
products and intrusion prevention products. The development of all these new
technologies and products, starting in 2000, has put the buyers back in the position they
were in before the first generation of integrated appliances: The technology to secure
their network exists, but it is again too expensive and too difficult to deploy for the
average organization. As a result, we're now seeing a second generation of integrated
appliances that combines traditional stateful-inspection firewall and VPN technology
with intrusion prevention, gateway AV, and application security. Many names are being
thrown around for these integrated appliances, including "deep inspection firewalls"
and "integrated security gateways."

There are many vendors in this space, including NetScreen (which is now owned by
Juniper Networks), Check Point, Symantec and Fortinet, and no two products look
exactly alike, but the goal is the same: A next-generation security appliance that can
identify and stop attacks from the network layer all the way up to the application layer.
A lofty goal indeed, but the mainstream market requires this level of integration in
order to protect against today's attacks.

Progress On Internal Security

While developing the technologies listed above, many security product companies also
have adapted existing products or developed new ones to deal with the internal security
threat. Interest in protecting against internal threats has been up and down over the
years, but there has been quite a bit of discussion of late, driven in large part by
increased deployment of wireless LANs and corporation-to-corporation extranets; both
add new requirements for internal security.

Providing strong security inside the network requires a lot of processing and a lot of
flexibility. It's one thing to secure all the traffic coming in and out of a T1 connection; it's
entirely another to monitor and secure all the traffic flowing across a Gigabit LAN.

The appliance vendors mentioned above, as well as others, have developed products
with multigigabit capacity using custom-designed ASICs and network processors. There
are also security products with many LAN ports and the ability to assign different
security policies per port (or even to segment the traffic flowing through a single port
into virtual security domains). These advancements did not require new security
technology, just intelligent and efficient application of existing technology.

As more companies began deploying large wireless LANs in 2003, vendors popped out
of the woodwork selling WLAN-specific security gateways that combined
authentication, firewalls and VPN/encryption for data security. Examples include
Vernier and Bluesocket. Many of these vendors regard wireless LANs as an entry point;
they built products to satisfy the immediate need in that market and plan to branch out
into the broader enterprise security market.

The security appliance market is a large one. In 2004, over $2.4 billion dollars will be
spent worldwide on VPN/firewall appliances alone, and with all these new
developments, more growth is on the way. But standalone security products aren't the
only means of protection standing between private networks and the evil hackers. Enter
network-integrated security products.

Network-integrated Security Products


While many people have been watching the security appliance market with great
interest, they tend to overlook the extent to which security is actually deployed through
routers and switches. Just as distributed Internet connectivity and the need for
companies of all sizes to secure their networks drove the integration of multiple security
technologies into single products, these same factors also drove network product
manufacturers to integrate security into routers and switches.

[FIGURE 3 OMITTED]

The secure-router market has quietly grown into a giant; nearly $1 billion worth of
routers with integrated firewall and/or IPSec VPN (as well as a host of other security
functions) will sell in 2004. Most of the future growth in the enterprise router market
will come from products that support security. Juniper paid nearly $4 billion for
NetScreen, in large part to enable them to develop secure routers and compete head-to-
head with Cisco for this fast-growing opportunity.

Cisco is the primary secure router vendor, but it has run a parallel security strategy since
the late 1990s: Offer both standalone and network-integrated products, and let the
customer choose what fits best where. Beginning with the integration of packet filtering
firewalls and IPSec into Cisco IOS, the company is reaching full speed with the
announcement of its new line of security-enhanced branch and remote-office routers and
with the success of its security blades for Catalyst switches.

Why do companies deploy network-integrated security? The reasons vary: Large


companies invest in "defense in depth," meaning the more places they deploy security
technology, the more likely they are to stop attacks and minimize the costs associated
with security problems. Small and medium companies with limited IT staff look to
network-integrated products to reduce both capital and operational expenses.

The Cast

Network security has more players than almost any other area of networking, and each
has a unique background and take on the market. Cisco has spent the last five years
positioning itself for the lead, acquiring companies, building products in house and
integrating security technology across its product line. Check Point and Symantec are
incredibly strong security-focused vendors selling a mix of technologies and product
types. Juniper, through its acquisition of NetScreen, is a leading player in the appliance
market and will look to challenge Cisco for a serious chunk of network-integrated
security product revenue. Both SonicWall and Watchguard have traditionally focused
on small and medium businesses. Commodity vendors like NetGear, Linksys (now
owned by Cisco), and D-Link are selling firewall appliances and secure routers at chain
stores for less than $100.

Figure 3 shows recent revenue market share for the top players in network security,
including VPN/firewall hardware and software, intrusion detection and prevention and
secure routers. Cisco's lead in these segments is strong, but not yet dominant. There are
serious challengers, and network security represents only a portion of the total security
products market.

Many startups and established companies, character actors if you will, also are attacking
specific aspects of this market, taking on application security, internal security, intrusion
prevention and other emerging areas. Some will see success, some will fall by the
wayside, but the majority will be involved in small to medium mergers and acquisitions,
and will likely see their technology integrated into multifunction products. Security
products of all types, including appliances, secure routers and secure switches will
prosper.

Roll Credits

Ultimately it is the buyers who make or break technology markets. Security buyers have
shown a willingness to invest large sums of money in security technologies that greatly
improve their security posture. In the end, the plot is really quite simple from the
buyer's perspective: Let the good traffic in, keep the bad traffic out. The products that do
that job most effectively will bubble to the top, and for better or worse, will probably
always be called firewalls, even if they bear very little resemblance to the firewalls of
yesterday or today.

So is network security really interesting enough to make into a Hollywood blockbuster?


Not really, but with billions of dollars of end-user money on the line every year, and a
never-ending supply of hackers looking to make life difficult for organizations around
the globe, there might be enough drama for a TV mini-series, or maybe a soap opera.
"As the Worm Turns" has a nice ring

FIGURE 1 Planned Security Purchases

Percent of Responses
2004 2006

Hardware Appliance 64% 68%


Router 66% 68%
Switch 33% 44%

Note: Table made from bar graph.

FIGURE 2 Security Choices At The Internet Boundary

Security Products 2006 2004

Router with integrated security 74% 70%


Security software 65% 62%
Multifunction security appliance 53% 48%
LAN switch with integrated security 51% 47%
Single-function security appliance 39% 39%

Percent Of Respondents With A Secure Internet Connection Boundary

Note: Table made from bar graph.


Companies Mentioned In This Article

Bluesocket (www.bluesocket.com

Check Point Software Technologies (www.checkpoint.com)

Cisco Systems (www.cisco.com)

D-Link (www.dlink.com)

Enterasys Networks (www.enterasys.com)

Fortinet (www.fortinet.com)

Internet Security Systems (www.iss.net)

Linksys (now Cisco) (www.linksys.com)

NetGear (www.netgear.com)

Netscreen (now Juniper) (www.juniper.net)

SonicWall (www.sonicwall.com)

Symantec (www.symantec.com)

Vernier Software and Technology (www.vernier.com)

Watchguard (www.watchguard.com)

Jeff Wilson is principal analyst, VPNs and security with Infonetics Research
(www.infonetics.com), specializing in firewalls, IDS/IPS, VPNs, integrated security
appliances, and application security. He can be reached at jeff@infonetics.com.

COPYRIGHT 2004 MediaLive International/BCR Events, Inc.


The future of the firewall: security functions are finding new homes in
appliances, switches and routers.

Business Communications Review; 5/1/2005; Wilson, Jeff

"What is a firewall?" My mom asked me that question the other day, demonstrating the
fact that Internet security is no longer the domain of reclusive super-nerds. Honestly,
that can be a tough question to answer when the person asking still doesn't know how to
make "folders" and put "files" in them.

I told Mom that firewalls keep the bad guys from getting on to your network, server or
personal computer; the answer satisfied her. It's a simple and accurate answer, and it's
not going to change. What will change is how firewalls, and other devices, will perform
firewall functions.

[FIGURE 1 OMITTED]

A Brief History Of Firewalls

The term firewall has other uses besides referring to Internet security; homes and cars
have fire containment barriers, also called firewalls. In the late 1980s, routers used
packet filtering to separate network segments so problems in one segment didn't affect
other segments. In the early 1990s, members of the then-small Internet community
noticed increasingly frequent attacks, acknowledged that their private community
wasn't really private any more, and a multi-billion-dollar market was born.

In the early-mid 1990s, companies like DEC, TIS, ANS and Raptor built specialized (and
complicated) firewall products and offered development toolkits to help companies
protect their Internet-connected networks. In 1994, Check Point launched Firewall-1, the
first packaged firewall product that attempted to be user-friendly. From the beginning,
many firewalls have used packet filtering (static, dynamic or stateful), circuit gateway
information, and/or application-layer information/proxies to perform the important job
of keeping bad guys out. Even as far back as the early 1990s, some firewalls have used
more than one technology to accomplish this goal (the DEC SEAL used packet filtering
and application proxies).

So that's what firewalls have been, so far--but what will they be? If my mom were to ask
me this question, I'd have another simple answer: In the future, firewalls will continue to
protect systems and networks from bad guys, but they'll come in a package that fits any
situation, and they'll do an even better job securing things.

More Form Factors, Plus Higher Performance

Every network-connected system on earth faces threats that could be mitigated with a
firewall, but many still are not protected by firewalls. Why is this? The simple answer is
cost, and cost's constant companion, ease-of-use. Firewalls come in a variety of form
factors--software that installs on the host, software for network servers, standalone
hardware appliances, network-integrated firewalls (built into modems, routers and
switches)--available at a range of prices, but we aren't yet to the point where everyone
can afford to buy one and anyone can figure out how to use one.

[FIGURE 2 OMITTED]

Home users can get built-in firewalls with their $69 broadband routers and wireless
access points, and sometimes they even turn these on, but the products typically lack
many features of enterprise-class firewalls. Advanced features like virus scanning, spam
filtering and intrusion protection are gradually being commoditized and will likely
trickle down in the next year or two to home users.

Many small and medium organizations are in a situation similar to the home users, in
that the products they can afford or are willing to spend money on aren't necessarily
capable of protecting them from today's sophisticated attacks. Enterprise-class firewalls
start at about $300, and that price will come down, but many small and medium
organizations don't know how to find the right products, nor do they know how to
install and manage them. For these customers, the coming generations of routers may be
the easiest way to get good protection, as they will have built-in enterprise-class
security technology.

Large organizations with knowledgeable IT staff have a growing range of good choices,
including security appliances and firewall blades for LAN switches. Over the next two
years, vendors of networking equipment who do not already offer built-in or optional
firewalls will include them. Throughput capacities (performance) will also improve, as
network and appliance vendors respond to the many large organizations that are
anticipating increased firewall deployments on internal wireless LANs and between
their wireless and wired LANs. As Figure 1 shows, customers are moving from
appliances that secure 100-Mbps LAN links to those with 1-Gbps capacity, and beyond.

Service providers, too, are looking to increase their firewall deployments, typically for
network-based products in four different applications: managed CPE services, network-
based services, data-center use and protecting their own internal networks. Providers
have strong requirements for remote management, virtualization (the ability to create
virtual domains within a given hardware device, enabling one device to serve many
customers) and most importantly, performance.

In our study, "Service Provider Plans for VPNs and Security: North America, Europe
and Asia Pacific 2005," we asked service providers the same question we asked
enterprises about performance requirements for firewalls. Most providers currently look
for network-based products in the 1-Gbps to 5-Gbps range, but they expect to shift to 2-
Gbps to > 5-Gbps in 2006 (Figure 2).

[FIGURE 3 OMITTED]
Firewall Functions Will Improve, Too

Security devices, like the attacks they must thwart, improve over time. Unlike basic
network transmission speeds, which are constrained by physics of the media, firewall
functions are only limited by the hackers' imaginations. New attacks lead to new
firewall features, which lead to new attacks in an endless cycle of development. In the
mid-to-late 1990s--the first boom in the firewall market--most firewalls focused on the
network and stopping network attacks, and that worked well for a time. In 2005 and
beyond, firewalls have to do much more.

Most firewalls already have integrated virtual private network (VPN) functionality, and
most firewall vendors are now integrating gateway virus scanning, intrusion
detection/prevention, and Web/application security. There are standalone products
that individually offer each of these functions, but mainstream network managers
probably won't buy, deploy and manage four or more devices at every boundary, which
is what's currently required to provide adequate security. The market needs one device,
and that device will be called a firewall.

Don't let the semantics confuse you. If you define a firewall only in terms of packet
filtering (even stateful packet inspection), you may think that many of today's
enterprise-class firewalls aren't really firewalls. I think it's more appropriate to default
to that simple definition that I gave my mom--the firewall is a bad-guy stopper--and I
think most customers care more about stopping the bad guys than about the specific
technologies integrated into the firewall so that it can do a better job. So let's keep it
simple and just keep calling them firewalls.

In 2004, enterprise customers told us that, when considering future firewalls, they are
thinking of devices with a whole host of features beyond packet filtering and stateful
inspection, as shown in Figure 3. Anticipating this demand, firewall and LAN
switch/router vendors are retooling their products; specifically, these companies are
adding more security functions (like intrusion prevention), building partnerships with
antivirus (AV) vendors to integrate gateway AV, and looking at Web/application
security technology. In truth though, as things stand today, most enterprise customers
are still chugging along, satisfied with their current-generation products that mostly use
stateful inspection and packet filtering.

Wireless LAN Drivers

A major firewall hardware trend is being driven by wireless LAN adoption, because
early WLAN security was bad or non-existent. Consequently, customers began moving
VPN and firewall products that were designed for the network edge inward to the
WLAN, or to where the WLAN joins the wired infrastructure.

Vendors responded by developing high-performance, multiport VPN and firewall


appliances, and, although these products began shipping in 2002, their real impact on
VPN/firewall appliance revenue was not seen until 2004. That was the year in which
many organizations began to realize they would need to build security into their LANs
by adopting new switches and routers; by changing the way their networks are
segmented; and by developing security policies for the internal network. This growing
focus on internal security is driving some vendors to build firewall appliances with
many Ethernet ports, and others to integrate security into their switch products.

[FIGURE 4 OMITTED]

Widespread deployment of wireless LANs and the consequent spike in interest in


wireless LAN security is not only driving firewall purchases--it's also pushing
development of wireless-specific features for firewalls. Many enterprises will deploy
firewalls to protect WLAN segments, and will use VPN clients to encrypt WLAN
sessions and authenticate WLAN users.

Initially, this looked like a short-term solution to the problem, as the wireless
community was at work developing standard approaches to wireless security (e.g., 802.1
li), but most companies continue to invest in VPNs and firewalls. Some firewall vendors
have gone as far as building firewall appliances with integrated wireless access points,
and more will join that trend.

Conclusion

We've discussed throughput, or performance, as a general requirement for high-end


enterprise and service provider customers. If customers and service providers are
already considering multi-Gigabit performance, it's not unreasonable to expect there to
be applications for 10-Gbps and up in the next several years. This won't be as hard to
meet for basic packet filtering and stateful inspection as it will for intrusion prevention,
or for any content inspection that requires packet payload inspections. Advances in
ASICs, network processors, software and system architecture will all be required to
push tomorrow's firewalls up to and beyond the 10-Gbps performance mark.

So is the future of firewalls simple or complicated? I guess it depends on where you're


sitting. For the people building them, it's complicated to integrate scores of disparate
functions and technologies into one platform that runs at 5 Gbps and up, and that
always stops all the bad traffic and always lets the good traffic in--oh, and that costs less
than $100. Throw in the fact that hackers never go on vacation: As soon as you have a
problem licked there is a new one ready to take its place. That's certainly a challenging
position for any product manufacturer.

Firewall customers, however, will demand that the future be simple: No more worms,
no more viruses, no more hacks, no more trojans, no more denial-of-service attacks and
no more security headaches. End users, based on our research, have one primary
concern when it comes to security: they don't want to be attacked from the outside
(Figure 4).

And that's what a firewall does--keeps the flames off your network and off your
devices, right? The firewall of the future may not look much like the firewall of today,
and the historical bread and butter of firewalls--that is, packet filtering--won't even
scratch the surface of what the firewall of the future will do. Eventually we may find it
more appropriate to call it an intrusion prevention system or integrated threat protection
system. But it seems more likely that we'll still call it a firewall

FIGURE 1 Customer Performance Requirements For Firewall Appliances

Performance Requirement Percent Of Integrated Security


Appliance Respondents

2006 2004

5G and up 10% 6%
2G 6% 3%
1G 29% 24%
100M 23% 33%
50M 4% 6%
10M 7% 10%
5M 4% 6%

Source: Infonetics Research study: User plans for Security Products and
Services, North America 2004

Note: Table made from bar graph.

FIGURE 2 Service Provider Performance Requirements For Network-based


Products

Aggregate Performance Percent Of Service Provider


Requirement Respondents

2006 2005

> 5G 32% 0%
5G 37% 26%
2G 26% 47%
1G 5% 21%
100M 0% 5%
50M 0% 0%
10M 0% 0%
5M 0% 0%

Source: Infonetics Research study: Service Provider Plans for VPNs and
Security: North America, Europe and Asia Pacific 2005

Note: Table made from bar graph.

FIGURE 3 Desired Features For Next-Gen Firewalls

Features Percent Of Integrated Security


Appliance Respondents
2006 2004

Firewall 94% 87%

Virus scanning 84% 73%

VPN 84% 73%

Spam filtering 74% 58%

Intrusion detection 73% 59%

Content filtering 72% 61%

Intrusion prevention 68% 49%

Application security 62% 49%

Denial of Service 62% 52%


prevention

Vulnerability 61% 48%


assessment

Source: Infonetics Research study: User plans for Security products and
services, North America 2004

Note: Table made from bar graph.

FIGURE 4 Security Deployment Drivers

Factors Percentage of Respondents Rating


Each Factor a 6 or 7

Attacks from the outside 79%

Increase in sensitive 50%


traffic

Business/regulatory 48%
requirement

Attacks from the inside 46%

Addition of Internet 41%


connections

Increase in mobile 32%


workers/telecommuters/
day extenders

Demand from customers or 30%


business partners

Addition of an extranet 27%


Addition of VOIP 23%

Source: Infonetics Research study: User Plans for Security and


Services,
North American 2004

Note: Table made from bar graph.

Jeff Wilson is principal analyst, VPNs and security with Infonetics Research
(www.infonetics.com), specializing in firewalls, IDS/IPS, VPNs, integrated security
appliances and application security. He can be reached at jeff@infonetics.com.

COPYRIGHT 2005 MediaLive International/BCR Events, Inc.

The key to network security: intrusion-prevention systems augment the


defenses provided by firewalls and antivirus software.(Special Focus:
Network Security)

Communications News; 9/1/2005; Heslop, Mark

Today, enterprises should seriously consider integrating intrusion-prevention systems


(IPS) as a critical element in existing security infastructure to thwart both internal and
external network attacks. One of the most misunderstood threats is the one coming from
inside the firewall--the credentialed user. The problem is compounded by mobile users
with laptops that unwittingly obtain and release threats contracted from other networks
they previously interacted with that are less secure than their own enterprise network.

In addition, there are an increasing number of unauthorized services, users and


applications living on networks today. These include instant messaging, peer-to-peer
applications, rogue e-mail, FTP and Web servers. Most companies have policies in place
that prohibit these kinds of services; however, a lack of visibility increases the difficulty
in policing this traffic, so many rogue services live on, and networks remain vulnerable.

For example, popular file- and music-sharing applications may open up ports and allow
unauthorized back door access, increasing vulnerability. End-users have no idea they
are downloading malicious code hidden inside the music, video or other file type.

Worms such as Sobig and Bagle propagate this way and can cause mass mailings to a
user's personal contact list, or others can install applications like IRC bots that run at
predesignated times and execute specific instructions to cause harm. For example,
Internet relay chat bots can issue timed-distributed denial-of-service attacks (DDoS) on
well-known Internet sites.
Today's networked businesses are no longer simple architectures requiring just a
firewall and antivirus to protect the perimeter. Extension of the business network
through virtual private networks (VPNs) and Web-enabled applications has blurred the
distinction between internal and external users.

Most businesses are now highly interconnected, and advances in networking and
communication technologies, combined with Web-enabled applications, have reduced
the financial barriers or the traditional "cost of connectivity." Inexpensive access has
created highly efficient communications with both partners and employees, bringing
together the right people with essential data and applications at the optimal time.

The benefits of these connections are obvious; however, they come with little control
over the security at these "semi-trusted" networks. Traffic of these external networks
should be rigorously monitored.

An offshore contractor, for example, directly linked into your software development
group, may not be as vigilant regarding security and may deliver some infected traffic
into the network. Having an IPS system in place would analyze and mitigate that traffic
before it could inflict any significant havoc.

Various emerging threats should cause concern for any network administrator, and
could be combated in part or fully by an effective IPS installation. These include:

* Phishing (including pharming and spear phishing). These information traps require
some human intervention; however, the reliance on spam to propagate gives the IPS a
chance to contribute to their detection and disarming.

* Mobile malicious code. PDAs and smartphones are increasingly becoming targets for
viruses and worms. Most of these devices are unprotected and must be monitored as
their use for external network access increases.

* Blended threats. Worms with multiple infection and entry methods that require a
combination of strong policies, updated signature files and visibility to stop their
lightening-quick movement.

* Industrial system security. Power and gas companies, traditionally siloed networks,
are becoming internet-worked and increasingly customer facing, which opens up these
vital services to external threats.

Today's IPS products support multiple detection methods (signature, protocol anomaly
and behavioral anomaly), as well as addressing a range of performance needs. These
systems are effective in protecting against a wide range of threats from both inside and
outside the network. The real challenge that an IPS faces is in its ability to:

* monitor and manage an ever-increasing volume of network security data;


* handle a large volume of threats from multiple IPS devices across large enterprise
networks; and

* validate attacks with aggregation and correlation of information from devices like
intrusion-detection systems (IDS), firewalls and vulnerability-assessment devices,
including accurate analysis and actionable reporting.

A high-performance, low-cost complementary threat-management solution--tightly


integrated with the IPS solution and able to manage a wide range of events in real-time
across the enterprise--is what is needed. Additionally, these systems should be able to
analyze packet flow reports, anomaly warnings and other security information from IPS
devices, and rapidly correlate viruses/worms, hackers, spyware and off-policy user
behavior.

IPS solutions should scale to manage the volume of security threats occurring across the
network. Functionality that aggregates and correlates large amounts of data in real time
across hundreds of distributed IPS units is essential. Future IPS requirements will
include the ability to collect and analyze threats and data from other devices, such as
firewalls, IDS and vulnerability-assessment tools. Improved reporting functionality,
including real-time flow monitoring that captures and analyzes every packet flowing
through the network, will also become increasingly critical over time.

For more information from NitroSecurity: www.rsleads.com/509cn-265

Mark Heslop is director of product marketing for NitroSecurity in Portsmouth. N.H.

COPYRIGHT 2005 Nelson Publishing

This material is published under license from the publisher through the Gale Group,
Farmington Hills, Michigan. All inquiries regarding rights should be directed to the
Gale Group.

Bring on the security gateway: internal security is often overlooked when


firewalls and IPS are already in place.(Special Focus: Network Security)

Communications News; 9/1/2005; Hardof, Tamir

Just a few years ago, deployment of an antivirus solution and a next-generation


perimeter firewall would have been enough o let your IT security staff sleep at night--
but those days are long gone. Antivirus solutions are point products that block known
viruses and are not designed to even recognize application-layer worms.
Firewalls will continue to be critical for network security, but they do not address
threats that bypass the perimeter any more than a 10-foot wall would stop a fly from
traversing over or a mole from burrowing under it. Firewalls are critical and the first line
of a layered security defense, but what do you do when the threats are already inside
your perimeter defenses? Today's threat environment is about threats that emerge from
inside the network, either through penetration of the perimeter or, more commonly, by
introduction from a source that directly accesses the inside of the network. How many
laptop users in your organization connect from home or external locations such as
airports, cafes and other public hotspots that are beyond your company's perimeter line
of defense? These mobile laptops can become infected and spread malicious data inside
the LAN--their remote-access connections represent an authorized tunnel right into the
network.

How many contractors, visitors, partners or temporary workers connect their laptops to
your internal networks? Do you know what is on those laptops? In any of these
scenarios, these laptops have become potential carriers of malicious code and direct
attacks that plug right into your internal network.

The first development to address this area was intrusion-detection systems (IDS), an
array of servers and sensors deployed across a network to watch for and report on
network traffic. An IDS is designed to be strictly passive, however, and, at best, alerts IT
managers about potential threats based on signatures--but it is incapable of actually
responding. Furthermore, IDS solutions generate a large number of alerts and are
inherently prone to an unacceptably high rate of false positives.

EVOLUTIONARY SECURITY PATH

The natural evolutionary path of the IDS was to improve accuracy by reducing false
positives and to develop a way to respond to alert information in a timely manner. Thus,
the intrusion-prevention system (IPS) was born, which incorporated the traffic-
monitoring functionality of its predecessor, while adding application-layer inspection
and proactive attack protection that was lacking in legacy firewalls.

An IPS still primarily relies on signatures and faces a challenge dealing with false
positives. In the effort to cut down on false alerts, an IPS can also suffer from false
negatives, failing to identify and block unknown attacks.

Standalone IPS products are constricted to a limited deployment posture, primarily at


the network perimeter, so they often miss the activity generated inside the network.
They attempt to prevent attacks aimed at compromising the internal network, but they
try to do this from the perimeter. Unless the internal traffic is being inspected with an
intelligent mechanism designed to address the unique aspects of securing the LAN, the
internal network is still not secure.

An enterprise-wide view of the network is critical to ensure exceptional security


protection. Achieving this bird's-eye view requires a layered approach that integrates
both perimeter and internal security devices that share not only central management,
but also central logging, reporting and event correlation-for a more comprehensive
ability to monitor and respond to attacks.

In order to inspect and control all traffic on the LAN, a solution that sits inside the
network--not at the perimeter--is required. An internal security gateway offers not only
a direct view for inspection and monitoring, but it also offers multiple advanced
methods for reacting in real time to malicious or suspicious activity. This can be
achieved through traffic behavior analysis--the internal security gateway has the ability
to "learn" what is considered normal and abnormal traffic and can check data against
regularly updated signatures.

Simply keeping up with emerging threats and vulnerabilities is not enough. Internal
security gateways offer not only updated signatures and new defense mechanisms in a
timely manner but also provide advisories, with detailed descriptions of vulnerabilities
and threats, to stay ahead of the curve.

Network zone segmentation and quarantine capabilities are additional features that
enhance internal security solutions. Zone segmentation allows IT managers to assign
different security levels to different areas of the network to provide added protection to
high-value network segments. Quarantining is used to confine attacks and sequester
compromised devices.

Combining security and management components with forensics is also necessary in


order to monitor the logging and reporting generated by gateway devices, as well as
translating security events into actionable information. Automated aggregation and
correlation of data substantially minimizes the time an IT team spends analyzing data,
and also isolates and prioritizes real security threats. This further allows for the
identification of additional and previously undetectable activity, and reduces business
risk by responding in real time.

While point IPS products offer limited security capabilities, many of their features are an
important part of a complete security solution. Elements of intrusion prevention-
application--layer security and attack-blocking, for example--are best deployed at
multiple layers in the network and not as a standalone point product. A firewall that
offers these features is critical to protecting the network from hackers and malware that
attempt to penetrate the perimeter. The distinction to note is that these features are
equally important inside the network and on all hosts.

The best technology in the world still needs to be fiscally beneficial, delivering a clearly
recognizable value. Whether purchasing decision makers and IT teams are motivated by
preventing business disruption, protecting productivity or meeting regulatory
compliance, internal security is too vital and should not be addressed by anything less
than an intelligent, multitiered security architecture that is scalable and specifically
designed to protect the internal network.

For more information from Check Point Software: www.rsleads.com/509cn-250


Tamir Hardof is product manager for Check Point Software Technologies, Redwood
City, Calif.

COPYRIGHT 2005 Nelson Publishing

This material is published under license from the publisher through the Gale Group,
Farmington Hills, Michigan. All inquiries regarding rights should be directed to the
Gale Group.

You might also like