Contents:
Part Six:
Setting up Internet Filters
Internet filters are used in conjunction with dial on demand. These
are upgradable features not available on the basic Communications Server.
To use filters, you must enable dial on demand. It is necessary to purchase
an 'Activation Key' from your distributor or Stallion Technologies.
Then use the web configuration utility to perform the upgrade (via Setup
> Server > Server Name, Password & Identification.)
The INTERNET FILTER command allows you to defined packet filtering
rules which help to establish, maintain and disconnection Dial
On Demand (DOD) network connections. This section outlines the following
topics:
- Overview
- Approach A
- Approach B
- Entering Filter Rules
- Filter Rule Syntax
Overview
Filters are used to control Dial-On-Demand (DOD) connections.
They determine when to establish a connection, what kinds of network
traffic maintain the connection, and how long a connection will
remain active if there is no suitable network activity.
Creating filters requires in-depth network protocol knowledge, however,
by following some simple rules and using examples, it is possible
to create some effective filter rules for most applications.
First, you must choose which approach to filtering to use.
1. Reject some things, accept everything else.
You would choose this method when you are not too concerned about security.
If you have a DOD connection, but you do not want a particular network
protocol to force a connection, you would choose this approach.
2. Accept some things, reject everything else.
If security is of major concern then you will choose this approach.
This allows you tight control over what traffic is allowed to cross
the DOD network.
One of these methods will generally suit most applications. While it
is possible to combine aspects of both methods, it is not recommended.
Syntax. A filter rule is made up of several parts, some
are required and some are not. A filter rules looks something
like:
<protocol> <action>
[ttl] [value specific rules]
The protocol for a rule is required and must appear first in the rule.
Currently the protocol may be "tcp", "udp" or "icmp".
The next important part of the rule is the action. The three
actions are "accept", "reject" and "ignore".
- Accept means that the protocol/packet specified by this rule
is allowed to cross the connection. It is usually accompanied by the
"ttl" field (Time to Live), which specifies how much longer
the connection will remain active after seeing this packet of information.
If it is non-zero, then it instruct the DOD service to initiate
the connection.
- Reject means the protocol/packet is not allowed to cross
the connection, and, where possible a protocol error will be reported.
- Ignore means the protocol/packet will be discarded without
any warnings.
The value-specific rules are more complicated. Some of this will
be shown in the examples below. The full syntax of all rules will
be provided at the end of this tutorial. The DOD service looks at each
rule until one matches the protocol/packet that it is checking,
and then takes the action given by that rule.
Approach A
Let us assume we have a DOD connection to another site, but we do not
want any routing packets (RIP) to start the connection. We will
keep the connection up for one minute, once initiated. Although
we do not let RIP packets start a connection, we do allow them
to cross the link once it is up. Our rules might look as follows:
1. udp udp_sport=520 udp_dport=520 accept 0
2. tcp accept 60
3. icmp accept 60
4. udp accept 60
Rules 2, 3 and 4 accept all the network protocols currently supported
on a DOD connection. The 60 in these rules is the TTL for packets
that match this rule. Rule 1 prevents RIP from bringing the connection
up. RIP operates using UDP packets on port 520. So we match
those ports. We accept the packet, which means it is allowed to
cross the link, but we give the connection a TTL of 0, which means
that these packets will not start a connection or add to the life of
a connection.
So for this approach, rule 1 is the "Reject Some things" rule,
while rules 2, 3 and 4 are the "Accept everything else" rules.
Here are some more examples of rules that you might use in this approach.
udp accept 0
Allow UDP, but it never starts or maintains a link.
udp ignore
Prevent UDP totally.
tcp tcp_dport=telnet reject
Prevent telnet connections in either direction
tcp tcp_dport=smtp ignore
SMTP requests are ignored.
Some more advanced examples:
tcp ip_src&255.255.255.0=10.1.2.0 tcp_dport=telnet reject
Do not allow telnet requests from our network to cross the link.
tcp rx ip_src&255.255.255.0=10.1.2.0 ignore
Prevent potentially spoofed TCP packets from entering our network.
We do this by checking their source address against our network address
with a network mask.
Approach B
If you are more concerned about security over a link, then this
is the best approach to use. It allows you to be very specific
about what protcols/packets are allowed to cross the link. This
makes your filters much more complex as you must explicitly state everything
that you want to allow. It is very easy to create a crippled network
connection that doesn't operate correctly using this approach.
The following example only allows telnet connections on the link.
All other protocols/packets are rejected.
1. tcp tcp_dport=telnet accept 60
2. tcp tcp_sport=telnet accept 60
3. tcp reject
4. icmp reject
5. udp reject
Rules 1 and 2 are both required, otherwise data cannot flow from
the telnet server to the telnet client and vice versa. We could
make this filter more effective by only allowing outgoing telnet connections.
To do this we add our network address information to rules 1 and 2:
1 tcp tcp_dport=telnet
ip_src&255.255.255.0=10.1.2.0 accept
60
2 tcp tcp_sport=telnet
ip_dst&255.255.255.0=10.1.2.0 accept
60
Rule 1 allows traffic to a telnet server, from a machine on our
network. Rule 2 allows traffic from a telnet server, to a machine
on our network. To make this even more secure we could add the spoofing
Rule from the earlier approach.
Entering Filter Rules
A an example of how to enter your filter rules, we will create
a filter that uses the rules from approach A. These are the commands
required to create a filter call "test1" which uses those rules.
CHANGE INTERNET FILTER
test1 ENTRY 1 RULE "udp udp_sport=520
udp_dport=520 accept
0"
CHANGE INTERNET FILTER
test1 ENTRY 2 RULE "tcp accept 60"
CHANGE INTERNET FILTER
test1 ENTRY 3 RULE "icmp accept 60"
CHANGE INTERNET FILTER
test1 ENTRY 4 RULE "udp accept 60"
Once we have created a filter, we can delete, change or insert
new rules at any point. Suppose we wanted to increase the time
from 60 seconds to 120, and add a new rule between rules 1 &
2:
CHANGE INTERNET FILTER
test1 ENTRY 2 RULE "tcp accept 120"
CHANGE INTERNET FILTER
test1 ENTRY 3 RULE "icmp accept 120"
CHANGE INTERNET FILTER
test1 ENTRY 4 RULE "udp accept 120"
CHANGE INTERNET FILTER
test1 INSERT 2 RULE "tcp tcp_dport=telnet reject"
The order here is important, as inserting the new rule first
would change the numbering of rules 2, 3 and 4. Our new rules
are:
1. udp udp_sport=520 udp_dport=520 accept 0
2. tcp tcp_dport=telnet reject
3. tcp accept 120
4. icmp accept 120
5. udp accept 120
You may have a many filters and rules as the storage space in the server
allows. You may check how much space is available with the:
SHOW SERVER STATUS
Filter Rule Syntax
A "filter_rule" is basically free form text that adheres to the following
grammar. Filters are applied in order starting from line 1. The
first filter to match is the rule that is used. For this reason
you would place specific rules first and more general rules later. Order
is important.
filter-rule
::= protocol directive-list
protocol ::= number
|
protocol-name
protocol-name ::= "tcp"
|
"udp"
|
"icmp"
directive-list ::= directive
|
directive " " directive-list
directive ::= number
# keep link up at least this
long
|
boolean
|
keyword
keyword ::= "accept"
# by default this is set,
accept packet
|
"reject" # reject packet,
NOT-REACHABLE error
|
"ignore" # silently ignore packet
boolean ::= expr bool-op expr
|
expr
bool-op ::= ">"
|
"<"
|
"="
|
">="
|
"<="
|
"!="
expr ::=
var-const expr-op var-const
|
var-const
expr-op ::= "&"
# bit wise and
|
"|"
# bit wise or
var-const ::= number
|
named-value
|
unnamed-value
unnamed-value ::= "c[" number "]"
|
"s[" number "]"
|
"l[" number "]"
|
"cd[" number "]"
|
"sd[" number "]"
|
"ld[" number "]"
named-value ::=
#
# These names are used to refer to fields of interest in the
# current network packet.
#
"ip_len" # the ip packet len
|
"ip_src" # the ip source address
|
"ip_dst" # the ip destination address
|
"tcp_sport" # the tcp source port
|
"tcp_dport" # the tcp destination port
|
"tcp_flags" # tcp bit flags (ie., ack,
push)
|
"udp_len" # udp packet len
|
"udp_sport" # udp source port
|
"udp_dport" # udp destination port
|
"icmp_type" # icmp packet type
|
"icmp_code" # icmp packet code
#
# useful tcp/ip port numbers (-dgm is used for udp ports)
# /etc/services under most unix platforms lists these names.
#
|
"echo" # TCP/UDP echo port
(7)
|
"telnet" # TCP telnet port
(23)
|
"ftp" # TCP ftp port
(21)
|
"smtp" # TCP SMTP port
(25)
|
"nameserver" # TCP nameserver port
(42)
|
"tftp" # UDP TFTP port
(69)
|
"nb-ns" # TCP/UDP netbios name
service (137)
|
"nb-dgm" # TCP/UDP netbios datagrams
(138)
|
"nb-ssn" # TCP netbios session
(139)
|
"smnp" # UDP SNMP port
(161)
|
"smnp-trap" # UDP SNMP trap port
(162)
|
"exec" # TCP unix exec
(512)
|
"login" # TCP unix login
(513)
|
"shell" # TCP unix cmd
(514)
|
"route" # UDP RIP port
(540)
#
# TCP flag constants for use with tcp_flags above, these
are
# bit fields and should be tested as "tcp_flags&fin",
# or "tcp_flags&fin=fin".
#
|
"fin"
|
"syn"
|
"rst"
|
"push"
|
"ack"
|
"urg"
#
# Direction Variables (useful in preventing spoofing)
#
|
"rx" # packet just received
on link
|
"tx" # about to transmit
packet on link
number ::= decimal
|
hexidecimal
decimal ::= digit decimal
|
digit
hexidecimal ::= "0x" hexdigits
hexdigits ::= hexdigit hexdigits
|
hexdigit
digit ::= "0"
|
"1"
|
"2"
|
"3"
|
"4"
|
"5"
|
"6"
|
"7"
|
"8"
|
"9"
hexdigit ::= digit
|
"a"
|
"b"
|
"c"
|
"d"
|
"e"
|
"f"
The unamed-value is equivalent to:
c[10]
is the same as ((unsigned
char *)
address-of-header)[10]
s[10]
is the same as ntohs((unsigned
short *)
address-of-header)[10]
l[10]
is the same as
ntohl((unsigned long *)
address-of-header)[10]
cd[10]
is the same as ((unsigned
char *)
address-of-data)[10]
sd[10]
is the same as ntohs((unsigned
short *)
address-of-data)[10]
ld[10]
is the same as ntohl((unsigned
long *)
address-of-data)[10]
It is important to note the network to host conversions here,
as they may affect some custom filtering. For our existing hardware
combinations, network order is the same as host order, so it is
not an issue yet.
Go to
Top of Page
