Firewall
From UntangleWiki
 Firewall
|
|
About Firewall
Firewall provides traditional firewall functionality, blocking or logging traffic based on rules. Although the term "Firewall" has grown to encompass many functionalities, the Untangle "Firewall" is a simple traditional firewall used to block traffic. Other functionalities (such as port forwarding or blocking protocols) are in other apps or networking configuration.
Firewall uses a simple list of rules to determine what traffic to block (or log) and what traffic to pass. Each time untangle catches a new session, the list of rules is evaluated in order. Firewall takes the first matching rule and applies the corresponding action stated in that rule.
Rules are based on a combination of the following:
- Traffic Type (Protocol)
- Source Interface
- Destination Interface
- Source Address
- Destination Address
- Source Port
- Destination Port
Settings
Since Firewall rules are different for most networks, the settings will be covered a bit differently from the other applications.
Using Firewall
Using Firewall rules network administrators can construct a rule set that blocks and allows traffic according to their preferences. By default, the default action of the Firewall is set to Pass.
Typically, Untangle is installed as a NAT/gateway device, or behind another NAT/gateway device in bridge mode. In this scenario all inbound sessions are blocked except those explicitly allowed with port forwards. As such, the Firewall application is not needed to filter inbound sessions, but can still be used to tightly control outbound sessions (often called Egress filtering). In cases where inbound sessions are not being blocked the Firewall application can filter those sessions like any other session.
The following are the most common use cases for Firewall.
| Approach | Description | How |
|---|---|---|
| Block Everything except Explicitly Allowed Traffic | In this scenario all traffic is blocked except explicitly allowed traffic. This can be the most secure, but can also require higher maintenance and be more problematic for users. To do this simply change the default action to Block then create an explicit rule that allows all traffic you want to pass. Typically this means creating a pass rule for outbound DNS, web traffic and any other protocols, and creating a pass rule for any inbound traffic you may have. (Note: In this scenario, any port forwards must also have accompanying Firewall rules or the Firewall will block that forwarded traffic) |
To do this change the default action to Block then create an explicit rule that allows all traffic you want to pass. Typically this means creating a pass rule for outbound DNS, web traffic and any other protocols, and creating a pass rule for any inbound traffic you may have. (Note: In this scenario, any port forwards must also have accompanying Firewall rules or the Firewall will block that forwarded traffic |
| Explicitly Block Some Ports or Machines |
In this scenario most traffic is passed, but Firewall is being used to explicitly limit some ports or machines from passing certain types of traffic. This is a very commonly used scenario as it provides a good compromise between security and maintenance which suits many organizations. |
To do this change the default action to Pass and create an explicit rule for traffic that should be blocked. |
| Using Firewall for Logging and Information |
Another common scenario is to use firewall for debugging and logging information to see what is happening on the network. |
To do so, simply set the default action to Pass and then create a rule to log traffic. Using Firewall as a tool can help network administrators see what is going on and save that information in Reports. |
Anatomy of a Firewall Rule
Firewall matches the sessions/connections using rules based on traffic criteria. When a new session is caught, the rules are evaluated in order. If all of a sessions attributes match all of the criteria of a session it is considered a match. Firewall applies the action of the first matching rule. If no rule matches - the default action is applied.
Each rule matches traffic based on certain criteria which consist of the protocol (traffic type), as well as source and destination interfaces, and source and destination addresses and ports. See the table below for detail values.
Note: Firewall matches against connections - not packets. The criteria evaluated are the criteria of the connection. If a connection is passed, all associated packets in a connection will automatically be passed without evaluating the rules.
| Traffic Type | The traffic type criteria selects the protocol to be matched. Valid values are TCP, UDP, both TCP & UDP, or any. |
| Source Interface | The client's interface. The client is the host that initiates the request. Your choices are any (all), External, DMZ, VPN, Internal, Less Trusted or More Trusted Interfaces.
If one of your interfaces doesn't appear in the list, go to Adding Network Cards or Testing Internet Connection. |
| Destination Interface | The server's interface. The server is the host that services the request. Your choices are any (all), External, DMZ, VPN, Internal, Less Trusted or More Trusted Interfaces.
If one of your interfaces doesn't appear in the list, go to Adding Network Cards or Testing Internet Connection. |
| Source Address | The IP address of the host which initiated the connection. Addresses are specified in IP Matcher format, which can be simple addresses, address ranges (address-address), or subnets with CIDR (address/subnet) notation. |
| Destination Address | The IP address of the host which received the connect request. Addresses are specified in IP Matcher format, which can be simple addresses, address ranges (address-address), or subnets with CIDR (address/subnet) notation. |
| Source Port | The port of the connection source. Valid values are in Port Matcher format.
WARNING: Usually the source port is randomly chosen by the sender and will be a value between 0 and 65535. In most rules this should be left as Any. |
| Destination Port | The port of the connection destination. Valid values are in Port Matcher format. |
Example: Blocking SSH Traffic on Port 22
The following example shows a rule that blocks SSH traffic going out the external interface.
Note: Although you can use the Firewall to achieve your goal, consider using the Protocol Control. Protocol Control does not require that you know the ports on which applications communicate. Moreover, you don't need to create a rule. You need only select one check box to achieve your goal. Of course, for those that are used to a traditional firewall, Untangle's Firewall offers the typical features, including port blocking.
Building a Ruleset
For each new connection the rules are evaluated in order until the first matching rule is found. This allows the administrator to create very detailed firewall policies by carefully ordering the rules. For example if the first rule is to allow SSH traffic from 192.168.1.10 and the next rule is to block all SSH traffic, then the result is that SSH is blocked for all IPs except 192.168.1.10. Rules can be combined in this manner to create fine-grained firewall policies.
Rules can also be easily reordered by dragging the reorder icon on each rule and hitting either the OK or Apply button.
Note: Additionally the Firewall application can be combined with Policy Manager and AD Connector to have different sets of rules apply for different users or even different times of day.
Event Log
Every rule that has "log" checked creates a firewall event. The Firewall Event Log is used to view recent events.
Note: When no rule matches the default action is taken and no event is logged. To log all events then a final rule should be created with the same action as the default action but with the log checkbox checked and all criteria set to "any." This will match all sessions that have not been matched by a previous rule and log them all. It is advised this is only done for debugging purposes as this will log many events.
Use the following terms and definitions to understand Firewall Event Log:
timestamp The time the event took place. action The action that was taken on the traffic. Valid values are block and pass. client The client IP address of the traffic. reason for action The rule that was applied to the traffic. server The intended server IP address of the traffic.
Related Topics
Firewall FAQs
Why doesn't the Untangle Server's Firewall have rules enabled by default?
- When the Untangle Server is your router, it is performing NAT. NAT protects you from most threats.
- When the Untangle Server is a bridge, the Untangle Server is already behind a firewall. A firewall protects you from most threats.
Can I have a firewall and still use NetMeeting?
Yes. However, on the Untangle Server, you need to pass specific protocols and open specific ports as outlined in Firewall. A Microsoft article, How to Establish NetMeeting Connections Through a Firewall, explains which protocols to pass and which ports to open.
How do I identify insecure ports?
There are free programs on the Internet that identify insecure ports. More information can be found here.
We currently have a firewall, which lets us do port mapping. I don't see that feature in your Firewall. Will you be adding it, or is there an alternative?
Port mapping (redirection or port forwarding) is a feature available in Networking configuration. Read more about port forwarding.
I want to lock-down my network but for a few exceptions. What is the best way to do this?
You can set the default behavior to block, as discussed in Anatomy of a Firewall Rule. Then, create a few rules to pass.
How can I block outbound SMTP?
Often administrators would like to block all outbound port 25 except from the mail server. To do so first you must remove the outbound port 25 policy rule so that outbound port 25 traffic goes through the rack in question. Then you need to create a rule to block all port 25 traffic with Destination Interface External then you need to create a rule just above that passes outbound port 25 traffic where the client is your email server. Beware, this means that mail coming from your mail server now goes through the rack and may be scanned by Spam Blocker, Phish Blocker, etc. Alternatively, You can add a rule in firewall blocking all port 25 traffic and then add a policy manager rule sending all outbound port 25 traffic from the email server to ">No Rack."
Should I use pre-NAT or post-NAT addresses in firewall rules?
Firewall rules always match on the address which has more information. In other words if the entire internal network is being NATd from 192.168.*.* to 1.2.3.4, Firewall will match on the 192.168.*.* for traffic to and from this network. At the session layer this works out to be pre-NAT on source address and post-NAT on destination address.
How do I create a rule to log all traffic, inbound and outbound?
You will need to create a rule with "any" with log check mark box checked.
How come my firewall rules are not being triggered?
Firewall rules work from top to bottom. Very first rule that the traffic matches, it will use that rule. So if you have an incorrect rule or a generic rule that the rule is matching, your other rules might not be triggered.
