| SUSE LINUX – Administration Guide Part IV. Network / Chapter 19. Security in the Network | ||||
|---|---|---|---|---|
 | 18.3. Proxy Server: Squid | 19.2. SSH — Secure Shell, the Safe Alternative |  | |
| SUSE LINUX – Administration Guide Part IV. Network / Chapter 19. Security in the Network | ||||
|---|---|---|---|---|
| 18.3. Proxy Server: Squid | 19.2. SSH — Secure Shell, the Safe Alternative | | |
Table of Contents
Abstract
Masquerading, firewall, and Kerberos constitute the basis for a secure network, enabling control of the data traffic. The secure shell (SSH) allows users to log in to remote hosts by way of an encrypted connection. The information in this chapter gives basic instructions for securing a network and working securely in the network with these tools.
Because of its outstanding network capabilities, Linux is frequently used as a router operating system for dial-up or dedicated lines. Router, in this case, refers to a host with multiple network interfaces that transmits any packets not destined for one of its own network interfaces to another host communicating with it. This router is often called a gateway. The packet filtering mechanism provided by the Linux kernel allows precise control over which packets of the overall traffic are transferred.
In general, defining the exact rules for a packet filter requires at least some experience on the part of the administrator. For the less experienced user, SUSE LINUX includes a separate package, SUSEfirewall2, intended to make it easier to set up these rules.
SUSEfirewall2 is highly configurable, making it also a good choice for a more complex packet filtering setup. With this packet filter solution, a Linux machine can be used as a router with masquerading to link a local network through a dial-up or dedicated connection where only one IP address is visible to the outside world. Masquerading is accomplished by implementing rules for packet filtering.
![[Warning]](admon/warning.png) | Warning |
|---|---|
This chapter only describes standard procedures that should work well in most situations. Although every effort has been made to provide accurate and complete information, no guarantee is included. SUSE cannot be held responsible for the success or failure of your security measures. We do appreciate your criticism and comments. Although you might not receive a direct answer from us, rest assured that suggestions for improvement are taken seriously. | |
Masquerading is the Linux-specific form of NAT (Network Address Translation). The basic principle is a simple one: Your router has more than one network interface, typically a network card and a separate interface to the Internet (such as an ISDN interface). While this interface links with the outside world, the remaining ones are used to connect this router with the other hosts in your network. For example, the dial-up is conducted via ISDN and the network interface is ippp0. Several hosts in your local network are connected to the network card of your Linux router, in this example, eth0. Hosts in the network should be configured to send packets destined outside the local network to this gateway.
![[Important]](admon/important.png) | Important |
|---|---|
When configuring your network, make sure that both the broadcast address and the network mask are the same for all the hosts. | |
When one of the hosts sends a packet destined for an Internet address, this packet is sent to the network's default router. The router needs to be configured before it can forward such packets. However, SUSE LINUX does not enable this with a default installation for security reasons. Therefore, set the variable IP_FORWARD, defined in the file /etc/sysconfig/sysctl, to IP_FORWARD=yes. The forwarding mechanism is enabled after rebooting or after issuing the command echo 1 > /proc/sys/net/ipv4/ip_forward.
The target host can only see your router, but knows nothing about the host in your internal network from which the packets originated. This internal host is disguised behind the router, which is why the technique is called masquerading. Because of the address translation, the router is the first destination of any packets coming back in reply. Now the router must identify these incoming packets and translate their target address, so packets can be forwarded back to the correct host in the local network.
The identification of packets belonging to a connection, as handled by a masquerading router, is done with the help of a table, which is maintained by the kernel of your router as long as the connection exists. root can study this table with the iptables command. Read the man page of this command for detailed instructions. Masqueraded connections are identified not only by their source and target addresses, but also by the port numbers used and the protocols involved. This makes it possible for a router to keep open many different connections for each internal host simultaneously.
With the routing of inbound traffic depending on the masquerading table, there is no way to open a connection to an internal host from the outside. For such a connection, there would be no entry in the table. In addition, any established connection is assigned a status entry in the table, so the entry cannot be used by another connection. As a consequence of all this, you might experience some problems with a number of applications, such as ICQ, cucme, IRC (DCC, CTCP), Quake, and FTP (in PORT mode). Netscape, the standard FTP program, and many others use the PASV mode. This passive mode is much less problematic as far as packet filtering and masquerading is concerned.
Firewall is probably the most widely used term to describe a mechanism to control the data traffic between two networks and to provide and manage the link between networks. There are various types of firewalls, which mostly differ in regard to the abstract level on which traffic is analyzed and controlled. Strictly speaking, the mechanism described in this section is called a packet filter. Like any other type of firewall, a packet filter alone does not guarantee full protection from all security risks. A packet filter implements a set of rules related to protocols, ports, and IP addresses to decide whether data may pass. This blocks any packets that, according to the address or destination, are not supposed to reach your network. Packets sent to the telnet service of your hosts on port 23, for example, should be blocked, while you might want people to have access to your web server and therefore enable the corresponding port. A packet filter does not scan the contents of any packets as long as they have legitimate addresses (e.g., directed to your web server). Thus, packets could attack your CGI server, but the packet filter would let them through.
A more effective, but more complex mechanism is the combination of several types of systems, such as a packet filter interacting with an application gateway or proxy. In this case, the packet filter rejects any packets destined to disabled ports. Only packets directed to the application gateway are accepted. This gateway or proxy pretends to be the actual client of the server. In a sense, such a proxy could be considered a masquerading host on the protocol level used by the application. One example for such a proxy is Squid, an HTTP proxy server. To use Squid, the browser must be configured to communicate via the proxy. Any HTTP pages requested will be served from the proxy cache and pages not found in the cache are fetched from the Internet by the proxy. As another example, the SUSE proxy suite (proxy-suite) provides a proxy for the FTP protocol.
The following section focuses on the packet filter that comes with SUSE LINUX. For more information and links, read the Firewall HOWTO included in howto. If this package is installed, read the HOWTO with less /usr/share/doc/howto/en/txt/Firewall-HOWTO.gz.
The configuration of SuSEfirewall2 requires a certain degree of experience and understanding. The documentation of SuSEfirewall2 is available in /usr/share/doc/packages/SuSEfirewall2. The configuration can be performed with YaST (see Section 19.1.3.2. “Configuration with YaST”) or manually in the file /etc/sysconfig/SuSEfirewall2, which is well commented.
The following paragraphs provide step-by-step instructions for a successful configuration. For each configuration item, find a note specifying whether it is relevant for firewalling or for masquerading. Aspects related to the DMZ (demilitarized zone) are not covered here. If your requirements are strictly limited to masquerading, only fill out items marked “masquerading”.
First, use the YaST runlevel editor to enable SuSEfirewall2 in your runlevel (3 or 5 most likely). It sets the symlinks for the SuSEfirewall2_* scripts in the /etc/init.d/rc?.d/ directories.
FW_DEV_WORLD (firewall, masquerading): The device linked to the Internet, such as eth0 or, in the case of ISDN, ippp0.
FW_DEV_INT (firewall, masquerading): The device linked to the internal, private network. Leave this blank if there is no internal network and the firewall is supposed to protect only the one host.
FW_ROUTE (firewall, masquerading): If you need the masquerading function, enter yes here. Your internal hosts will not be visible to the outside, because their private network addresses (for instance 192.168.x.x) are ignored by Internet routers.
For a firewall without masquerading, only set this to yes to allow access to the internal network. Your internal hosts need to use officially registered IPs in this case. Normally, however, you should not allow access to your internal network from the outside.
FW_MASQUERADE (masquerading): Set this to yes if you need the masquerading function. It is more secure to have a proxy server between the hosts of the internal network and the Internet.
FW_MASQ_NETS (masquerading): Specify the hosts or networks to masquerade, leaving a space between the individual entries. For example, FW_MASQ_NETS="192.168.0.0/24 192.168.10.1"
FW_PROTECT_FROM_INTERNAL (firewall): Set this to yes to protect your firewall host from attacks originating in your internal network. Services will only be available to the internal network if explicitly enabled. See also FW_SERVICES_INTERNAL_TCP and FW_SERVICES_INTERNAL_UDP.
FW_AUTOPROTECT_GLOBAL_SERVICES (firewall): This should normally be yes.
FW_SERVICES_EXTERNAL_TCP (firewall): Enter the services that should be available, for example, www smtp ftp domain 443. Leave this blank for a workstation at home that should not offer any services.
FW_SERVICES_EXTERNAL_UDP (firewall): Leave this blank if you do not run a name service that should be made available to the outside. Otherwise, enter the ports to use.
FW_SERVICES_INTERNAL_TCP (firewall): This defines the services available to the internal network. The notation is the same as for external TCP services, but, in this case, refers to the internal network.
FW_SERVICES_INTERNAL_UDP (firewall): See above.
FW_TRUSTED_NETS (firewall): Specify the hosts you really trust (“trusted hosts”). Note, however, that these also need to be protected from attacks.
“172.20.0.0/16 172.30.4.2” means that all hosts with an IP address beginning with 172.20.x.x and the host with the IP address 172.30.4.2 are allowed to pass information through the firewall.
FW_SERVICES_TRUSTED_TCP (firewall): Here, specify the port addresses that may be used by the trusted hosts. For example, to grant them access to all services, enter 1:65535. Usually, it is sufficient to enter the port address of ssh to allow this as the only service.
FW_SERVICES_TRUSTED_UDP (firewall): Just like above, but for UDP ports.
FW_ALLOW_INCOMING_HIGHPORTS_TCP (firewall): Set this to ftp-data if you intend to use normal (active) FTP services.
FW_ALLOW_INCOMING_HIGHPORTS_UDP (firewall): Set this to dns to use the name servers registered in /etc/resolv.conf. If you enter yes here, all high ports will be enabled.
FW_SERVICE_DNS (firewall): Enter yes if you run a name server that should be available to external hosts. At the same time, enable port 53 under FW_TCP_SERVICES_*.
FW_SERVICE_DHCLIENT (firewall): Enter yes here if you use dhclient to assign your IP address.
FW_LOG_* (firewall): Specify the firewall's logging activity. For normal operation, it is sufficient to set FW_LOG_DENY_CRIT to yes.
FW_STOP_KEEP_ROUTING_STATE (firewall): Insert yes if you have configured your dial-up procedure to work automatically via diald or ISDN (dial-on-demand).
Now that you have configured the firewall, do not forget to test your setup (for example, with telnet from an external host). Have a look at /var/log/messages, where you should see something like:
Mar 15 13:21:38 linux kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:80:c8:94:c3:e7:00:a0:c9:4d:27:56:08:00 SRC=192.168.10.0 DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=15330 DF PROTO=TCP SPT=48091 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A061AFEBC0000000001030300)
The YaST dialogs for the graphical configuration can be accessed from the YaST Control Center. Select -> . The configuration is divided in four sections:
Specify the interfaces to protect. To protect an individual host to which no internal network is connected, just specify the interface facing the Internet. If an internal network is connected to your system, the interface facing the network must also be specified. Exit this dialog with .
You only need this option to use your system to offer services accessible from the Internet (web server, mail server, etc.). Activate the respective check boxes or use to enable services by way of their port numbers (listed in /etc/services). If you are not going to use your host as a server, press to exit this dialog without making any changes.
Here, select the main features of your firewall:
assists in checking the routing to your firewall.
protects hosts in the internal network against the Internet — all Internet services appear to be used by your firewall, while the internal hosts remain invisible.
indicates that network access to TCP and UDP services of the firewall is denied entirely. This does not affect the services explicitly made available in the preceding step.
Only the released firewall services are available for internal hosts. As it is not possible to make services available here, deactivate this option to grant access from the internal network.
Upon completion of the feature configuration, exit this dialog with .
Determine the scope of logging for your firewall. Before you activate the , consider that these log files produce a great amount of output. The configuration of the logging function is the final step of the firewall configuration. Exit the dialog with and confirm the following message to activate the firewall.
