| Home Prev |  cOS Stream 4.00.03 Administration Guide
|
Next |
|---|
The Clavister NetShield Firewall architecture is centered on the concept of flows. Traditional IP routers or switches commonly inspect all packets and then perform forwarding decisions based on information found in the packet headers. With this approach, packets are forwarded without any sense of context which eliminates any possibility to detect and analyze complex protocols and enforce corresponding security policies.
The Clavister NetShield Firewall employs a technique called stateful inspection which means that it inspects and forwards traffic on a per-flow basis. cOS Stream detects when a new flow between a source and destination is being established, and keeps information about the flow over its lifetime. By doing this, cOS Stream is able to understand the context of network traffic and this enables it to perform a variety of important functions.The stateful inspection approach additionally provides high throughput performance with the added advantage of a design that is highly scalable. The subsystem that implements stateful inspection will sometimes be referred to in documentation as the state-engine.
All flows have a specified idle lifetime, after which they are removed from the flow table.
Basic Building Blocks
From the administrator's viewpoint, the basic firewall building blocks are:Interfaces such as physical Ethernet interfaces or logical VPN tunnels.
Logical Objects which are individual logical definitions within cOS Stream. For example, Address objects can be defined in the Address Book to give logical names to IP and other types of addresses.
The IP Rule Set which make up the security policies which the administrator wants to implement. These include IP rules.
These three types of building blocks are discussed next.
Interfaces
Interfaces are the doorways through which network traffic enters or leaves the Clavister NetShield Firewall. Without interfaces, a Clavister NetShield Firewall has no means for receiving or sending traffic.The following types of interface are supported:
Physical interfaces
These correspond to the actual physical Ethernet interface ports through which traffic arrives and leaves the Clavister NetShield Firewall.
Tunnel interfaces
Used for receiving and sending traffic through VPN tunnels. These are treated as logically equivalent to physical interfaces when configuring cOS Stream. For example, a route in a routing table could specify either a physical or tunnel interface as the destination for a particular network.
Interface Symmetry
cOS Stream interface design is symmetric, meaning that the interfaces of the device are not fixed as being on the "insecure outside" or "secure inside" of a network topology. The notion of what is inside and outside is totally for the administrator to define.Logical Objects
Logical objects can be seen as predefined building blocks for use by the rule sets. The address book, for instance, contains named objects representing host and network addresses.Another example of logical objects are services which represent specific protocol and port combinations.
Rule Set
Finally, rules which are defined by the administrator in the Main rule set are used for actually implementing cOS Stream security policies. The most fundamental set of rules are the IP Rules, which are used to define layer 3 IP filtering policies.Basic Packet Flow
This section outlines the basic flow for packets received and forwarded by cOS Stream. The following description is simplified and might not be fully applicable in all scenarios, however, the basic principles will be valid for all deployments.An Ethernet frame is received on one of the Ethernet interfaces in the system. Basic Ethernet frame validation is performed and the packet is dropped if the frame is invalid.
The IP datagram within the packet is passed on to the consistency checker. The checker performs a number of sanity checks on the packet, including validation of checksums, protocol flags, packet length and so on. If the consistency checks fail, the packet gets dropped and the event is logged.
cOS Stream now tries to lookup an existing flow by matching parameters from the incoming packet. A number of parameters are used in the match attempt, including the source interface, source and destination IP addresses and IP protocol.
If a match cannot be found, a flow establishment process starts.
The Access Rules are evaluated to find out if the source IP address of the new flow is allowed on the received interface. If no Access Rule matches then a reverse route lookup will be done in the routing tables.
In other words, by default, an interface will only accept source IP addresses that belong to networks routed over that interface. A reverse lookup means that cOS Stream looks in the routing tables to confirm that there is a route with this network as the destination on the same interface.
If the Access Rule lookup determines that the source IP is invalid, then the packet is dropped and the event is logged.
A route lookup is made using the routing table. The destination interface for the flow has now been determined.
The IP rules are now searched for a rule that matches the packet. The following parameters are part of the matching process:
If a match cannot be found, the packet is dropped.
If a rule is found that matches the new flow, the Action property of the rule decides what cOS Stream should do with the flow. If the action is Drop, the packet is dropped and the event is logged according to the log settings for the rule.
If the action is Allow, the packet is allowed through the system. A corresponding flow will be noted by cOS Stream for matching subsequent packets belonging to the same flow. The allowed traffic is also bidirectional so that the same IP rule also permits packets to return from the destination network.
Finally, the opening of the new flow will be logged according to the log settings of the rule. The default is for logging to be enabled.
Eventually, the packet will be forwarded out on the destination interface according to the flow. If the destination interface is a tunnel interface, additional processing such as encryption or encapsulation might occur.
