2005-05-20 00:17:37 +02:00
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
2003-12-30 02:19:52 +01:00
|
|
|
<html>
|
2005-10-12 00:05:30 +02:00
|
|
|
<head>
|
|
|
|
|
<meta name="generator"
|
|
|
|
|
content="HTML Tidy for Linux (vers 1st April 2002), see www.w3.org">
|
|
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|
|
|
|
<title>Shorewall News</title>
|
|
|
|
|
</head>
|
|
|
|
|
<body>
|
|
|
|
|
<h1 style="text-align: left;">Shorewall News and Announcements<br>
|
|
|
|
|
</h1>
|
|
|
|
|
<span style="font-weight: bold;">Tom Eastep<br>
|
|
|
|
|
<br>
|
|
|
|
|
</span>Copyright © 2001-2005 Thomas M. Eastep<br>
|
|
|
|
|
<p>Permission is granted to copy, distribute and/or modify this
|
|
|
|
|
document under the terms of the GNU Free Documentation License, Version
|
|
|
|
|
1.2 or any later version published by the Free Software Foundation;
|
|
|
|
|
with no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
|
|
|
|
Texts. A copy of the license is included in the section entitled “<span
|
|
|
|
|
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
|
|
|
|
|
Documentation License</a></span>”.<br>
|
|
|
|
|
</p>
|
2005-11-05 17:43:05 +01:00
|
|
|
<p>2005-11-11<br>
|
2005-10-12 00:05:30 +02:00
|
|
|
</p>
|
2005-11-05 17:43:05 +01:00
|
|
|
<hr style="width: 100%; height: 2px;"> <span style="font-weight: bold;">11/11/2005
|
|
|
|
|
Shorewall 3.0.0</span><br>
|
|
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|
|
|
|
<meta name="Generator" content="Kate, the KDE Advanced Text Editor">
|
|
|
|
|
<pre>New Features in Shorewall 3.0.0<br><br>1) Error and warning messages are made easier to spot by using
|
|
|
|
|
capitalization (e.g., ERROR: and WARNING:).<br><br>2) A new option 'critical' has been added to
|
|
|
|
|
/etc/shorewall/routestopped. This option can be used to enable
|
|
|
|
|
communication with a host or set of hosts during the entire
|
|
|
|
|
"shorewall [re]start/stop" process. Listing a host with this option
|
|
|
|
|
differs from listing it without the option in several ways:
|
|
|
|
|
|
|
|
|
|
a) The option only affect traffic between the listed host(s) and the
|
|
|
|
|
firewall itself.
|
|
|
|
|
|
|
|
|
|
b) If there are any entries with 'critical', the firewall
|
|
|
|
|
will be completely opened briefly during start, restart and stop but
|
|
|
|
|
there will be no chance of any packets to/from the listed host(s)
|
|
|
|
|
being dropped or rejected.
|
|
|
|
|
|
|
|
|
|
Possible uses for this option are:
|
|
|
|
|
|
|
|
|
|
a) Root file system is NFS mounted. You will want to list the NFS server
|
|
|
|
|
in the 'critical' option.
|
|
|
|
|
|
|
|
|
|
b) You are running Shorewall in a Crossbeam environment
|
|
|
|
|
(www.crossbeam.com). You will want to list the Crossbeam interface
|
|
|
|
|
in this option
|
|
|
|
|
|
|
|
|
|
3) A new 'macro' feature has been added.
|
|
|
|
|
|
|
|
|
|
Macros are very similar to actions and can be used in similar
|
|
|
|
|
ways. The differences between actions and macros are as follows:
|
|
|
|
|
|
|
|
|
|
a) An action creates a separate chain with the same name as the
|
|
|
|
|
action (when logging is specified on the invocation of an action,
|
|
|
|
|
a chain beginning with "%" followed by the name of the action and
|
|
|
|
|
possibly followed by a number is created). When a macro is
|
|
|
|
|
invoked, it is expanded in-line and no new chain is created.
|
|
|
|
|
|
|
|
|
|
b) An action may be specified as the default action for a policy;
|
|
|
|
|
macros cannot be specified this way.
|
|
|
|
|
|
|
|
|
|
c) Actions must be listed in either /usr/share/shorewall/actions.std
|
|
|
|
|
or in /etc/shorewall/actions. Macros are defined simply by
|
|
|
|
|
placing their definition file in the CONFIG_PATH.
|
|
|
|
|
|
|
|
|
|
d) Actions are defined in a file with a name beginning with
|
|
|
|
|
"action." and followed by the name of the action. Macro files are
|
|
|
|
|
defined in a file with a name beginning with "macro.".
|
|
|
|
|
|
|
|
|
|
e) Actions may invoke other actions. Macros may not directly invoke
|
|
|
|
|
other macros although they may invoke other macros indirectly
|
|
|
|
|
through an action.
|
|
|
|
|
|
|
|
|
|
f) DNAT[-] and REDIRECT[-] rules may not appear in an action. They
|
|
|
|
|
are allowed in a macro with the restriction that the a macro
|
|
|
|
|
containing one of these rules may not be invoked from an action.
|
|
|
|
|
|
|
|
|
|
g) The values specified in the various columns when you invoke a
|
|
|
|
|
macro are substituted in the corresponding column in each rule in
|
|
|
|
|
the macro. The first three columns get special treatment:
|
|
|
|
|
|
|
|
|
|
ACTION If you code PARAM as the action in a macro then
|
|
|
|
|
when you invoke the macro, you can include the
|
|
|
|
|
name of the macro followed by a slash ("/") and
|
|
|
|
|
an ACTION (either built-in or user-defined. All
|
|
|
|
|
instances of PARAM in the body of the macro will be
|
|
|
|
|
replaced with the ACTION.
|
|
|
|
|
|
|
|
|
|
Any logging applied when the macro is invoked is
|
|
|
|
|
applied following the same rules as for actions.
|
|
|
|
|
|
|
|
|
|
SOURCE and
|
|
|
|
|
DEST If the rule in the macro file specifies a value and
|
|
|
|
|
the invocation of the rule also specifies a value then
|
|
|
|
|
the value in the invocation is appended to the value
|
|
|
|
|
in the rule using ":" as a separator.
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/macro.SMTP
|
|
|
|
|
|
|
|
|
|
PARAM - loc tcp 25
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
|
|
|
|
|
|
SMTP/DNAT:info net 192.168.1.5
|
|
|
|
|
|
|
|
|
|
Would be equivalent to the following in the rules file:
|
|
|
|
|
|
|
|
|
|
DNAT:info net loc:192.168.1.5 tcp 25
|
|
|
|
|
|
|
|
|
|
Rest Any value in the invocation replaces the value in the
|
|
|
|
|
rule in the macro.
|
|
|
|
|
|
|
|
|
|
One additional restriction applies to the mixing of macros and
|
|
|
|
|
actions. Macros that are invoked from actions cannot themselves
|
|
|
|
|
invoke other actions.
|
|
|
|
|
|
|
|
|
|
4) If you have 'make' installed on your firewall, then when you use
|
|
|
|
|
the '-f' option to 'shorewall start' (as happens when you reboot),
|
|
|
|
|
if your /etc/shorewall/ directory contains files that were modified
|
|
|
|
|
after Shorewall was last restarted then Shorewall is started using
|
|
|
|
|
the config files rather than using the saved configuration.
|
|
|
|
|
|
|
|
|
|
5) The 'arp_ignore' option has been added to /etc/shorewall/interfaces
|
|
|
|
|
entries. This option sets
|
|
|
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_ignore. By default, the
|
|
|
|
|
option sets the value to 1. You can also write arp_ignore=<value>
|
|
|
|
|
where value is one of the following:
|
|
|
|
|
|
|
|
|
|
1 - reply only if the target IP address is local address
|
|
|
|
|
configured on the incoming interface
|
|
|
|
|
|
|
|
|
|
2 - reply only if the target IP address is local address
|
|
|
|
|
configured on the incoming interface and both with the sender's
|
|
|
|
|
IP address are part from same subnet on this interface
|
|
|
|
|
|
|
|
|
|
3 - do not reply for local addresses configured with scope
|
|
|
|
|
host, only resolutions for global and link addresses are
|
|
|
|
|
replied
|
|
|
|
|
|
|
|
|
|
4-7 - reserved
|
|
|
|
|
|
|
|
|
|
8 - do not reply for all local addresses
|
|
|
|
|
|
|
|
|
|
WARNING -- DO NOT SPECIFY arp_ignore FOR ANY INTERFACE INVOLVED IN
|
|
|
|
|
PROXY ARP.
|
|
|
|
|
|
|
|
|
|
6) In /etc/shorewall/rules, "all+" in the SOURCE or DEST column works
|
|
|
|
|
like "all" but also includes intrazone traffic. So the rule:
|
|
|
|
|
|
|
|
|
|
ACCEPT loc all+ tcp 22
|
|
|
|
|
|
|
|
|
|
would allow SSH traffic from loc->loc whereas
|
|
|
|
|
|
|
|
|
|
ACCEPT loc all tcp 22
|
|
|
|
|
|
|
|
|
|
does not.
|
|
|
|
|
|
|
|
|
|
7) A new FASTACCEPT option has been added to shorewall.conf.
|
|
|
|
|
|
|
|
|
|
Normally, Shorewall defers accepting ESTABLISHED/RELATED packets
|
|
|
|
|
until these packets reach the chain in which the original connection
|
|
|
|
|
was accepted. So for packets going from the 'loc' zone to the 'net'
|
|
|
|
|
zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net'
|
|
|
|
|
chain.
|
|
|
|
|
|
|
|
|
|
If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are
|
|
|
|
|
accepted early in the INPUT, FORWARD and OUTPUT chains. If you set
|
|
|
|
|
FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or
|
|
|
|
|
RELATED sections of /etc/shorewall/rules.
|
|
|
|
|
|
|
|
|
|
8) Shorewall now generates an error if the 'norfc1918' option is
|
|
|
|
|
specified for an interface with an RFC 1918 address.
|
|
|
|
|
|
|
|
|
|
9) You may now specify "!" followed by a list of addresses in the
|
|
|
|
|
SOURCE and DEST columns of entries in /etc/shorewall/rules,
|
|
|
|
|
/etc/shorewall/tcrules and in action files and Shorewall will
|
|
|
|
|
generate the rule that you expect.
|
|
|
|
|
|
|
|
|
|
Example 1 (/etc/shorewall/rules):
|
|
|
|
|
|
|
|
|
|
#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
|
|
|
ACCEPT loc:!192.168.1.0/24,10.0.0.0/8 net tcp 80
|
|
|
|
|
|
|
|
|
|
That rule would allow loc->net HTTP access except for the local
|
|
|
|
|
networks 192.168.1.0/24 and 10.0.0.0/8.
|
|
|
|
|
|
|
|
|
|
Example 2 (/etc/shorewall/rules):
|
|
|
|
|
|
|
|
|
|
#ACTION SOURCE DEST PROTO DEST PORT(S)
|
|
|
|
|
ACCEPT loc:10.0.0.0/24!10.0.0.4,10.0.0.22 \
|
|
|
|
|
net tcp 80
|
|
|
|
|
|
|
|
|
|
That rule would allow loc->net HTTP access from the local
|
|
|
|
|
network 10.0.0.0/24 except for hosts 10.0.0.4 and 10.0.0.22.
|
|
|
|
|
|
|
|
|
|
10) Tunnel types "openvpnserver" and "openvpnclient" have been added
|
|
|
|
|
to reflect the introduction of client and server OpenVPN
|
|
|
|
|
configurations in OpenVPN 2.0.
|
|
|
|
|
|
|
|
|
|
11) The COMMAND variable is now set to 'restore' in restore
|
|
|
|
|
scripts. The value of this variable is sometimes of interest to
|
|
|
|
|
programmers providing custom /etc/shorewall/tcstart scripts.
|
|
|
|
|
|
|
|
|
|
12) Previously, if you defined any intra-zone rule(s) then any traffic
|
|
|
|
|
not matching the rule(s) was subject to normal policies (which
|
|
|
|
|
usually turned out to involve the all->all REJECT policy). Now, the
|
|
|
|
|
intra-zone ACCEPT policy will still be in effect in the presence of
|
|
|
|
|
intra-zone rules. That policy can still be overridden by an
|
|
|
|
|
explicit policy in your /etc/shorewall/policy file.
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
|
|
|
|
|
|
DNAT loc:!192.168.1.4 loc:192.168.1.4:3128 tcp 80
|
|
|
|
|
|
|
|
|
|
Any other loc->loc traffic will still be accepted. If you want to
|
|
|
|
|
also log that other loc->loc traffic at the info log level then
|
|
|
|
|
insert this into /etc/shorewall/policy:
|
|
|
|
|
|
|
|
|
|
#SOURCE DEST POLICY LOG LEVEL
|
|
|
|
|
loc loc ACCEPT info
|
|
|
|
|
|
|
|
|
|
13) Prior to Shorewall 2.5.3, the rules file only controlled packets in
|
|
|
|
|
the Netfilter states NEW and INVALID. Beginning with this release,
|
|
|
|
|
the rules file can also deal with packets in the ESTABLISHED and
|
|
|
|
|
RELATED states.
|
|
|
|
|
|
|
|
|
|
The /etc/shorewall/rules file may now be divided into
|
|
|
|
|
"sections". Each section is introduced by a line that begins with
|
|
|
|
|
the keyword SECTION followed by the section name. Sections
|
|
|
|
|
are as listed below and must appear in the order shown.
|
|
|
|
|
|
|
|
|
|
ESTABLISHED
|
|
|
|
|
|
|
|
|
|
Rules in this section apply to packets in the ESTABLISHED
|
|
|
|
|
state.
|
|
|
|
|
|
|
|
|
|
RELATED
|
|
|
|
|
|
|
|
|
|
Rules in this section apply to packets in the RELATED state.
|
|
|
|
|
|
|
|
|
|
NEW
|
|
|
|
|
|
|
|
|
|
Rules in this section apply to packets in the NEW and INVALID
|
|
|
|
|
states.
|
|
|
|
|
|
|
|
|
|
Rules in the ESTABLISHED and RELATED sections are limited to the
|
|
|
|
|
following ACTIONs:
|
|
|
|
|
|
|
|
|
|
ACCEPT, DROP, REJECT, QUEUE, LOG and User-defined actions.
|
|
|
|
|
|
|
|
|
|
Macros may be used in these sections provided that they expand to
|
|
|
|
|
only these ACTIONs.
|
|
|
|
|
|
|
|
|
|
At the end of the ESTABLISHED and RELATED sections, there is an
|
|
|
|
|
implicit "ALLOW all all all" rule.
|
|
|
|
|
|
|
|
|
|
RESTRICTION: If you specify FASTACCEPT=Yes in
|
|
|
|
|
/etc/shorewall.shorewall.conf then the ESTABLISHED and RELATED
|
|
|
|
|
sections must be empty.
|
|
|
|
|
|
|
|
|
|
14) The value 'ipp2p' is once again allowed in the PROTO column of
|
|
|
|
|
the rules file. It is recommended that rules specifying 'ipp2p'
|
|
|
|
|
only be included in the ESTABLISHED section of the file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
15) Shorewall actions lack a generalized way to pass parameters to an
|
|
|
|
|
extension script associated with an action. To work around this
|
|
|
|
|
lack, some users have used the log tag as a parameter. This works
|
|
|
|
|
but requires that a log level other than 'none' be specified when
|
|
|
|
|
the action is invoked. Beginning with this release, you can invoke
|
|
|
|
|
an action with 'none'.
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
#ACTION SOURCE DEST
|
|
|
|
|
A:none:these,are,parameters $FW net
|
|
|
|
|
|
|
|
|
|
When /etc/shorewall/A is invoked, the LEVEL variable will be empty
|
|
|
|
|
but the TAG variable will contain "these,are,parameters" which
|
|
|
|
|
can be easily parsed to isolate "these", "are" and "parameters":
|
|
|
|
|
|
|
|
|
|
ifs=$IFS
|
|
|
|
|
IFS=,
|
|
|
|
|
set -- $TAG
|
|
|
|
|
IFS=$ifs
|
|
|
|
|
|
|
|
|
|
Now, $1 = these, $2 = are and $3 = parameters
|
|
|
|
|
|
|
|
|
|
16) The "shorewall check" command now checks the /etc/shorewall/masq,
|
|
|
|
|
/etc/shorewall/blacklist, /etc/shorewall/proxyarp,
|
|
|
|
|
/etc/shorewall/nat and /etc/shorewall/providers files.
|
|
|
|
|
|
|
|
|
|
17) Arne Bernin's "tc4shorewall" package has been integrated into
|
|
|
|
|
Shorewall.
|
|
|
|
|
|
|
|
|
|
See: http://www.shorewall.net/3.0/traffic_shaping.htm for details.
|
|
|
|
|
|
|
|
|
|
Thanks, Arne!
|
|
|
|
|
|
|
|
|
|
18) When /usr/share/shorewall/functions is loaded it now sets
|
|
|
|
|
|
|
|
|
|
SHOREWALL_LIBRARY=Loaded
|
|
|
|
|
|
|
|
|
|
Application code such as /etc/shorewall/tcstart may test that
|
|
|
|
|
variable to determine if the library has been loaded into the
|
|
|
|
|
current shell process.
|
|
|
|
|
|
|
|
|
|
19) The install.sh script now does a much cleaner job of backing up the
|
|
|
|
|
current installation. It copies the directories /etc/shorewall,
|
|
|
|
|
/usr/share/shorewall and /var/lib/shorewall to a directory of the
|
|
|
|
|
same name with "-$VERSION.bkout" appended. The init script and
|
|
|
|
|
/sbin/shorewall are backed up to the /usr/share/shorewall and
|
|
|
|
|
/var/lib/shorewall directories respectively. This makes it very
|
|
|
|
|
simple to remove the backups:
|
|
|
|
|
|
|
|
|
|
rm -rf /etc/shorewall-*.bkout
|
|
|
|
|
rm -rf /usr/share/shorewall-*.bkout
|
|
|
|
|
rm -rf /var/lib/shorewall-*.bkout
|
|
|
|
|
|
|
|
|
|
20) A new '-n' option has been added to the "start", "restart",
|
|
|
|
|
"restore", "stop" and "try" commands. This option instructs
|
|
|
|
|
Shorewall to not alter the routing in any way.
|
|
|
|
|
|
|
|
|
|
This option is useful when you have a multi-ISP environment because
|
|
|
|
|
it prevents the route cache from being flushed which preserves the
|
|
|
|
|
mapping of end-point address pairs to routes.
|
|
|
|
|
|
|
|
|
|
21) The output of "shorewall dump" now includes a capabilities report
|
|
|
|
|
such as the one produced by "shorewall show capabilities".
|
|
|
|
|
|
|
|
|
|
22) The "plain" zone type has been replaced by "ipv4". The types
|
|
|
|
|
"IPv4" and "IPV4" are synonyms for "ipv4". In addition, "IPSEC",
|
|
|
|
|
"ipsec4" and "IPSEC4" are recognized synonyms for "ipsec".
|
|
|
|
|
|
|
|
|
|
23) The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been
|
|
|
|
|
removed as have the 'newnotsyn' options in /etc/shorewall/interfaces
|
|
|
|
|
and /etc/shorewall/hosts. See the Migration Considerations for
|
|
|
|
|
instructions if you wish to block "new-not-syn" TCP packets.
|
|
|
|
|
|
|
|
|
|
24) The "shorewall show zones" command now displays the zone type. You
|
|
|
|
|
must have restarted Shorewall using this release before this feature
|
|
|
|
|
will work correctly.
|
|
|
|
|
|
|
|
|
|
25) The multi-ISP code now requires that that you set MARK_IN_FORWARD_CHAIN=Yes
|
|
|
|
|
in shorewall.conf. This is done to ensure that "shorewall refresh" will
|
|
|
|
|
work correctly.
|
|
|
|
|
|
|
|
|
|
26) Shorewall now supports UDP IPP2P matching. In addition to the "ipp2p"
|
|
|
|
|
keyword in the PROTOCOL column of the relevant files, the following
|
|
|
|
|
values may be specified:
|
|
|
|
|
|
|
|
|
|
ipp2p:tcp Equivalent to ipp2p and matches TCP traffic
|
|
|
|
|
only.
|
|
|
|
|
ipp2p:udp Matches UDP traffic.
|
|
|
|
|
ipp2p:all Matches both UDP and TCP traffic. You may
|
|
|
|
|
not specify a SOURCE PORT with this PROTOCOL.
|
|
|
|
|
|
|
|
|
|
27) Normally MAC verification triggered by the 'maclist' interface and host
|
|
|
|
|
options is done out of the INPUT and FORWARD chains of the filter table.
|
|
|
|
|
Users have reported that under some circumstances, MAC verification is
|
|
|
|
|
failing for forwarded packets when the packets are being forwarded out
|
|
|
|
|
of a bridge.
|
|
|
|
|
|
|
|
|
|
To work around this problem, a MACLIST_TABLE option has been added to
|
|
|
|
|
shorewall.conf. The default value is MACLIST_TABLE=filter which results
|
|
|
|
|
in the current behavior. If MACLIST_TABLE=mangle then filtering will
|
|
|
|
|
take place out of the PREROUTING chain of the mangle table. Because
|
|
|
|
|
the REJECT target may not be used in the PREROUTING chain, the settings
|
|
|
|
|
MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.
|
|
|
|
|
|
|
|
|
|
28) The sample configurations are now packaged with the product. They are
|
|
|
|
|
in the Samples directory on the tarball and are in the RPM they are
|
|
|
|
|
in the Samples sub-directory of the Shorewall documentation
|
|
|
|
|
directory.
|
|
|
|
|
</pre>
|
|
|
|
|
<span style="font-weight: bold;">10/31/2005
|
|
|
|
|
Shorewall 2.4.6<br>
|
|
|
|
|
<br>
|
|
|
|
|
</span>Problems Corrected in 2.4.6<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>"shorewall refresh" would fail if there were entries in
|
|
|
|
|
/etc/shorewall/tcrules with non-empty USER/GROUP or TEST columns.</li>
|
|
|
|
|
<li>An unprintable character in a comment caused /sbin/shorewall to
|
|
|
|
|
fail when used with a light-weight shell like 'dash'.</li>
|
|
|
|
|
<li>When using some flavors of 'ash', certain /sbin/shorewall
|
|
|
|
|
commands produced 'ipset: not found' messages.</li>
|
|
|
|
|
<li>Support for OpenVPN TCP tunnels was released in Shorewall 2.2.0
|
|
|
|
|
but the implementation was incomplete. It has now been completed and is
|
|
|
|
|
documented in the /etc/shorewall/tunnels file.</li>
|
|
|
|
|
<li>The test that Shorewall uses to detect the availability of the
|
|
|
|
|
owner match capability has been changed to avoid the generation of
|
|
|
|
|
ipt_owner messages under kernel 2.6.14.</li>
|
|
|
|
|
</ol>
|
|
|
|
|
New Features in 2.4.6<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>Normally MAC verification triggered by the 'maclist' interface
|
|
|
|
|
and host options is done out of the INPUT and FORWARD chains of the
|
|
|
|
|
filter table. Users have reported that under some circulstances, MAC
|
|
|
|
|
verification is failing for forwarded packets when the packets are
|
|
|
|
|
being forwarded out of a bridge.<br>
|
|
|
|
|
<br>
|
|
|
|
|
To work around this problem, a MACLIST_TABLE option has been added to
|
|
|
|
|
shorewall.conf. The default value is MACLIST_TABLE=filter which results
|
|
|
|
|
in the current behavior. If MACLIST_TABLE=mangle then filtering will
|
|
|
|
|
take place out of the PREROUTING chain of the mangle table. Because the
|
|
|
|
|
REJECT target may not be used in the PREROUTING chain, the settings
|
|
|
|
|
MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.</li>
|
|
|
|
|
<li>A "dump" command has been added to /sbin/shorewall for
|
|
|
|
|
compatibility with Shorewall 3.0. In 2.4.6, the "dump" command provides
|
|
|
|
|
the same output as the "status".<br>
|
|
|
|
|
</li>
|
|
|
|
|
</ol>
|
|
|
|
|
<span style="font-weight: bold;">10/05/2005
|
2005-10-12 00:05:30 +02:00
|
|
|
Shorewall 2.4.5<br>
|
|
|
|
|
</span>
|
|
|
|
|
<br>
|
|
|
|
|
Problems Corrected in 2.4.5<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>In previous versions, when the command is 'start', 'restart' or
|
|
|
|
|
'stop' then OUTPUT traffic to hosts listed in
|
|
|
|
|
/etc/shorewall/routestopped is not enabled if ADMINISABSENTMINDED=Yes.
|
|
|
|
|
That traffic is now enabled independent of the setting of
|
|
|
|
|
ADMINISABSENTMINDED.</li>
|
|
|
|
|
<li>Although it was documented that icmp types could be used in the
|
|
|
|
|
tcrules file, the code did not support it. Thanks to Jorge Molina, that
|
|
|
|
|
problem is now corrected.</li>
|
|
|
|
|
<li>In a multi-ISP configuration, fwmark routing rules now have a
|
|
|
|
|
higher priority than source IP rules. This allows entries in tcrules to
|
|
|
|
|
be more effective in controlling routing.</li>
|
|
|
|
|
<li>Previously, not all of the mangle chains were flushed during
|
|
|
|
|
"shorewall restart".</li>
|
|
|
|
|
</ol>
|
|
|
|
|
<span style="font-weight: bold;">09/12/2005 Shorewall 2.4.4<br>
|
|
|
|
|
</span><br>
|
|
|
|
|
Problems Corrected<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>An incorrect comment in the /etc/shorewall/proxyarp file has been
|
|
|
|
|
removed.</li>
|
|
|
|
|
<li>The message generated when a duplicate policy has been entered is
|
|
|
|
|
now more informative. Previously, only the POLICY column contents
|
|
|
|
|
appeared in the message. Now the SOURCE, DEST and POLICY column
|
|
|
|
|
contents are shown.</li>
|
|
|
|
|
<li>Shorewall now clears the Netfilter "raw" table during "shorewall
|
|
|
|
|
[re]start", "shorewall stop" and "shorewall clear" processing.</li>
|
|
|
|
|
</ol>
|
|
|
|
|
New Features<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>Tunnel types "openvpnserver" and "openvpnclient" have been added
|
|
|
|
|
to reflect the introduction of client and server OpenVPN configurations
|
|
|
|
|
in OpenVPN 2.0.</li>
|
|
|
|
|
<li>The COMMAND variable is now set to 'restore' in restore scripts.
|
|
|
|
|
The value of this variable is sometimes of interest to programmers
|
|
|
|
|
providing custom /etc/shorewall/tcstart scripts.<br>
|
|
|
|
|
</li>
|
|
|
|
|
</ol>
|
|
|
|
|
<span style="font-weight: bold;">08/16/2005 Shorewall 2.4.3<br>
|
|
|
|
|
</span><br>
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>Shorewall is no longer dependent on the 'which' utility.</li>
|
|
|
|
|
<li>The 'shorewall add' command failed if there existed a zone in the
|
|
|
|
|
configuration that specified the 'ipsec' option in /etc/shorewall/hosts.</li>
|
|
|
|
|
<li>Shorewall is no longer dependent on /bin/echo.</li>
|
|
|
|
|
<li>A CLASSIFY rule with $FW in the SOURCE column (tcrules) no
|
|
|
|
|
longer results in a "shorewall start" error.</li>
|
|
|
|
|
<li>You may now use port lists in the DEST PORT and SOURCE PORT
|
|
|
|
|
columns of the /etc/shorewall/accounting file.</li>
|
|
|
|
|
<li>The "shorewall show capabilities" command now accurately reports
|
|
|
|
|
the availability of "Packet type match" independent of the setting of
|
|
|
|
|
PKTTYPE in shorewall.conf.</li>
|
|
|
|
|
<li>Thanks to Tuomo Soini, all of the files have been siginificantly
|
|
|
|
|
cleaned up in terms of formatting and extra white-space.<br>
|
|
|
|
|
</li>
|
|
|
|
|
</ol>
|
|
|
|
|
New Features:<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>New Allow.Submission and Allow.NTPbrd actions have been added.
|
|
|
|
|
Users of the Allow.NTP action that use NTP broadcasting should switch
|
|
|
|
|
to use of Allow.NTPbrd instead.</li>
|
|
|
|
|
<li>The kernel version string is now included in the output of
|
|
|
|
|
"shorewall status".<br>
|
|
|
|
|
</li>
|
|
|
|
|
</ol>
|
|
|
|
|
<span style="font-weight: bold;">07/30/2005 Shorewall 2.2.6<br>
|
|
|
|
|
<br>
|
|
|
|
|
</span>Problems Corrected:<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li><a href="#20050717">MACLIST_TTL Vulnerability</a> fix.</li>
|
|
|
|
|
<li>TCP_FLAGS_LOG_LEVEL=ULOG breaks with recent versions of iptables.</li>
|
|
|
|
|
<li>The bogons file has been updated to reflect recent IANA
|
|
|
|
|
allocations.</li>
|
|
|
|
|
</ol>
|
|
|
|
|
<span style="font-weight: bold;">07/21/2005 Shorewall 2.4.2<br>
|
|
|
|
|
<br>
|
|
|
|
|
</span>Problems Corrected:<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>The /etc/shorewall/hosts file now includes information about
|
|
|
|
|
defining a zone using one or more ipsets.</li>
|
|
|
|
|
<li>A <a href="#20050717">vulnerability involving MACLIST_TTL > 0
|
|
|
|
|
or MACLIST_DISPOSITION=ACCEPT</a> has been corrected.</li>
|
|
|
|
|
<li>It is now possible to specify !<address> in the SUBNET
|
|
|
|
|
column of /etc/shorewall/masq. Previously, it was necessary to write
|
|
|
|
|
0.0.0.0/0!<address>.</li>
|
|
|
|
|
<li>When <network1>!<network2> was specified in the
|
|
|
|
|
SUBNET column of /etc/shorewall/masq, IPSEC policies were not correctly
|
|
|
|
|
applied to the resulting rules. This usually resulted in IPSEC not
|
|
|
|
|
working through the interface specified in the INTERFACES column.<br>
|
|
|
|
|
</li>
|
|
|
|
|
</ol>
|
|
|
|
|
New Features:<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li> A 'loose' provider option has been added. If you wish to be able
|
|
|
|
|
to use marking to specify the gateway used by connections originating
|
|
|
|
|
on the firewall itself, the specify 'loose' for each provider. It has
|
|
|
|
|
bee reported that 'loose' may break the effect of 'track' so beware if
|
|
|
|
|
you need 'track' functionality (you shouldn't be originating many
|
|
|
|
|
connections from your firewall to the net anyway).<br>
|
|
|
|
|
<br>
|
|
|
|
|
To use 'loose', you also need to add two entries in /etc/shorewall/masq:<br>
|
|
|
|
|
<pre><span style="font-family: monospace;">#INTERFACE SUBNET ADDRESS<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
$IF_ISP1 $IP_ISP2 $IP_ISP1<br>
|
|
|
|
|
$IF_ISP2 $IP_ISP1 $IP_ISP2</span>
|
2005-10-12 00:05:30 +02:00
|
|
|
</pre>
|
|
|
|
|
where:<br>
|
|
|
|
|
<pre> $IF_ISP1 is the interface to ISP 1.<br>
|
2005-09-23 02:12:12 +02:00
|
|
|
$IF_ISP2 is the interface to ISP 2.<br>
|
|
|
|
|
$IP_ISP1 is the IP address of $IF_ISP1<br>
|
|
|
|
|
$IP_ISP2 is the IP address of $IF_ISP2
|
2005-10-12 00:05:30 +02:00
|
|
|
</pre>
|
|
|
|
|
</li>
|
|
|
|
|
<li>/sbin/shorewall now issues a warning each time that it finds that
|
|
|
|
|
startup is disabled.</li>
|
|
|
|
|
<li>A new COPY column has been added to the /etc/shorewall/providers
|
|
|
|
|
file. Normally, when a table name/number is given in the DUPLICATE
|
|
|
|
|
column, the entire table (less default routes) is copied. The COPY
|
|
|
|
|
column allows you to limit the routes copied to those that go through
|
|
|
|
|
an interface listed in COPY. For example, if you enter eth0 in
|
|
|
|
|
INTERFACE, "eth1,eth2" in COPY and 'main' in DUPLICATE then the new
|
|
|
|
|
table created will contain those routes through the interfaces eth0,
|
|
|
|
|
eth1 and eth2.<br>
|
|
|
|
|
</li>
|
|
|
|
|
</ol>
|
|
|
|
|
<hr style="width: 100%; height: 2px;">
|
|
|
|
|
<h2><a name="20050717"></a><font color="#ff0000">07/17/2005 Security
|
|
|
|
|
vulnerability in MACLIST processing</font></h2>
|
|
|
|
|
<h3>Description</h3>
|
|
|
|
|
<p>A security vulnerability has been discovered which affects all
|
|
|
|
|
supported stable versions of Shorewall. This vulnerability
|
|
|
|
|
enables a client accepted by MAC address filtering to bypass any other
|
|
|
|
|
rule. If MACLIST_TTL is set to a value greater than 0 or
|
|
|
|
|
MACLIST_DISPOSITION is set to "ACCEPT" in /etc/shorewall/shorewall.conf
|
|
|
|
|
(default is MACLIST_TTL=0 and MACLIST_DISPOSITION=REJECT), and a client
|
|
|
|
|
is positively identified through its MAC address, it bypasses all other
|
|
|
|
|
policies/rules in place, thus gaining access to all open services on
|
|
|
|
|
the firewall.</p>
|
|
|
|
|
<h3>Fix</h3>
|
|
|
|
|
<h4>Workaround</h4>
|
|
|
|
|
<p>For Shorewall 2.2.x or 2.4.x, set MACLIST_TTL=0 or
|
|
|
|
|
MACLIST_DISPOSITION=REJECT in /etc/shorewall/shorewall.conf. For
|
|
|
|
|
Shorewall 2.0.x, set MACLIST_DISPOSITION=REJECT in
|
|
|
|
|
/etc/shorewall/shorewall.conf. MACLIST filtering is of limited
|
|
|
|
|
value on Internet-connected hosts, and the Shorewall team recommends
|
|
|
|
|
this approach to be used if possible.</p>
|
|
|
|
|
<h4>Upgrade</h4>
|
|
|
|
|
<p>For Shorewall 2.4.x, a fixed version of the 'firewall' script is
|
|
|
|
|
available at: <a
|
|
|
|
|
href="http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">
|
|
|
|
|
http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>
|
|
|
|
|
and its mirrors, <a
|
|
|
|
|
href="http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">
|
|
|
|
|
http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>
|
|
|
|
|
and <a
|
|
|
|
|
href="http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">
|
|
|
|
|
http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>.</p>
|
|
|
|
|
<p>For Shorewall 2.2.x, a fixed version of the 'firewall' script is
|
|
|
|
|
available at: <a
|
|
|
|
|
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">
|
|
|
|
|
http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>
|
|
|
|
|
and its mirrors, <a
|
|
|
|
|
href="http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">
|
|
|
|
|
http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>
|
|
|
|
|
and <a
|
|
|
|
|
href="http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">
|
|
|
|
|
http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>.</p>
|
|
|
|
|
<p>For Shorewall 2.0.x, a fixed version of the 'firewall' script is
|
|
|
|
|
available at: <a
|
|
|
|
|
href="http://shorewall.net/pub/shorewall/errata/2.0.17/firewall">http://shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>
|
|
|
|
|
and its mirrors, <a
|
|
|
|
|
href="http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall">
|
|
|
|
|
http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall</a> and <a
|
|
|
|
|
href="http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall">
|
|
|
|
|
http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>.</p>
|
|
|
|
|
<p>Users of any version before 2.0.17 are urged to upgrade to a
|
|
|
|
|
supported version of Shorewall (preferably 2.4.1) before using the
|
|
|
|
|
fixed files. Only the most recent version of the 2.0.x and 2.2.x
|
|
|
|
|
streams will be supported by the development team, and the 1.x branches
|
|
|
|
|
are no longer maintained at all. Future releases of Shorewall
|
|
|
|
|
will include this fix.</p>
|
|
|
|
|
<p>This information was based on <a
|
|
|
|
|
href="http://seclists.org/lists/fulldisclosure/2005/Jul/0409.html">Patrick
|
|
|
|
|
Blitz's post to the Full Disclosure mailing list</a>. Thanks to
|
|
|
|
|
Supernaut (supernaut at ns dot sympatico dot ca) for reporting this bug.<br>
|
|
|
|
|
</p>
|
|
|
|
|
<p><span style="font-weight: bold;">Version Upgrade<br>
|
|
|
|
|
</span></p>
|
|
|
|
|
<p>The vulnerability is corrected in Shorewall 2.4.2 and in Shorewall
|
|
|
|
|
2.2.6.<br>
|
|
|
|
|
</p>
|
|
|
|
|
<hr style="width: 100%; height: 2px;"> <span style="font-weight: bold;">07/13/2005
|
|
|
|
|
Shorewall 2.4.1<br>
|
|
|
|
|
</span><br>
|
|
|
|
|
Problems Corrected:<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>Shell variables may now be used in the zones file.</li>
|
|
|
|
|
<li>The /usr/share/shorewall/bogons file has been updated to reflect
|
|
|
|
|
recent IANA allocations.</li>
|
|
|
|
|
<li>Shorewall now detects an error where multiple providers specify
|
|
|
|
|
the 'track' option on the same interface.</li>
|
|
|
|
|
<li>The remnants of the GATEWAY column in /etc/shorewall/interfaces
|
|
|
|
|
have been removed. This column appeared briefly in one of the Beta
|
|
|
|
|
versions and was immediately removed but some vestiges remained.</li>
|
|
|
|
|
<li>Shorewall now correctly restores a load-balancing default route
|
|
|
|
|
during processing of the 'shorewall restore' and 'shorewall -f start'
|
|
|
|
|
commands. The latter command is normally executed by the Shorewall init
|
|
|
|
|
script during reboot.</li>
|
|
|
|
|
<li>A log level of "None!" is now allowed on builtin actions such as
|
|
|
|
|
ACCEPT and DROP.</li>
|
|
|
|
|
<li>Previously, LIMIT:BURST parameters in /etc/shorewall/policy were
|
|
|
|
|
not correctly applied when the policy was QUEUE.</li>
|
|
|
|
|
<li>The 'chkconfig' command on FC4 and Mandriva previously created
|
|
|
|
|
symbolic links with incorrect names ("S-1shorewall"). The init script
|
|
|
|
|
has been changed to prevent this incorrect behavior.</li>
|
|
|
|
|
<li>DHCP traffic forwarded through a bridge could, under some
|
|
|
|
|
configurations, be filtered by the 'maclist' option even though the
|
|
|
|
|
'dhcp' option was specified. This has been corrected.<br>
|
|
|
|
|
</li>
|
|
|
|
|
</ol>
|
|
|
|
|
<span style="font-weight: bold;">06/05/2005 Shorewall 2.4.0<br>
|
|
|
|
|
<br>
|
|
|
|
|
Note:</span> Because of the short time that has elapsed since the
|
|
|
|
|
release of Shorewall 2.2.0, Shorewall 2.0 will be supported until 1
|
|
|
|
|
December 2005 or until the release of Shorewall 2.6.0, whichever occurs
|
|
|
|
|
first.<br>
|
|
|
|
|
<br>
|
|
|
|
|
New Features:<br>
|
|
|
|
|
<ol>
|
|
|
|
|
<li>Shorewall 2.4.0 includes support for multiple internet interfaces
|
|
|
|
|
to different ISPs.<br>
|
|
|
|
|
<br>
|
|
|
|
|
The file /etc/shorewall/providers may be used to define the different
|
|
|
|
|
providers. It can actually be used to define alternate routing tables
|
|
|
|
|
so uses like transparent proxy can use the file as well.<br>
|
|
|
|
|
<br>
|
|
|
|
|
Columns are:<br>
|
|
|
|
|
<br>
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
NAME
|
|
|
|
|
The provider name.</span><br style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
NUMBER The
|
|
|
|
|
provider number -- a number between 1 and 15</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
MARK
|
|
|
|
|
A FWMARK value used in your /etc/shorewall/tcrules file to direct
|
|
|
|
|
packets for this provider.</span><br style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
DUPLICATE The name of an existing
|
|
|
|
|
table to duplicate. May</span> <span style="font-family: monospace;">be
|
|
|
|
|
'main' or the name of a previous provider.</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
INTERFACE The name of the network
|
|
|
|
|
interface to the</span> <span style="font-family: monospace;">provider.
|
|
|
|
|
Must be listed in</span><span style="font-family: monospace;">/etc/shorewall/interfaces.</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
GATEWAY The IP address
|
|
|
|
|
of the provider's gateway router.</span> <span
|
|
|
|
|
style="font-family: monospace;">If you enter "detect" here then
|
|
|
|
|
Shorewall<br>
|
|
|
|
|
|
|
|
|
|
will</span> <span style="font-family: monospace;">attempt to determine
|
|
|
|
|
the gateway IP address</span> <span style="font-family: monospace;">automatically.</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
OPTIONS A
|
|
|
|
|
comma-separated list selected from the</span> <span
|
|
|
|
|
style="font-family: monospace;">following:</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
track If specified, connections FROM this interface are</span>
|
|
|
|
|
<span style="font-family: monospace;">to be tracked so that
|
|
|
|
|
responses may be<br>
|
|
|
|
|
|
|
|
|
|
routed</span> <span style="font-family: monospace;">back out this same
|
|
|
|
|
interface.</span><br style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
You want specify 'track' if internet hosts will be</span> <span
|
|
|
|
|
style="font-family: monospace;">connecting to local servers through<br>
|
|
|
|
|
|
|
|
|
|
this</span> <span style="font-family: monospace;">provider.</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
Because of limitations in the 'ip' utility and</span> <span
|
|
|
|
|
style="font-family: monospace;">policy routing, you may not use the
|
|
|
|
|
SAVE or</span><span style="font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
RESTORE tcrules options or use connection</span><span
|
|
|
|
|
style="font-family: monospace;">marking on any traffic to or from this</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
interface. For traffic control purposes, you</span> <span
|
|
|
|
|
style="font-family: monospace;">must mark packets in the FORWARD chain
|
|
|
|
|
(or</span><span style="font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
better yet, use the CLASSIFY target).</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
balance The providers that have 'balance' specified will</span> <span
|
|
|
|
|
style="font-family: monospace;">get outbound traffic load-balanced
|
|
|
|
|
among<br>
|
|
|
|
|
|
|
|
|
|
them. By</span> <span style="font-family: monospace;">default, all
|
|
|
|
|
interfaces with 'balance' specified</span> <span
|
|
|
|
|
style="font-family: monospace;">will have the same weight (1).<br>
|
|
|
|
|
|
|
|
|
|
You can change the</span><span style="font-family: monospace;">weight
|
|
|
|
|
of the route out of the interface by</span> <span
|
|
|
|
|
style="font-family: monospace;">specifiying balance=<weight><br>
|
|
|
|
|
|
|
|
|
|
where <weight> is</span><span style="font-family: monospace;">the
|
|
|
|
|
desired route weight.</span><br style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
Example: You run squid in
|
|
|
|
|
your DMZ on IP address 192.168.2.99. Your DMZ interface is eth2<br>
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
#NAME NUMBER MARK DUPLICATE INTERFACE
|
|
|
|
|
GATEWAY OPTIONS</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
Squid 1
|
|
|
|
|
1
|
|
|
|
|
-
|
|
|
|
|
eth2 192.168.2.99 -</span><br>
|
|
|
|
|
<br>
|
|
|
|
|
Use of this feature requires that your kernel and iptabls support
|
|
|
|
|
CONNMARK target and conntrack match support. It does NOT require the
|
|
|
|
|
ROUTE target extension.<br>
|
|
|
|
|
<br>
|
|
|
|
|
WARNING: The current version of iptables (1.3.1) is broken with respect
|
|
|
|
|
to CONNMARK and iptables-save/iptables-restore. This means that if you
|
|
|
|
|
configure multiple ISPs, "shorewall restore" may fail. You must patch
|
|
|
|
|
your iptables using the patch at <a
|
|
|
|
|
href="http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff">
|
|
|
|
|
http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff</a>.<br>
|
|
|
|
|
<br>
|
|
|
|
|
</li>
|
|
|
|
|
<li>Shorewall 2.3.0 supports the 'cmd-owner' option of the owner
|
|
|
|
|
match facility in Netfilter. Like all owner match options, 'cmd-owner'
|
|
|
|
|
may only be applied to traffic that originates on the firewall.<br>
|
|
|
|
|
<br>
|
|
|
|
|
The syntax of the USER/GROUP column in the following files has been
|
|
|
|
|
extended:<br>
|
|
|
|
|
<br>
|
|
|
|
|
/etc/shorewall/accounting<br>
|
|
|
|
|
/etc/shorewall/rules<br>
|
|
|
|
|
/etc/shorewall/tcrules<br>
|
|
|
|
|
|
|
|
|
|
/usr/share/shorewall/action.template<br>
|
|
|
|
|
<br>
|
|
|
|
|
To specify a command, prefix the command name with "+".<br>
|
|
|
|
|
<br>
|
|
|
|
|
Examples:<br>
|
|
|
|
|
<br>
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
+mozilla-bin
|
|
|
|
|
#The program is named "mozilla-bin"</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
joe+mozilla-bin #The
|
|
|
|
|
program is named "mozilla-bin" and</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
#is being run by user "joe"</span><br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
joe:users+mozilla-bin #The program is named "mozilla-bin"
|
|
|
|
|
and</span><br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
#is being run by user "joe" with</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
#effective group "users".</span><br style="font-family: monospace;">
|
|
|
|
|
<br>
|
|
|
|
|
Note that this is not a particularly robust feature and I
|
|
|
|
|
would never advertise it as a "Personal Firewall" equivalent. Using
|
|
|
|
|
symbolic links, it's easy to alias command names to be anything you
|
|
|
|
|
want.<br>
|
|
|
|
|
<br>
|
|
|
|
|
</li>
|
|
|
|
|
<li>Support has been added for ipsets (see <a
|
|
|
|
|
href="http://people.netfilter.org/kadlec/ipset/">http://people.netfilter.org/kadlec/ipset/</a>).<br>
|
|
|
|
|
<br>
|
|
|
|
|
In most places where a host or network address may be used, you may
|
|
|
|
|
also use the name of an ipset prefaced by "+".<br>
|
|
|
|
|
<br>
|
|
|
|
|
Example: "+Mirrors"<br>
|
|
|
|
|
<br>
|
|
|
|
|
The name of the set may be optionally followed by:<br>
|
|
|
|
|
<br>
|
|
|
|
|
a) a number from 1 to 6 enclosed in square brackets ([]) -- this number
|
|
|
|
|
indicates the maximum number of ipset binding levels that are to be
|
|
|
|
|
matched. Depending on the context where the ipset name is used, either
|
|
|
|
|
all "src" or all "dst" matches will be used.<br>
|
|
|
|
|
<br>
|
|
|
|
|
Example: "+Mirrors[4]"<br>
|
|
|
|
|
<br>
|
|
|
|
|
b) a series of "src" and "dst" options separated by commas and inclosed
|
|
|
|
|
in square brackets ([]). These will be passed directly to iptables in
|
|
|
|
|
the generated --set clause. See the ipset documentation for details.<br>
|
|
|
|
|
<br>
|
|
|
|
|
Example:
|
|
|
|
|
"+Mirrors[src,dst,src]"<br>
|
|
|
|
|
<br>
|
|
|
|
|
Note that "+Mirrors[4]" used in the SOURCE column of the rules file is
|
|
|
|
|
equivalent to "+Mirrors[src,src,src,src]".<br>
|
|
|
|
|
<br>
|
|
|
|
|
To generate a negative match, prefix the "+" with "!" as in "!+Mirrors".<br>
|
|
|
|
|
<br>
|
|
|
|
|
Example 1: Blacklist all hosts in an ipset named "blacklist"<br>
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/blacklist<br>
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
#ADDRESS/SUBNET
|
|
|
|
|
PROTOCOL PORT</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
+blacklist</span><br style="font-family: monospace;">
|
|
|
|
|
<br>
|
|
|
|
|
Example 2: Allow SSH from all hosts in an ipset named "sshok:<br>
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
/etc/shorewall/rules<br>
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
#ACTION
|
|
|
|
|
SOURCE DEST
|
|
|
|
|
PROTO DEST PORT(S)</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
ACCEPT
|
|
|
|
|
+sshok
|
|
|
|
|
fw
|
|
|
|
|
tcp 22</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br>
|
|
|
|
|
Shorewall can automatically capture the contents of your ipsets for
|
|
|
|
|
you. If you specify SAVE_IPSETS=Yes in /etc/shorewall/shorewall.conf
|
|
|
|
|
then "shorewall save" will save the contents of your ipsets. The file
|
|
|
|
|
where the sets are saved is formed by taking the name where the
|
|
|
|
|
Shorewall configuration is stored and appending "-ipsets". So if you
|
|
|
|
|
enter the command "shorewall save standard" then your Shorewall
|
|
|
|
|
configuration will be saved in var/lib/shorewall/standard and your
|
|
|
|
|
ipset contents will be saved in /var/lib/shorewall/standard-ipsets.
|
|
|
|
|
Assuming the default RESTOREFILE setting, if you just enter "shorewall
|
|
|
|
|
save" then your Shorewall configuration will be saved in
|
|
|
|
|
/var/lib/shorewall/restore and your ipset contents will be saved in
|
|
|
|
|
/var/lib/shorewall/restore-ipsets.<br>
|
|
|
|
|
<br>
|
|
|
|
|
Regardless of the setting of SAVE_IPSETS, the "shorewall -f start" and
|
|
|
|
|
"shorewall restore" commands will restore the ipset contents
|
|
|
|
|
corresponding to the Shorewall configuration restored provided that the
|
|
|
|
|
saved Shorewall configuration specified exists.<br>
|
|
|
|
|
<br>
|
|
|
|
|
For example, "shorewall restore standard" would restore the ipset
|
|
|
|
|
contents from /var/lib/shorewall/standard-ipsets provided that
|
|
|
|
|
/var/lib/shorewall/standard exists and is executable and that
|
|
|
|
|
/var/lib/shorewall/standard-ipsets exists and is executable.<br>
|
|
|
|
|
<br>
|
|
|
|
|
Also regardless of the setting of SAVE_IPSETS, the "shorewall forget"
|
|
|
|
|
command will purge the saved ipset information (if any) associated with
|
|
|
|
|
the saved shorewall configuration being removed.<br>
|
|
|
|
|
<br>
|
|
|
|
|
You can also associate ipset contents with Shorewall configuration
|
|
|
|
|
directories using the following command:<br>
|
|
|
|
|
<br>
|
|
|
|
|
ipset -S > <config
|
|
|
|
|
directory>/ipsets<br>
|
|
|
|
|
<br>
|
|
|
|
|
Example:<br>
|
|
|
|
|
<br>
|
|
|
|
|
ipset -S > /etc/shorewall/ipsets<br>
|
|
|
|
|
<br>
|
|
|
|
|
When you start or restart Shorewall (including using the 'try' command)
|
|
|
|
|
from the configuration directory, your ipsets will be configured from
|
|
|
|
|
the saved ipsets file. Once again, this behavior is independent of the
|
|
|
|
|
setting of SAVE_IPSETS.<br>
|
|
|
|
|
<br>
|
|
|
|
|
Ipsets are well suited for large blacklists. You can maintain your
|
|
|
|
|
blacklist using the 'ipset' utility without ever having to restart or
|
|
|
|
|
refresh Shorewall. If you use the SAVE_IPSETS=Yes feature just be sure
|
|
|
|
|
to "shorewall save" after altering the blacklist ipset(s).<br>
|
|
|
|
|
<br>
|
|
|
|
|
Example /etc/shorewall/blacklist:<br>
|
|
|
|
|
<br>
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
#ADDRESS/SUBNET
|
|
|
|
|
PROTOCOL PORT</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
+Blacklist[src,dst]</span><br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
+Blacklistnets[src,dst]</span><br style="font-family: monospace;">
|
|
|
|
|
<br>
|
|
|
|
|
Create the blacklist ipsets using:<br>
|
|
|
|
|
<br>
|
|
|
|
|
ipset -N
|
|
|
|
|
Blacklist iphash<br>
|
|
|
|
|
ipset -N
|
|
|
|
|
Blacklistnets nethash<br>
|
|
|
|
|
<br>
|
|
|
|
|
Add entries<br>
|
|
|
|
|
<br>
|
|
|
|
|
ipset -A Blacklist 206.124.146.177<br>
|
|
|
|
|
ipset -A Blacklistnets
|
|
|
|
|
206.124.146.0/24<br>
|
|
|
|
|
<br>
|
|
|
|
|
To allow entries for individual ports<br>
|
|
|
|
|
<br>
|
|
|
|
|
ipset -N SMTP portmap --from 1
|
|
|
|
|
--to 31<br>
|
|
|
|
|
ipset -A SMTP 25<br>
|
|
|
|
|
<br>
|
|
|
|
|
ipset -A Blacklist 206.124.146.177<br>
|
|
|
|
|
ipset -B Blacklist 206.124.146.177
|
|
|
|
|
-b SMTP<br>
|
|
|
|
|
<br>
|
|
|
|
|
Now only port 25 will be blocked from 206.124.146.177.<br>
|
|
|
|
|
<br>
|
|
|
|
|
</li>
|
|
|
|
|
<li>Shorewall 2.4.0 can now configure routing if your kernel and
|
|
|
|
|
iptables support the ROUTE target extension. This extension is
|
|
|
|
|
available in Patch-O-Matic-ng. This feature is *EXPERIMENTAL* since the
|
|
|
|
|
Netfilter team have no intention of ever releasing the ROUTE target
|
|
|
|
|
extension to kernel.org.<br>
|
|
|
|
|
<br>
|
|
|
|
|
Routing is configured using the /etc/shorewall/routes file. Columns in
|
|
|
|
|
the file are as follows:<br>
|
|
|
|
|
<br>
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
SOURCE
|
|
|
|
|
Source of the packet. May be any of the</span> <span
|
|
|
|
|
style="font-family: monospace;">following:</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
- A host or network address</span><br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
- A network interface name.</span><br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
- The name of an ipset prefaced with "+"</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
- $FW (for packets originating on the firewall)</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
- A MAC address in Shorewall format</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
- A range of IP addresses (assuming that your</span> <span
|
|
|
|
|
style="font-family: monospace;">kernel and iptables support range
|
|
|
|
|
match)</span><br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
- A network interface name followed by ":"</span> <span
|
|
|
|
|
style="font-family: monospace;">and an address or address range.</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
DEST
|
|
|
|
|
Destination of the packet. May be any of the</span> <span
|
|
|
|
|
style="font-family: monospace;">following:</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
- A host or network address</span><br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
- A network interface name (determined from</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
routing table(s))</span><br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
- The name of an ipset prefaced with "+"</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
- A network interface name followed by ":"</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
and an address or address range.</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
PROTO
|
|
|
|
|
Protocol - Must be "tcp", "udp", "icmp",</span> <span
|
|
|
|
|
style="font-family: monospace;">"ipp2p", a number, or "all". "ipp2p"
|
|
|
|
|
requires</span><span style="font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
ipp2p match support in your kernel and</span><span
|
|
|
|
|
style="font-family: monospace;">iptables.</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
PORT(S) Destination
|
|
|
|
|
Ports. A comma-separated list of</span> <span
|
|
|
|
|
style="font-family: monospace;">Port names (from /etc/services), port<br>
|
|
|
|
|
|
|
|
|
|
numbers</span> <span style="font-family: monospace;">or port ranges;
|
|
|
|
|
if the protocol is "icmp", this</span><span
|
|
|
|
|
style="font-family: monospace;">column is interpreted as the<br>
|
|
|
|
|
|
|
|
|
|
destination</span> <span style="font-family: monospace;">icmp-type(s).</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
If the protocol is ipp2p, this column is</span> <span
|
|
|
|
|
style="font-family: monospace;">interpreted as an ipp2p option without
|
|
|
|
|
the</span><span style="font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
leading "--" (example "bit" for bit-torrent).</span> <span
|
|
|
|
|
style="font-family: monospace;">If no PORT is given, "ipp2p" is
|
|
|
|
|
assumed.</span><br style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
This column is ignored if PROTOCOL = all but</span> <span
|
|
|
|
|
style="font-family: monospace;">must be entered if any of the following<br>
|
|
|
|
|
|
|
|
|
|
field</span> <span style="font-family: monospace;">is supplied. In
|
|
|
|
|
that case, it is suggested that</span> <span
|
|
|
|
|
style="font-family: monospace;">this field contain "-"</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
SOURCE PORT(S) (Optional) Source port(s). If omitted,</span> <span
|
|
|
|
|
style="font-family: monospace;">any source port is acceptable.
|
|
|
|
|
Specified as a</span><span style="font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
comma-separated list of port names, port</span> <span
|
|
|
|
|
style="font-family: monospace;">numbers or port ranges.</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
TEST
|
|
|
|
|
Defines a test on the existing packet or</span> <span
|
|
|
|
|
style="font-family: monospace;">connection mark.</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
The rule will match only if the test returns</span> <span
|
|
|
|
|
style="font-family: monospace;">true. Tests have the format</span><span
|
|
|
|
|
style="font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
[!]<value>[/<mask>][:C]</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
Where:</span><br style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
! Inverts the test (not equal)</span>
|
|
|
|
|
<span style="font-family: monospace;"><value> Value of the
|
|
|
|
|
packet or</span><span style="font-family: monospace;"><br>
|
|
|
|
|
|
|
|
|
|
connection mark.</span><br style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
<mask> A mask to be applied to the</span> <span
|
|
|
|
|
style="font-family: monospace;">mark before testing</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
:C Designates a connection</span> <span
|
|
|
|
|
style="font-family: monospace;">mark. If omitted, the packet</span> <span
|
|
|
|
|
style="font-family: monospace;">mark's value<br>
|
|
|
|
|
|
|
|
|
|
is tested.</span><br style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
INTERFACE The interface that the
|
|
|
|
|
packet is to be routed</span> <span style="font-family: monospace;">out
|
|
|
|
|
of. If you do not specify this<br>
|
|
|
|
|
|
|
|
|
|
field then</span> <span style="font-family: monospace;">you must place
|
|
|
|
|
"-" in this column and enter an</span> <span
|
|
|
|
|
style="font-family: monospace;">IP address in the GATEWAY<br>
|
|
|
|
|
|
|
|
|
|
column.</span><br style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
<span style="font-family: monospace;">
|
|
|
|
|
GATEWAY The gateway
|
|
|
|
|
that the packet is to be forewarded</span> <span
|
|
|
|
|
style="font-family: monospace;">through.</span><br
|
|
|
|
|
style="font-family: monospace;">
|
|
|
|
|
<br style="font-family: monospace;">
|
|
|
|
|
</li>
|
|
|
|
|
<li>Normally when Shorewall is stopped, starting or restarting then
|
|
|
|
|
connections are allowed from hosts listed in
|
|
|
|
|
/etc/shorewall/routestopped to the firewall and to other hosts listed
|
|
|
|
|
in /etc/shorewall/routestopped.<br>
|
|
|
|
|
<br>
|
|
|
|
|
A new 'source' option is added for entries in that file which will
|
|
|
|
|
cause Shorewall to allow traffic from the host listed in the entry to
|
|
|
|
|
ANY other host. When 'source' is specified in an entry, it is
|
|
|
|
|
unnecessary to also specify 'routeback'.<br>
|
|
|
|
|
<br>
|
|
|
|
|
Similarly, a new 'dest' option is added which will cause Shorewall to
|
|
|
|
|
allow traffic to the host listed in the entry from ANY other host. When
|
|
|
|
|
'source' is specified in an entry, it is unnecessary to also specify
|
|
|
|
|
'routeback'.<br>
|
|
|
|
|
<br>
|
|
|
|
|
</li>
|
|
|
|
|
<li>This change was implemented by Lorenzo Martignoni. It provides
|
|
|
|
|
two new commands: "safe-start" and "safe-restart".<br>
|
|
|
|
|
<br>
|
|
|
|
|
<span style="font-weight: bold;">safe-start</span> starts Shorewall
|
|
|
|
|
then prompts you to ask you if everything looks ok. If you answer "no"
|
|
|
|
|
or if you don't answer within 60 seconds, a "shorewall clear" is
|
|
|
|
|
executed.<br>
|
|
|
|
|
<br>
|
|
|
|
|
<span style="font-weight: bold;">safe-restart</span> saves your
|
|
|
|
|
current configuration to /var/lib/shorewall/safe-restart then issues a
|
|
|
|
|
"shorewall restart"; It then prompts you to ask if you if you want to
|
|
|
|
|
accept the new configuration. If you answer "no" or if you don't answer
|
|
|
|
|
within 60 seconds, the configuration is restored to its prior state.<br>
|
|
|
|
|
<br>
|
|
|
|
|
These new commands require either that your /bin/sh supports the "-t"
|
|
|
|
|
option to the 'read' command or that you have /bin/bash installed.<br>
|
|
|
|
|
</li>
|
|
|
|
|
</ol>
|
|
|
|
|
<span style="font-weight: bold;">Old News <a href="oldnews.html">here</a><br>
|
|
|
|
|
</span>
|
|
|
|
|
</body>
|
2003-12-30 02:19:52 +01:00
|
|
|
</html>
|
