IPNetSentryX is an advanced firewall intrusion detector that includes bandwidth allocation, bandwidth accounting, Ethernet bridging, AirPort configuration, and detailed logging. IPNetSentryX supplements and is fully compatible with Apple's own firewall in OSX while providing additional capability to solve network problems users may encounter.
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
Beyond this basic protection, IPNetSentryX offers unprecedented flexibility for specifying what traffic to allow on your network and responding to network events.
System Requirements: Mac OS X 10.3.9 or later, Leopard compatible.
Pricing: Single User $60
Upgrade from IPNetSentry classic $30
DOWNLOAD | BUY
Summary of Key Benefits
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. If you have a reason to care about network throughput such as doing remote backups, this can be significant.
- 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. IPNetSentryXs 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. Mac OS X'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.
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
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.
Hierarchical Filter Rules
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.
Simple and Flexible
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 IPNetSentryXs 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 on 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 two actions for combining rules:
advance to next level or child
begin a group of related rules
||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) ->
if (B) perform_action
A or B
If the action to be performed is a leaf node, we can use this form:
if (A) perform_action
if (B) perform_action
In 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 performed is to test against another
firewall rule (not a leaf node), we can use this form:
if (any) Group
if (!A) ->
if (!B) Exit group
The "Group" and "Exit group" actions allow 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".
Terminating and Multiple Actions
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_action1
if (B) perform_action2
If 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.
Rule Ordering and Dynamic State
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 a separate table for dynamic (added in response to the network) versus stable (added by the user) firewall rules. The structure of the dynamic table 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.
if (include == trigger_table) perform_action
Would test if our packet is from an address in the triggered IP
address table. We might load the table based on suspicious activity
if (destPort == telnet) trigger
An 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 rule. 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.
Stateful Packet Inspection
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.
Hardware MAC Address Filtering
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 its 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 (bits/second) available to matching TCP connections.
The purpose of Bandwidth Allocation is to manage network resources to 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.
A precondition for being able to apply bandwidth management is to first classify traffic so you can limit the specific data flows of interest. IPNetSentryXs hierarchical filter rules are designed with this flexibility in mind.
The purpose of a firewall is to enforce a network access policy, but defining an appropriate access policy often depends on actual usage patterns which can change over time. Traffic Discovery allows you to examine how your network is being used, see what actually happens as you access various services, and audit for undesirable activity. With Traffic Discovery, you can answer questions like what are the top 25 remote sites, network services, or protocols used as a percentage of total bandwidth. If network problems occur, Traffic Discovery allows you to see what happened so you can take corrective action.
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 day
- Day of week
- Date and time
- Parent idle time
- Parent match count
- Parent byte count
These 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.
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
Testing and User Confidence
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.
- 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.
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.