Firewall rules examine the control information in individual packets, and either block
or allow them according to the criteria that you define. Firewall rules can be assigned
to a policy or directly to a computer.
![]() |
NoteThis article specifically covers how to create a firewall rule. For information on
how to configure the firewall module, see Set up the Deep Security firewall.
|
To create a new firewall rule, you need to:
When you're done with your firewall rule, you can also learn how to:
Add a new rule
There are three ways to add a new firewall rule on the Policies > Common Objects > Rules > Firewall Rules page. You can:
-
Create a new rule. Click New > New Firewall Rule.
-
Import a rule from an XML file. Click New > Import From File.
-
Copy and then modify an existing rule. Right-click the rule in the Firewall Rules list and then click Duplicate. To edit the new rule, select it and then click Properties.
Select the behavior and protocol of the rule
-
Enter a Name and Description for the rule.
Tip
It is good practice to document all firewall rule changes in the Description field of the firewall rule. Make a note of when and why rules were created or deleted for easier firewall maintenance. -
Select the Action that the rule should perform on packets. You can select from one of the following five actions:
Note
Only one rule action is applied to a packet, and rules (of the same priority) are applied in the order of precedence listed below.-
The rule can allow traffic to bypass the firewall. A bypass rule allows traffic to pass through the firewall and intrusion prevention engine at the fastest possible rate. Bypass rules are meant for traffic using media intensive protocols where filtering may not be desired or for traffic originating from trusted sources.
Tip
For an example of how to create and use a bypass rule for trusted sources in a policy, see Allow trusted traffic to bypass the firewall.The "bypass" action on firewall rules differs from a Force Allow rule in the following ways:Note
Bypass rules are unidirectional. Explicit rules are required for each direction of traffic.Tip
You can achieve maximum throughput performance on a bypass rule with the following settings:-
Priority: Highest
-
Frame Type: IP
-
Protocol: TCP, UDP, or other IP protocol. (Do not use the "Any" option.)
-
Source and Destination IP and MAC: all "Any"
-
If the protocol is TCP or UDP and the traffic direction is "incoming", the destination ports must be one or more specified ports (not "Any"), and the source ports must be "Any".
-
If the protocol is TCP or UDP and the traffic direction is "outgoing", the source ports must be one or more specified ports (Not "Any"), and the destination ports must be "Any".
-
Schedule: None.
-
-
The rule can log only. This action will make entries in the logs but will not process traffic.
-
The rule can force allow defined traffic (it will allow traffic defined by this rule without excluding any other traffic.)
-
The rule can deny traffic (it will deny traffic defined by this rule.)
-
The rule can allow traffic (it will exclusively allow traffic defined by this rule.)
Note
If you have no allow rules in effect on a computer, all traffic is permitted unless it is specifically blocked by a deny rule. Once you create a single allow rule, all other traffic is blocked unless it meets the requirements of the allow rule. There is one exception to this: ICMPv6 traffic is always permitted unless it is specifically blocked by a deny rule. -
-
Select the Priority of the rule. The priority determines the order in which rules are applied. If you have selected "force allow", "deny", or "bypass" as your rule action, you can set a priority of 0 (low) to 4 (highest). Setting a priority allows you to combine the actions of rules to achieve a cascading rule effect.
Note
Log only rules can only have a priority of 4, and Allow rules can only have a priority of 0.Note
High priority rules get applied before low priority rules. For example, a port 80 incoming deny rule with a priority of 3 will drop a packet before a port 80 incoming force allow rule with a priority of 2 gets applied to it.For detailed information on how actions and priority work together, see Firewall rule actions and priorities. -
Select a Packet Direction. Select whether this rule will be applied to incoming (from the network to the computer) or outgoing(from the computer to the network) traffic.
Note
An individual firewall rule only apply to a single direction of traffic. You may need to create incoming and outgoing firewall rules in pairs for specific types of traffic. -
Select an Ethernet Frame Type. The term "frame" refers to Ethernet frames, and the available protocols specify the data that the frame carries. If you select "Other" as the frame type, you need to specify a frame number.
-
Note
IP covers both IPv4 and IPv6. You can also select IPv4 or IPv6 individuallyNote
On Solaris, Deep Security Agents will only examine packets with an IP frame type, and Linux Agents will only examine packets with IP or ARP frame types. Packets with other frame types will be allowed through. Note that the Virtual Appliance does not have these restrictions and can examine all frame types, regardless of the operating system of the virtual machine it is protecting.If you select the Internet Protocol (IP) frame type, you need to select the transport Protocol. If you select "Other" as the protocol, you also need to enter a protocol number.
Select a Packet Source and Packet Destination
Select a combination of IP and MAC addresses, and if available for the frame type, Port and Specific Flags for the Packet Source and Packet Destination.
Support for IP-based frame types is as follows:
|
IP
|
MAC
|
Port
|
Flags
|
Any
|
✔
|
✔
|
|
|
ICMP
|
✔
|
✔
|
|
✔
|
ICMPV6
|
✔
|
✔
|
|
✔
|
IGMP
|
✔
|
✔
|
|
|
GGP
|
✔
|
✔
|
|
|
TCP
|
✔
|
✔
|
✔
|
✔
|
PUP
|
✔
|
✔
|
|
|
UDP
|
✔
|
✔
|
✔
|
|
IDP
|
✔
|
✔
|
|
|
ND
|
✔
|
✔
|
|
|
RAW
|
✔
|
✔
|
|
|
TCP+UDP
|
✔
|
✔
|
✔
|
✔
|
![]() |
NoteARP and REVARP frame types only support using MAC addresses as packet sources and
destinations.
|
You can select Any Flags or individually select the following flags:
-
URG
-
ACK
-
PSH
-
RST
-
SYN
-
FIN
IP Addresses
MAC Address
Port
Configure rule events and alerts
When a firewall rule is triggered, it logs an event in the Deep Security Manager
and records the packet data.
![]() |
NoteNote that rules using the "Allow", "Force Allow" and "Bypass" actions will not log
any events.
|
Alerts
You can configure rules to also trigger an alert if they log an event. To do so,
open the properties for a rule, click on Options, and then select Alert when this rule logs an event.
![]() |
NoteOnly firewall rules with an action set to "Deny" or "Log Only" can be configured to
trigger an alert.
|
Set a schedule for the rule
Select whether the firewall rule should only be active during a scheduled time.
For more information on how to do so, see Define a schedule that you can apply to rules.
Assign a context to the rule
Rule contexts allow you to set firewall rules uniquely for different network environments.
Contexts are commonly used to allow for different rules to be in effect for laptops
when they are on and off-site.
For more information on how to create a context, see Define contexts for use in policies.
![]() |
TipFor an example of a policy that implements firewall rules using contexts, look at
the properties of the "Windows Mobile Laptop" Policy.
|
See policies and computers a rule is assigned to
You can see which policies and computers are assigned to a firewall rule on the
Assigned To tab. Click on a policy or computer in the list to see their properties.
Export a rule
You can export all firewall rules to a .csv or .xml file by clicking Export and selecting the corresponding export action from the list. You can also export
specific rules by first selecting them, clicking Export and then selecting the corresponding export action from the list.
Delete a rule
To delete a rule, right-click the rule in the Firewall Rules list, click Delete and then click OK.
![]() |
NoteFirewall Rules that are assigned to one or more computers or that are part of a policy
cannot be deleted.
|
Flags background
There are a number of ways these flags can be used in different attacks. Only a selection
will be discussed here.
The URG flag indicates that the packet is urgent and must be processed before all
others, while the PSH flag sets the TCP stack to flush its buffers and send all information
up to the application. Both flags can be used in a type port scan called the Xmas
scan which is typically a FIN packet with the URG and PSH flags enabled. This scan
gets its name from the alternating bits turned on and off in the flags byte (00101001),
much like the lights of a Christmas tree.
When an unprotected machine receives packets related to a Xmas scan, the following
happens:
Condition
|
Response
|
Closed Port
|
Returns an RST packet
|
Open Port
|
No response, exposing existence of the open port
|
The RST, or RESET, flag abruptly terminates TCP connections. As described above, among
its legitimate uses is to terminate connections to closed ports indicating an impossible
or disallowed connection. However, the RST flag can also be used as part of a RST
attack, designed to disrupt existing sessions. The following diagram illustrates a
situation where an attack, Host C, was able to calculate the TCP sequence number that
Host A expected from a packet from Host B, thereby spoofing Host A into believing
that Host B had sent it a RST packet. The end result is a denial of service attack:
