Many network and firewall administrators consider the network firewall at the network edge as their primary defense against all network woes.

RimApp RoadBLOCK goes beyond simple filtering! Many network and firewall administrators consider the network firewall at the network edge as their primary defense against all network woes. However, traditional firewalls cannot provide a high level of security for modern Internet connected networks. This is because they perform basic packet filtering and allow inbound traffic to services that are provided to remote users. For example, if only HTTP, HTTPS and IMAP4 access is allowed to resources on the corporate network, the traditional stateful packet filtering firewall will only allow new inbound connection requests for TCP ports 80, 143 and 443. The traditional packet filtering firewall can quickly determine the destination port and validity of the layer 4 and below information, and accept or reject the traffic. While this approach provides a small measure of security, it is far from what is required to protect modern networks. The RimApp RoadBLOCK application layer aware firewall performs the real work of a network firewall stateful application layer inspection of both inbound and outbound traffic. Since modern exploits are aimed at the application layer, RoadBLOCK does the job of checking the validity of the communications such as checking the details of the HTTP communication and block suspicious connections through the firewall. The RoadBLOCK appliance makes sure that inappropriate traffic (such as worm generated traffic) does not cross into the network. Simple packet filtering is inadequate when it comes to protecting resources inside the network. Not only must all incoming connections be subjected to deep application layer inspection, but there must also be control over what leaves the asset networks using strong user/group based access control. Strong outbound user/group based access control is an absolute requirement. In contrast to a typical packet filtering firewall that lets all traffic out of the network, firewalls must also be able to control outbound connections based on user/group based membership. Reasons for this include: the requirement to log the user name of all outbound connections so that users are made accountable for their Internet activity the need to log the application the user used to access Internet content; this allows the assessment of whether applications not allowed by network use policy are being used and enables effective countermeasures to be taken the necessity to track data leaving the network and block inappropriate material from leaving the network the ability to block corporate data from leaving the network and record user names and applications the users are using to transfer proprietary information to a location outside the network Page 1 of 6

RoadBLOCK is ideal because it meets all of these requirements. When systems are properly configured as Firewall and Web Proxy clients, RoadBLOCK is able to: Record the user name for all TCP and UDP connections made to the Internet (or any other network that the user might connect to by going through the ISA Server 2004 firewall) Record the application the user uses to make these TCP and UDP connections through the ISA Server 2004 firewall Block connections to any domain name or IP address based on user name or group membership Block access to any content outside their network based on user name or group membership Block transfer of information from the Asset Network to any other network based on user name or group membership Application layer stateful inspection and access control requires processing power. That s why you should size your servers appropriately to meet the requirements of powerful stateful application layer processing. Fortunately, even with complex rule sets, RoadBLOCK is able to handle well over 1.5 gigabits/second per server, and even higher traffic volumes with the appropriate hardware. 5 Possible RoadBLOCK Deployment Scenarios RoadBLOCK Deployment Scenario 1 Page 2 of 6

RoadBLOCK Deployment Scenario 2 Page 3 of 6