Firewall and Masquerading in SuSE Linux 6.4/7.0/7.1

Support knowledgebase (sm_masq2)

SuSE Linux: Versions 6.4 to 7.1
This article refers to an older version of SuSE Linux. Therefore some of the informations given in this article may be outdated or the article may contain stale links.

Kernel: Versions since 2.2

Situation:

• 1. You want to enable hosts in an internal, private network to access the Internet without any additional filters (insecure).
• 2. You want to enable hosts in an internal, private network to access the Internet with simple filters (from SuSE Linux 7.1).
• 3. You want to set up a firewall with configurable packet filters.

Procedure:

Introductory Notes

• The configuration of the SuSEfirewall package has not undergone any drastic changes from SuSE Linux 6.4 to SuSE Linux 7.1. Therefore, the following information basically applies to all three versions. However, since individual options may have been added in the course of time, not all listed parameters may exist in all versions. The parameter numbers were adopted from the latest version 4.2. Previous versions that do not contain all options may have different sequence numbers.
• As of SuSE Linux 7.1, the package name was changed from firewals to SuSEfirewall.
• In case you wish to use SuSEfirewall with a 2.4.x series kernel, the kernel module ipchains must be loaded, since the entire packet filter code was redesigned starting from kernel 2.4.x and the tool iptables is now used for configuring packet filters. A firewall script that makes use of iptables is currently being developed. However, for the time being we recommend use of SuSE Linux 7.1 with kernel 2.2.18 as firewall.

1. Pure Masquerading Without Filters

   This procedure enables internal network hosts to access the Internet without any filters.

   Attention: Please note that although this procedure is the easiest way to provide all internal hosts with Internet access, it leaves them relatively defenseless. Therefore, never choose this option for productive operations.

   Attention 2: From SuSE Linux 7.1 on, you should use personal-firewall for masquerading instead of this method (see further below).

   For this reason, this section will not (!) draw attention to the fact that /sbin/init.d was moved to /etc/init.d starting from SuSE Linux 7.1, and therefore the paths indicated in this section do not apply.

   The package ipchains (series sec) must be installed.

   Set the parameter START_FW in /etc/rc.config to "no".

   Create the file /sbin/init.d/masquerade with the following content:
   Since browsers often cause cut & paste errors, we recommend that you do this with Lynx and the following command:

   lynx -dump http://sdb.suse.de/sdb/de/html/sm_masq2.html > masquerade

   Then delete the text before and after the script.

   
   #! /bin/sh
   
   . /etc/rc.config
   
   PROG="/sbin/ipchains"
   WORLD_DEV="ippp0"
   MODULES="ip_masq_autofw ip_masq_cuseeme ip_masq_ftp ip_masq_irc ip_masq_mfw \
          ip_masq_portfw ip_masq_quake ip_masq_raudio ip_masq_user ip_masq_vdolive"
   
   LOADED_MODULES=$(lsmod|grep ip_masq|cut -d " " -f1)
   
   return=$rc_done
   
   if [ ! -x $PROG ]
   then
     echo -n "Start masquerading failed- install ipchains"
     return=$rc_failed
     echo -e "$return"
     exit 1
   fi
   
   case "$1" in
    start)
      echo -n "Starting masquerading"
      echo "1" > /proc/sys/net/ipv4/ip_forward
   
      $PROG -F || return=$rc_failed
      $PROG -A forward -i $WORLD_DEV -j MASQ || return=$rc_failed
   
      for i in $MODULES;do
         insmod $i > /dev/null 2>&1 || return=$rc_failed;
      done
   
      echo -e "$return"
      ;;
   
   stop)
      echo -n "Shutting down masquerading"
   
      $PROG -F || return=$rc_failed
   
      test "$IP_FORWARD" = no && echo "0" > /proc/sys/net/ipv4/ip_forward
   
      for i in $LOADED_MODULES;do
         rmmod $i > /dev/null 2>&1 || return=$rc_failed;
      done
   
      echo -e "$return"
      ;;
   
   *)
   
      echo "Usage: $0 {start|stop}"
      exit 1
      ;;
   esac
   
   test "$return" = "$rc_done" || exit 1
   
   exit 0
   
   

   "ippp0" must be replaced with the device you use for establishing Internet connections.
   Of course this procedure also works with an analog connection and ppp0.

   Make the file executable: chmod 700 /sbin/init.d/masquerade.

   Set up the corresponding links for automatic start-up in the respective runlevels:

      ln -s ../masquerade /sbin/init.d/rc2.d/S99masquerade
      ln -s ../masquerade /sbin/init.d/rc2.d/K51masquerade
      ln -s ../masquerade /sbin/init.d/rc3.d/S99masquerade
      ln -s ../masquerade /sbin/init.d/rc3.d/K51masquerade
   

   The next time the system is booted, LAN hosts can access the Internet if they have entered the masquerading host as default gateway.

2. Masquerading with Simple Filters (from SuSE Linux 7.1)

   Starting from SuSE Linux 7.1, the best solution for simple masquerading is the use of personal-firewall. This approach, too, is very easy to configure, but provides a measure of protection for the internal network, since all incoming connections are rejected at the outer device.

   In order to be able to use this solution, the personal-firewall package (series sec) must be installed. In new installations, this option is included in the default software selection. When updating from an older SuSE Linux version, it may be necessary to postinstall this package.

   An update can be downloaded from ftp://ftp.suse.com/pub/suse/i386/update/7.1/sec1/personal-firewall.rpm

   The configuration requires only one parameter to be modified:

   REJECT_ALL_INCOMING_CONNECTIONS in the file /etc/rc.config.d/security.rc.config.

   Possible values:

   • no: all rules are deleted, filters and masquerading are not applied.
   • yes: all incoming connections are rejected.
   • The device(s) at which incoming connections are to be rejected, e.g. ippp0 if you use ISDN.
   • masq: for masquerading internal network traffic; masquerades everything that arrives at an interface that is not blocked.

   Accordingly, for one network adaptor eth0 and ISDN dial-in ippp0 , the entry for masquerading the entire internal network traffic traversing ippp0 and block all incoming external connections would look as follows:
   
   

   REJECT_ALL_INCOMING_CONNECTIONS="ippp0 masq"

3. Firewall with Packet Filters

   Here a short description of the settings in /etc/rc.config.d/firewall.rc.config.

   The following packages must be installed:

   • firewals (series sec) -> Scripts for configuring and starting the firewall.
     In case you use SuSE Linux 6.4, please download the firewals 2.1 update from ftp://ftp.suse.com/pub/suse/i386/update/6.4/sec1/firewals.rpm.

   • ipchains (series sec) -> Tool for activating the rules in the kernel.

   Set the parameter START_FW= in /etc/rc.config to "yes" in order for the firewall scripts to be processed when the system is booted.

   If your firewall is a dial-in host with dynamic IP addresses, the call /sbin/SuSEfirewall must be entered in the script /etc/ppp/ip-up.
   

   • For ISDN, preferably at the end of the dial-in procedure, i.e. before the line
     test -x /etc/ppp/ip-up.local && /etc/ppp/ip-up.local $*
     
   • and upon hang-up, after the interface has been reactivated, i.e. before the line
     test -x /etc/ppp/ip-down.local && /etc/ppp/ip-down.local $*
   • For modems, during dial-up, before the line
     test -x /etc/ppp/ip-up.local && /etc/ppp/ip-up.local $*
   • and during hang-up, before the line
     test -x /etc/ppp/ip-down.local && /etc/ppp/ip-down.local $*

   If you are using SuSE Linux 7.0 or 7.1, the respective entries already exist in /etc/ppp/ip-up.
   Simply set the parameter START_FW in /etc/rc.config to yes.
   You can ignore any error messages regarding missing devices that you may receive when you boot the system, since the actual rules are set later on during dial-up.

   All other settings are performed in /etc/rc.config.d/firewall.rc.config.

   Important notes:

   The configuration, setup, and maintenance of your firewall is not eligible for installation support.

   Be sure to read the documentation in /usr/doc/packages/firewals for SuSE Linux 6.4, /usr/share/doc/packages/firewals for SuSE Linux 7.0, or /usr/share/doc/packages/SuSEfirewall/ for SuSE Linux 7.1, as well as chapters 6.7 and 18 in the manual.

   If you only perform these settings and use SuSEfirewall, do not expect your system to be bulletproof!
   There is no solution that you can simply install to protect yourself against all kinds of assaults from the Internet.

   In order to increase the security of a firewall server, you should:
   • Minimize all services to insecure networks (such as the Internet). Only programs regarded as secure should be used (postfix, apop3d, ssh, etc.) and configured carefully.
   • It is advisable NOT to execute services as "root". Furthermore, services should run in a "chroot" environment if this is possible.
   • Use the script harden_suse from the package hardsuse in order to disable all services immediately after the installation; then reactivate only the services you really need.
   • Compile a new kernel in which you have marked all security options. Use the openwall-linux kernel patch (formerly secure-linux patch, by Solar Designer) or use the module secumod that is included in the CDs.
   • Regularly check the server integrity with tools such as tripwire as well as the package seccheck from the CDs.
   • If you intend to use the firewall/bastion server as masquerading server or as routing server, you should make sure that proxy services can be used, e.g. Squid for WWW, smtpd for mail etc. (use "chroot" and do not run the processes under "root"). If the proxy services can not be used, we recommend that you disable routing on this machine.

   The options that need to be configured are as follows:

   • Your computer is connected to the network with only one interface:
     You just need to modify option 2 as well as 9, 11, and 17 if necessary. All other settings are OK.
     
   • Your computer is a firewall that only works as a proxy, i.e. there will be no direct routing between the network interfaces:
     Modify the options 2, 3, and 9 as well as 7, 10, 11, 12, and 17 if necessary. Of course the proxy services also need to be configured.
     
   • Your computer is a firewall that is supposed to route actively between the "secure" network and the "insecure" network:
     Modify the options 2, 3, 5, 6, 9 as well as 7, 10, 11, 12, and 17 if necessary.
     
   • In case you want to include a DMZ (demilitarized zone) in one of the said configurations, you also need to modify the options 4, 9, 13, and possibly 18. A DMZ is a host/network that is separated from the internal network and that can be accessed from outside via the firewall.
   • The default settings should be kept for the options 8, 14, 15, 16, 18, 19, 20, and 21. You should only modify them if you are really sure about what you are doing.

   The individual options:

   • 2:   FW_DEV_WORLD
     Here you should enter all network interfaces that are located on the outer, "insecure" side of the computer, i.e. those that are connected to the Internet.
     Entries are separated by spaces.
     Example:  FW_DEV_WORLD="ippp0"

   • 3:   FW_DEV_INT
     Here you should enter all network interfaces that are located on the inner, "secure" side of the computer, i.e. your private network. This field should remain blank in case your computer is a stand-alone system.
     Entries are separated by spaces.
     Example.:  FW_DEV_INT="eth0"

   • 4:   FW_DEV_DMZ
     Here you should enter the network interface to which your DMZ is connected. If you do not have a DMZ, leave this option blank.
     A DMZ is a host/network that is only connected to the Internet via the firewall for the purpose of offering services (WWW, mail, ...) externally.
     The DMZ must have an official IP address that is routed through your firewall.
     In order to make this service available, you also need to set FW_ROUTE to "yes" and enable forwarding of the offered services with FW_FORWARD_TCP and FW_FORWARD_UDP.
     Example:  FW_DEV_INT="eth2"

   • 5:   FW_ROUTE
     You should only set this option to "yes" if you want to enable a direct connection (without proxy services on the firewall) between LAN hosts, the Internet, and/or the DMZ.
     This option is necessary for establishing connections to the DMZ from the Internet; it is not advisable for you to allow access from the Internet to the internal network.
     However, this option alone is not sufficient; in addition, you must either activate masquerading with FW_MASQUERADE or configure the services to be forwarded with FW_FORWARD_*.
     This option overrides IP_FORWARD in /etc/rc.config.

   • 6:   FW_MASQUERADE, FW_MASQ_NETS, and FW_MASQ_DEV
     
     • FW_MASQUERADE   Set this option to "yes" if internal network hosts with private IP addresses (e.g.: 192.168.x.x) are to be provided with direct access to the Internet without proxy services.
       This causes the firewall/router to replace private IP addresses with the official IP address. Thus, for other hosts in the Internet it will look as though the service is requested by the firewall itself. In the other direction, the addresses are rewritten to the private addresses.
       Please note that the use of proxy services is more secure than masquerading.
       In order to be able to use masquerading, FW_DEV_INT, FW_MASQ_NETS, FW_MASQ_DEV, and FW_ROUTE="yes" must also be set.
     • FW_MASQ_NETS   Here you should enter all hosts/networks that are to be provided with access to the Internet by means of masquerading.
       Entries are separated by spaces. Example:
       
       • FW_MASQ_NETS="192.168.1.1 192.168.2.0/24" for the host 192.168.1.1 and the class C network 192.168.2.x.
       • Do not set this option to 0/0!
     • FW_MASQ_DEV   Here you should indicate the outgoing interface at which masquerading is to be performed.
       Normally: FW_MASQ_DEV="$FW_DEV_WORLD"

   • 7:   FW_PROTECT_FROM_INTERNAL
     If this option is set to "yes", internal network hosts can only access explicitly released firewall services (FW_*_SERVICES_INTERNAL).
     If this option is set to "no", all internal network users can connect to the firewall and attack it.
     In order to be able to use this option, FW_DEV_INT must also be set.

   • 8:   FW_AUTOPROTECT_GLOBAL_SERVICES
     This option protects services (TCP and UDP) that wait for connections at all network addresses of the firewall (not only at specifically defined ones).
     Example: 0.0.0.0:23 is protected, but 10.0.0.01:53 is not.
     This option can be deactivated for individual services with the options FW_*_SERVICES_*.

   • 9:   FW_SERVICES_*
     Here you should enter all firewall services that may be used by the respective networks.
     If you want to release all services internally, set FW_PROTECT_FROM_INTERNAL="no"
     Possible entries (separated by spaces):
     
     • Individual port numbers, e.g. "123 524" for the ports 123 and 524.
     • Entire port ranges, e.g. "3200:3299" for all ports from 3200 to 3299.
     • Names of services that can be resolved by /etc/services, e.g. "smtp telnet".
     • You can combine the three possibilities as you wish.

   • 10:   FW_TRUSTED_NETS and FW_SERVICES_TRUSTED_*.
     
     • FW_TRUSTED_HOSTS: Trusted Internet hosts/networks that are to be granted access to specific internal services.
       The entries are separated by spaces. Example:
       FW_TRUSTED_HOSTS="192.168.1.1 192.168.2.0/24" for the host 192.168.1.1 and the class C network 192.168.2.x .
     • FW_SERVICES_TRUSTED_* specify the firewall services these hosts/networks are to be granted access to.
       The syntax for entering ports/port ranges is the same as in 9.

   • 11:   FW_ALLOW_INCOMING_HIGHPORTS_*
     This parameter allows you to specify how the unprivileged firewall ports (above 1013) may be accessed.
     
     • "yes" allows all, "no" allows none to access these ports, or:
     • Requests from specific ports can be permitted (this can easily be circumvented):
       enter these ports directly or use the names that can be resolved by /etc/services.
       
     • FW_ALLOW_INCOMING_HIGHPORTS_UDP should contain "dns" so that your name servers specified in /etc/resolv.conf can respond to requests.
     • In order to be able to use FTP in active mode, "ftp-data" must be entered in FW_ALLOW_INCOMING_HIGHPORTS_TCP.
       However, we recommend that you leave this option blank and use FTP in passive mode.
     • RPC services such as showmount or rpcinfo as root can not be used.

   • 12:   FW_SERVICE_*
     Set these options to yes if you offer/need the respective service on the firewall.
     • Set FW_SERVICE_DNS   to yes if you operate a name server on the firewall.
       In this case, you also need to release port 53 (or domain) for the respective network from which requests may be submitted in FW_SERVICES_*_*.
     • Set FW_SERVICE_DHCLIENT   to yes if you need to use the DHCP client on the firewall.
     • Set FW_SERVICE_DHCPD   to yes if you operate a DHCP server on the firewall.
     • Set FW_SERVICE_SAMBA   to yes if you use Samba on this computer (server or client). If the machine is to run as a Samba server, you also need to enter port 139 in the respective variables FW_SERVICES_*_TCP. However, we strongly advise not to operate any Samba servers on the firewall machine.

   • 13:   FW_FORWARD_*
     Here you can specify whether internal hosts or the DMZ may be accessed from the Internet.
     
     • As this opens a direct connection to your internal network, you should only use this possibility for your DMZ.
     • For this purpose, a static, non-private IP adress is required for the internal hosts.
     • A forwarding rule consists of the host/network to be granted access, the IP address of the internal host to which access is to be granted, and the port on this host.
     • The three parts of a rule are separated by commas, two rules are separated by spaces.
     • Example: the rule "12.12.12.0/24,13.13.13.13,25" forwards accesses from the external network 12.12.12.0/24 to port 25 of the internal host 13.13.13.13.

   • From here on the sequence numbers of the options no longer apply to all versions, since some variables have been added in some versions.

   • 16:   FW_LOG_*
     These options determine which packets are logged.

   • 17:   FW_KERNEL_SECURITY
     This option activates additional security-relevant kernel options.
     Tip: Set this option to "no" during the test phase and to "yes" once everything works.

   • 18:   FW_STOP_KEEP_ROUTING_STATE
     If you use diald or ISDN by autodial for dial-in, you should set this option to yes.
     This makes sure routing is not disabled when the rules are unloaded, thus enabling automatic dial-in.
     Please note that this is not particularly secure: if the rules are unloaded while you are still online, access to the internal network is possible.
     However, depending on the configuration, this option may be necessary to reach your DMZ.
     The option FW_ROUTE=yes must be set.

   • 19:   FW_ALLOW_PING_*
     These variables determine whether or not the firewall and/or the DMZ are to respond to pings from the Internet.
     "yes" or "no".

   The following options should be left with their default settings unless you are absolutely sure of what you are doing:

   • 14:   FW_FORWARD_MASQ_*
     This option allows you to permit external access to masqueraded internal network hosts with private IP addresses. We recommend that you do not use this possibility. Rather, you should place hosts that require external access into the DMZ. If a web server that is masqueraded with this method is attacked, you can be sure the attacker has already invaded the internal network!!!
     A rule consists of three parts separated by commas: the source address, the destination address, and the destination port, e.g.
     FW_FORWARD_MASQ_TCP="0/0,1.2.3.4,80"
     Forwards web requests from any host to the internal server 1.2.3.4.

   • 15:   FW_REDIRECT_*
     Here you can specify which services are to be redirected to other local ports. For example, you can can force all internal users to surf only via the proxy server, or external web server requests can can redirected to a secure internal web server.
     
     • A rule consists of the source address, the destination address, the original port of the request, and the port to which requests are to be redirected.
     • The four parts of a rule are separated by commas, two rules are separated by spaces.
     • Example: the rule 192.168.0.0/24,0/0,80,3128 redirects all outgoing web requests from the internal network 192.168.0.0/24 to port 3128 of Squid on the firewall.

   • 20:   FW_ALLOW_FW_TRACEROUTE
     This variable determines whether the firewall is to send ICMP time-to-live-exceeded responses, which are required by traceroute on the firewall server.
     Please note:
     • Unix traceroute additionally requires FW_UDP_ALLOW_INCOMING_HIGHPORTS to be set.
     • Windows traceroute requires FW_ALLOW_FW_PING="yes"

   • 22:   FW_MASQ_MODULES
     Here you can determine which masquerading modules are to be loaded.
     
     • Possibilities: autofw, cuseeme, ftp, irc, mfw, portfw, quake, raudio, user, vdolive
     • The module names are separated by spaces.
     • In order to be able to use masquerading, FW_ROUTE and FW_MASQUERADE must also be set.

   • 23:   FW_CUSTOMRULES
     Here you can specify a file containing your own rules (from version 4.0).
     A description is contained in the example file /etc/rc.config.d/firewall-custom.rc.config.
     However, you should only use this possibility if you are absolutely sure about what you are doing and understand the source code of SuSEfirewall.
     Simply said, this file consists of a number of predefined functions that are executed at specified times. You can insert you own rules in these functions.