Jay Beale, ... Brian Caswell, in Snort Intrusion Detection 2.0, 2003 A third class of preprocessor performs attack detection that cannot be performed using regular rules or protocol anomaly detection. The preprocessors that we examine here show how Snort
can be extended easily to detect attacks in about any way a developer can imagine. Although it hasn't been done yet, one might even give Snort the capability to do statistical measurement and learning of normal network traffic, alerting on deviations from normal behavior. This is simply a wild example of how preprocessors allow a developer to add nearly any IDS functionality conceivable to Snort, giving it the capability to straddle all boundaries between types of NIDS. Before you get too
excited, let's look at the two preprocessors that have been declared Enterprise-ready code at the time of this book's publication, portscan and bo (Back Orifice). As an additional note, this class of preprocessors is more concerned with alerting than with rewriting packets. As a result, this section will not include a discussion of how each of these preprocessors place a packet back into the detection engine—this
doesn't apply to them. Some attacks just can't be detected by rule-matching or protocol anomaly detection. For example, how does one reliably detect a portscan from a single packet or connection? A portscan generally involves several probes, generally to more than one port or more than one machine. If it does not, it's extremely difficult to distinguish from an ordinary valid connection attempt. A single
incoming port-80-destined packet to your non-Web server workstation could be the Internet equivalent of a “wrong number.” A user could have entered a name or IP address incorrectly, or your organization's DNS entries might have an error. On the other hand, 200 port-80-destined packets addressed to each of your IP addresses, arriving in numerical order by IP address, are almost certainly a curious party's portscan. What distinguishes one from the other is a subtle combination of at least the
following factors: Number of destination hosts Number of destination ports Time over which the packets were sent There's no real way to take all these factors into account with straight rule-matching, even with stream reassembly. Remember, the multiple packets
that we're looking for would each be seen as belonging to their own separate connection. Snort's portscan preprocessor, in spp_portscan.c, detects portscans by watching for a specific number of probe packets sent within a certain time period of each other. These probe packets can be directed entirely at one host or spread across a network of machines—all that matters is that the number of packets crosses a preset threshold in a preset period of time. Once this happens, the portscan preprocessor
alerts. This preprocessor also sounds an alert whenever it receives one of the well-known “stealth scan” packets, such as those sent by nmap. These include the odd/illegal packets shown in Table 6.1. Table 6.1. Snort-Detected Stealth Packets
Preprocessors
Preprocessor Options for Nonrule or Anomaly-Based Detection
portscan
NULL
All TCP flags are deactivated.
FIN
Only the FIN flag is on.
SYN-FIN
Only the SYN and FIN flags are on.
XMAS
Only the FIN, URG, and PSH flags are on.
You should never encounter one of these packets on your network if it corresponds perfectly to the TCP specifications. For example, NULL packets should never happen—these correspond to a total lack of state information in a stateful protocol!
One warning is in order: the portscan preprocessor's code itself warns that, “… the connection information reported at the end of scan is wildly inaccurate.” In essence, the preprocessor is fairly good at telling you that someone is scanning your network, but it's not very good at counting exactly how many probes the scanning party sent. The basic reason for this failure is that the portscan preprocessor is not building and consulting a database of all traffic sent by a scanning system. It's just not designed to maintain this much historical information. It maintains some simple counts of how many connections each host has tried to open and how many connections each host has received. It removes information on hosts often, as the user-configured expiration time is reached without a given host having initiated the threshold number of connections.
This is easier to understand with an example. Say that we're watching for five probes within 15 minutes. If a host scans four ports on our network in five seconds, then waits an hour, and then scans six ports, we won't get an alert until the second set of scans is almost complete. That's expected and normal. However, the alert won't tell us about the initial four ports that were scanned, because the preprocessor will already have forgotten about those four probes when it gets the new probes. This is part of why tuning a portscan detector is so difficult. On the one hand, you're eager to make sure that an attacker can't bypass detection by sending his probe packets very slowly. On the other hand, you can't alert on every SYN packet that enters your network unexpectedly!
Anyway, this lack of accurate reporting doesn't make the preprocessor useless. It's still decent at detecting scans—it's just not going to give you hyper-accurate data on how many probes a particular attacker sent you.
You can activate the portscan preprocessor by adding the following line to your Snort configuration file:
preprocessor portscan:
<monitor network> <number of ports> <detection period> <file path>
You must replace <monitor network> with the target network you'd like the preprocessor to watch for scans against, listed in CIDR notation. The <number of ports> and <detection period> parameters denote a number of ports scanned within a period in seconds, specifying a time-limited threshold. Finally, the <file path> parameter denotes the fully qualified pathname of the file to which you'd like portscans logged. For example, to alert whenever 5 ports are scanned within a 60-second period on the 10.0.0.0/8 network, you'd add this line:
preprocessor portscan: 10.0.0.0/8 5 60 /var/log/portscan.log
The portscan preprocessor also comes with a function that allows you to specify source hosts that should be ignored. You can use this by specifying a space-delimited list of IP addresses, in CIDR notation, on a preprocessor portscan-ignorehosts line:
preprocessor portscan-ignorehosts: 192.168.1.1/32 192.168.2.0/24
Back Orifice
The Cult of the Dead Cow wrote Back Orifice in 1998 as a remote control mechanism, often used by attackers to maintain control of their compromised systems. The remote control mechanism does not use a reserved port, and it does use encryption, making it less than trivial to detect on a network. Luckily, it uses an overly simple encryption scheme to both hide and authenticate access to the target system. In this scheme, the attacker picks a password, which is then hashed into a 16-bit number. Sixteen bits is a relatively small keyspace, presenting only 65,536 possibilities. All traffic is encrypted by XOR'ing it with this hash. All requests made from the client to the server begin with the magic string “*!*QWTY?” before encryption—this “known plaintext” vulnerability makes it easy to brute-force the password. In essence, we can try XOR'ing “*!*QWTY?” with every hash value until we find one that matches one of the packets we see on the wire. Since the encryption scheme is so simple, one can easily write a program to brute-force the encryption, giving a security analyst a clear picture of what the attacker orders the machine to do.
Snort's bo (Back Orifice) preprocessor, in spp_bo.c, detects Back Orifice by examining every UDP packet of size at least 18 bytes and checking its first eight characters of payload against a precomputed table of enciphered versions of the magic string. (Actually, to save resources, it checks only the first two characters and the last two characters of this string.) The Back Orifice preprocessor computes this table when Snort first starts up, during the preprocessor's initialization phase. We'll examine the preprocessor initialization phase in the last section of this chapter, when we examine the telnet_negotiation preprocessor in-depth.
The Back Orifice preprocessor takes no arguments—it cannot be configured at all. In the current release of Snort, version 2.0, the configuration file passes the - nobrute parameter to the preprocessor, like so:
preprocessor bo: -nobrute
This has absolutely no effect—nobrute has been deprecated. Originally, the preprocessor worked differently—it performed the brute-force attack on every packet, instead of implementing a lookup table. This was obviously much slower.
General Nonrule-Based Detection
As you can see, one major purpose for Snort preprocessors is to detect attacks that can't be easily caught via straight rule-matching. These represent a strong method of adding more intelligence to Snort without sacrificing the speed of straight pattern-matching. Nicely, a Snort box deployed to simply capture traffic will not have to run packets through these preprocessors, as the analyzer box(es) can perform that function well. Again, the Snort developers have worked very hard to maintain performance.
You should note that most of the preprocessors offered alerting modes that could be deactivated. These alerting modes form the basis for Snort's protocol-anomaly detection and might catch sneakier attackers. On the other hand, they might prove too noisy on some networks, depending on what operating systems are deployed. For example, stream4 tends to alert on protocol problems too often on networks with particular versions of Windows. If you have time to observe and tune your preprocessors, it's wise to leave these alerting options active initially, backing off on noisy ones. If you don't have the time or resources to tune, you can just configure each preprocessor for its primary functionality. Actually, as of Snort 1.9.1, most of the default settings assume that you prefer the latter strategy.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781931836746500117
Preprocessors
In Snort Intrusion Detection and Prevention Toolkit, 2007
Summary
Preprocessors add significant power to Snort. Snort's existing preprocessors give it the capability to reassemble packets, do protocol-specific decoding and normalization, do significant protocol anomaly detection, and add functionality outside of rule checking and anomaly detection.
The stream4 and frag3 preprocessors enhance Snort's original rule-based pattern-matching model by allowing it to match patterns across several packets with TCP stream reassembly, TCP state keeping, and IP defragmentation based upon target. Data carried by TCP is generally contained in several packets—stream reassembly can build a single packet out of an entire stream so that data broken across several packets can still match attack rules. As packets are carried across networks, they often must be broken into fragments. frag3 rebuilds these fragments into packets that can then be run through Snort's detection engine, emulating the end host operating system and distance the whole time.
The HTTP decode and RPC decode preprocessors serve the primary purpose of data normalization. The HTTP decode preprocessor deals with the problem created by Web servers that accept many forms of the same URL by creating a “canonical” form of the URL to which rule-maintainers can write their URLs. This preprocessor does not do data replacement either—the canonicalization can be accessed by using the uricontent keyword in an HTTP rule. RPC, when carried over TCP, must still be separated into discrete messages. The protocol makes this separation by defining a formal message as being composed of one or more message fragments. The fragment mechanism creates ambiguity in rule creation, because fragment headers can occur anywhere within the application data. The RPC decode preprocessor normalizes the RPC protocol by converting all multiple-fragment RPC messages into single-fragment messages. It makes these adjustments inline, and thus destructively, in the original decoded packed data.
The dynamic preprocessors, although new in Snort 2.6.0, allow much more functionality. The DNS, FTP_Telnet, and SMTP preprocessors each enable new boundary checking and vulnerability analysis from a preprocessor perspective. Without having to recompile the entire Snort engine, the new preprocessors are much more user friendly and Plug and Play.
The first two types of preprocessors enhance Snort's rule checking and add substantial protocol anomaly detection. They allow Snort to perform rule checking across packets and within nontrivial protocols. Finally, by using greater understanding and memory of the protocols involved, they perform protocol anomaly detection to catch attacks that don't necessarily match an existing signature.
The third type of preprocessor we discussed allows Snort to move beyond the rules-based and protocol anomaly detection models for a particular purpose. portscan counts probe packets from each given source and attempts to detect portscans. Back Orifice watches UDP packets for stored encrypted values of a plain text string known to be the header for a popular hacker remote control tool. Each of these functions cannot be easily accomplished with Snort's existing rules or protocol-anomaly detection engines.
You can build your own dynamic preprocessors fairly readily, starting with the Snort manual as a guide. An encouragement is also made to start your research into shared object rules as well.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597490993500112
Implementing Security and Access Controls
Eric D. Knapp, Joel Thomas Langill, in Industrial Network Security (Second Edition), 2015
Protocol Anomaly Detection
Another type of anomaly detection looks specifically at the protocol: malformed messages, sequencing errors, and similar variations from a protocol’s “known good” behavior. Protocol anomaly detection can be very powerful against unknown or zero-day exploits, which might attempt to manipulate protocol behavior for malicious purposes. However, be very careful when deploying protocol anomaly detection, as many legitimate products from legitimate ICS vendors utilize protocols that have been implemented “out of spec”—either using proprietary protocol extensions or altering the protocol’s implementation in a product to overcome some limitation in the “pure” standard. Knowing this, protocol anomaly detection of industrial protocols can be subject to high rates of false positives, unless some effort has been made to “tune” the detection parameters to the nuances of a particular vendor or product.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9780124201149000101
Dissecting the Juniper Firewall
Brad Woodberg, ... Ralph Bonnell, in Configuring Juniper Networks NetScreen & SSG Firewalls, 2007
Intrusion Detection and Prevention
Juniper Networks’ IDP product is a network appliance designed to provide intrusion detection and prevention for today's enterprise networks. It can be deployed in several different configurations to accommodate needed functionality. First, it can be deployed as a nonintrusive network traffic sniffer to detect incoming attacks, and to record, and alert on them. In this mode, you can easily install them to provide a network baseline, or to quickly replace your other IDS devices. Second, you can install the device in gateway mode. In this mode, you can use the IDP as an active defense mechanism. In this mode, it provides several ways to stop network attacks. It can close or drop the connection on both the client and server sides. It can also capture the session for subsequent analysis. This product is great for doing forensic research on the attack.
The IDP platform provides a trademarked multi-method detection (MMD), which combines several detection mechanisms. Various applications require distinctively different methods of detecting attacks. The applied detection methods ensure that critical attacks are detected, providing you the information you need to identify network threats in your environment. The IDP currently provides nine different mechanisms to detect attacks.
▪Stateful signatures Detect known attack patterns. This mechanism allows you to detect a greater number of attacks, and reduce the incidence of false positive alerts. A false positive is an alert that falsely detects an attack. A false positive can waste valuable time and resources.
▪Protocol anomaly detection Reviews the different types of connections that go through the IDP and acknowledges any connections that deviate from the proper protocol standards. This can be used to detect new attacks and expose vulnerabilities.
▪Backdoor detection Looks through interactive traffic for possible malicious communications. A backdoor is an application that resides on a host system unknown to the end user. These malicious applications, when installed on a user's system, can allow attackers to access your network's resources. When using the backdoor detection mechanism on your IDP, you can identify these intrusive connections and then block these connections to eliminate this harmful traffic.
▪Traffic anomaly detection Allows you to look further than a single packet or a single session. It allows you to look across multiple sessions and identify anomalous traffic. An example of this type of traffic is a reconnaissance attack such as a port scan. A port scan is a series of sessions or connections that individually may not raise a red flag. However, when you add many of these probing packets together, this constitutes a traffic anomaly, which can be detected with this mode of operation.
▪Network honeypot Mimics a system's services pretending to be a vulnerable system. This entices an attacker to access these services first, drawing attention away from your critical systems.
▪Layer-2 detection Monitors network traffic on the second layer of the Open Systems Interconnect (OSI) model. This allows you to detect address resolution protocol (ARP) attacks on your network.
▪DoS detection Allows you to detect certain types of Denial of Service (DoS) attacks. Denial of Service attacks can bring your network to its knees and early detection is critical to mitigate these attacks.
▪Spoofing detection Provides the capability to detect spoofed IP packets. A spoofed IP packet is a packet that seems to be coming from a host, but really is coming from a malicious attacker.
▪Compound signatures Combine multiple detection methods for complex attack detection. Juniper Networks combines stateful signatures and protocol anomaly to create a powerful detection mechanism.
Managing the IDP is simplified with its integrated management system, or by using Juniper's NSM (IDP software version 4.0 and later). Logging of attacks is detailed, providing extensive information in order to determine what is happening on your network.
The policy editor component, Policy Editor, is a graphical interface that allows for granular control over what type of traffic you want to detect and defend. Your configuration and signature information is readily available to use from within the policy editor. This allows you to easily create effective policies, thereby providing detection of, and prevention from, network attacks. The IDP product is an excellent product to use in your network to provide a new layer of security for your organization.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597491181500046
Stalking the Competition: How ISA 2004 Stacks Up
Dr.Thomas W. Shinder, Debra Littlejohn Shinder, in Dr. Tom Shinder's Configuring ISA Server 2004, 2005
Comparing ISA 2004 to Symantec Enterprise Firewall
Symantec is well known for the popular Norton anti-virus software and its comprehensive virus database available on the Web. The company posted a 31 percent increase in revenues for fiscal third quarter ending 01/02/2004. Enterprise security, administration, and services represented 51 percent of total revenues (Source: //www.symantec.com/press/2004/n040121.html).
Symantec markets low-cost basic firewall/VPN appliances for SOHO, small businesses and remote locations, as well as enterprise-level gateway security appliances that provide application layer filtering, centralized management, and high availability. Symantec also offers a software firewall product that runs on the Windows and Solaris operating systems.
In this section, we will provide an overview of Symantec Enterprise firewall software and appliances. We will look at Symantec's general specifications, platform support and system requirements, application layer filtering capabilities, VPN support and Web caching abilities, and examine how ISA Server 2004 stacks up against them.
Symantec: General Specifications
Symantec's firewall/VPN products that are available at the time of this writing can be broken into three major categories, as shown in Table 3.6.
Table 3.6. Symantec Firewall/VPN Product Categories
| Symantec Firewall/ VPN 100 | SGS 5420 | Symantec Enterprise Firewall |
| Symantec Firewall/ VPN 200 | SGS 5440 | |
| Symantec Firewall/ VPN 200R | SGS 5460 |
Table 3.7 shows key features of Symantec's small/remote office firewall/VPN appliances at the time of this writing:
Table 3.7. Symantec Small/Remote Office Firewall/VPN Model-by-Model Comparison
| Stateful inspection firewall functionality | Yes | Yes | Yes |
| Intrusion detection | Yes | Yes | Yes |
| Remote access VPN | No | No | Yes |
| Gateway-to-Gateway VPN | Yes | Yes | Yes |
| VPN client included | No | No | Yes |
| IPSec/VPN pass-through | Yes | Yes | Yes |
| DSL/cable interface | Yes | Yes | Yes |
| T-1/ISDN interface | Yes | Yes | Yes |
| PPPoE support | Yes | Yes | Yes |
| 10/100 LAN ports | 4 | 8 | 8 |
| WAN ports | 1 | 2 | 2 |
| Load balancing | No | Yes | Yes |
| Number of users (recommended) | 15-25 | 30-40 | 30-40 |
| Failover | Analog dialup with external modem | Analog dialup with external modem | Analog dialup with external modem |
| Configuration | Web interface | Web interface | Web interface |
| Processor | ARM7 | ARM7 | ARM7 |
| WAN throughput (bi-directional) | 8Mbps | 8Mbps | 8Mbp |
| Web caching | No | No | No |
| Application layer content filtering | No | No | No |
| Built-in DHCP server | Yes | Yes | Yes |
| NAT | Yes | Yes | Yes |
Symantec's current enterprise gateway security appliances, at the time of this writing, comprise the 5400 series (SGS 5430, SGS 5440 and SGS 5460).Table 3.8 compares features of the three enterprise gateway security appliances.
Table 3.8. Symantec Enterprise Gateway Appliance Model-by-Model Comparison
| Stateful inspection firewall functionality | Yes | Yes | Yes |
| WAN Ports | 6 | 6 | 8 |
| 10/100 ports | 6 | 0 | 0 |
| Gigabit ports | 0 | 6 | 8 |
| Maximum nodes (recommended) | 500 | 2500 | 4500 |
| Concurrent connections | 64,000 | 190,000 | 200,000 |
| Stateful throughput | 200Mbps | 1.4Gbps | 1.8Gbps |
| Full inspection | 95Mbps | 680Mbps | 730Mbps |
| VPN w/3DES | 90Mbps | 400Mbps | 600Mbps |
| Memory | 512MB | 1GB | 2GB |
| Hard disk | 40GB | 80GB | 80GB |
| Signature-based intrusion detection | Yes | Yes | Yes |
| IPSec compliant VPN | Yes | Yes | Yes |
| Application layer inspection | Yes | Yes | Yes |
| HTTP content filtering | Yes | Yes | Yes |
| Web caching | No | No | No |
| Anti-spam protection | Yes | Yes | Yes |
Symantec markets two software packages that are designed to run on Windows NT/2000 or Solaris; these are the Symantec Enterprise Firewall and Symantec Enterprise VPN. The current version is 7.0 at the time of this writing. The Symantec Enterprise Firewall is ICSA certified.
This software is also the basis for the enterprise security gateway appliances. Symantec Enterprise Firewall 7.0 includes:
▪Hybrid architecture firewall
▪Deep packet inspection
▪Application proxy
▪Automated system hardening
▪Wide range of user authentication methods (RADIUS, LDAP, digital certificates, S/Key, Defender, SecureID, Windows domain authentication)
▪Integrated Web content filtering
▪Integrated load balancing
▪EAL-4 certification
▪AES support
▪NAT: both inbound and outbound for VPN and non-VPN traffic
▪WebNOT URL filtering
Symantec Enterprise VPN includes:
▪Support for IPSec VPNs; interoperates with other IPSec-compliant VPN clients and servers
▪Operates independently of firewall and integrates into networks with non-Symantec firewalls
▪One-step configuration and one-step connect
▪Remote centralized management for large scale deployments.
The cost of the Symantec firewall/VPN appliances for small or remote offices, at the time of this writing, is as follows:
| ▪ | Symantec Firewall/VPN 100: | $499 |
| ▪ | Symantec Firewall/VPN 200: | $899 |
| ▪ | Symantec Firewall/VPN 200R: | $1199 |
The cost of the Symantec enterprise gateway security appliances, at the time of this writing, is shown in the following list. These prices are for a base license (50-node firewall, one client-to-gateway VPN session).
| ▪ | Symantec SGS 5420: | $2999.99 |
| ▪ | Symantec SGS 5440: | $6899.98 |
| ▪ | Symantec SGS 5460: | $11,534.98 |
A base license is for a 50-node firewall, unlimited gateway-to-gateway VPN, and one client-to-gateway VPN session. The base license also includes one year of Gold Maintenance support service and content updates of virus definitions, attack signatures, and URL filtering via LiveUpdate.
The appliance itself contains all supported security features, but several of the security functions have to be licensed separately, including the following:
▪Optional Event Manager plug-in for centralized logging, alerting and reporting
▪Optional Advanced Manager plug-in (included Event Manager) for centralized management of rule sets and security policies
▪Optional high availability and load balancing
▪Optional enhanced anti-virus engine
▪Optional hybrid anomaly intrusion prevention and detection engine (real-time monitoring, detection and prevention using protocol anomaly detection and attack signatures)
▪Additional concurrent VPN sessions
Symantec: Platform Support and System Requirements
SGS is based on the Raptor firewall plus the Recourse Intrusion Detection System (IDS) plus Symantec's Antivirus. The software version of the Symantec Enterprise Firewall will run on Windows NT/2000 or Solaris. Windows machines require a 400 MHz PIII processor, 256MB of RAM, and 8 GB of disk space. Solaris machines require Solaris 7 or 8, Sun UltraSPARC I or II sbus or PCI bus, 256MB of RAM and 8 GB of disk space.
How does ISA Server 2004 compare? ISA Server 2004 runs on standard Intel PCs that are easily upgraded and can be installed on Windows 2000 Server or Windows Server 2003, providing a standardized, familiar management interface and the flexibility to use hardware of your choice.
The Windows Server 2003 OS can be “hardened” by applying a series of special profiles included in Server 2003 SP2 for the Security Configuration wizard. Microsoft also provides a system hardening guide that includes specific configuration recommendations and deployment strategies for ISA Server 2004. The document can be downloaded at //www.microsoft.com/technet/prodtechnol/isa/2004/plan/securityhardeningguide.mspx.
Symantec: Application Layer Filtering Capabilities
Symantec provides application layer filtering for intrusion detection, HTTP and SMTP/POP3 protection, and FTP filtering (virus and attack protection). The firewall uses ManHunt (which Symantec purchased from Recourse Technologies) for IDS. ManHunt monitors as passive IDS or actively blocks specified attacks. Symantec uses WebNot content filtering for URL screening. Anti-spam filtering is also sold as a separate optional function.
How does ISA Server 2004 compare? ISA Server 2004's built-in intrusion detection examines the HTTP, POP3, IMAP, SMTP, FTP, and DNS protocols. ISA Server 2004 performs intelligent stateful inspection using “smart” application filters. Not only can you determine the validity of data moving through the firewall in request and response headers, you can also filter by “signature” (text string) for keyword filtering or filter for particular file types.
ISA Server 2004 inspects all aspects of HTTP communications. The SMTP filter protects against invalid SMTP commands that cause buffer overflows, and the SMTP message screener blocks spam and mail containing dangerous attachments. ISA Server's RPC filtering protects against exploits and malicious code directed to the RPC services and ensures that only valid connections get through to the Exchange server. DNS filtering prevents application layer attacks aimed at published DNS servers, and the POP3 filters protect published POP3 mail servers from attack.
ISA Server was built from the beginning to perform ALF, and ISA Server's SDK allows easy development of new web and application filters.
Symantec: VPN Support
The Symantec Enterprise VPN 7.0 runs on Windows NT/2000 and Solaris 7/8 and is included in the Enterprise Gateway appliances. The Symantec Enterprise VPN client runs on Windows 9x, ME, 2000, NT 4.0 and XP. Enterprise VPN software is integrated with the Enterprise Firewall software on Symantec's security appliances.
Symantec Enterprise VPN includes:
▪Support for IPSec VPNs; interoperates with other IPSec-compliant VPN clients and servers
▪Operation independent of firewall and integrates into networks with non-Symantec firewalls
▪One-step configuration for administrators and one-step connect for clients
▪Remote centralized management for large-scale deployments.
The Enterprise VPN client includes personal firewall software; remote policies create a bootstrap file for clients, and the VPN server performs ProxySecured scanning of VPN connections.
How does ISA Server 2004 compareIn ISA Server 2004, the number of simultaneous VPN connections depend on the operating system, from 1000 (Standard edition), and up. ISA Server supports IPSec VPNs for site-to-site connections and both PPTP and the more secure L2TP for remote access connections. ISA Server can apply firewall policy to the VPN interfaces.
ISA Server does not require any software to be added to VPN clients. ISA Server supports the PPTP and L2TP/IPSec VPN clients that are built into Windows 9x/ME, Windows XP, Windows NT, 2000, and Server 2003 operating systems.
ISA Server's VPN quarantine allows administrators to enforce specific conditions VPN clients must meet before being allowed to connect (for example, latest service pack/updates must be installed) and direct clients to server to download and install the required updates.
ISA Server's VPN quarantine is a function of Windows Server 2003 and allows you to block VPN access if the client does not meet pre-defined configuration criteria, including installation of current service packs and hotfixes, operational anti-virus and firewall. No proprietary client software is required to use VPN-Q, and there is no extra cost to apply it to any number of clients up to the limits of the operating system.
Symantec: Web Caching
Symantec firewalls do not perform Web caching. A separate appliance or third-party Web caching solution must be implemented to provide this functionality on the network.
How does ISA Server 2004 compare? ISA Server 2004 includes Web caching functionality at no extra charge. Forward caching allows the ISA Server 2004 firewall to cache objects retrieved by internal users from external Web servers. Reverse caching allows the ISA Server 2004 firewall to cache objects retrieved by remote users from servers that have been published by the ISA Server 2004 firewall. Web objects requested by remote users are cached on the ISA Server 2004 firewall, and subsequent requests for the same objects are served from the firewall's Web cache instead of forwarding the request to the published Web server located behind the ISA Server 2004 firewall.
Fast RAM caching allows the ISA Server 2004 firewall to keep most frequently accessed items in memory. This optimizes response time by retrieving items from memory rather than from disk. ISA Server 2004 gives you an optimized disk cache store that minimizes disk access for both read and write operations. ISA Server 2004 also supports Web proxy chaining, which allows the ISA Server 2004 firewall to forward Web requests to an upstream Web proxy server.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781931836197500101