FireBrick FB6402, Руководство пользователя

Страница: 64 / 196

Session Handling
47
checked for target IP of, say, 0.0.0.0/24, that would pass if the target IP is within the same /24 as the
source IP. This only works on IPv4, and only on subnets, not ranges, and only on
source-ip
and
target-ip
checks. Although not in RFC5735, the same logic is applied to IPv6 for ::/32-127.
A rule-set can also be named by setting the
name
attribute value, and enabled/disabled under control of a
profile. The
comment
attribute is a general purpose comment field that you can use to briefly describe the
purpose of the rule-set.
Under the heading "Individual rules, first match applies", you will see the list of session-rules within the rule-
set. A session-rule is defined by a
rule
object, which is a child object of a
rule-set
object.
Below the list of session-rules, you will see the
no-match-action
attribute, which is mandatory and has
one of the values shown in Table 7.1. Recall that this attribute specifies the action to take if all of the rules in
a rule-set have been considered, and none of them matched against the traffic.
7.3.3.1. Recommended method of implementing firewalling
Although there are likely numerous ways in which you can construct workable rule-sets that implement
firewalling in addition to any traffic-shaping or NAT etc., we recommend that you implement firewalling as
follows :-
• create one or more rule-sets that are specifically for firewalling
• use one rule set per interface, with the interface specified as the target-interface in the entry criteria, such
that the rule-set relates to sessions "to" that interface
• implement a 'default drop' policy on each firewalling rule-set, such that you have to list exceptions to
this policy to allow sessions to the specified target interface - to implement this policy, you set the
no-
match-action
attribute to either
drop
or
reject
• ensure these firewalling rule-sets appear before any other (non-firewalling) rule-sets
• create subsequent rule-sets if necessary to perform any modifications to the session, such as NAT'ing, or to
subject sessions to traffic shaping
Caution
If you have a large number of interfaces (for example, more than just WAN and LAN), you must take
care that you have covered all the interfaces that need to be firewalled
Alternatively, you could have a single firewalling rule-set without any entry-criteria and with
no-match-
action
attribute set to either
drop
or
reject
- that way, all traffic, regardless of its origin, or its
characteristics, will be subject to the 'default drop' policy. A disadvantage of this approach is that you will
need to specify target interfaces in every rule in order to replicate the functionality of the method described
previously.
In any case, you can verify that your rule-sets function the way you intended using the diagnostic facility
described in Section 13.1.
The XML fragment below shows a small firewalling rule-set for an interface, with a 'default drop' policy :-
<rule-set name="firewall_to_LAN"
target-interface="LAN"
no-match-action="drop">
<rule name="web"
target-port="80"