IPNetSentryX (included as part of IPNetRouterX) is an advanced firewall, intrusion detector, and network management tool that provides greater control over the traffic that flows on your network.
Unlike most other Internet security products, IPNetSentryX offers basic protection without erecting barriers for the safe use of your Internet connection. There is no need to "punch holes" in a firewall for specific applications you may wish to run. Instead, IPNetSentryX silently and intelligently watches for suspicious behavior, and when triggered, invokes a solid filter which completely bans the potential intruder from your Macintosh. The advantage is you don't need a network expert to configure your firewall or debug compatibility conflicts.
Beyond this basic protection, IPNetSentryX offers exceptional flexibility for specifying what traffic to allow on your network and responding to network events.
A firewall is a mechanism for enforcing an access policy by controlling what traffic to allow on your network. Firewalls work by examining one or more properties of each network packet and deciding whether to allow the packet through or take other appropriate action.
Since there is no "one size fits all" access policy that is appropriate for every network, the value of any firewall depends on how effectively it can be adapted to implement your access policy. More specifically, what properties of packets or data flows it can detect, what actions it can take, and how much traffic it can handle without adversely impacting performance.
A firewall is typically used to: (1) Limit outside access to certain users or services; (2) Block unwanted or harmful traffic that could disrupt network services; (3) Keep a record or log of interesting network events including possible threats or inappropriate traffic; and (4) do all this without interfering with normal use. IPNetSentryX provides a simple yet powerful user interface for doing this by supporting a full set of packet properties and response options. The supplied default configuration is readily modified to suit simple to very advanced requirements.
Firewalls are configured by specifying one or more firewall rules. A rule specifies some set of conditions and what action to take if the conditions are met. A condition can be defined by some property having a specified value. You might think of each rule as a filter that excludes certain packets from the network. In an effort to keep the rules simple, most IP firewalls limit the set of properties they can match. As more properties are added, the firewall rules become longer and more complex.
IPNetSentryX uses hierarchical filter rules so that each rule matches only a single property but can contain child rules that must also match to create any combination. This keeps the rules themselves simple and allows factoring for greater efficiency.
Since each filter rule need only specify a single condition (property and value), we can support many properties without making the rules ever more complex.
To match a traditional filter rule, the packet is checked against each condition in the rule (device, direction, source address, destination address, source port, destination port, etc.). If any property fails to match, the packet is then checked against the next rule. Notice a packet might be checked to determine whether it came from Ethernet built-in many times (once for each rule). With hierarchical filter rules, a single rule could check for Ethernet built-in. All the rules within this rule need not repeat this test. In this way, packets flow through the hierarchy or filter tree until they reach a leaf node that specifies some action.
In a traditional firewall, it is the responsibility of the administrator to keep the number of rules as small as possible to minimize filtering overhead. With IPNetSentryX’s hierarchical filter rules, much of the filter tree falls away and is only tested when actually necessary thereby enhancing performance.
Each hierarchical filter rule includes some information about its position in the hierarchy (parent and children if any), a single condition, and an action. The condition is defined by specifying a property, a relationship, and a value. If the condition is met, the corresponding action is taken. If the condition is not met, testing proceeds to the next rule at the same or previous level in the hierarchy. In the most common case, if a packet matches a given rule, it will then be tested against the first child of that rule. If it doesn't match, it will move on to the next rule at the same or previous level.
IPNetSentryX provides three actions for combining rules:
| -> | advance to next level or child |
| ++ | skip over next filter rule (including any children) |
| Group | begin a group of related rules |
| Exit group | skip to the end of the preceding group |
The default action if a condition is not met is to fall through to the next rule at the same or previous level. Using these actions, we can represent logical expressions as follows (where A and B are conditions and ! represents negation).
A and B
if (A) ->A or B
if (B) perform_actionnext_rule
if (A) perform_actionIn the example above, "perform_action" refers to some leaf action like deleting a packet, or passing it on without testing against any more rules. If the action to be performed is to test against another firewall rule (not a leaf node) and then continue processing, we can use this form:
if (B) perform_action
next_rule
if (any) Group
if (!A) ->
rules_for_A_or_Bif (!B) Exit group
next_rule
The "Group" and "Exit group" actions allows you to test against any sequence of subrules, and then continue with the next rule at the same or previous level as the preceding "Group".
Certain actions like "Delete" or "Pass" terminate processing on a packet so it is not matched against any more rules. Other actions like "Log" cause an event to be logged but do not prevent the packet from being matched against subsequent rules. To perform multiple actions based on a single condition, we can append them as children.
if (A) perform_action1If condition A is satisfied, testing proceeds with any children of this rule. If “action1” is a terminating action such as “Delete”, no rules beyond the children of this rule will be processed, and no other terminating actions will be executed. Condition B could specify to match “Any” packet, or further restrict which packets will be subject to additional action. This ability to continue matching children even after a terminating condition allows us to both Log and send Email for a packet that is to be deleted for example. If there are no children of a matching rule that specifies a terminating action, testing stops immediately.
if (B) perform_action2
By factoring, we can make comparing packets against our rules very efficient, but we are dependent on testing our rules in hierarchical order. At the same time, we may wish to add rules to our firewall dynamically based on traffic events. To avoid frequent changes to the rule hierarchy, we use separate tables for dynamic (added in response to the network) versus static (added by the user) firewall rules. The structure of the dynamic tables can be made simpler since we always add rules of the same type.
We define a dynamic table for triggered IP addresses to block packets from any source address involved in suspicious activity such as scanning. To compare a packet against the addresses in the triggered address table, we define a special "include" property which takes as a value the name of a table we wish to test against.
For example:
if (include == trigger_table) perform_actionWould test if our packet is from an address in the triggered IP address table. We might load the table based on suspicious activity like this:
if (destPort == telnet) triggerAn intruder that tries to gain telnet access to our host can be barred from any further access.
The triggered address table can be modeled as a simple array of addresses and their time to live (the actual implementation uses AVL trees for faster lookup). Using purpose specific dynamic tables allows us to test dynamic state efficiently while using less kernel memory.
In addition to banning certain addresses immediately, we might want to remember a previously seen address to detect repeated access attempts by the same host. We define a dynamic table to remember previously seen addresses as another entry type in the triggered address table specified by the action “keep address” and searched with the “include == address” property.
We might also want to temporarily authorize access from a previously seen address that matches some firewall rules. We define a dynamic table to remember authorized addresses as another entry type in the triggered address table specified by the action “authorize” and searched with the “include == authorize” property.
Many advanced firewalls maintain a connection state or data flow table so they can reject packets not only based on their content, but also on the conversation state of the corresponding source and destination. In this way, incoming packets that are not part of a previously established conversation can be ignored. Similar to our “trigger” and “keep address” tables above, IPNetSentryX maintains a connection table to track data flows between network endpoints. A filter rule can search this table to see if a packet is from an established connection using the “include == state” property. When combined with other properties, this can provide Stateful Packet Inspection.
In addition to recognizing packet headers, IPNetSentryX provides features for matching URL keywords and searching for text strings inside packets. This allows the firewall to block common Internet worms and server attack profiles. If a rule matches undesired TCP content, it is important to drop the connection (Drop connection) and not simply drop the packet. This avoids filling the TCP state table with open but failed connections.
For inbound packets, dropping the connections sends a TCP RESET to the local endpoint.
For outbound packets, dropping the connection sends a TCP FIN segment as a response to the local endpoint.
IPNetSentryX recognizes Ethernet hardware addresses so that filter rules can distinguish traffic sent to or from specific devices attached to your LAN.
In addition to allowing or denying network access, sometimes it’s desirable to limit the amount of bandwidth consumed by certain users or applications so that other network applications can remain responsive. IPNetSentryX allows you to specify the maximum bandwidth (bytes/second) available to matching TCP connections.
The purpose of bandwidth management is to allocate network resources and improve network efficiency (the amount of useful information transferred per unit time). IPNetSentryX provides TCP rate limiting (pacing) by adjusting the advertised window size of packets from corresponding matching connections. This technique uses TCP/IPs built-in flow control mechanism and avoids adding latency that can reduce network efficiency.
Some UNIX firewalls provide packet shaping using pipes or queues (weighted fair queuing) that were originally intended to simulate impaired network connections. Since TCP/IP is adaptive, it will self adjust to the impaired network bandwidth available. A disadvantage of this approach is that queuing (buffering and waiting) adds latency and does not proactively prevent congestion before it occurs.
More importantly, a precondition for being able to apply bandwidth management is to first classify traffic so you can limit the specific data flows of interest. IPNetSentryX’s hierarchical filter rules are designed with this flexibility in mind.
By enabling "Bandwidth Accounting", IPNetSentryX allows you to keep a record of the amount of traffic matching designated firewall rules so you can monitor specific traffic of interest such as traffic that flows over a particular data link that is subject to ISP billing.
Another way of understanding network usage patterns is to examine the connections or data flows established. By enabling “Connection Logging”, IPNetSentryX allows you to keep a record of each connection or data flow established between a local and remote network endpoint (IP address and protocol port) and the amount of traffic sent between them. The connection log may be used as an audit trail to verify whether a specific network access has occurred with less overhead than enabling Traffic Discovery which keeps per second transfer statistics for every network service and device.
IPNetSentryX can test some conditions that are not related to packet contents. These include:
Time of dayThese rules provide the flexibility to respond to higher level network policies and events. Using “Time of day” and “Day of week” for example, we might restrict access to certain web sites or services only during business hours, or send Email notification to different administrators depending on the time of day.
Day of week
Parent idle time
Parent match count
Parent byte count
Each filter rule maintains simple statistics on the packets it matches. When a packet arrives that matches a given rule, its idle time is set to zero, its match count is incremented by 1, and its byte count is incremented by the size of the packet. In addition to viewing these statistics from the user interface, we can create rules that test against them to probe servers and report when services become unavailable or overloaded.
A timer within the network kernel walks the filter table periodically sending any updates to the user interface and checking any rules that match against the “Parent idle time”. If such a rule hasn’t detected traffic from a given server within the specified idle time, the action for that rule is performed even though no packet was received. The available actions include sending a network probe, notifying an administrator the server is not responding, or resetting the “Parent match count” so we can arrange to be notified only once, or every 4 hours while a server fails to respond.
By combining hierarchical filter rules, traffic statistics, and flexible notification options, IPNetSentryX can function as a sophisticated network monitor.
While many “firewall” products can claim to provide network security, these claims are hard to evaluate unless you can verify how the firewall is working to implement your access policy on your network. IPNetSentryX is designed to show how it is working in several ways:
Hierarchical filter rules are easier to understand and debug since you can examine each tested condition one at a time.A common weak link in the firewall chain is complexity and the likelihood of configuration errors. IPNetSentryX is designed to let you see, test, and understand what your firewall is doing.On screen updates allow you to see each rule being matched (match count and byte count) as traffic occurs. Individual rules are easily enabled or disabled to facilitate testing.
IPNetSentryX provides detailed logging showing not only when access is denied (or allowed), but which rule was matched by number and optional name.
Firewall rules have a descriptive name and parameter field that can be used to document what the rule does.
Firewall rules can be copied and pasted as plain text making it easy to share rules or compare notes with other users.
IPNetSentryX provides flexible notification options including Logging, on screen Alerts, Email, URL, and AppleScript.
IPNetSentryX includes basic tools for examining network traffic and generating probe packets to test network behavior.
Compared to Unix ipfw, the standard firewall included with Mac OS X, IPNetSentryX offers several advantages:
Excellent performance using hierarchical filtering entirely within the network kernel.IPNetSentryX supplements and is fully compatible with Apple's own firewall in Mac OS X while providing additional capability to solve network problems users may encounter.Excellent compatibility. As a shared resource, Unix ipfw is often configured by multiple programs with conflicting models. IPNetSentryX does not use or depend on ipfw leaving it available for Internet Sharing or other Unix software. IPNetSentryX’s trigger on suspicious activity model is less likely to interfere with legitimate network use (such as games, conferencing, or streaming media).
Flexible configuration, logging, and notification options. Jaguar’s built-in firewall does not filter UDP, does not provide detailed logs, does not filter packet content, does not provide rate limiting, is difficult to debug, and cannot provide Email or AppleScript notification of possible network attacks.