Linux notebook / Typical
Description: Documents various Linux or *nix programs and concepts, including qmail, djbdns, emacs, Perl, hardware, bash, TCP/IP, DNS, etc...
Keywords: find djbdns system dns typical bash less gdb daemontools mirrordir math tables mysql qmail isdn make http ezmlm shell pppd cftp regexps intro awk dhcp test hardware ucspi-tcp apache html perl php3 fetchmail versions emacs email peripherals

Apache Awk Bash C cftp daemontools DHCP djbdns DNS Emacs Email ezmlm Fetchmail find GDB Hardware HTML HTTP Intro ISDN less Make Math mc mirrordir MySQL Peripherals Perl PHP3 pppd qmail Regexps Shell System Tables test To do Typical ucspi-tcp Versions Index TCP/IP slides
Typical |  | top

> Introduction

> Some points regarding typical configurations will be detailed below, linking to other places in these documents if possible. A disclaimer is in order, however: the security concepts below are always subject to the possibility that a very smart cracker finds a way to bypass the protections. Use it at your own risk.

> Network security concerns

> A very common network setup based on Linux is similar to the following:

> The picture depicts a network made out of 3 workstations, running whatever operating system is required, a server (running Linux, in our examples), a router (which can be replaced by a internal dial-up adapter in the server, be it a analog modem or a ISDN board, etc), and the Internet.

> We are assuming, for our analysis, that the router is some sort of transparent device, that is, it is accessed by a single IP address from the server side. Also, the server has a dedicated network adapter connecting it to the inner network. The router would be connected to another network adapter, inner port, etc.

> From the above, we can define the server as being both the firewall and the Internet router. We want to enable the workstations access to the Internet in the most secure way possible.

> The usual solution is to deploy a firewall on the server, limiting the kind of traffic that can reach the workstations (and the server itself) from the Internet. The problem with this approach is that one runs the risk of limiting either too much (negating access to unforeseen legitimate access) or not enough (opening access to risky traffic).

> The other solution, assuming that the inner network is trusted (that is, that the workstations won't hack each other and won't deliberately open access to risky traffic) is to make the workstation unroutable from the Internet. This means that no one from the Internet would be able to create a path to a individual workstation without the intervention of the server.

> The server would then accept traffic from the inner network, and translate that traffic from the point of vue of the Internet as if it was coming from the server itself, reversing the translation for legitimate traffic from the Internet only. This is called IP masquerading or NAT (Network Address Translation).

> This approach has the (dis)advantage that it wouldn't be possible to initiate a connection from the Internet into a local workstation. Some legitimate protocols may have problems with this:

> - FTP

>   > The standard (so called active) mode of operation for FTP requires that the FTP server on the Internet from or to which we intend to transfer files initiates the connection. If the workstation is unroutable, the FTP server won't be able to establish the connection. The way around this is to configure the FTP clients to the passive mode, which happens to be also the mode in which all Web browsers operate for FTP transfers.

> - IRC

>   > The so called DCC chat for IRC can't be established if the remote host initiates the connection. The way around is to initiate the DCC chat from the workstation. However, considering the risks involved in DCC (it's Direct Computer to Computer, after all) one shouldn't be sorry to block this kind of traffic.

> - Napster

>   > The remote host also initiates downloads, and as for FTP this is impossible to accomplish to a unroutable workstation. If this is a desirable or undesirable, is up to the network administrator.

> The "unrouting" approach is not a complete security solution:

> 1. If the server is compromised, there's no security

>    > Care must be taken to limit the server's open ports; avoid address spoofing.

> 2. Trojans and virus can still enter the network, as payload to email, FTP'ed files, etc.

>    > The standard protection measures should be taken at the workstation level: anti-virus software; elimination of fragile programs or configurations (Outlook and Windows Scripting Host is a no-no, for example); teaching the users to be basically distrustful of files downloaded from the Internet, odd ball emails, etc.

> 3. The enemy might be within

>    > Standard security precautions must still be implemented: secrecy of passwords; physical protection of the servers; use of encrypted traffic; many security compromises originate in disgruntled employees; etc.

Last update: Wed, 2 Nov 2005 10:16:21 GMT | top