Westermo MR Series - Manual (Page 402)

402 6622-3201
Web Interface and Command Line Reference Guide www.westermo.com
Stateful Inspection 15.8
The Westermo routing code stack contains a sophisticated scripted “Stateful Firewall” and “Route
Inspec tion” engine. Stateful inspection is a powerful tool that allows the unit to keep track of a TCP/
UDP or ICMP session and match packets based on the state of the connection on which they are
being car ried. In addition to providing sophisticated Firewall functionality the SF/RI engine also pro-
vides a number of facilities for tracking the “health” of routes, marking “dead” routes as being Out
Of Service (OOS) and creating rules for the automatic status checking of routes previously marked
as OOS (for use in multi-level backup/restore scenarios).
The firewall may be used to place interface into an OOS state and also control how the interfaces
return to service. When an interface goes OOS, all routes configured to use that interface will have
their route metric set to 16 (the maximum value), meaning that some other route with a lower
metric will be selected.
When a firewall stateful inspection rule expires, a decision is made as to whether the traffic being
allowed to pass by this rule completed successfully or not. For example, if the stateful rule moni-
tors SYN and FIN packets in both directions for a TCP socket then that rule will expire successfully.
How ever, if SYNs are seen to pass in one direction but no SYNs pass in the other direction, the
stateful rule will expire and the unit will tag this as a failure.
The following conditions tag a stateful rule as a failure:
packets have only passed in one direction •
10 packets have passed in one direction with no return packets (for TCP the packets must also •
be re-transmits)
All of these features depend upon the stateful inspection capabilities of the Firewall engine which
are explained below.
The [inspect] field takes the following format:
inspect = [“inspect-state” {“oos” {interface-name¦logical-name}
secs {t=secs} {c=count} {d=count}} {r=“ping”¦“tcp”{,secs{secs}}}
{rd=x} {dt=secs}{stat}]
The field can be used on its own or with an optional oos (Out Of Service) parameter.
To understand this better let us look at a simple example in which we want to set up a filter to
allow all machines on a local network with addresses in the range 10.1.2.*, to access the Internet on
port 80. We will need one rule to filter the outgoing packets and another to filter the responses:
pass out break end on ppp 0 from 10.1.2.0/24 to any port=80
pass in break end on ppp 0 from any port=80 to 10.1.2.0/24
In this example, the first rule allows outgoing http requests on PPP 0 from any address matching
the mask 10.1.2.* providing that the requests are on port 80 (the normal port address for HTTP
requests).
The second rule allows http response packets to be received on PPP 0 providing they are on port
80 and they are addressed to an IP address matching the mask 10.1.2.*.
However, rule 2 creates a potential security “hole”. The problem with filtering based on the source
port is that you can trust the source port only as much as you trust the source machine. For
instance an attacker could perform a port scan and provided the source port was set to 80 in each
packet, it would get through this filter. Alternatively, on an already compromised system, a “Trojan
horse” might be set up listening on port 80.
A more secure firewall can be defined using the “inspect-state” option. The stateful inspection sys-
tem intelligently creates and manages dynamic filter rules based on the type of connection and the
source/ destination IP addresses. Applying this to the above example, we can redesign the script to
make it both simpler and more effective as described below.
As a consequence of the fact that only the first packet in a TCP handshake will have the SYN flag
set, we can use a rule that checks the SYN flag:
pass out break end on ppp 0 from 10.1.2.0/24 to any port=80 flags
s inspect-stateblock in break end on ppp 0
The first rule matches only the first outgoing packet because it checks the status of the s (SYN)
flag and will only pass the packet if the SYN flag is set. At first glance however, it appears that the
second rule blocks all inbound packets on PPP 0. Whilst this may be inherently more secure, it