With the increasingly dominant threat of network security breaches from the professional computer abuser, to innocent net sweepers, to accidental exposure of critical network information, the necessity for secure firewall systems seem to be growing exponentially. Unfortunately, with an increase in security comes a trade off with convenience. As the number of connections into a network increases, so does the vulnerability from attacks. What resources should one protect? Whom must the network be defended against? When does "security" become adequate? Such decisions are clearly an iterative process with the answers never being final on an ever-expanding network.

    To analyze the security potential of any network, one must first assess the risk of the network being compromised. What is the risk of unauthorized access? Of virus infection? If most Telnet sessions come from untrusted machines, what protection can minimize the intrusion of a remote Telnet session recording username and password combinations or entire log sessions? Quickly one realizes the necessity of implementing a security policy; a set of decisions that collectively determine an organizations stance toward security.

    ACC has long recognized the importance of providing network security in its products and therefore continues to expand its firewall capabilities as new challenges are discovered in the marketplace.


    An ACC bridge/router that is connected between a network and the Internet, or between two or more networks, can be considered a firewall system when properly configured. Firewall systems can sometimes be referred to as a gateway. A bridge/router can be programmed to restrict intercommunication with non-privileged users and/or restrict specific network information from propagating beyond defined borders.

    Within a network it is common to implement several types and combinations of firewalls, both for internal and external isolation purposes. ACC provides firewall management primarily through the implementation of software filters. The following paragraphs help explain some of the various types of filters one might implement.


    ACC extends filtering abilities to eliminate network intruders and to provide enhanced Internet "Firewall" security. This enhancement is in response to an increase of 'violators' breaking into computer systems through an Internet connection in order to access proprietary information.

    ACC's software enhancement extends its extensive filtering capabilities to restrict access into an external interface by not allowing a packet through if it contains a source address from an internal network. In addition, this enhancement filters outgoing packets that have a source address different from an internal network. This last feature prevents a source IP spoofing attack originating from an internal network. Both of these features combine to build a firewall which will prevent any IP spoofing attacks.


    Unlike traditional bridging filters which only allow filtering based on MAC layer addresses or protocol type, semantic filters filter packets based on higher-level information, as well as on MAC layer addresses or protocol type. Semantic filters employ traditional bridge/router filters such as network ID and socket number over the bridged frame. Thus, when the ACC products are bridged between two Ethernets or two Token Rings, application-specific filters can be set to select which packets cross over bridged boundaries. The following chart highlights the advantages of semantic filtering over traditional bridge filtering techniques.

    Table 1: Advantages of Semantic Filtering
    Bridging TechniqueMAC Layer Semantic Filter
    Ethernet 802.1 (d) BridgingBlock forward or flood MAC destinationPrioritize or discard based on Ethernet Packet Type, SNAP PID, or DSAP, or refer decision to Network Layer datagram filter
    Token Ring 802.5 (d) Source RoutingBlock or forward traffic between station pairsPrioritize or discard on SNAP PID, or DSAP, or refer decision to Network Layer

    Semantic filters also extend the power of traditional routing filters found in network layer protocols. Traditional router filters simply allow or deny access to attached networks. Semantic filters go beyond traditional routing filters and employ filters at the specific datagram level.

    Table 2 highlights the advantages of semantic filtering over traditional router filtering techniques by specifying datagram parameters that can be selected for various protocols.

    Table 2: Datagram Parameters for Various Protocols
    Routing AlgorithmRoute Filter Semantic Filters (datagram)
    AppleTalkAccept or reject routes to AppleTalk Networks from differing neighborsPrioritize or discard datagrams based on source, destination, socket, or transport layer protocol
    DECnet Phase IVAccept or reject routes to DECnet nodes or areas from differing neighborsPrioritize or discard datagrams between stated source and destination nodes or areas
    IPAccept or reject RIP updates from differing neighborsPrioritize or discard datagrams based on source, destination Transport layer protocols or UDP/TCP based. Note: ranges of port numbers can be employed.
    XNS IDPAccept or reject routes to XNS Networks from differing neighbors. Accept or reject SAP entriesPrioritize or discard datagrams based on destination host, socket and PEP application

    Prioritize or discard datagrams based on source and destination networks


    BGP is the Border Gateway Protocol, also known as an Exterior Gateway Protocol. Although there is an Exterior Gateway Protocol of the same name, EGP, it has been superseded by BGP for a variety of reasons. BGP has many dynamic characteristics which make it the better choice as an interface between interior networks using RIP and OSPF and the Internet backbone, an exterior network. For more specific information on Border Gateway Protocol, please refer to ACC's White Paper on BGP.


    The following categories are intended to illustrate ACC's implementation of programming commands for a secure network. Firewall security is effectively managed through a variety of software filters.

      IP filtering is a basic component of most firewalls. With the implementation of IP filters, a bridge/router has the ability to restrict types of IP traffic to isolate hosts or networks, or to restrict the type of traffic permitted.

    • <EXAMPLE> Suppose one does not desire IP traffic from a specific host to leave that host. Assuming the host's IP address is, the following filter will accomplish that goal:

    "add ip filterentry0."
    <dest><mask><IP addr><mask><action>

    • The above filter discards all IP packets to any IP destination with any mask, that originates from IP address

    • <EXAMPLE> Suppose one wishes to restrict Telnet access to a specific network, the following command causes a bridge/router to discard all packets trying to open a Telnet session to that network:

    "add ip filt ent129.192.64.0255."

    • The above filter discards any TCP packet, for Telnet services, destined for IP network originating from any IP source address with any mask. Note: "0x6" specifies port 6 (TCP) protocol, and "D=23" specifies Telnet service.

      Similarly, IPX filters are also a basic component of most network firewalls. IPX filters provide a wide spectrum of firewall protection through host filtering, network filtering, route filtering, and sap filtering. The following paragraphs illustrate examples of each:

    • <Host Filter>

    "add ipx host filter entry00:00:00:00:00:000x1230x0discard"
    <host MAX addr><sock><pc><action>

    • The above host filter discards IPX packets destined to socket 0x123 at any IPX destination host (MAC addr). (Note that "0x0" serves as a wildcard for 'any' host).

    • <Network Filter>

    "add ipx network filter entry 0x8000 0x1000 0x22 0x33 0 high"
    <dest> <src> <dest> <src> <t> <action>

    • The above filter sets the priority to 'high' for all packets to the destination address of 0x8000 from the source address of 0x1000, and to the destination socket of 0x22 from the source socket of 0x33. Note: the action could also have been 'low', 'normal', or 'discard'.

    • <Route Filter>

    "add ipx route filter entry 00:dd:00:12:34:00 0xa5 reject"
    <Mac addr> <net> <action>

    • The above filter configures the bridge/router to reject any routes from network A5 advertised by the router whose MAC address is 00:DD:00:12:34:00.

    • <IPX SAP Filter>

    "add ipx sap filter entry 0x0000 "NWSERVER1" accept"
    <s-type><ser-name> <action>

    • The above filter accepts (or stores) SAP advertisements from the server "NWSERVER1" in the router's SAP database. Note: Service type "0x0000" allows any advertised service.

      ACC also provides non-IP and non-IPX filters for firewall protection, including: AppleTalk, DECnet, DLS, and IDP filters. Examples of each follow:

    • <AppleTalk Filter>

    "add AppleTalk filt ent 1 65534 1 65534 0 255 any discard"
    "add AppleTalk filt ent 100 199 1 65534 0 255 any normal"
    <ds> <de> <ss> <se> <scs><sce><t> <action>

    • The above two filters exclude all AppleTalk traffic from a particular link except for traffic directed to a particular network range of 100 to 199.

    • <AppleTalk Route Filter>

    "add AppleTalk route filter entry 300 399 100 199 accept"
    "add AppleTalk route filter entry 400 499 100 199 reject"
    <nrs> <nre> <rs> <re> <action>

    • The effect of the above two filters is as if neighboring router 407.2 is not advertising the route to 100 to 199 network address range, even if it is, and even if it is a better route. Only the route through 392.1 is to be advertised to routers further away.

    • <DECnet Filter>

    "add DECnet filter entry 1.2 3.5 discard"
    <dest> <src><action>

    • The above filter discards all packets from source address of 3.5 to the destination address of 1.2.

    • <DECnet Route Filter>

    "add DECnet route filter entry 2.7 0.0 reject"
    <adj> <tar> <action>

    • This filter configures the bridge/router to reject route information about all nodes in all areas as advertised by the adjacent node with a DECnet node ID of 2.7.

    • <DLS Filter>

    "add dls filter macaddr 12:3e:ff:42:11:2b"
    <MAC address>

    • The above filter allows LLC packets with a destination and source address of 12:3E:FF:42:11:2B to pass through the DLSw port. If this is the only entry in the DLS filter table, and the destination and source address do not match, the packet does not pass through the DLSw port.

    • <IDP Host Filter>

    "add idp host filt ent 00:00:00:00:00:00 0x123 0x4567 discard"
    <host MAC addr> <socket><pep-c> <action>

    • This filter protects ones' host from the PEP protocol using socket 0x123 and the PEP client type 0x4567.

    • <IDP Network Filter>

    "add idp network filter entry 0x8000 0x1000 0x22 0x33 0 dis"
    <dest> <src> <D-><S-s><t><actn>

    • This filter discards all packets to the destination address of 0x8000 from the source address of 0x1000, and to the destination socket of 0x22 from the source socket of 0x33.

    • <IDP Route Filter>

    "add idp route filter entry 00:dd:00:12:34:00 0xa5 reject"
    <router MAC> <net> <action>

    • This filter configures the bridge/router to reject any routes from network A5 advertised by router with MAC = 00:DD:00:12:34:00.

    • <Bridge Filter>

    "add bridge filter ent ca:fe:00:1a:ae:42 ff:ff:ff:ff:ff:00
    00:ae:88:f0:od:42 ff:ff:ff:ff:ff:ff discard 2 ! 0x0800"

    • This filter drops all non-IP packets bound for bridge port 2, from the stations at 00:AE:88:F0:0D:00 through 00:AE:88:F0:0D:FF, destined for the station at CA:FE:00:1A:AE:42.


    When considering 'firewalls', there are no 'pat' solutions without fully understanding all the elements of ones' network. It has correctly been said, "that which is not expressly prohibited within a network, is permitted". One should also be cognizant of what has NOT been expressly permitted but is none-the-less lurking within a network. A firewall must be designed to block everything, then allow services to be enabled on a case by case basis, but only after careful assessment of need and risk.

    Firewalls can not protect effectively against viruses. There are too many ways to encode binary files for transport over networks, and there are too many architectures and viruses to risk one's network security with a look-up table.

    Whenever possible, generate a suite of network tests to verify the limits imposed by one's firewall filters. As new filters are added and deleted, keep the suite updated. Conflicting filters may create unwanted results.

    Copyright © 1996 Advanced Computer Communications