From 2565081ff986fedbf73347685665b2ef7f7dc7c4 Mon Sep 17 00:00:00 2001 From: teastep Date: Sun, 29 Dec 2002 18:23:07 +0000 Subject: [PATCH] Some post-1.2.12 documentation cleanup git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@389 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/Documentation.htm | 14 +- Shorewall-docs/FAQ.htm | 2 +- Shorewall-docs/MAC_Validation.html | 151 ++- Shorewall-docs/News.htm | 4 +- Shorewall-docs/configuration_file_basics.htm | 651 ++++++------ Shorewall-docs/errata.htm | 925 +++++++++--------- Shorewall-docs/gnu_mailman.htm | 97 +- Shorewall-docs/mailing_list.htm | 302 +++--- Shorewall-docs/seattlefirewall_index.htm | 4 +- Shorewall-docs/shorewall_logging.html | 137 +++ Shorewall-docs/shorewall_quickstart_guide.htm | 367 +++---- Shorewall-docs/shorewall_setup_guide.htm | 2 +- Shorewall-docs/sourceforge_index.htm | 4 +- Shorewall-docs/support.htm | 315 +++--- 14 files changed, 1526 insertions(+), 1449 deletions(-) create mode 100644 Shorewall-docs/shorewall_logging.html diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index 26a605911..78d55113c 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -755,7 +755,7 @@ in both the SOURCE and DEST columns.
  • LOG LEVEL - Optional. If left empty, no log message is generated when the policy is applied. Otherwise, this column should contain an integer or name indicating - a syslog level.
    • + a syslog level.
  • LIMIT:BURST - Optional. If left empty, TCP connection requests from the SOURCE zone @@ -1251,7 +1251,7 @@ here as in the policy file above.

    • The ACTION may optionally be followed by ":" and a syslog + href="shorewall_logging.html">syslog level (example: REJECT:info). This causes the packet to be logged at the specified level prior to being processed according to the specified ACTION.
    @@ -2243,7 +2243,7 @@ is assumed.
    This parameter determines the level at which packets logged under the 'norfc1918' mechanism  are logged. The value must be a valid syslog + href="shorewall_logging.html">syslog level and if no level is given, then info is assumed. Prior to Shorewall version 1.3.12, these packets are always logged at the info level.

  • TCP_FLAGS_DISPOSITION - Added in Version 1.3.11
    @@ -2254,7 +2254,7 @@ DROP (ignore the packet). If not set or if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed.
  • TCP_FLAGS_LOG_LEVEL - Added in Version 1.3.11
    Determines the syslog + href="shorewall_logging.html">syslog level for logging packets that fail the checks enabled by the tcpflags interface option.The value must be a valid syslogd log level. If you don't want to log these packets, set to the empty @@ -2268,7 +2268,7 @@ or DROP (ignore the connection request). If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed.
  • MACLIST_LOG_LEVEL - Added in Version 1.3.10
    Determines the syslog + href="shorewall_logging.html">syslog level for logging connection requests that fail MAC Verification. The value must be a valid syslogd log level. If you don't want to log these connection requests, set @@ -2295,7 +2295,7 @@ unless they are handled by an explicit entry in the syslog + href="shorewall_logging.html">syslog level at which you want the packets logged. Example: LOGNEWNOTSYN=ULOG|

    Note: Packets logged under this option are usually @@ -2612,7 +2612,7 @@ assumed.
    • at. Its value is a syslog + href="shorewall_logging.html">syslog level (Example: BLACKLIST_LOGLEVEL=debug). diff --git a/Shorewall-docs/FAQ.htm b/Shorewall-docs/FAQ.htm index 10242d846..03bd5dc0b 100644 --- a/Shorewall-docs/FAQ.htm +++ b/Shorewall-docs/FAQ.htm @@ -616,7 +616,7 @@ see "man syslog") in your policies 
         LOGLIMIT=""
         LOGBURST=""

    Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages to a separate file.
    + href="shorewall_logging.html">set up Shorewall to log all of its messages to a separate file.

    6a. Are there any log parsers that work diff --git a/Shorewall-docs/MAC_Validation.html b/Shorewall-docs/MAC_Validation.html index 49be690fa..df0785f0f 100644 --- a/Shorewall-docs/MAC_Validation.html +++ b/Shorewall-docs/MAC_Validation.html @@ -2,110 +2,109 @@ MAC Verification - + - + - + - - - + + - - - + +
    + + + +
    - +
    +

    MAC Verification
    -

    -
    -
    -
    - Beginning with Shorewall version 1.3.10, all traffic from an interface - or from a subnet on an interface can be verified to originate from a defined - set of MAC addresses. Furthermore, each MAC address may be optionally associated +
    + Beginning with Shorewall version 1.3.10, all traffic from an interface + or from a subnet on an interface can be verified to originate from a defined + set of MAC addresses. Furthermore, each MAC address may be optionally associated with one or more IP addresses.
    -
    -You must have the iproute package (ip utility) installed to use MAC Verification.
    -
    -There are four components to this facility.
    - +
    + You must have the iproute package (ip utility) installed to use MAC Verification +and your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC - +module name ipt_mac.o).
    +
    + There are four components to this facility.
    +
      -
    1. The maclist interface option in /etc/shorewall/interfaces. When -this option is specified, all traffic arriving on the interface is subjet -to MAC verification.
      2. -
    2. The maclist option in /etc/shorewall/hosts. - When this option is specified for a subnet, all traffic from that subnet - is subject to MAC verification.
      3. -
    3. The /etc/shorewall/maclist file. This file is used to associate -MAC addresses with interfaces and to optionally associate IP addresses with - MAC addresses.
      4. -
    4. The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables - in /etc/shorewall/shorewall.conf. -The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and -determines the disposition of connection requests that fail MAC verification. -The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection -requests that fail verification are to be logged. If set the the empty value -(e.g., MACLIST_LOG_LEVEL="") then failing connection requests are not logged.
      -
      5. - +
    5. The maclist interface option in /etc/shorewall/interfaces. When this +option is specified, all traffic arriving on the interface is subjet to MAC +verification.
      6. +
    6. The maclist option in /etc/shorewall/hosts. When this option +is specified for a subnet, all traffic from that subnet is subject to MAC +verification.
      7. +
    7. The /etc/shorewall/maclist file. This file is used to associate + MAC addresses with interfaces and to optionally associate IP addresses +with MAC addresses.
      8. +
    8. The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables + in /etc/shorewall/shorewall.conf. The + MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and determines + the disposition of connection requests that fail MAC verification. The +MACLIST_LOG_LEVEL variable gives the syslogd level at which connection requests +that fail verification are to be logged. If set the the empty value (e.g., +MACLIST_LOG_LEVEL="") then failing connection requests are not logged.
      +
      9. +
    - The columns in /etc/shorewall/maclist are:
    - + The columns in /etc/shorewall/maclist are:
    + - +

    Example 1: Here are my files:

    - /etc/shorewall/shorewall.conf:
    -     + /etc/shorewall/shorewall.conf:
    + 
         MACLIST_DISPOSITION=REJECT
         MACLIST_LOG_LEVEL=info
    - /etc/shorewall/interfaces:
    - + /etc/shorewall/interfaces:
    + 
         #ZONE           INTERFACE       BROADCAST       OPTIONS
         net             eth0            206.124.146.255 norfc1918,filterping,dhcp,blacklist
         loc             eth2            192.168.1.255   dhcp,filterping,maclist
         dmz             eth1            192.168.2.255   filterping
         net             eth3            206.124.146.255 filterping,blacklist
         -               texas           192.168.9.255   filterping
         loc             ppp+            -               filterping
    - /etc/shorewall/maclist:
    - + /etc/shorewall/maclist:
    + 
         #INTERFACE              MAC                     IP ADDRESSES (Optional)
         eth2                    00:A0:CC:63:66:89       192.168.1.3     #Wookie
         eth2                    00:10:B5:EC:FD:0B       192.168.1.4     #Tarry
         eth2                    00:A0:CC:DB:31:C4       192.168.1.5     #Ursa
         eth2                    00:06:25:aa:a8:0f       192.168.1.7     #Eastept1 (Wireless)
         eth2                    00:04:5A:0E:85:B9       192.168.1.250   #Wap
    - As shown above, I use MAC Verification on my local + As shown above, I use MAC Verification on my local zone.
    - +

    Example 2: Router in Local Zone

    - Suppose now that I add a second ethernet segment to my local zone and -gateway that segment via a router with MAC address 00:06:43:45:C6:15 and -IP address 192.168.1.253. Hosts in the second segment have IP addresses in -the subnet 192.168.2.0/24. I would add the following entry to my /etc/shorewall/maclist + Suppose now that I add a second ethernet segment to my local zone and + gateway that segment via a router with MAC address 00:06:43:45:C6:15 and + IP address 192.168.1.253. Hosts in the second segment have IP addresses +in the subnet 192.168.2.0/24. I would add the following entry to my /etc/shorewall/maclist file:
    - + 
         eth2                     00:06:43:45:C6:15       192.168.1.253,192.168.2.0/24
    - This entry accomodates traffic from the router itself (192.168.1.253) -and from the second LAN segment (192.168.2.0/24). Remember that all traffic - being sent to my firewall from the 192.168.2.0/24 segment will be forwarded - by the router so that traffic's MAC address will be that of the router (00:06:43:45:C6:15) - and not that of the host sending the traffic. -

    Updated 12/22/2002 - Tom Eastep -

    + This entry accomodates traffic from the router itself (192.168.1.253) + and from the second LAN segment (192.168.2.0/24). Remember that all traffic + being sent to my firewall from the 192.168.2.0/24 segment will be forwarded + by the router so that traffic's MAC address will be that of the router (00:06:43:45:C6:15) + and not that of the host sending the traffic. +

    Updated 12/29/2002 - Tom Eastep +

    - -

    Copyright + +

    Copyright © 2001, 2002 Thomas M. Eastep.

    -
    -
    -
    -


    diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm index 72cba3084..9bc63eeaf 100644 --- a/Shorewall-docs/News.htm +++ b/Shorewall-docs/News.htm @@ -52,7 +52,7 @@ the current packet classification filters. The output from this command is the LOG target. This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) and log all Shorewall messages to a separate log file. + href="shorewall_logging.html">to a separate log file.
  • If you are running a kernel that has a FORWARD chain in the mangle table ("shorewall show mangle" will show you the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in than the LOG target. This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) and log all Shorewall messages to a separate log file.
    • + href="shorewall_logging.html">to a separate log file.
  • If you are running a kernel that has a FORWARD chain in the mangle table ("shorewall show mangle" will show you the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for diff --git a/Shorewall-docs/configuration_file_basics.htm b/Shorewall-docs/configuration_file_basics.htm index cfb645017..fd526e0e4 100644 --- a/Shorewall-docs/configuration_file_basics.htm +++ b/Shorewall-docs/configuration_file_basics.htm @@ -1,435 +1,340 @@ - + - + - + - + Configuration File Basics - + - - - + + - - - + + + +
    - +
    +

    Configuration Files

    -
    - -

    Warning: If you copy or edit your - configuration files on a system running Microsoft Windows, you must - run them through dos2unix - before you use them with Shorewall.

    - -

    Files

    - + +

    Warning: If you copy or edit your + configuration files on a system running Microsoft Windows, you must + run them through dos2unix + before you use them with Shorewall.

    + +

    Files

    +

    Shorewall's configuration files are in the directory /etc/shorewall.

    - +
      -
    • /etc/shorewall/shorewall.conf - used to set several - firewall parameters.
      • -
    • /etc/shorewall/params - use this file to set shell +
    • /etc/shorewall/shorewall.conf - used to set several + firewall parameters.
      • +
    • /etc/shorewall/params - use this file to set shell variables that you will expand in other files.
      • -
    • /etc/shorewall/zones - partition the firewall's -view of the world into zones.
      • -
    • /etc/shorewall/policy - establishes firewall high-level - policy.
      • -
    • /etc/shorewall/interfaces - describes the interfaces +
    • /etc/shorewall/zones - partition the firewall's + view of the world into zones.
      • +
    • /etc/shorewall/policy - establishes firewall high-level + policy.
      • +
    • /etc/shorewall/interfaces - describes the interfaces on the firewall system.
      • -
    • /etc/shorewall/hosts - allows defining zones in -terms of individual hosts and subnetworks.
      • -
    • /etc/shorewall/masq - directs the firewall where - to use many-to-one (dynamic) Network Address Translation (a.k.a. - Masquerading) and Source Network Address Translation (SNAT).
      • -
    • /etc/shorewall/modules - directs the firewall to - load kernel modules.
      • -
    • /etc/shorewall/rules - defines rules that are exceptions - to the overall policies established in /etc/shorewall/policy.
      • -
    • /etc/shorewall/nat - defines static NAT rules.
      • -
    • /etc/shorewall/proxyarp - defines use of Proxy +
    • /etc/shorewall/hosts - allows defining zones in + terms of individual hosts and subnetworks.
      • +
    • /etc/shorewall/masq - directs the firewall where + to use many-to-one (dynamic) Network Address Translation (a.k.a. + Masquerading) and Source Network Address Translation (SNAT).
      • +
    • /etc/shorewall/modules - directs the firewall +to load kernel modules.
      • +
    • /etc/shorewall/rules - defines rules that are +exceptions to the overall policies established in /etc/shorewall/policy.
      • +
    • /etc/shorewall/nat - defines static NAT rules.
      • +
    • /etc/shorewall/proxyarp - defines use of Proxy ARP.
      • -
    • /etc/shorewall/routestopped (Shorewall 1.3.4 and +
    • /etc/shorewall/routestopped (Shorewall 1.3.4 and later) - defines hosts accessible when Shorewall is stopped.
      • -
    • /etc/shorewall/tcrules - defines marking of packets - for later use by traffic control/shaping or policy routing.
      • -
    • /etc/shorewall/tos - defines rules for setting +
    • /etc/shorewall/tcrules - defines marking of packets + for later use by traffic control/shaping or policy routing.
      • +
    • /etc/shorewall/tos - defines rules for setting the TOS field in packet headers.
      • -
    • /etc/shorewall/tunnels - defines IPSEC, GRE and -IPIP tunnels with end-points on the firewall system.
      • -
    • /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC +
    • /etc/shorewall/tunnels - defines IPSEC, GRE and + IPIP tunnels with end-points on the firewall system.
      • +
    • /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC addresses.
      • -
    • /etc/shorewall/init - commands that you wish to execute at the beginning -of a "shorewall start" or "shorewall restart".
      • -
    • /etc/shorewall/start - commands that you wish to execute at the completion -of a "shorewall start" or "shorewall restart"
      • -
    • /etc/shorewall/stop - commands that you wish to execute at the beginning -of a "shorewall stop".
      • -
    • /etc/shorewall/stopped - commands that you wish to execute at the +
    • /etc/shorewall/init - commands that you wish to execute at the beginning + of a "shorewall start" or "shorewall restart".
      • +
    • /etc/shorewall/start - commands that you wish to execute at the completion + of a "shorewall start" or "shorewall restart"
      • +
    • /etc/shorewall/stop - commands that you wish to execute at the beginning + of a "shorewall stop".
      • +
    • /etc/shorewall/stopped - commands that you wish to execute at the completion of a "shorewall stop".
      -
      • - + +
    - -

    Comments

    - -

    You may place comments in configuration files by making the first non-whitespace - character a pound sign ("#"). You may also place comments at -the end of any line, again by delimiting the comment from the rest + +

    Comments

    + +

    You may place comments in configuration files by making the first non-whitespace + character a pound sign ("#"). You may also place comments at +the end of any line, again by delimiting the comment from the rest of the line with a pound sign.

    - +

    Examples:

    - + 
    # This is a comment
    - + 
    ACCEPT	net	fw	tcp	www	#This is an end-of-line comment
    - -

    Line Continuation

    - -

    You may continue lines in the configuration files using the usual backslash - ("\") followed immediately by a new line character.

    - + +

    Line Continuation

    + +

    You may continue lines in the configuration files using the usual backslash + ("\") followed immediately by a new line character.

    +

    Example:

    - + 
    ACCEPT	net	fw	tcp \
    smtp,www,pop3,imap  #Services running on the firewall
    - +

    Using DNS Names

    - -

    - -

    WARNING: I personally recommend strongly against - using DNS names in Shorewall configuration files. If you use DNS names - and you are called out of bed at 2:00AM because Shorewall won't start - as a result of DNS problems then don't say that you were not forewarned. -
    -

    - -

        -Tom
    -

    - -

    Beginning with Shorwall 1.3.9, Host addresses in Shorewall - configuration files may be specified as either IP addresses or DNS - Names.
    -
    - DNS names in iptables rules aren't nearly as useful as they -first appear. When a DNS name appears in a rule, the iptables utility -resolves the name to one or more IP addresses and inserts those addresses -into the rule. So changes in the DNS->IP address relationship that -occur after the firewall has started have absolutely no effect on the - firewall's ruleset.

    - -

    If your firewall rules include DNS names then:

    +

    + +

    WARNING: I personally recommend strongly against + using DNS names in Shorewall configuration files. If you use DNS names + and you are called out of bed at 2:00AM because Shorewall won't start + as a result of DNS problems then don't say that you were not forewarned. +
    +

    + +

        -Tom
    +

    + +

    Beginning with Shorwall 1.3.9, Host addresses in Shorewall + configuration files may be specified as either IP addresses or DNS + Names.
    +
    + DNS names in iptables rules aren't nearly as useful as they + first appear. When a DNS name appears in a rule, the iptables utility + resolves the name to one or more IP addresses and inserts those addresses + into the rule. So changes in the DNS->IP address relationship that + occur after the firewall has started have absolutely no effect on the + firewall's ruleset.

    + +

    If your firewall rules include DNS names then:

    +
      -
    • If your /etc/resolv.conf is wrong then your firewall won't - start.
      • -
    • If your /etc/nsswitch.conf is wrong then your firewall +
    • If your /etc/resolv.conf is wrong then your firewall won't start.
      • -
    • If your Name Server(s) is(are) down then your firewall -won't start.
      • -
    • If your startup scripts try to start your firewall before +
    • If your /etc/nsswitch.conf is wrong then your firewall + won't start.
      • +
    • If your Name Server(s) is(are) down then your firewall + won't start.
      • +
    • If your startup scripts try to start your firewall before starting your DNS server then your firewall won't start.
      -
      • -
    • Factors totally outside your control (your ISP's router +
      • +
    • Factors totally outside your control (your ISP's router is down for example), can prevent your firewall from starting.
      • -
    • You must bring up your network interfaces prior to starting - your firewall.
      -
      • - -
    +
  • You must bring up your network interfaces prior to starting + your firewall.
    +
    • -

    Each DNS name much be fully qualified and include a minumum - of two periods (although one may be trailing). This restriction is imposed - by Shorewall to insure backward compatibility with existing configuration - files.
    -
    - Examples of valid DNS names:
    -

    - - - Examples of invalid DNS names:
    + +

    Each DNS name much be fully qualified and include a minumum + of two periods (although one may be trailing). This restriction is +imposed by Shorewall to insure backward compatibility with existing +configuration files.
    +
    + Examples of valid DNS names:
    +

    - DNS names may not be used as:
    +
  • mail.shorewall.net
    • +
  • shorewall.net. (note the trailing period).
    • + + Examples of invalid DNS names:
    + + DNS names may not be used as:
    + + - These restrictions are not imposed by Shorewall simply for -your inconvenience but are rather limitations of iptables.
    - -

    Complementing an Address or Subnet

    - -

    Where specifying an IP address, a subnet or an interface, you can - precede the item with "!" to specify the complement of the item. For - example, !192.168.1.4 means "any host but 192.168.1.4". There must be -no white space following the "!".

    - -

    Comma-separated Lists

    - -

    Comma-separated lists are allowed in a number of contexts within the - configuration files. A comma separated list:

    - - - -

    Port Numbers/Service Names

    - -

    Unless otherwise specified, when giving a port number you can use - either an integer or a service name from /etc/services.

    - -

    Port Ranges

    - -

    If you need to specify a range of ports, the proper syntax is <low - port number>:<high port number>. For example, - if you want to forward the range of tcp ports 4000 through 4100 to local - host 192.168.1.3, the entry in /etc/shorewall/rules is:
    -

    - + These restrictions are not imposed by Shorewall simply for +your inconvenience but are rather limitations of iptables.
    + +

    Complementing an Address or Subnet

    + +

    Where specifying an IP address, a subnet or an interface, you can + precede the item with "!" to specify the complement of the item. For + example, !192.168.1.4 means "any host but 192.168.1.4". There must +be no white space following the "!".

    + +

    Comma-separated Lists

    + +

    Comma-separated lists are allowed in a number of contexts within the + configuration files. A comma separated list:

    + + + +

    Port Numbers/Service Names

    + +

    Unless otherwise specified, when giving a port number you can use + either an integer or a service name from /etc/services.

    + +

    Port Ranges

    + +

    If you need to specify a range of ports, the proper syntax is <low + port number>:<high port number>. For example, + if you want to forward the range of tcp ports 4000 through 4100 to +local host 192.168.1.3, the entry in /etc/shorewall/rules is:
    +

    + 
         DNAT	net	loc:192.168.1.3	tcp	4000:4100
    - -

    Using Shell Variables

    - -

    You may use the /etc/shorewall/params file to set shell variables - that you can then use in some of the other configuration files.

    - + +

    Using Shell Variables

    + +

    You may use the /etc/shorewall/params file to set shell variables + that you can then use in some of the other configuration files.

    +

    It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally - within the Shorewall programs

    - + size="1">     to distinguish them from variables used internally + within the Shorewall programs

    +

    Example:

    - -
    - - 
    NET_IF=eth0
    NET_BCAST=130.252.100.255
    NET_OPTIONS=noping,norfc1918
    -
    - -


    - Example (/etc/shorewall/interfaces record):

    - - -
    - - 
    net $NET_IF $NET_BCAST $NET_OPTIONS
    -
    -     - -

    The result will be the same as if the record had been written

    - - -
    - - 
    net eth0 130.252.100.255 noping,norfc1918
    -
    -     - -

    Variables may be used anywhere in the other configuration - files.

    - -

    Using MAC Addresses

    - -

    Media Access Control (MAC) addresses can be used to specify packet - source in several of the configuration files. To use this feature, - your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) - included.

    - -

    MAC addresses are 48 bits wide and each Ethernet Controller has a - unique MAC address.
    -
    - In GNU/Linux, MAC addresses are usually written as a -series of 6 hex numbers separated by colons. Example:
    -
    -      [root@gateway root]# ifconfig eth0
    -      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
    -      inet addr:206.124.146.176 Bcast:206.124.146.255 - Mask:255.255.255.0
    -      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    -      RX packets:2398102 errors:0 dropped:0 overruns:0 - frame:0
    -      TX packets:3044698 errors:0 dropped:0 overruns:0 - carrier:0
    -      collisions:30394 txqueuelen:100
    -      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 - (1582.8 Mb)
    -      Interrupt:11 Base address:0x1800
    -
    - Because Shorewall uses colons as a separator for address - fields, Shorewall requires MAC addresses to be written in another - way. In Shorewall, MAC addresses begin with a tilde ("~") and -consist of 6 hex numbers separated by hyphens. In Shorewall, the -MAC address in the example above would be written "~02-00-08-E3-FA-55".
    -

    - -

    Note: It is not necessary to use the special Shorewall notation - in the /etc/shorewall/maclist file.
    -

    - -

    Logging

    - By default, Shorewall directs NetFilter to log using syslog (8). Syslog - classifies log messages by a facility and a priority (using - the notation facility.priority).
    -
    - The facilities defined by syslog are auth, authpriv, cron, daemon, -kern, lpr, mail, mark, news, syslog, user, uucp and local0 through -local7.
    -
    - Throughout the Shorewall documentation, I will use the term level - rather than priority since level is the term used by NetFilter. - The syslog documentation uses the term priority.
    - -

    Syslog Levels
    -

    - Syslog levels are a method of describing to syslog (8) the importance - of a message and a number of Shorewall parameters have a syslog level -as their value.
    -
    - Valid levels are:
    -
    -        7       debug
    -        6       info
    -        5       notice
    -        4       warning
    -        3       err
    -        2       crit
    -        1       alert
    -        0       emerg
    -
    - For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall - log messages are generated by NetFilter and are logged using the kern - facility and the level that you specify. If you are unsure of the level - to choose, 6 (info) is a safe bet. You may specify levels by name or by - number.
    -
    - Syslogd writes log messages to files (typically in /var/log/*) based -on their facility and level. The mapping of these facility/level pairs to -log files is done in /etc/syslog.conf (5). If you make changes to this file, - you must restart syslogd before the changes can take effect.
    - -

    Configuring a Separate Log for Shorewall Messages

    - There are a couple of limitations to syslogd-based logging:
    - -
      -
    1. If you give, for example, kern.info it's own log destination then - that destination will also receive all kernel messages of levels 5 (notice) - through 0 (emerg).
      2. -
    2. All kernel.info messages will go to that destination and not just - those from NetFilter.
      -
      3. - -
    - Beginning with Shorewall version 1.3.12, if your kernel has ULOG target - support (and most vendor-supplied kernels do), you may also specify a log -level of ULOG (must be all caps). When ULOG is used, Shorewall will direct -netfilter to log the related messages via the ULOG target which will send -them to a process called 'ulogd'. The ulogd program is available from http://www.gnumonks.org/projects/ulogd -and can be configured to log all Shorewall message to their own log file.
    -
    - Download the ulod tar file and:
    - -
      -
    1. cd /usr/local/src (or wherever you do your builds)
      2. -
    2. tar -zxf source-tarball-that-you-downloaded
      3. -
    3. cd ulogd-version
      -
      4. -
    4. ./configure
      5. -
    5. make
      6. -
    6. make install
      -
      7. - -
    - If you are like me and don't have a development environment on your firewall, -you can do the first five steps on another system then either NFS mount your -/usr/local/src directory or tar up the /usr/local/src/ulogd-version -directory and move it to your firewall system.
    -
    - Now on the firewall system, edit /usr/local/etc/ulogd.conf and set:
    - -
      -
    1. syslogfile <file that you wish to log to>
      2. -
    2. syslogsync 1
      3. - -
    - I also copied the file /usr/local/src/ulogd-version/ulogd.init to -/etc/init.d/ulogd. I had to edit the line that read "daemon /usr/local/sbin/ulogd" -to read daemon /usr/local/sbin/ulogd -d". On a RedHat system, a simple "chkconfig ---level 3 ulogd on" starts ulogd during boot up. Your init system may need -something else done to activate the script.
    -
    - Finally edit /etc/shorewall/shorewall.conf and set LOGFILE=<file that -you wish to log to>. This tells the /sbin/shorewall program where to -look for the log when processing its "show log", "logwatch" and "monitor" -commands.
    + +
    -

    Shorewall Configurations

    - -

    Shorewall allows you to have configuration directories other than /etc/shorewall. - The shorewall start and - restart commands allow you to specify an alternate configuration - directory and Shorewall will use the files in the alternate directory - rather than the corresponding files in /etc/shorewall. The alternate directory - need not contain a complete configuration; those files not in the alternate - directory will be read from /etc/shorewall.

    - -

    This facility permits you to easily create a test or temporary configuration - by:

    - + 
    NET_IF=eth0
    NET_BCAST=130.252.100.255
    NET_OPTIONS=noping,norfc1918
    +
    + +


    + Example (/etc/shorewall/interfaces record):

    + + +
    + + 
    net $NET_IF $NET_BCAST $NET_OPTIONS
    +
    +     + +

    The result will be the same as if the record had been written

    + + +
    + + 
    net eth0 130.252.100.255 noping,norfc1918
    +
    +     + +

    Variables may be used anywhere in the other configuration + files.

    + +

    Using MAC Addresses

    + +

    Media Access Control (MAC) addresses can be used to specify packet + source in several of the configuration files. To use this feature, + your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) + included.

    + +

    MAC addresses are 48 bits wide and each Ethernet Controller has a + unique MAC address.
    +
    + In GNU/Linux, MAC addresses are usually written as a +series of 6 hex numbers separated by colons. Example:
    +
    +      [root@gateway root]# ifconfig eth0
    +      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
    +      inet addr:206.124.146.176 Bcast:206.124.146.255 + Mask:255.255.255.0
    +      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    +      RX packets:2398102 errors:0 dropped:0 overruns:0 + frame:0
    +      TX packets:3044698 errors:0 dropped:0 overruns:0 + carrier:0
    +      collisions:30394 txqueuelen:100
    +      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 + (1582.8 Mb)
    +      Interrupt:11 Base address:0x1800
    +
    + Because Shorewall uses colons as a separator for address + fields, Shorewall requires MAC addresses to be written in another + way. In Shorewall, MAC addresses begin with a tilde ("~") and consist + of 6 hex numbers separated by hyphens. In Shorewall, the MAC address + in the example above would be written "~02-00-08-E3-FA-55".
    +

    + +

    Note: It is not necessary to use the special Shorewall notation + in the /etc/shorewall/maclist file.
    +

    + +

    Shorewall Configurations

    + +

    Shorewall allows you to have configuration directories other than /etc/shorewall. + The shorewall start +and restart commands allow you to specify an alternate configuration + directory and Shorewall will use the files in the alternate directory + rather than the corresponding files in /etc/shorewall. The alternate +directory need not contain a complete configuration; those files not +in the alternate directory will be read from /etc/shorewall.

    + +

    This facility permits you to easily create a test or temporary configuration + by:

    +
      -
    1. copying the files that need modification from -/etc/shorewall to a separate directory;
      2. -
    2. modify those files in the separate directory; -and
      3. -
    3. specifying the separate directory in a shorewall - start or shorewall restart command (e.g., shorewall -c /etc/testconfig - restart ).
      4. - +
    4. copying the files that need modification from + /etc/shorewall to a separate directory;
      5. +
    5. modify those files in the separate directory; + and
      6. +
    6. specifying the separate directory in a shorewall + start or shorewall restart command (e.g., shorewall -c /etc/testconfig + restart ).
      7. +
    - -

    Updated 12/20/2002 - Tom Eastep + +

    Updated 12/29/2002 - Tom Eastep

    - -

    Copyright - © 2001, 2002 Thomas M. Eastep.
    -

    + +

    Copyright + © 2001, 2002 Thomas M. Eastep.
    +

    +


    diff --git a/Shorewall-docs/errata.htm b/Shorewall-docs/errata.htm index f9bc052e0..3ff84aea1 100644 --- a/Shorewall-docs/errata.htm +++ b/Shorewall-docs/errata.htm @@ -1,564 +1,579 @@ - + Shorewall 1.3 Errata - + - + - + - + - - - + + - - - + + + +
    - +
    +

    Shorewall Errata/Upgrade Issues

    -
    - +

    IMPORTANT

    - +
      -
    1. - -

      If you use a Windows system to download - a corrected script, be sure to run the script through - dos2unix after you have moved +

    2. + +

      If you use a Windows system to download + a corrected script, be sure to run the script through + dos2unix after you have moved it to your Linux system.

      -
      3. -
    3. - -

      If you are installing Shorewall for the -first time and plan to use the .tgz and install.sh script, you can -untar the archive, replace the 'firewall' script in the untarred directory +

      4. +
    4. + +

      If you are installing Shorewall for the first +time and plan to use the .tgz and install.sh script, you can untar +the archive, replace the 'firewall' script in the untarred directory with the one you downloaded below, and then run install.sh.

      -
      5. -
    5. - -

      When the instructions say to install a corrected - firewall script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall - or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to -overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD -/etc/shorewall/firewall or /var/lib/shorewall/firewall before -you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall - are symbolic links that point to the 'shorewall' file used by your - system initialization scripts to start Shorewall during boot. -It is that file that must be overwritten with the corrected -script.

      -
      6. -
    6. -

      DO NOT INSTALL CORRECTED COMPONENTS - ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. For +

      7. +
    7. + +

      When the instructions say to install a corrected + firewall script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall + or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to overwrite + the existing file. DO NOT REMOVE OR RENAME THE OLD /etc/shorewall/firewall + or /var/lib/shorewall/firewall before you do that. /etc/shorewall/firewall + and /var/lib/shorewall/firewall are symbolic links that point + to the 'shorewall' file used by your system initialization scripts + to start Shorewall during boot. It is that file that must be overwritten + with the corrected script.

      +
      8. +
    8. +

      DO NOT INSTALL CORRECTED COMPONENTS + ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. For example, do NOT install the 1.3.9a firewall script if you are running 1.3.7c.
      -

      -
      9. - +

      + +
    - + - -
    + +

    Problems in Version 1.3

    -

    Version 1.3.11a

    + +

    Version 1.3.12 LRP

      -
    • This -copy of /etc/shorewall/rfc1918 reflects the recent allocation of 82.0.0.0/8.
      +
    • The .lrp was missing the /etc/shorewall/routestopped file -- a new +lrp (shorwall-1.3.12a.lrp) has been released which corrects this problem.
    +

    Version 1.3.11a

    + + +

    Version 1.3.11

    - +
      -
    • When installing/upgrading using the .rpm, you may receive the following - warnings:
      -
      -      user teastep does not exist - using root
      -      group teastep does not exist - using root
      -
      - These warnings are harmless and may be ignored. Users downloading the -.rpm from shorewall.net or mirrors should no longer see these warnings as +
    • When installing/upgrading using the .rpm, you may receive the following + warnings:
      +
      +      user teastep does not exist - using root
      +      group teastep does not exist - using root
      +
      + These warnings are harmless and may be ignored. Users downloading the +.rpm from shorewall.net or mirrors should no longer see these warnings as the .rpm you will get from there has been corrected.
      • -
    • DNAT rules that exclude a source subzone (SOURCE column contains -! followed by a sub-zone list) result in an error message and Shorewall -fails to start.
      +
    • DNAT rules that exclude a source subzone (SOURCE column contains +! followed by a sub-zone list) result in an error message and Shorewall fails + to start.
      +
      + Install this + corrected script in /usr/lib/shorewall/firewall to correct this problem. + Thanks go to Roger Aich who analyzed this problem and provided a fix.

      - Install this - corrected script in /usr/lib/shorewall/firewall to correct this problem. -Thanks go to Roger Aich who analyzed this problem and provided a fix.
      -
      - This problem is corrected in version 1.3.11a.
      -
      • - + This problem is corrected in version 1.3.11a.
      + +
    - +

    Version 1.3.10

    - +
      -
    • If you experience problems connecting to a PPTP server running -on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, +
    • If you experience problems connecting to a PPTP server running + on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, this - version of the firewall script may help. Please report any cases where - installing this script in /usr/lib/shorewall/firewall solved your connection - problems. Beginning with version 1.3.10, it is safe to save the old version - of /usr/lib/shorewall/firewall before copying in the new one since /usr/lib/shorewall/firewall + href="http://www.shorewall.net/pub/shorewall/errata/1.3.10/firewall">this + version of the firewall script may help. Please report any cases where + installing this script in /usr/lib/shorewall/firewall solved your connection + problems. Beginning with version 1.3.10, it is safe to save the old version + of /usr/lib/shorewall/firewall before copying in the new one since /usr/lib/shorewall/firewall is the real script now and not just a symbolic link to the real script.
      -
      • - + +
    - +

    Version 1.3.9a

    - -
      -
    • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No - then the following message appears during "shorewall [re]start":
      • - -
    +
      +
    • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No + then the following message appears during "shorewall [re]start":
      • + +
    + 
              recalculate_interfacess: command not found
    - +
    The updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - corrects this problem.Copy the script to /usr/lib/shorewall/firewall as - described above.
    -
    - -
    Alternatively, edit /usr/lob/shorewall/firewall and change the - single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' - to 'recalculate_interface'.
    -
    - -
      -
    • The installer (install.sh) issues a misleading message "Common - functions installed in /var/lib/shorewall/functions" whereas the file -is installed in /usr/lib/shorewall/functions. The installer also performs -incorrectly when updating old configurations that had the file /etc/shorewall/functions. - Here - is an updated version that corrects these problems.
      -
      • - -
    + target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + corrects this problem.Copy the script to /usr/lib/shorewall/firewall +as described above.
    + + +
    Alternatively, edit /usr/lob/shorewall/firewall and change the + single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' + to 'recalculate_interface'.
    +
    -

    Version 1.3.9

    - TUNNELS Broken in 1.3.9!!! There is an updated firewall script - at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall as described above.
    -
    - Version 1.3.8
      -
    • Use of shell variables in the LOG LEVEL or SYNPARMS columns - of the policy file doesn't work.
      • -
    • A DNAT rule with the same original and new IP addresses -but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24 - tcp 25 - 10.1.1.1")
      -
      • - +
    • The installer (install.sh) issues a misleading message "Common + functions installed in /var/lib/shorewall/functions" whereas the file is + installed in /usr/lib/shorewall/functions. The installer also performs incorrectly + when updating old configurations that had the file /etc/shorewall/functions. + Here + is an updated version that corrects these problems.
      +
      • +
    - Installing - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects these problems. - -

    Version 1.3.7b

    - -

    DNAT rules where the source zone is 'fw' ($FW) - result in an error message. Installing - - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this problem.

    - -

    Version 1.3.7a

    - -

    "shorewall refresh" is not creating the proper - rule for FORWARDPING=Yes. Consequently, after - "shorewall refresh", the firewall will not forward - icmp echo-request (ping) packets. Installing - - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this problem.

    - -

    Version <= 1.3.7a

    - -

    If "norfc1918" and "dhcp" are both specified as - options on a given interface then RFC 1918 - checking is occurring before DHCP checking. This - means that if a DHCP client broadcasts using an - RFC 1918 source address, then the firewall will - reject the broadcast (usually logging it). This - has two problems:

    - -
      -
    1. If the firewall is running - a DHCP server, the client won't be able - to obtain an IP address lease from -that server.
      2. -
    2. With this order of checking, - the "dhcp" option cannot be used as -a noise-reduction measure where there -are both dynamic and static clients on -a LAN segment.
      3. - -
    - -

    - This version of the 1.3.7a firewall script - corrects the problem. It must be installed - in /var/lib/shorewall as described above.

    - -

    Version 1.3.7

    - -

    Version 1.3.7 dead on arrival -- please use - version 1.3.7a and check your version against - these md5sums -- if there's a difference, please - download again.

    - -
    	d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
    	6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
    	3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp
    - -

    In other words, type "md5sum <whatever package you downloaded> - and compare the result with what you see above.

    - -

    I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the - .7 version in each sequence from now on.

    - -

    Version 1.3.6

    - + +

    Version 1.3.9

    + TUNNELS Broken in 1.3.9!!! There is an updated firewall +script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + -- copy that file to /usr/lib/shorewall/firewall as described above.
    +
    + Version 1.3.8
      -
    • - -

      If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf, - an error occurs when the firewall script attempts to add -an SNAT alias.

      -
      • -
    • - -

      The logunclean and dropunclean options - cause errors during startup when Shorewall is run with iptables - 1.2.7.

      +
    • Use of shell variables in the LOG LEVEL or SYNPARMS columns + of the policy file doesn't work.
      • +
    • A DNAT rule with the same original and new IP addresses +but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24 + tcp 25 - 10.1.1.1")
    - + Installing + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects these problems. + +

    Version 1.3.7b

    + +

    DNAT rules where the source zone is 'fw' ($FW) + result in an error message. Installing + + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects this problem.

    + +

    Version 1.3.7a

    + +

    "shorewall refresh" is not creating the proper + rule for FORWARDPING=Yes. Consequently, after + "shorewall refresh", the firewall will not forward + icmp echo-request (ping) packets. Installing + + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects this problem.

    + +

    Version <= 1.3.7a

    + +

    If "norfc1918" and "dhcp" are both specified as + options on a given interface then RFC 1918 + checking is occurring before DHCP checking. This + means that if a DHCP client broadcasts using an + RFC 1918 source address, then the firewall will + reject the broadcast (usually logging it). This + has two problems:

    + +
      +
    1. If the firewall is running + a DHCP server, the client won't be +able to obtain an IP address lease +from that server.
      2. +
    2. With this order of checking, + the "dhcp" option cannot be used as + a noise-reduction measure where there + are both dynamic and static clients +on a LAN segment.
      3. + +
    + + +

    + This version of the 1.3.7a firewall script + corrects the problem. It must be installed + in /var/lib/shorewall as described above.

    + +

    Version 1.3.7

    + +

    Version 1.3.7 dead on arrival -- please use + version 1.3.7a and check your version against + these md5sums -- if there's a difference, please + download again.

    + +
    	d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
    	6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
    	3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp
    + +

    In other words, type "md5sum <whatever package you downloaded> + and compare the result with what you see above.

    + +

    I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the + .7 version in each sequence from now on.

    + +

    Version 1.3.6

    + +
      +
    • + +

      If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf, + an error occurs when the firewall script attempts to add +an SNAT alias.

      +
      • +
    • + +

      The logunclean and dropunclean options + cause errors during startup when Shorewall is run with iptables + 1.2.7.

      +
      • + +
    +

    These problems are fixed in - this correct firewall script which must be installed in - /var/lib/shorewall/ as described above. These problems are also - corrected in version 1.3.7.

    - + href="http://www.shorewall.net/pub/shorewall/errata/1.3.6/firewall"> + this correct firewall script which must be installed in + /var/lib/shorewall/ as described above. These problems are also + corrected in version 1.3.7.

    +

    Two-interface Samples 1.3.6 (file two-interfaces.tgz)

    - -

    A line was inadvertently deleted from the "interfaces - file" -- this line should be added back in if the version that you + +

    A line was inadvertently deleted from the "interfaces + file" -- this line should be added back in if the version that you downloaded is missing it:

    - +

    net    eth0    detect    routefilter,dhcp,norfc1918

    - -

    If you downloaded two-interfaces-a.tgz then the above - line should already be in the file.

    - + +

    If you downloaded two-interfaces-a.tgz then the above + line should already be in the file.

    +

    Version 1.3.5-1.3.5b

    - -

    The new 'proxyarp' interface option doesn't work :-( - This is fixed in - this corrected firewall script which must be installed in - /var/lib/shorewall/ as described above.

    - + +

    The new 'proxyarp' interface option doesn't work :-( + This is fixed in + this corrected firewall script which must be installed in + /var/lib/shorewall/ as described above.

    +

    Versions 1.3.4-1.3.5a

    - -

    Prior to version 1.3.4, host file entries such as the - following were allowed:

    - -
    + +

    Prior to version 1.3.4, host file entries such as the + following were allowed:

    + +
    	adm	eth0:1.2.4.5,eth0:5.6.7.8
    -
    - -
    -

    That capability was lost in version 1.3.4 so that it is only - possible to  include a single host specification on each line. -This problem is corrected by this - modified 1.3.5a firewall script. Install the script in /var/lib/pub/shorewall/firewall +

    + +
    +

    That capability was lost in version 1.3.4 so that it is only + possible to  include a single host specification on each line. This + problem is corrected by this + modified 1.3.5a firewall script. Install the script in /var/lib/pub/shorewall/firewall as instructed above.

    -
    - -
    +
    + +

    This problem is corrected in version 1.3.5b.

    -
    - +
    +

    Version 1.3.5

    - -

    REDIRECT rules are broken in this version. Install - - this corrected firewall script in /var/lib/pub/shorewall/firewall - as instructed above. This problem is corrected in version + +

    REDIRECT rules are broken in this version. Install + + this corrected firewall script in /var/lib/pub/shorewall/firewall + as instructed above. This problem is corrected in version 1.3.5a.

    - +

    Version 1.3.n, n < 4

    - -

    The "shorewall start" and "shorewall restart" commands - to not verify that the zones named in the /etc/shorewall/policy -file have been previously defined in the /etc/shorewall/zones -file. The "shorewall check" command does perform this verification -so it's a good idea to run that command after you have made configuration + +

    The "shorewall start" and "shorewall restart" commands + to not verify that the zones named in the /etc/shorewall/policy file + have been previously defined in the /etc/shorewall/zones file. +The "shorewall check" command does perform this verification so +it's a good idea to run that command after you have made configuration changes.

    - +

    Version 1.3.n, n < 3

    - -

    If you have upgraded from Shorewall 1.2 and after - "Activating rules..." you see the message: "iptables: No chains/target/match - by that name" then you probably have an entry in /etc/shorewall/hosts - that specifies an interface that you didn't include in /etc/shorewall/interfaces. - To correct this problem, you must add an entry to /etc/shorewall/interfaces. - Shorewall 1.3.3 and later versions produce a clearer error + +

    If you have upgraded from Shorewall 1.2 and after + "Activating rules..." you see the message: "iptables: No chains/target/match + by that name" then you probably have an entry in /etc/shorewall/hosts + that specifies an interface that you didn't include in /etc/shorewall/interfaces. + To correct this problem, you must add an entry to /etc/shorewall/interfaces. + Shorewall 1.3.3 and later versions produce a clearer error message in this case.

    - +

    Version 1.3.2

    - -

    Until approximately 2130 GMT on 17 June 2002, the - download sites contained an incorrect version of the .lrp file. That - file can be identified by its size (56284 bytes). The correct -version has a size of 38126 bytes.

    - + +

    Until approximately 2130 GMT on 17 June 2002, the + download sites contained an incorrect version of the .lrp file. That + file can be identified by its size (56284 bytes). The correct version + has a size of 38126 bytes.

    +
      -
    • The code to detect a duplicate interface entry - in /etc/shorewall/interfaces contained a typo that prevented -it from working correctly.
      • -
    • "NAT_BEFORE_RULES=No" was broken; it behaved -just like "NAT_BEFORE_RULES=Yes".
      • - +
    • The code to detect a duplicate interface entry + in /etc/shorewall/interfaces contained a typo that prevented + it from working correctly.
      • +
    • "NAT_BEFORE_RULES=No" was broken; it behaved + just like "NAT_BEFORE_RULES=Yes".
      • +
    - +

    Both problems are corrected in - this script which should be installed in /var/lib/shorewall + href="http://www.shorewall.net/pub/shorewall/errata/1.3.2/firewall"> + this script which should be installed in /var/lib/shorewall as described above.

    - +
      -
    • - -

      The IANA have just announced the allocation of subnet +

    • + +

      The IANA have just announced the allocation of subnet 221.0.0.0/8. This - updated rfc1918 file reflects that allocation.

      -
      • - + href="http://www.shorewall.net/pub/shorewall/errata/1.3.2/rfc1918"> + updated rfc1918 file reflects that allocation.

      + +
    - +

    Version 1.3.1

    - +
      -
    • TCP SYN packets may be double counted when - LIMIT:BURST is included in a CONTINUE or ACCEPT policy (i.e., +
    • TCP SYN packets may be double counted when + LIMIT:BURST is included in a CONTINUE or ACCEPT policy (i.e., each packet is sent through the limit chain twice).
      • -
    • An unnecessary jump to the policy chain is sometimes - generated for a CONTINUE policy.
      • -
    • When an option is given for more than one interface - in /etc/shorewall/interfaces then depending on the option, - Shorewall may ignore all but the first appearence of the +
    • An unnecessary jump to the policy chain is +sometimes generated for a CONTINUE policy.
      • +
    • When an option is given for more than one interface + in /etc/shorewall/interfaces then depending on the option, + Shorewall may ignore all but the first appearence of the option. For example:
      -
      - net    eth0    dhcp
      - loc    eth1    dhcp
      -
      - Shorewall will ignore the 'dhcp' on eth1.
      • -
    • Update 17 June 2002 - The bug described in the - prior bullet affects the following options: dhcp, dropunclean, - logunclean, norfc1918, routefilter, multi, filterping and - noping. An additional bug has been found that affects only - the 'routestopped' option.
      -
      - Users who downloaded the corrected script prior -to 1850 GMT today should download and install the corrected - script again to ensure that this second problem is corrected.
      • - +
      + net    eth0    dhcp
      + loc    eth1    dhcp
      +
      + Shorewall will ignore the 'dhcp' on eth1. +
    • Update 17 June 2002 - The bug described in +the prior bullet affects the following options: dhcp, +dropunclean, logunclean, norfc1918, routefilter, multi, +filterping and noping. An additional bug has been found +that affects only the 'routestopped' option.
      +
      + Users who downloaded the corrected script prior +to 1850 GMT today should download and install the corrected + script again to ensure that this second problem is corrected.
      • +
    - +

    These problems are corrected in - this firewall script which should be installed in /etc/shorewall/firewall + href="http://www.shorewall.net/pub/shorewall/errata/1.3.1/firewall"> + this firewall script which should be installed in /etc/shorewall/firewall as described above.

    - +

    Version 1.3.0

    - +
      -
    • Folks who downloaded 1.3.0 from the links on -the download page before 23:40 GMT, 29 May 2002 may have -downloaded 1.2.13 rather than 1.3.0. The "shorewall version" -command will tell you which version that you have installed.
      • -
    • The documentation NAT.htm file uses non-existent - wallpaper and bullet graphic files. The - corrected version is here.
      • - +
    • Folks who downloaded 1.3.0 from the links on + the download page before 23:40 GMT, 29 May 2002 may have + downloaded 1.2.13 rather than 1.3.0. The "shorewall version" + command will tell you which version that you have installed.
      • +
    • The documentation NAT.htm file uses non-existent + wallpaper and bullet graphic files. The + corrected version is here.
      • +
    - -
    + +

    Upgrade Issues

    - +

    The upgrade issues have moved to a separate page.

    - -
    -

    Problem with + +
    +

    Problem with iptables version 1.2.3

    - -
    -

    There are a couple of serious bugs in iptables 1.2.3 that - prevent it from working with Shorewall. Regrettably, RedHat - released this buggy iptables in RedHat 7.2. 

    - + +
    +

    There are a couple of serious bugs in iptables 1.2.3 that + prevent it from working with Shorewall. Regrettably, RedHat + released this buggy iptables in RedHat 7.2. 

    + +

    I have built a - corrected 1.2.3 rpm which you can download here  and I have also - built an -iptables-1.2.4 rpm which you can download here. If you are currently - running RedHat 7.1, you can install either of these RPMs - before you upgrade to RedHat 7.2.

    - -

    Update 11/9/2001: RedHat - has released an iptables-1.2.4 RPM of their own which you can download - from http://www.redhat.com/support/errata/RHSA-2001-144.html. - I have installed this RPM on my firewall and it works fine.

    - -

    If you would like to patch iptables 1.2.3 yourself, - the patches are available for download. This patch - which corrects a problem with parsing of the --log-level specification - while this patch - corrects a problem in handling the  TOS target.

    - -

    To install one of the above patches:

    - -
      -
    • cd iptables-1.2.3/extensions
      • -
    • patch -p0 < the-patch-file
      • - -
    -
    + href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm"> + corrected 1.2.3 rpm which you can download here  and I have also + built an + iptables-1.2.4 rpm which you can download here. If you are currently + running RedHat 7.1, you can install either of these RPMs + before you upgrade to RedHat 7.2.

    -

    Problems with kernels >= 2.4.18 - and RedHat iptables

    - -
    -

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 - may experience the following:

    - -
    - - 
    # shorewall start
    Processing /etc/shorewall/shorewall.conf ...
    Processing /etc/shorewall/params ...
    Starting Shorewall...
    Loading Modules...
    Initializing...
    Determining Zones...
    Zones: net
    Validating interfaces file...
    Validating hosts file...
    Determining Hosts in Zones...
    Net Zone: eth0:0.0.0.0/0
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    -
    - -

    The RedHat iptables RPM is compiled with debugging enabled but the - user-space debugging code was not updated to reflect recent changes in - the Netfilter 'mangle' table. You can correct the problem by installing - - this iptables RPM. If you are already running a 1.2.5 version - of iptables, you will need to specify the --oldpackage option to rpm - (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    -
    +

    Update 11/9/2001: RedHat + has released an iptables-1.2.4 RPM of their own which you can download + from http://www.redhat.com/support/errata/RHSA-2001-144.html. + I have installed this RPM on my firewall and it works fine.

    - -

    Problems installing/upgrading + +

    If you would like to patch iptables 1.2.3 yourself, + the patches are available for download. This patch + which corrects a problem with parsing of the --log-level specification + while this patch + corrects a problem in handling the  TOS target.

    + + +

    To install one of the above patches:

    + +
      +
    • cd iptables-1.2.3/extensions
      • +
    • patch -p0 < the-patch-file
      • + +
    +

    + +

    Problems with kernels >= 2.4.18 + and RedHat iptables

    + +
    +

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 + may experience the following:

    + +
    + + 
    # shorewall start
    Processing /etc/shorewall/shorewall.conf ...
    Processing /etc/shorewall/params ...
    Starting Shorewall...
    Loading Modules...
    Initializing...
    Determining Zones...
    Zones: net
    Validating interfaces file...
    Validating hosts file...
    Determining Hosts in Zones...
    Net Zone: eth0:0.0.0.0/0
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    +
    + +

    The RedHat iptables RPM is compiled with debugging enabled but the + user-space debugging code was not updated to reflect recent changes in + the Netfilter 'mangle' table. You can correct the problem by installing + + this iptables RPM. If you are already running a 1.2.5 version + of iptables, you will need to specify the --oldpackage option to +rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    +
    + + +

    Problems installing/upgrading RPM on SuSE

    - -

    If you find that rpm complains about a conflict - with kernel <= 2.2 yet you have a 2.4 kernel - installed, simply use the "--nodeps" option to - rpm.

    - + +

    If you find that rpm complains about a conflict + with kernel <= 2.2 yet you have a 2.4 kernel + installed, simply use the "--nodeps" option to + rpm.

    +

    Installing: rpm -ivh --nodeps <shorewall rpm>

    - +

    Upgrading: rpm -Uvh --nodeps <shorewall rpm>

    - -

    Problems with - iptables version 1.2.7 and MULTIPORT=Yes

    - -

    The iptables 1.2.7 release of iptables has made - an incompatible change to the syntax used to - specify multiport match rules; as a consequence, - if you install iptables 1.2.7 you must be running - Shorewall 1.3.7a or later or:

    - + +

    Problems with + iptables version 1.2.7 and MULTIPORT=Yes

    + +

    The iptables 1.2.7 release of iptables has made + an incompatible change to the syntax used to + specify multiport match rules; as a consequence, + if you install iptables 1.2.7 you must be running + Shorewall 1.3.7a or later or:

    +
      -
    • set MULTIPORT=No in - /etc/shorewall/shorewall.conf; or
      • -
    • if you are running Shorewall - 1.3.6 you may install - - this firewall script in /var/lib/shorewall/firewall +
    • set MULTIPORT=No in + /etc/shorewall/shorewall.conf; or
      • +
    • if you are running Shorewall + 1.3.6 you may install + + this firewall script in /var/lib/shorewall/firewall as described above.
      • - +
    - +

    Problems with RH Kernel 2.4.18-10 and NAT
    -

    - /etc/shorewall/nat entries of the following form will result in Shorewall - being unable to start:
    -
    - +

    + /etc/shorewall/nat entries of the following form will result in +Shorewall being unable to start:
    +
    + 
    #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
    192.0.2.22      eth0            192.168.9.22    yes                     yes
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - Error message is:
    - + Error message is:
    + 
    Setting up NAT...
    iptables: Invalid argument
    Terminated

    - The solution is to put "no" in the LOCAL column. Kernel support for - LOCAL=yes has never worked properly and 2.4.18-10 has disabled it. The -2.4.19 kernel contains corrected support under a new kernel configuraiton -option; see http://www.shorewall.net/Documentation.htm#NAT
    - -

    Last updated 12/3/2002 - - Tom Eastep

    - -

    Copyright + The solution is to put "no" in the LOCAL column. Kernel support +for LOCAL=yes has never worked properly and 2.4.18-10 has disabled it. +The 2.4.19 kernel contains corrected support under a new kernel configuraiton + option; see http://www.shorewall.net/Documentation.htm#NAT
    + +

    Last updated 12/28/2002 - + Tom Eastep

    + +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    +

    +



    diff --git a/Shorewall-docs/gnu_mailman.htm b/Shorewall-docs/gnu_mailman.htm index e6e3076d7..840c088d7 100644 --- a/Shorewall-docs/gnu_mailman.htm +++ b/Shorewall-docs/gnu_mailman.htm @@ -1,76 +1,79 @@ - + - + - + - + GNU Mailman - + - - - + + - - - + Way + + + +
    +

    GNU Mailman/Postfix the Easy -Way

    -
    - +

     

    - +

    The following was posted on the Postfix mailing list on 5/4/2002 by Michael - Tokarev as a suggested addition to the Postfix FAQ.

    - + Tokarev as a suggested addition to the Postfix FAQ. +

    Q: Mailman does not work with Postfix, complaining about GID mismatch
    -
    - A: Mailman uses a setgid wrapper that is designed to be used in system-wide - aliases file so that rest of mailman's mail handling processes will run +
    + A: Mailman uses a setgid wrapper that is designed to be used in system-wide + aliases file so that rest of mailman's mail handling processes will run with proper uid/gid. Postfix has an ability to run a command specified in an alias as owner of that alias, thus mailman's wrapper is not needed here. -The best method to invoke mailman's mail handling via aliases is to use + The best method to invoke mailman's mail handling via aliases is to use separate alias file especially for mailman, and made it owned by mailman and group mailman. Like:
    -
    - alias_maps = hash:/etc/postfix/aliases, hash:/var/mailman/aliases
    -
    - Make sure that /var/mailman/aliases.db is owned by mailman user (this may -be done by executing postalias as mailman userid).
    -
    - Next, instead of using mailman-suggested aliases entries with wrapper, use -the following:
    -
    - instead of
    - mailinglist: /var/mailman/mail/wrapper post mailinglist
    - mailinglist-admin: /var/mailman/mail/wrapper mailowner mailinglist
    - mailinglist-request: /var/mailman/mail/wrapper mailcmd mailinglist
    - ...
    -
    - use
    - mailinglist: /var/mailman/scripts/post mailinglist
    - mailinglist-admin: /var/mailman/scripts/mailowner mailinglist
    - mailinglist-request: /var/mailman/scripts/mailcmd mailinglist
    - ...

    - -

    The Shorewall mailing lists are currently running Postfix 1.1.11 together - with the stock RedHat Mailman-2.0.13 RPM configured as shown above.

    - -

    Last updated 9/14/2002 - + alias_maps = hash:/etc/postfix/aliases, hash:/var/mailman/aliases
    +
    + Make sure that /var/mailman/aliases.db is owned by mailman user (this +may be done by executing postalias as mailman userid).
    +
    + Next, instead of using mailman-suggested aliases entries with wrapper, +use the following:
    +
    + instead of
    + mailinglist: /var/mailman/mail/wrapper post mailinglist
    + mailinglist-admin: /var/mailman/mail/wrapper mailowner mailinglist
    + mailinglist-request: /var/mailman/mail/wrapper mailcmd mailinglist
    + ...
    +
    + use
    + mailinglist: /var/mailman/scripts/post mailinglist
    + mailinglist-admin: /var/mailman/scripts/mailowner mailinglist
    + mailinglist-request: /var/mailman/scripts/mailcmd mailinglist
    + ...

    + +

    The above tip works with Mailman 2.0; Mailman 2.1 has adopted something +very similar so that no workaround is necessary. See the README.POSTFIX file +included with Mailman-2.1. 

    + +

    Last updated 12/29/2002 - Tom Eastep

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.

    +

    +
    diff --git a/Shorewall-docs/mailing_list.htm b/Shorewall-docs/mailing_list.htm index f023d06e8..1c4153246 100644 --- a/Shorewall-docs/mailing_list.htm +++ b/Shorewall-docs/mailing_list.htm @@ -1,124 +1,127 @@ - + - + - + - + Shorewall Mailing Lists + - + - - - + + - - - + Powered by Postfix    

    + + + +
    - +
    +

    Vexira Logo - - - + - Shorewall Mailing ListsShorewall Mailing ListsCourier-Imap -

    + - +


    -

    - +

    +


    - Powered by Postfix    

    -
    - +

    Note: The list server limits posts to 120kb.

    - +

    Not getting List Mail? -- Check Here

    - +

    If you experience problems with any of these lists, please - let me know

    - + let me know

    +

    Not able to Post Mail to shorewall.net?

    - +

    You can report such problems by sending mail to tom dot eastep - at hp dot com.

    - -

    A Word about SPAM Filters -  

    - + at hp dot com.

    + +

    A Word about SPAM Filters 

    +

    Before subscribing please read my policy about list traffic that bounces. Also please note that the mail server - at shorewall.net checks incoming mail:
    -

    - + at shorewall.net checks incoming mail:
    +

    +
      -
    1. against the open relay databases at ordb.org.
      2. -
    2. to ensure that the sender address is fully qualified.
      3. -
    3. to verify that the sender's domain has an A or MX record in DNS.
      4. -
    4. to ensure that the host name in the HELO/EHLO command is a valid - fully-qualified DNS name.
      5. - +
    5. against Spamassassin +(including Vipul's Razor).
      +
      6. +
    6. to ensure that the sender address is fully qualified.
      7. +
    7. to verify that the sender's domain has an A or MX record in +DNS.
      8. +
    8. to ensure that the host name in the HELO/EHLO command is a +valid fully-qualified DNS name that resolves.
      9. +
    +

    Please post in plain text

    -While the list server here at shorewall.net accepts and distributes HTML -posts, a growing number of MTAs serving list subscribers are rejecting this -HTML list traffic. At least one MTA has gone so far as to blacklist shorewall.net -"for continuous abuse"!!
    -
    -I think that blocking all HTML is a rather draconian way to control spam -and that the unltimate loser here is not the spammers but the list subscribers -whose MTAs are bouncing all shorewall.net mail. Nevertheless, all of you -can help by restricting your list posts to plain text.
    -
    -And as a bonus, subscribers who use email clients like pine and mutt will -be able to read your plain text posts whereas they are most likely simply -ignoring your HTML posts.
    -
    -A final bonus for the use of HTML is that it cuts down the size of messages -by a large percentage -- that is important when the same message must be -sent 500 times over the slow DSL line connecting the list server to the internet.
    - -

    - + A growing number of MTAs serving list subscribers are rejecting all HTML +traffic. At least one MTA has gone so far as to blacklist shorewall.net "for +continuous abuse" because it has been my policy to allow HTML in list posts!!
    +
    + I think that blocking all HTML is a Draconian way to control spam and +that the ultimate losers here are not the spammers but the list subscribers + whose MTAs are bouncing all shorewall.net mail. As one list subscriber wrote +to me privately "These e-mail admin's need to get a (explitive deleted) +life instead of trying to rid the planet of HTML based e-mail". Nevertheless, +to allow subscribers to receive list posts as must as possible, I have now +configured the list server at shorewall.net to strip all HTML from outgoing +posts.
    +

    Other Mail Delivery Problems

    +If you find that you are missing an occasional list post, your e-mail admin +may be blocking mail whose Received: headers contain the names of +certain ISPs. Again, I believe that such policies hurt more than they help +but I'm not prepared to go so far as to start stripping Received: +headers to circumvent those policies.
    +

    Mailing Lists Archive Search

    - -
    -

    Match: + + +

    Match: - Format: + Format: - Sort by: + Sort by: -
    - Search:

    - - + +

    Please do not try to download the entire -Archive -- its 75MB (and growing daily) and my slow DSL line simply won't -stand the traffic. If I catch you, you'll be blacklisted.
    -

    - +Archive -- it is 75MB (and growing daily) and my slow DSL line simply won't +stand the traffic. If I catch you, you will be blacklisted.
    +
    +

    Shorewall CA Certificate

    - If you want to trust X.509 certificates issued by Shoreline Firewall - (such as the one used on my web site), you may download and install my CA certificate - in your browser. If you don't wish to trust my certificates then you + in your browser. If you don't wish to trust my certificates then you can either use unencrypted access when subscribing to Shorewall mailing lists or you can use secure access (SSL) and accept the server's certificate -when prompted by your browser.
    - + when prompted by your browser.
    +

    Shorewall Users Mailing List

    - +

    The Shorewall Users Mailing list provides a way for users - to get answers to questions and to report problems. Information of general - interest to the Shorewall user community is also posted to this list.

    - + to get answers to questions and to report problems. Information of +general interest to the Shorewall user community is also posted to +this list.

    +

    Before posting a problem report to this list, please see - the problem reporting guidelines.

    - + the problem reporting guidelines.

    +

    To subscribe to the mailing list, go to http://www.shorewall.net/mailman/listinfo/shorewall-users - SSL: https//www.shorewall.net/mailman/listinfo/shorewall-users

    - + href="http://mail.shorewall.net/mailman/listinfo/shorewall-users">http://mail.shorewall.net/mailman/listinfo/shorewall-users + SSL: https//mail.shorewall.net/mailman/listinfo/shorewall-users

    +

    To post to the list, post to shorewall-users@shorewall.net.

    - +

    The list archives are at http://www.shorewall.net/pipermail/shorewall-users.

    - + href="http://mail.shorewall.net/pipermail/shorewall-users/index.html">http://mail.shorewall.net/pipermail/shorewall-users.

    +

    Note that prior to 1/1/2002, the mailing list was hosted at Sourceforge. The archives from that list may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.

    - +

    Shorewall Announce Mailing List

    - +

    This list is for announcements of general interest to the - Shorewall community. To subscribe, go to http://www.shorewall.net/mailman/listinfo/shorewall-announce - SSL: https//www.shorewall.net/mailman/listinfo/shorewall-announce.
    -
    - The list archives are at http://www.shorewall.net/pipermail/shorewall-announce.

    - + Shorewall community. To subscribe, go to http://mail.shorewall.net/mailman/listinfo/shorewall-announce + SSL: https//mail.shorewall.net/mailman/listinfo/shorewall-announce.
    +
    + The list archives are at http://mail.shorewall.net/pipermail/shorewall-announce.

    +

    Shorewall Development Mailing List

    - +

    The Shorewall Development Mailing list provides a forum for - the exchange of ideas about the future of Shorewall and for coordinating - ongoing Shorewall Development.

    - + the exchange of ideas about the future of Shorewall and for coordinating + ongoing Shorewall Development.

    +

    To subscribe to the mailing list, go to http://www.shorewall.net/mailman/listinfo/shorewall-devel - SSL: https//www.shorewall.net/mailman/listinfo/shorewall-devel.
    - To post to the list, post to http://mail.shorewall.net/mailman/listinfo/shorewall-devel + SSL: https//mail.shorewall.net/mailman/listinfo/shorewall-devel.
    + To post to the list, post to shorewall-devel@shorewall.net. 

    - +

    The list archives are at http://www.shorewall.net/pipermail/shorewall-devel.

    - + href="http://mail.shorewall.net/pipermail/shorewall-devel">http://mail.shorewall.net/pipermail/shorewall-devel.

    +

    How to Unsubscribe from one of - the Mailing Lists

    - + the Mailing Lists +

    There seems to be near-universal confusion about unsubscribing - from Mailman-managed lists. To unsubscribe:

    - + from Mailman-managed lists although Mailman 2.1 has attempted to make +this less confusing. To unsubscribe:

    +
      -
    • +
    • +

      Follow the same link above that you used to subscribe - to the list.

      -
      • -
    • + to the list.

      +
      • +
    • +

      Down at the bottom of that page is the following text: - "To change your subscription (set options like digest and delivery -modes, get a reminder of your password, or unsubscribe from -<name of list>), enter your subscription email address:". Enter -your email address in the box and click on the "Edit Options" button.

      -
      • -
    • + " To unsubscribe from <list name>, get a password +reminder, or change your subscription options enter your subscription + email address:". Enter your email address in the box and click + on the "Unsubscribe or edit options" button.

      +
      • +
    • +

      There will now be a box where you can enter your password - and click on "Unsubscribe"; if you have forgotten your password, there - is another button that will cause your password to be emailed to you.

      -
      • - + and click on "Unsubscribe"; if you have forgotten your password, there + is another button that will cause your password to be emailed to you.

      + +
    - -
    + +

    Frustrated by having to Rebuild Mailman to use it with Postfix?

    - +

    Check out these instructions

    - -

    Last updated 12/27/2002 - Last updated 12/29/2002 - Tom Eastep

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    +

    +
    +

    diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm index e643bc6a8..1441788b7 100644 --- a/Shorewall-docs/seattlefirewall_index.htm +++ b/Shorewall-docs/seattlefirewall_index.htm @@ -213,7 +213,7 @@ is also added as a separate page in "shorewall monitor" than the LOG target. This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) and log all Shorewall messages to a separate log file. + href="shorewall_logging.html">to a separate log file.
  • If you are running a kernel that has a FORWARD chain in the mangle table ("shorewall show mangle" will show you the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in rather than the LOG target. This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) and log all Shorewall messages to a separate log file.
    • + href="shorewall_logging.html">to a separate log file.
  • If you are running a kernel that has a FORWARD chain in the mangle table ("shorewall show mangle" will show you the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. diff --git a/Shorewall-docs/shorewall_logging.html b/Shorewall-docs/shorewall_logging.html new file mode 100644 index 000000000..80f488aa4 --- /dev/null +++ b/Shorewall-docs/shorewall_logging.html @@ -0,0 +1,137 @@ + + + + Shorewall Logging + + + + + + + + + + + +
    + +

    Logging

    +
    +
    +By default, Shorewall directs NetFilter to log using syslog (8). Syslog + classifies log messages by a facility and a priority (using + the notation facility.priority).
    +
    + The facilities defined by syslog are auth, authpriv, cron, daemon, +kern, lpr, mail, mark, news, syslog, user, uucp and local0 through + local7.
    +
    + Throughout the Shorewall documentation, I will use the term level + rather than priority since level is the term used by NetFilter. + The syslog documentation uses the term priority.
    + +

    Syslog Levels
    +

    + Syslog levels are a method of describing to syslog (8) the importance + of a message and a number of Shorewall parameters have a syslog level as + their value.
    +
    + Valid levels are:
    +
    +        7       +debug
    +        6       +info
    +        5       +notice
    +        4       +warning
    +        3       +err
    +        2       +crit
    +        1       +alert
    +        0       +emerg
    +
    + For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall + log messages are generated by NetFilter and are logged using the kern + facility and the level that you specify. If you are unsure of the level + to choose, 6 (info) is a safe bet. You may specify levels by name or by + number.
    +
    + Syslogd writes log messages to files (typically in /var/log/*) based + on their facility and level. The mapping of these facility/level pairs +to log files is done in /etc/syslog.conf (5). If you make changes to this +file, you must restart syslogd before the changes can take effect.
    + +

    Configuring a Separate Log for Shorewall Messages

    + There are a couple of limitations to syslogd-based logging:
    + +
      +
    1. If you give, for example, kern.info it's own log destination then + that destination will also receive all kernel messages of levels 5 (notice) + through 0 (emerg).
      2. +
    2. All kernel.info messages will go to that destination and not just + those from NetFilter.
      +
      3. +
    + Beginning with Shorewall version 1.3.12, if your kernel has ULOG target + support (and most vendor-supplied kernels do), you may also specify a log + level of ULOG (must be all caps). When ULOG is used, Shorewall will direct + netfilter to log the related messages via the ULOG target which will send + them to a process called 'ulogd'. The ulogd program is available from http://www.gnumonks.org/projects/ulogd + and can be configured to log all Shorewall message to their own log file.
    +
    + Download the ulod tar file and:
    + +
      +
    1. cd /usr/local/src (or wherever you do your builds)
      2. +
    2. tar -zxf source-tarball-that-you-downloaded
      3. +
    3. cd ulogd-version
      +
      4. +
    4. ./configure
      5. +
    5. make
      6. +
    6. make install
      +
      7. +
    + If you are like me and don't have a development environment on your firewall, + you can do the first five steps on another system then either NFS mount +your /usr/local/src directory or tar up the /usr/local/src/ulogd-version + directory and move it to your firewall system.
    +
    + Now on the firewall system, edit /usr/local/etc/ulogd.conf and set:
    + +
      +
    1. syslogfile <file that you wish to log to>
      2. +
    2. syslogsync 1
      3. +
    + I also copied the file /usr/local/src/ulogd-version/ulogd.init to + /etc/init.d/ulogd. I had to edit the line that read "daemon /usr/local/sbin/ulogd" + to read daemon /usr/local/sbin/ulogd -d". On a RedHat system, a simple "chkconfig + --level 3 ulogd on" starts ulogd during boot up. Your init system may need + something else done to activate the script.
    +
    + Finally edit /etc/shorewall/shorewall.conf and set LOGFILE=<file +that you wish to log to>. This tells the /sbin/shorewall program +where to look for the log when processing its "show log", "logwatch" and +"monitor" commands.
    + +

    Updated 12/29/2002 - Tom Eastep +

    + + + +

    Copyright + © 2001, 2002 Thomas M. Eastep
    +

    + +


    +

    + + diff --git a/Shorewall-docs/shorewall_quickstart_guide.htm b/Shorewall-docs/shorewall_quickstart_guide.htm index 564fbaf64..80ffc658a 100644 --- a/Shorewall-docs/shorewall_quickstart_guide.htm +++ b/Shorewall-docs/shorewall_quickstart_guide.htm @@ -1,269 +1,274 @@ - + - + - + - + Shorewall QuickStart Guide - + - + - - - + + - - - + Version 3.1 + + + +
    - +
    +

    Shorewall QuickStart Guides
    - Version 3.1

    -
    - -

    With thanks to Richard who reminded me once again that -we must all first walk before we can run.

    - + +

    With thanks to Richard who reminded me once again that we +must all first walk before we can run.

    +

    The Guides

    - -

    These guides provide step-by-step instructions for configuring Shorewall + +

    These guides provide step-by-step instructions for configuring Shorewall in common firewall setups.

    - +

    The following guides are for users who have a single public IP address:

    - +
      -
    • Standalone Linux System
      • -
    • Two-interface Linux System - acting as a firewall/router for a small local network
      • -
    • Three-interface Linux - System acting as a firewall/router for a small local network and -a DMZ.
      • - +
    • Standalone Linux System
      • +
    • Two-interface Linux System + acting as a firewall/router for a small local network
      • +
    • Three-interface Linux + System acting as a firewall/router for a small local network and a + DMZ.
      • +
    - -

    The above guides are designed to get your first firewall up and running + +

    The above guides are designed to get your first firewall up and running quickly in the three most common Shorewall configurations.

    - -

    The Shorewall Setup Guide outlines - the steps necessary to set up a firewall where there are multiple - public IP addresses involved or if you want to learn more about Shorewall + +

    The Shorewall Setup Guide outlines + the steps necessary to set up a firewall where there are multiple + public IP addresses involved or if you want to learn more about Shorewall than is explained in the single-address guides above.

    - + - +

    Documentation Index

    - -

    The following documentation covers a variety of topics and supplements - the QuickStart Guides -described above. Please review the appropriate guide before trying + +

    The following documentation covers a variety of topics and supplements + the QuickStart Guides +described above. Please review the appropriate guide before trying to use this documentation directly.

    - + - +

    If you use one of these guides and have a suggestion for improvement please let me know.

    - -

    Last modified 12/13/2002 - Tom Eastep

    - + +

    Last modified 12/29/2002 - Tom Eastep

    +

    Copyright 2002 Thomas M. Eastep
    -

    -
    -
    -
    -
    -
    +

    diff --git a/Shorewall-docs/shorewall_setup_guide.htm b/Shorewall-docs/shorewall_setup_guide.htm index 9a72e16e0..6d8182c10 100644 --- a/Shorewall-docs/shorewall_setup_guide.htm +++ b/Shorewall-docs/shorewall_setup_guide.htm @@ -239,7 +239,7 @@ the request is first checked against the rules in /etc/shorewall/common.def.allow all connection requests from your local network to the internet
  • drop (ignore) all connection requests from the internet to your firewall or local network and log a message at the info level -(here is a description +(here is a description of log levels).
  • reject all other connection requests and log a message at the info level. When a request is rejected, the firewall will return an RST (if diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm index 3e41dbd76..a83054d3b 100644 --- a/Shorewall-docs/sourceforge_index.htm +++ b/Shorewall-docs/sourceforge_index.htm @@ -200,7 +200,7 @@ is also added as a separate page in "shorewall monitor"
    • than the LOG target. This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) and log all Shorewall messages to a separate log file. + href="shorewall_logging.html">to a separate log file.
  • If you are running a kernel that has a FORWARD chain in the mangle table ("shorewall show mangle" will show you the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in rather than the LOG target. This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) and log all Shorewall messages to a separate log file.
    • + href="shorewall_logging.html">to a separate log file.
  • If you are running a kernel that has a FORWARD chain in the mangle table ("shorewall show mangle" will show you the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. diff --git a/Shorewall-docs/support.htm b/Shorewall-docs/support.htm index 13e6171fc..e7a446e60 100644 --- a/Shorewall-docs/support.htm +++ b/Shorewall-docs/support.htm @@ -2,121 +2,121 @@ - + - + - + - + Support - + - + - - - + + - + + + - - + +
    +
    - +

    Shorewall Support -

    -
    - +


    -

    - +

    +

    I don't look at problems sent to me directly - but I try to spend some amount of time each day responding to problems - posted on the Shorewall mailing list.

    - + but I try to spend some amount of time each day responding to +problems posted on the Shorewall mailing list.     +

    -Tom

    - +

    Before Reporting a Problem

    - +

    There are a number of sources for problem solution information. Please - try these before you post.

    - + try these before you post.     +

    - +

    - +
      -
    • +

    • The FAQ has solutions to more than 20 common - problems.

      -
      • - + problems. + +
    - +

    - +
      -
    • +

    • The Troubleshooting Information - contains a number of tips to help you solve common problems.

      -
      • - + contains a number of tips to help you solve common problems. + +
    - +

    - +
      -
    • +

    • The Errata has links to download - updated components.

      -
      • - + updated components. + +
    - +

    - +
      -
    • +

    • The Mailing List Archives search facility can locate posts about similar problems:

      -
      • - + +
    - +

    - +

    Mailing List Archive Search

    - +
    - +

    Match: - + - Format: - + Format: + - Sort by: - + Sort by: + -
    - Search:

    -
    - + +

    Problem Reporting Guidelines

    - "Let me see if I can translate your message into a real-world example.  - It would be like saying that you have three rooms at home, and when you + "Let me see if I can translate your message into a real-world example.  + It would be like saying that you have three rooms at home, and when you walk into one of the rooms, you detect this strange smell.  Can anyone tell you what that strange smell is?
    -
    - Now, all of us could do some wonderful guessing as to the smell and even - what's causing it.  You would be absolutely amazed at the range and variety - of smells we could come up with.  Even more amazing is that all of the explanations - for the smells would be completely plausible."
    -
    - +
    + Now, all of us could do some wonderful guessing as to the smell and even + what's causing it.  You would be absolutely amazed at the range and variety + of smells we could come up with.  Even more amazing is that all of the +explanations for the smells would be completely plausible."
    +
    +
       - Russell Mosemann
    -
    -
    - + +
    +

    - +
      -
    • +

    • When reporting a problem, give as much information as you can. Reports that say "I tried XYZ and it didn't work" are not at all helpful.

      -
      • - + +
    - +

    - +
      -
    • +

    • Please don't describe your environment and then ask us to send you custom configuration files. We're here to answer your questions but we can't do your job for you.

      -
      • - + +
    - +

    - +
      -
    • +

    • Do you see any "Shorewall" messages in /var/log/messages when you exercise the function that is giving you problems?

      -
      • - + +
    - +

    - +
      -
    • +

    • Have you looked at the packet flow with a tool like tcpdump to try to understand what is going on?

      -
      • - + +
    - +

    - +
      -
    • +

    • Have you tried using the diagnostic capabilities of the application that isn't working? For example, if "ssh" isn't able to connect, using the "-v" option gives you a lot of valuable diagnostic - information.

      -
      • - + information. + +
    - +

    - +
      -
    • +

    • Please include any of the Shorewall configuration files (especially - the /etc/shorewall/hosts file if you have modified that file) -that you think are relevant.

      -
      • -
    • -

      If an error occurs when you try to "shorewall start", include -a trace (See the Troubleshooting section -for instructions).

      + the /etc/shorewall/hosts file if you have modified that file) + that you think are relevant.
      • - -
    - -

    - -
    • -

      The list server limits posts to 120kb so don't post GIFs of - your network layout, etc to the Mailing List -- your post - will be rejected.

      -
      • - +

      If an error occurs when you try to "shorewall start", include + a trace (See the Troubleshooting section + for instructions).

      + +
    - + +

    + +
      +
    • +

      The list server limits posts to 120kb so don't post GIFs of + your network layout, etc to the Mailing List -- your post + will be rejected.

      +
      • + +
    +

    - +
    +

    Please post in plain text

    -
    -

    While the list server here at shorewall.net accepts and distributes -HTML posts, a growing number of MTAs serving list subscribers are rejecting -this HTML list traffic. At least one MTA has gone so far as to blacklist -shorewall.net "for continuous abuse"!!

    -

    I think that blocking all HTML is a rather draconian way to control -spam and that the unltimate loser here is not the spammers but the list subscribers -whose MTAs are bouncing all shorewall.net mail. Nevertheless, all of you can -help by restricting your list posts to plain text.

    -

    And as a bonus, subscribers who use email clients like pine and -mutt will be able to read your plain text posts whereas they are most likely -simply ignoring your HTML posts.

    -

    A final bonus for the use of HTML is that it cuts down the size -of messages by a large percentage -- that is important when the same message -must be sent 500 times over the slow DSL line connecting the list server -to the internet.

    + +
    +

    A growing number of MTAs serving list subscribers are rejecting all +HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net +"for continuous abuse" because it has been my policy to allow HTML in list +posts!!
    +
    + I think that blocking all HTML is a Draconian way to control spam and +that the ultimate losers here are not the spammers but the list subscribers + whose MTAs are bouncing all shorewall.net mail. As one list subscriber wrote +to me privately "These e-mail admin's need to get a (explitive deleted) +life instead of trying to rid the planet of HTML based e-mail". Nevertheless, +to allow subscribers to receive list posts as must as possible, I have now + configured the list server at shorewall.net to strip all HTML from outgoing +posts.
    +

    +

    Where to Send your Problem Report or to Ask for Help

    - +

    - -
    + +

    If you run Shorewall under Bering -- please post your question or problem - to the LEAF Users mailing - list.

    - + to the LEAF Users mailing + list. + If you run Shorewall under MandrakeSoft Multi Network Firewall (MNF) +and you have not purchased an MNF license from MandrakeSoft then you can post +non MNF-specific Shorewall questions to the Shorewall users mailing list. + Do not expect to get free MNF support on the list.
    +

    Otherwise, please post your question or problem to the Shorewall users mailing list.

    -
    +
    - +

    - +

    To Subscribe to the mailing list go to http://www.shorewall.net/mailman/listinfo/shorewall-users - .

    + href="http://mail.shorewall.net/mailman/listinfo/shorewall-users">http://mail.shorewall.net/mailman/listinfo/shorewall-users + .

    - -

    Last Updated 12/27/2002 - Tom Eastep

    - + +

    Last Updated 12/29/2002 - Tom Eastep

    +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    -
    -
    -
    -
    +