If going with Apache, I would recommend using the 1.3 series unless you have some strange requirement for sticking to 1.2, the active development is now on 1.3, and includes many new features from security, usability, stability and performance viewpoints. Most servers based upon Apache (Red Hat Secure Server, Stronghold, etc.) are generally just as bug free but there are occasionally problems. You can download Apache from http://www.apache.org/. Almost all distributions ship with it, so you should have it as package or whatever.
Chroot'ing Apache
If you want to be paranoid I would suggest running Apache in a chroot'ed environment, this however is sometimes more trouble then it is worth. Doing this will break a great many things. You must also install numerous libraries, Perl, and any other utilities that your Apache server will be using, as well as any configuration files you wish to have access to. Any CGI scripts and other things that interact with the system will be somewhat problematic and generally harder to troubleshoot.
The simplest way to setup Apache chroot'ed is to simply install it and move/edit the necessary files. A good idea is to create a directory (such as /chroot/apache/), preferably on a separate filesystem from /, /usr, /etc (hard links, accidental filling of partitions, etc...), and then create a file structure under it for Apache. The following is an example, simply replace /chroot/apache/ with your choice. You must of course execute these steps as root for it to work. RPM supports this with the “--root /some/dir” directive, simply install Apache and the needed libs using rpm (thus gaining it's support for dependencies/etc, making your life easier). If you are not on an RPM based system simply use ldd to find out which shared libraries are required, and move everything needed into your /chroot/apache/ directory.
[seifried@host seifried]$ ldd /usr/bin/httpd
libm.so.6 => /lib/libm.so.6 (0x40017000)
libc.so.6 => /lib/libc.so.6 (0x40060000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Apache logs requests and so forth internally, so you don't have to worry about setting up pseudo logging daemons like holelogd to pass information to syslog in order to get your log files behaving.
Secure configuration of Apache
About the simplest way to secure Apache and insure that it doesn't have unnecessary access to your filesystem is to create a /www/ or similar directory and place ALL the websites, web content, cgi's and so forth under it. Then you can simply set access.conf up to deny any access to /, and enable access to /www/ and its various cgi-bin directories.
Example for httpd.conf:
Controlling access
Access to directories can also be controlled easily, Apache supports the defining and placement of files (usually referred to as htaccess files) that can control access based on username and password, IP of origin, and so forth. This is defined in srm.conf:
AccessFileName .htaccess
The format of this file is covered in the Apache documentation, and is identical to directives you would place in access.conf (well almost). User authentication via username and password is also covered in depth at: http://www.apacheweek.com/features/userauth.
If you also want to prevent people from viewing the .htaccess file(s), place this in your srm.conf:
order allow,deny
deny from all
This will disallow the viewing of any file called '.htaccess'.
apache-userdirldap
apache-userdirldap allows you to use an LDAP directory for looking up user home directories. In other words if you want to move all your users into an LDAP directory and do ALL authentication through it, you won't have to break Apache. You can get it at: http://horde.net/~jwm/software/apache-userdirldap/.
thttpd
A lightweight http server suitable for web based interfaces and the like (Phoenix Adaptive firewall uses it for htier interface for example). You can get it at:http://www.acme.com/software/thttpd/
AOL Server
I know, it sounds strange but it is true. AOL Server is a free www server, with source code available. Not only that but it supports SSL and several other advanced features. Definitely worth taking a look at. You can get it from: http://aolserver.com/.
There is more to securing your www server then installing Apache and configuring it properly. Most servers will need to allow access to their filesystems so that users can upload and modify files on the server. For this there are 4 widely used methods that I will cover in detail.
webfs
webfs is a lightweight www server that implements basic functionality and is available from: http://www.in-berlin.de/User/kraxel/webfs.html.
Simple Web Server
Simple Web Server is a small web server with basic functionality. You can get it at: http://linuxstuffs.cjb.net/.
Flash Web Server
A lightweight, fast www server, You can get it at: http://www.cs.rice.edu/~vivek/flash/.
Secure WWW server software
There are several free alternatives for Apache with SSL, and several commercial ones. If you are located in the US, RSA is patented, so you either have to use DSA (which is hard to get site certificates for) or buy a commercial server based on Apache (like Stronghold). If you are located in Europe you may live in a country where IDEA is patented, so make sure you check first. There are also a variety of commercial packages. I have also written two article covering the various secure www servers:
Apache-SSL
This is the one I currently use (simple because I tried it before Apache with mod_ssl, and it worked). You need to get Open-SSL, compile and install that, and then patch Apache with the Apache-SSL patch, compile Apache, and off you go. Open-SSL is available from: http://www.openssl.org/, simply get the latest tarball, unpack it, and run:
./config
make
make test
make install
It hasn't ever failed for me yet. You then need get the Apache-SSL stuff from http://www.apache-ssl.org/, unpack the Apache source somewhere, cd into the top level dir (/usr/local/src/apache_1.3.9/) and then unpack the Apache-SSL stuff into it (it tells you to do this in the docs, sort of a catch 22). You then simply run:
./FixPatch
Which should work (if it doesn't read the README.SSL), then configure Apache as usual, and run make, followed by make install. Skip down to the "Creating a certificate" section.
Apache with mod_ssl
Apache with mod_ssl is available from http://www.modssl.org/. I haven't tested it yet.
Creating a certificate
This is the easy part, the next step is to create a key set, and then configure httpsd.conf to use it appropriately. Find where "openssl" is installed and make sure it is in your path, then cd to wherever you placed your apache config files (whatever you prefixed as the apache root followed by /conf/). If you need to create a test certificate, simply to use internally then you can:
openssl genrsa -des3 > httpsd.key
openssl req -new -x509 -key httpsd.key > httpsd.crt
Browsers will complain loudly about this certificate because it is created by the person who signs it, and they are untrusted. If you want to generate a certificate, and a certificate request to send to someone like Thawte or Verisign then you need to:
openssl genrsa -des3 > httpsd.key
openssl req -new -key httpsd.key > httpsd.csr
You can also get real certificates with limited life times (usually a week or two) from Verisign to use for testing in a more "real world" environment.
Configuring Apache for SSL
There are several things you will need to add to your Apache config file to get Apache with SSL extensions actually doing anything useful with your certificates. You'll need to add some global configuration settings (note these apply to 1.3.9, and will barf on earlier versions of Apache):
# you will need to tell apache to listen to port 443, by default it only goes for 80
Listen 443
# if you use more then one secure site on an IP (BAD IDEA) you will need:
NameVirtualHost 10.1.1.1:443
#it's a good idea to disable SSL globally and enable it on a per host basis
SSLDisable
# SSL cache server, without this your server will die
SSLCacheServerPath /usr/bin/gcache
# port the cache server runs on
SSLCacheServerPort 12345
# timeout for the SSL cache, set shorter for testing, 300 is a good "real world" value
SSLSessionCacheTimeout 300
Now you can create a virtual host with SSL enabled:
Red Hat Secure Server
Red Hat Secure Server is an Apache based product from (guess who) Red Hat software. Essentially it is stock Apache with RSA cryptographic modules (which is what you are paying for essentially) and can also serve standard non cryptographic http requests. It can only be sold in the USA and Canada, and is the best option (in my opinion) as far as secure www servers that are legal to use in the US go (due to RSA patents). As far as security goes read the previous section on Apache / Apache-SSL, it all applies. Red Hat Secure Server costs $100 US and you get a $25 discount on your Thawte site certificate (so the site certificate only costs $100 US). I personally like it a lot as it is based on software that runs over half the www sites in the world and as such getting support/updates/etc. is easy. You can buy Red Hat Secure Server from: http://store.redhat.com/commerce/.
Roxen
Roxen is another commercial www server capable of https and is GPL licensed. You can freely download it if you are in the European Union or Australia, Canada, Japan, New Zealand, Norway, USA, or Switzerland. A version with “weak” (40 bit) crypto can be downloaded without any problems to any country. Roxen is an extremely solid product and is available from:http://www.roxen.com/.
Zeus
Zeus is a high end www server that supports SSL. It is a commercial product, and you can get it (a 30 day demo is available) at: http://www.zeustechnology.com/.
Netscape Enterprise
Currently in beta testing (although it installed and runs fine) for Linux, available from: http://www.iplanet.com/downloads/iwsonlinux.html.
IBM HTTP Server
IBM also makes an HTTP server for Linux (based on Apache) that you can download from here: http://www-4.ibm.com/software/webservers/httpservers/download.html.
Accessing your WWW server files
At some point you will need to access the files on the www server to update them. Logging in and using a text editor like emacs is not usually a good long term decision if you value your time. Several popular HTML authoring packages can access your website via FTP or windows file sharing.
FTP
This is the “classic” method of granting users access to ftp servers, typically concerns include users viewing each others data, viewing system data they should not, and so forth. Chroot’ing the users ftp session will solve most of these problems, however the main problem with ftp, as for encrypting the username and password this is typically undoable due to the fact most people are running Windows FTP clients. I would recommend ProFTPD over WU-FTPD for an application such as this, ProFTPD has much better access controls.
Samba access
Samba is quite useful for sharing out the www directories to Windows clients, you can then keep the usernames and passwords separate from the system (using smbpasswd rather then the system passwd) and encryption of logins is no problem. Simply make the shares non browseable, and use the “valid users” directive to restrict which users may view the share data. For example:
[www-example]
path = /www/www.example.org/
valid users = someuser
read only = No
browseable = No
will setup a pretty secure share for the directory “/www/www.example.org/” that only the user “example” can access.
FrontPage access
FrontPage is one of the most popular HTML programs for Windows users (heck, I even use it). It can talk directly to WWW servers and download / upload files from a site (called a “FrontPage Site”) if the server supports FrontPage extensions. FrontPage extensions are available for various UNIX platforms, for free, from Ready To Run Software, at: http://www.rtr.com/. In the past, security wise, RTR’s FrontPage extensions for UNIX have been a bit of a disaster. There are commercial alternatives however, one is Instant ASP, available from:http://www.halcyonsoft.com/. An excellent document on getting FrontPage working with Apache 1.3.X is available at: http://www.itma.lu/howto/apache/.
RearSite
RearSite is a cgi program that provides users access to their directories via a normal web browser. You can get it from: http://listes.cru.fr/rs/fd/.
Fast Webpage Exchanger
Fast Webpage Exchanger keeps files in synch using ftp and has a nice config file where you specify everything. You can download it from:http://www.enjoy.ne.jp/~gm/program/iwe_en.html.
WebRFM
WebRFM (Web-based Remote File Manager) is a CGI (Perl) application that allows users to manage their files. You can get it at: http://webrfm.netpedia.net/.
WWW based email readers
Overview
One of the better solutions is to use a www based mail client, these can usually be run under a secure www server with minimal extra work, and have the added bonus of letting users check email safely from locations that would normally make checking email difficult (while on vacation in Europe, for example). Unfortunately the majority of www-based mail reading clients stink, and the good ones cost an arm and a leg.
Non-commercial
AtDot
AtDot is GNU licensed and written in Perl. It has several modes of operation making it suitable for a variety of www based email solutions (hotmail style providers, ISP’s, etc.). You can download it from: http://www.nodomainname.net/software/atdot/.
acmemail
IMHO
IMP
IMP requires the Horde module (available on the same site) and a www server capable of PHP3 support. You can download IMP and Horde from: http://www.horde.org/imp/.
MailMan
MailMan is a quasi free (for non comemrcial use) web based gateway for POP email. If you plan to use it commrcially you must buy it. You can get it at:http://www.endymion.com/products/mailman/
SquirrelMail
TWIG
WebMail
Commercial
Coconut WebMail Pro
DmailWeb
WebImap
X Window System
Overview
The X Window System provides a network-transparent method for sharing graphical data, or more specifically for exporting the display of a program to a remote (or the local) host. Using it you can run a powerful 3d rendering package on your SGI origin 2000 and display it on a 486. Essentially it's the granddaddy to all this 'thin client' hype that is becoming very popular nowadays. It was created by MIT, at a time when security was not much of a concern. This, of course, has led to more then a few nasty bugs being found. Worse, the level of control X is given (it handles keystrokes, mouse movements, draws the screen, etc.) means if it is compromised, very bad things will happen. This data, if sent over the network (i.e., the X program being run is displaying on a remote host) can easily be logged, so sensitive information (like an xterm being used to login to another remote system) is vulnerable. In addition to these problems the authentication protocol that X uses is relatively weak (although it has been improved). Running a graphical xemacs session on a server 3 timezones away however can be a very handy thing.
X is very predictable in port usage, almost all implementations and installations of X use port 6000 for the first session and increment by one for other sessions, thus making it quite easy to scan for. If you are not going to be using X to display program running on remote systems I suggest strongly that you firewall port 6000.
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 6000:6100
ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 6000:6100
ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 6000:6100
or
ipchains -A input -p tcp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 6000:6100
ipchains -A input -p tcp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 6000:6100
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 6000:6100
X server security configuration
There are a number of methods to secure access to your X server.
xhost
xhost simply allows you to specify which machines are, or aren't allowed to connect to the X server, this is a very simplistic security mechanism and is not really suitable in any modern environment, however used in conjunction with other mechanisms it can help. The command is quite simple: 'xhost +example.org' adds example.org, 'xhost -example.org' removes example.org from the list, you must also specify 'xhost -' to turn on the access control list, or else everyone is let in by default.
mkxauth
mkxauth is definitely a step up from xhost. mkxauth helps create ~/.Xauthority files, and merge them, which are used to specify hostnames and the related magic cookies (basically a token used to gain access). These cookies can then be used to gain access to a remote X host (you essentially have a copy of the cookie on each end) and are transferred either plain text (insecure) or DES encrypted (quite secure). Using this method you can be relatively safe and secure. Xauthority files can also be used in conjunction with Kerberos, removing the necessity to copy Xauthority files around and keep them in synchronization. Hosts authenticate to each other through a central Kerberos key server(s) in an encrypted fashion, this method is most appropriate for large installations/etc. mkxauth has an excellent man page 'man mkxauth' and more generalized details are available in the Xsecurity man page (not sure how common this name page is) 'man Xsecurity'.
SSH tunnel
SSH or OpenSSH can be used to create a tunnel between hosts (or more specifically between two X servers), thus encrypting the channel, providing authentication, and generally making things safer. The following web page explains it in detail: http://csociety.ecn.purdue.edu/~sigos/projects/ssh/forwarding/.
Firewalling
Overview
Firewalling is the practice of filtering network traffic, typically at the point where your network connects to another (e.g. the Internet, a customers LAN, etc.) network, that may be untrusted (in the case of the Internet) or perhaps even trusted (another floor of your building). Like firewalls in a large building, a network firewall can prevent and even block the spread of an attack if one segment is compromised successfully, like their namesake firewalls can stop your network from being further compromised. There is a good FAQ on Internet firewalls at:http://www.interhack.net/pubs/fwfaq/. A paper on identifying ports and explanations of what they do is available at: http://www.robertgraham.com/pubs/firewall-seen.html.
Firewall software for Linux
Linux has had firewalling capacity for quite a while now in the form of ipfwadm, which was a very simple packet-level filter. With the advent of kernel 2.1 this has been replaced with ipchains which is quite a bit more sophisticated. This will be replaced in kernel 2.4 (proposed) with an even more advanced packet filter that is more independent. Both are still basic packet filters however and do not allow for advanced features such as stateful inspection or some types of proxying connections. However, Linux does support IPMASQ, an advanced form of NAT (Network Address Translation). IPMASQ allows you to hook up a network of computers to the Internet but proxy their connections at the IP level. Thus all traffic appears to be coming and going to one machine (the Linux IPMASQ box) which affords a high degree of protection to the internal network. As an added bonus the clients on the internal network require NO proxy configuration; as long as the Linux IPMASQ server is configured correctly, and the clients use it as their default gateway, things will work quite well.
Both ipchains and ipfwadm provide the following basic capabilities:
� blocking / allowing data to pass based on IP/port/interface source/destination
� masquerading of connections, based on IP/port/interface source/destination
� masquerading of connections, based on IP/port/interface source/destination
In addition to which ipchains supports:
� port forwarding
� creation of chains, for more intricate rules and conditions, easier to maintain
� quality of service (QOS) routing, useful on low speed connections or otherwise saturated connections
� specification of IP/port/interface as well as inverse specification (using the !)
� creation of chains, for more intricate rules and conditions, easier to maintain
� quality of service (QOS) routing, useful on low speed connections or otherwise saturated connections
� specification of IP/port/interface as well as inverse specification (using the !)
The Firewall-HOWTO and "man
When deciding policy you should choose a policy that will default to denying everything unless specifically allowed through (that is if there is a failure it will hopefully be minimized via default policies) or a policy that allows everything and blocks certain services/hosts. I typically use a policy of default denial as it can accommodate mistakes and changes more safely then a policy that defaults to allowing data through.
Case in point, you have a server secured via firewalling, currently running Apache, you install WU-FTPD on it for internal use (so people can upload files) at 3 am, you forget to change the firewall rules. If you have chosen a policy of default allowal, anyone on the Internet can access the ftp server, and silly you, you installed an old version which allowed someone to compromise the machine. If on the other hand you go with a policy of default denial, they would not have access to the ftp server, and neither would your users, but you would find out quite quickly. Annoyed users are much easier to appease then fixing a network that has been compromised.
I have decided to not cover specific firewalling rules in this section, for each network service I will provide examples, as to properly firewall a protocol you need to understand how it behaves. There is a huge difference between firewalling www and ftp for inbound and outbound access for example. Some general concepts/rules:
IPFWADM
Ipfwadm is a solid packet filter for Linux, although it lacks a lot of features available in Ipchains. Ipfwadm only supports 3 targets for a packet: accept, deny or reject, whereas ipchains rules can be targeted at 6 built-in targets, or a user defined target. Ipfwadm is really only appropriate for a simple IP-level firewall, ipmasquerading and if you plan to use FreeS/WAN (which currently does not support kernel 2.2.x). The basic options are: specify a direction (in, out, or both, useful with the interface flag), input rules, output rules, forwarding rules (say you have multiple interfaces, also covers the masquerading rules) and masquerade rules which control the behavior of masquerading (timeouts, etc). You can insert, append and delete rules, set default policies, and list all the rules. Other then that it is very similar to ipchains, with some minor variations. The following is a script appropriate for a server bridging 2 networks (10.0.0.x on eth0, 10.0.0.1 and 192.168.0.x on eth1, 192.168.0.1) with a mail server running.
#!/bin/bash
#
# Flush all the rule sets first
#
ipfwadm -f -I
ipfwadm -f -O
ipfwadm -f -F
#
# Allow forwarding between the two networks and otherwise deny it for security
#
ipfwadm -F -a accept -P all -S 10.0.0.0/24 -i eth0 -D 192.168.0.0/24
ipfwadm -F -a accept -P all -S 192.168.0.0/24 -i eth1 -D 10.0.0.0/24
ipfwadm -F -p deny
#
# And of course we have to allow those packets in
#
ipfwadm -I -a accept -P tcp -S 10.0.0.0/24 -i eth0 -D 192.168.0.0/24
ipfwadm -I -a accept -P tcp -S 192.168.0.0/24 -i eth1 -D 10.0.0.0/24
#
# Let them access the mail server port on the server but nothing else
#
ipfwadm -I -a accept -P tcp -S 10.0.0.0/24 -i eth0 -D 10.0.0.1 25
ipfwadm -I -a accept -P tcp -S 192.168.0.0/24 -i eth0 -D 192.168.0.1 25
ipfwadm -I -p deny
FreeS/WAN now supports the 2.2.x series of kernels, you should never choose ipfwadm over ipchains. ipchains offers a much finer degree of control and is much more flexible then ipfwadm.
IPCHAINS
ipchains contains several new features as compared to ipfwadm; you can create chains of rules (hence the name) and link them together, making administration of firewalls far easier. Ipchains supports more targets then ipfwadm; you can point a rule at: ACCEPT, DENY, REJECT, MASQ, REDIRECT, or RETURN or a user defined chain. As such it is very powerful, for example I could redirect all packets bound for port 80 (www traffic) going through my gateway machine to be redirected to local port 3128, the Squid proxy server. You can also use this in conjunction with quality of service routing, the example given in ipfwadm's documentation is that of prioritizing traffic going over a PPP link, you can give telnet traffic a much higher priority then say ftp, reducing latency problems caused by a saturated link. Typically I create an /etc/rc.d/init.d/ipchains-sh (or wherever appropriate) and call it immediately before the networking is brought up, this leaves a NO time in which the server is vulnerable.
The following script is appropriate for a gateway with 2 interfaces running, the reason I have used the DENY instead of REJECT target is so that the packet is dropped and not responded to in any way, this slows down network scans (as they wait for the packet to timeout instead of receiving a response) and gives away less information. I would also advise against logging data unless you have a significant amount of drive space available, for each packet I send (several bytes) many bytes of drive space is used up to create a log entry, making it easy to overwhelm syslog and/or your drive space on a fast connection. The ipchains homepage is at: http://netfilter.kernelnotes.org/.
#!/bin/bash
#
# This script sets up firewall rules appropriate for a server with 2 interfaces
# running as a gateway
# This script needs to be edited if you plan to use it.
# We assume the internal machines call all talk to the gateway, so no rules block
# internal traffic
#
# A couple of variables
#
# ETH0 is the IP address on ETH0 (the external interface)
# ETH0NET is the network
# ETH0NETMASK is the network mask
# TRUSTEDHOST1 is a trusted host (for webmin/ssh)
# TRUSTEDHOST2 is a trusted host (for webmin/ssh)
# ETH1IP is the IP address on ETH1 (internal interface)
# ETH1NET is the network
# ETH1NETMASK is the network mask
#
ETH0IP=1.1.1.1
ETH0NET=1.1.1.0
ETH0NETMASK=24
TRUSTEDHOST1=1.5.1.1
TRUSTEDHOST2=1.5.1.2
ETH1IP=10.0.0.1
ETH1NET=10.0.0.0
ETH1NETMASK=24
#
PATH=/sbin
# FLUSH ALL RULES
ipchains -F input
ipchains -F output
ipchains -F forward
# ANTI-SPOOFING
ipchains -A input -p all -j DENY -s 10.0.0.0/8 -i eth0 -d 0.0.0.0/0
ipchains -A input -p all -j DENY -s 127.0.0.0/8 -i eth0 -d 0.0.0.0/0
ipchains -A input -p all -j DENY -s 192.168.0.0/16 -i eth0 -d 0.0.0.0/0
ipchains -A input -p all -j DENY -s 172.16.0.0/16 -i eth0 -d 0.0.0.0/0
ipchains -A input -p all -j DENY -s $ETH0IP -i eth0 -d 0.0.0.0/0
# ICMP FIRST
ipchains -A input -p icmp -j ACCEPT -s $ETH0NET/$ETH0NETMASK -i eth0 -d 0.0.0.0/0
ipchains -A input -p icmp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0
# SSH
ipchains -A input -p tcp -j ACCEPT -s $TRUSTEDHOST1 -i eth0 -d 0.0.0.0/0 22
ipchains -A input -p tcp -j ACCEPT -s $TRUSTEDHOST2 -i eth0 -d 0.0.0.0/0 22
# BLOCKING 1:1023
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1:1023
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1:1023
# BLOCKING OTHER THINGS
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1109
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1524
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1600
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2003
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2049
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2105
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3001
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3001
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3128:3130
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3128:3130
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3306
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3306
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 4444
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6000:6100
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6000:6100
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6667
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 7000
# WEBMIN
ipchains -A input -p tcp -j ACCEPT -s $TRUSTEDHOST1 -i eth0 -d 0.0.0.0/0 10000
ipchains -A input -p tcp -j ACCEPT -s $TRUSTEDHOST2 -i eth0 -d 0.0.0.0/0 10000
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 10000
# FORWARD RULES
ipchains -P forward DENY
ipchains -A forward -p all -j MASQ -s $ETH1NET/$ETH1NETMASK -d 0.0.0.0/0
NETFILTER
NETFILTER is the next generation of packet firewalling for Linux. It should make a variety of activities easier, such as firewalling, IPSec, anything to do with packet management really. The HOWTO is available at: http://netfilter.kernelnotes.org/.
IPF
IPF is an alternative firewall package, available for Linux (and most other operating systems). You can get it at: http://coombs.anu.edu.au/~avalon/.
SINUS Firewall
SINUS Firewall is an alternate firewall for Linux (kernel 2.0.x and 2.2.x). You can get it at: http://www.sinusfirewall.org/.
Phoenix Adaptive Firewall
I am in the process of evaluating this product however it looks very promising. It replaces ipchains completely and adds a lot of intelligence to the firewalling process. It is a commercial product however (about $3000 US), and the first firewall to be ICSA certified for Linux. It is available at: http://www.progressive-systems.com/products/phoenix/.
FirePlug Edge
A "thin" Linux distributions suitable as a firewall/gateway. You can get it from: http://edge.fireplug.net/.
FWTK
FWTK (FireWall ToolKit) is a set of tools for building proxies and so forth, you can get it at: http://www.fwtk.org/.
Firewall piercing
Sometimes you will be stuck behind a firewall that is not properly set up, or otherwise stopping you from accessing data you need to. There is actually a mini-HOWTO on this that I will be folding into the LASG. http://www.linuxdoc.org/HOWTO/mini/Firewall-Piercing.html. In addition to this is an add-on for the IP Masquerading code that allows certain types of VPN's through, you can get it at: ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html.
Rule creation / scripts
Firewall scripts
Some scripts for Red Hat Linux in rpm format: http://www.webideal.de/rh-isdn/downloads/.
ipfwadm2ipchains
A simple script that converts ipfwadm rules to ipchains rules, making migration a snap. The script is available at: http://users.dhp.com/~whisper/ipfwadm2ipchains/
mason
Mason is an automated firewall rule generator for ipfwadm and ipchains. You load it up and it monitors the packets flowing through the machine, then based on that creates a set of rules to allow that type of activity (i.e. if your ftp into your server from a remote site it will allow that type of access in the rules it creates). A good tool for first time firewall admins, available from:http://users.dhp.com/~whisper/mason/.
Mklinuxfw
Mklinuxfw is a Perl tool that aims to provide a variety of interfaces (CGI, KDE, command line, etc.) to creation of firewall rules. It currently supports a CGI interface and GTK is in progress. You can download it from: http://www.madhouse.org.uk/~red/framepage.phtml?/mklinuxfw/index.html.
fwconfig
fwconfig is a rather nice www based configuration utility for ipfwadm and ipchains. You can download it from: http://www.mindstorm.com/~sparlin/fwconfig.shtml.
xipfwadm
xipfwadm is a Tcl/Tk application for X that simplifies the creation of ipfwadm rules. You can get it from: http://www.x25.org/xipfwadm.html.
Linux Firewall Tools
An interesting site, has an online cgi to create firewall scripts, didn't work for me however (very slow). You can view it at: http://www.linux-firewall-tools.com/.
Easy Firewall
A graphical application written in Tcl/Tk. You can get it at: http://www.linux-kheops.com/pub/easyfw/easyfwGB.html.
DNi
DNi is an online cgi that helps you create firewall rulesets for ipfwadm. You can try it at: http://members.tripod.com/~robel/dni/.
IP Security (IPSec)
Overview
IP Security (IPSec) is the encryption of network traffic. You cannot encrypt the header information or trailer (i.e. the IP address/port the packet is from, and going to, the CRC checksums, and so on), but you can encrypt the data payload. This allows you to secure protocols such as POP/WWW without having to change them in any ways, since the encryption occurs at the IP level. It also allows you to securely connects LANs and clients to each other over insecure networks (like the Internet). Currently IPSec for Linux is in testing, however there have been several stable releases, and I myself have deployed Linux based IPSec servers successfully. IPSec is a standard, and a part of the IPv6 protocol, you can already purchase IPSec software for Windows 95/98/NT, Solaris, and other unices that will interoperate with Linux IPSec. For "drilling" through a firewall or perhaps to get by a NAT box (such as Linux with IP Masquerading) please see thefirewall section.
IPSec kernel support
To use IPSec you need IPSec support in the kernel. Unfortunately no American Linux distribution can ship strong crypto outside of North America so generally speaking they choose not to include it at all, of the foreign Linux distributions, currently, none ship with IPSec support built into the kernel. You will need to get the kernel source (I recommend 2.2.13, as of December 1999), and the Linux IPSec source code, available from: http://www.freeswan.org/ (current stable snapshot 1.2, as of December 1999).
Install the kernel source (usually to /usr/src/linux) and then compile a new kernel, install it, boot to it, and test it. Make sure your networks work properly, if they don’t work, getting IPSec to work will be impossible. Now you need to download the latest IPSec software (version 1.0 will NOT work with 2.2.x kernels). Then go to /usr/local/src (or wherever you put your source code for programs), unpack the source and run the install program (make menugo typically for the ncurses based configuration). This will patch the kernel files, then run the kernel configuration, and then build the IPSec tools, and the kernel.
cd /usr/local/src/
tar –zvvxf /path/to/tarball/snapshot.tar.gz
chown –R root:root freeswan-snap1999Jun14b
cd freeswan-snap1999Jun14b
make menugo
make sure you save the kernel configuration, even though the options are chosen they have not been saved. You might also have to rebuild the kernel as the "make menugo" command sometimes runs a "make zImage" which usually fails due to the large kernel sizes with 2.2.x. Once the compile is done it should have an error message or two, simply:
cd /usr/src/linux
make bzImage
cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.2.13-ipsec
Now we need to edit lilo.conf, rerun lilo, and reboot to make use of the new kernel. lilo.conf should look like:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=100
image=/boot/vmlinuz-2.2.13-ipsec
label=linux-ipsec
root=/dev/hda1
read-only
image=/boot/vmlinuz-2.2.13
label=linux
root=/dev/hda1
read-only
rerun lilo and you should see:
linux-ipsec *
linux
then reboot and you should be running kernel 2.2.13 with IPSec support. As the machine reboots and starts the IPSec stuff you will see several errors, by default IPSec is set to use the eth999 interface, which of course does not exist. You should also add /usr/local/lib/ipsec to your path statement or else you will have to type the full path in a lot.
IPSec network setup
You will need to enable TCP-IP forwarding on the gateway server, in Red Hat Linux this is accomplished by changing the line in /etc/sysconfig/network from:
FORWARD_IPV4="false”
to:
FORWARD_IPV4="yes"
or you can enable it via the /proc filesystem:
cat 1 > /proc/sys/net/ipv4/ip_forward
Since most people have default deny policies for forwarding packets you will need to allow packets to traverse from the remote network / machine to your network / machine and vice versa. In addition to this, any masquerading rules for internal networks that are also using IPSec must come after the rules allowing IPSec related traffic, or the machine will try to masquerade the packets, instead of them being passed over to IPSec.
IPSec configuration
Then you need to configure your ipsec settings. These are typically held in /etc/ipsec.conf, and /etc/ipsec.secrets, you can use an include statement however to break the files up.
Manual connection keying
First we’ll set up a link using manual keying (for simplicity), you will need to edit ipsec.conf, and your firewall rules. Most of the defaults in the ipsec.conf file are fine but you will need to change the following:
conn sample
type=tunnel
left=
leftnexthop=
leftsubnet=
right=
rightnexthop=
rightsubnet=
spibase=0x200
esp=3des-md5-96
espenckey=
espauthkey=
replace the espenckey and espauthkey with new keys (using ranbits to generate a number, remember to leave the leading 0x that specifies it is a hex number) so that it looks like:
conn my-tunnel
type=tunnel
left=1.2.3.4
leftnexthop=1.2.3.1
leftsubnet=10.0.0.0/24
right=5.6.7.8
rightnexthop=5.6.7.1
rightsubnet=192.168.0.0/24
spibase=0x200
esp=3des-md5-96
espenckey=some_auth_key_here (ranbits 192)
espauthkey=some_other_key_here (ranbits 128)
Once you have done this copy the files ipsec.conf and ipsec.secrets from the machine you edited them on to the other server in a secure manner. Now all that remains to be done is the addition of some firewall rules so that packets do not get masqueraded (instead we simply want them forwarded).
On Server 1.2.3.4 you should add the following rules:
ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24
ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24
make sure these rules appear before the masquerading rule, it should look like this:
#
# FORWARD RULES
#
ipchains -P forward DENY
#
ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24
ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24
ipchains -A forward -p all -j MASQ -s 10.0.0.0/24 -d 0.0.0.0/0
And on server 5.6.7.8 you basically repeat the process:
ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24
ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24
make sure these rules appear before the masquerading rule, it should look like this:
#
# FORWARD RULES
#
ipchains -P forward DENY
#
ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24
ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24
ipchains -A forward -p all -j MASQ -s 192.168.0.0/24 -d 0.0.0.0/0
Now you should be able to bring up the ipsec tunnel on both machines manually and the machines on Network A should be able to talk to the machines on Network B with no problems.
ipsec manual –up my-tunnel
and it should produce output similar to:
/usr/local/lib/ipsec/spi: message size is 36
/usr/local/lib/ipsec/spi: message size is 132
/usr/local/lib/ipsec/spi: message size is 132
To test it try pinging 192.168.0.2 from the 10.0.0.2 client. If this works then you have set it up correctly. If it does not work check your network to make sure 1.2.3.4 can reach 5.6.7.8, and that TCP-IP forwarding is enabled, and make sure that no firewall rules are blocking the packets, or trying to masquerade them. Once you have established a connection and tested it successfully you should move to automatic keying (especially if it’s in a production environment).
Automatic connection keying
If you intend to use IPSec in a production environment, manual keying is a bad idea generally speaking. With automatic keying you have a 256 bit shared secret you copy to both ends of the tunnel, which is then used during the key exchanges to make sure a man in the middle attack does not occur. With automatic keying the default lifetime of a key is 8 hours, which you can set to anything you like, and if someone manages to brute force the key, it is only good for that 8 hour chunk of traffic. The following example builds on the previous one:
ipsec.secrets contains the shared secret. This file must be kept secure at all costs. For a connection between the 1.2.3.4 and 5.6.7.8 servers you would need a line like:
1.2.3.4 5.6.7.8 “0xa3afb7e6_20f10d66_03760ef1_9019c643_a73c7ce0_91e46e84_ef6281b9_812392bf”
This line needs to be in the ipsec.secrets file of both computers. You would then need to edit the tunnel configuration in ipsec.conf to the following:
conn my-tunnel
type=tunnel
left=1.2.3.4
leftnexthop=1.2.3.1
leftsubnet=10.0.0.0/24
right=5.6.7.8
rightnexthop=5.6.7.1
rightsubnet=192.168.0.0/24
keyexchange=ike
keylife=8h
keyingtries=0
The pluto daemon will then startup, try to connect to the Pluto daemon at the other end of the tunnel, and establish a connection. One caveat, Pluto runs on port 500, UDP, so chances are you will have to poke a hole in your firewall to allow it through:
ipchains -A input -p udp -j ACCEPT -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 500
I find it convenient to use the “%search” keyword instead of listing the tunnel to bring up, by adding:
auto=start
to each tunnel configuration and editing ipsec.secrets:
plutoload=%search
plutostart=%search
This will make your life generally easier in the long run. If all goes well you should see something like this in /var/log/messages:
Jun 26 02:10:41 server ipsec_setup: Starting FreeS/WAN IPSEC...
Jun 26 02:10:41 server ipsec_setup: /usr/local/lib/ipsec/spi: message size is 28.
Jun 26 02:10:41 server ipsec_setup: KLIPS debug `none'
Jun 26 02:10:41 server ipsec_setup: KLIPS ipsec0 on eth0 1.2.3.4/255.255.255.0 broadcast 24.108.11.255 Jun 26 02:10:42 server ipsec_setup: Disabling core dumps:
Jun 26 02:10:42 server ipsec_setup: Starting Pluto (debug `none'):
Jun 26 02:10:43 server ipsec_setup: Loading Pluto database `my-tunnel':
Jun 26 02:10:44 server ipsec_setup: Enabling Pluto negotiation:
Jun 26 02:10:44 server ipsec_setup: Routing for Pluto conns `my-tunnel':
Jun 26 02:10:45 server ipsec_setup: Initiating Pluto tunnel `my-tunnel':
Jun 26 02:10:45 server ipsec_setup: 102 "my-tunnel" #1: STATE_MAIN_I1: initiate
Jun 26 02:10:45 server ipsec_setup: 104 "my-tunnel" #1: STATE_MAIN_I2: from STATE_MAIN_I1; sent MI2, expecting MR2
Jun 26 02:10:45 server ipsec_setup: 106 "my-tunnel" #1: STATE_MAIN_I3: from STATE_MAIN_I2; sent MI3, expecting MR3
Jun 26 02:10:45 server ipsec_setup: 003 "my-tunnel" #1: STATE_MAIN_I4: SA established
Jun 26 02:10:45 server ipsec_setup: 110 "my-tunnel" #2: STATE_QUICK_I1: initiate
Jun 26 02:10:45 server ipsec_setup: 003 "my-tunnel" #2: STATE_QUICK_I2: SA established Jun 26 02:10:46 server ipsec_setup: ...FreeS/WAN IPSEC started
And in the /var/log/secure file you should see something like:
Jun 26 02:10:42 server Pluto[25157]: Starting Pluto (FreeS/WAN Version snap1999Jun14b)
Jun 26 02:10:44 server Pluto[25157]: added connection description "my-tunnel"
Jun 26 02:10:44 server Pluto[25157]: listening for IKE messages
Jun 26 02:10:44 server Pluto[25157]: adding interface ipsec0/eth0 1.2.3.4Jun 26 02:10:44 server Pluto[25157]: loading secrets from "/etc/ipsec.secrets"
Jun 26 02:10:45 server Pluto[25157]: "my-tunnel" #1: initiating Main Mode
Jun 26 02:10:45 server Pluto[25157]: "my-tunnel" #1: ISAKMP SA established
Jun 26 02:10:45 server Pluto[25157]: "grumpy-seifried" #2: initiating Quick Mode POLICY_ENCRYPT+POLICY_TUNNEL+POLICY_PFS
Jun 26 02:10:45 server Pluto[25157]: "my-tunnel" #2: sent QI2, IPsec SA established
Jun 26 02:11:12 server Pluto[25157]: "my-tunnel" #3: responding to Main Mode
Jun 26 02:11:12 server Pluto[25157]: "my-tunnel" #3: sent MR3, ISAKMP SA established
Jun 26 02:11:12 server Pluto[25157]: "my-tunnel" #4: responding to Quick Mode
Jun 26 02:11:12 server Pluto[25157]: "my-tunnel" #4: IPsec SA established
Jun 26 02:31:31 server Pluto[25157]: "my-tunnel" #5: responding to Main Mode
Jun 26 02:31:32 server Pluto[25157]: "my-tunnel" #5: sent MR3, ISAKMP SA established
Jun 26 02:31:32 server Pluto[25157]: "my-tunnel" #6: responding to Quick Mode
Jun 26 02:31:32 server Pluto[25157]: "my-tunnel" #6: IPsec SA established
In addition to this you can view the “eroute” output to make sure the tunnels are correctly configured:
10.0.0.0/24 -> 192.168.0.0/24 => tun0x114@1.2.3.4
And if you view your routes (“route”) you should see:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
1.2.3.4 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth
11.2.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
1.2.3.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
192.168.0.0 1.2.3.1 255.255.255.0 UG 0 0 0 ipsec0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0
eth1127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0
lo0.0.0.0 1.2.3.1 0.0.0.0 UG 0 0 0 eth0
Some example ipsec configurations
Two servers with protected networks directly attached
In our example we will have the following network setup:
Server A, where eth0 is attached to the Internet and has the IP address 1.2.3.4, and eth1 is attached to the internal network and has the IP address 10.0.0.1.
Network A is the network ‘behind’ Server A and consists of machines on the 10.0.0.* subnet.
Server B, where eth0 is attached to the Internet and has the IP address 5.6.7.8, and eth1 is attached to the internal network and has the IP address 192.168.0.1.
Network B is the network ‘behind’ Server B and consists of machines on the 192.168.0.* subnet.
Network C is the Internet, to which Server A and B are connected (by T1, let’s be generous).
Basic server setup
Each machine will have Red Hat Linux 6.1 installed, with the default kernel 2.2.12, make sure you install ipchains, by default this does not usually get installed. Any other software on the machines is incidental (we are primarily concerned about moving packets and such).
Go to ftp.linux.org (or your favourite mirror) and download the full Linux kernel 2.2.10. Go to /usr/src/ and remove the existing linux symlink, unpack kernel 2.2.10 and mv it to /usr/src/linux-2.2.10, and recreate the "linux" symlink to point to it. Then cd into /usr/src/linux, configure the kernel, compile and install it. Make sure you choose all the IP masquerading items, and where possible compile them in as static components, and not modules. Remember to use "make bzImage", as chances are the new kernel will be to large for lilo to load normally.
| cd /usr/src/ rm linux tar –zvvxf /path/to/tarball/linux-2.2.10.tar.gz mv linux linux-2.2.10 chown –R root:root linux-2.2.10 ln –s linux-2.2.10 linux cd linux make menuconfig make dep make bzImage make modules make modules_install cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.2.10 rm /boot/System.* cp /usr/src/linux/System.map /boot/System.map |
Now we need to edit lilo.conf, rerun lilo, and reboot to make use of the new kernel. Like the IPSec documentation stresses, make sure your network works first before even attempting to install the software.
Lilo.conf should look like:
| boot=/dev/hda map=/boot/map install=/boot/boot.b prompt timeout=100 image=/boot/vmlinuz-2.2.10 label=linux root=/dev/hda1 read-only image=/boot/vmlinuz-2.2.5-12 label=linuxold root=/dev/hda1 read-only |
rerun lilo and you should see:
| linux * linuxold |
then reboot and you should be running kernel 2.2.10.
Now we need to edit the firewall rules, on both servers you should be masquerading the internal machines and using a default policy of denying forwarding for security with something like:
Server A:
| ipchains -P forward DENY ipchains -A forward -p all -j MASQ -s 10.0.0.0/24 -d 0.0.0.0/0 |
Server B:
| ipchains -P forward DENY ipchains -A forward -p all -j MASQ -s 192.168.0.0/24 -d 0.0.0.0/0 |
Remember to put these rules last in your firewalling script. You will also need to enable packet forwarding, edit the /etc/sysconfig/network and replace the line:
| FORWARD_IPV4="no" |
with the line:
| FORWARD_IPV4="yes" |
You should now be able to ping Server B from Network A (ping 5.6.7.8), and you should also be able to ping Server A from Network B (ping 1.2.3.4).
Assuming all this works we can now attempt to install the IP Security software.
IPSec installation
Download the latest IPSec snapshot (version 1.0 will NOT work with 2.2.x kernels). Then go to /usr/local/src (or wherever), unpack the source and run the install program (make menugo typically for the ncurses based configuration). This will patch the kernel files, then run the kernel configuration, and then build the IPSec tools, and the kernel.
| cd /usr/local/src/ tar –zvvxf /path/to/tarball/snapshot.tar.gz chown –R root:root freeswan-snap1999Jun14b cd freeswan-snap1999Jun14b make menugo |
make sure you save the kernel configuration, even though the options are chosen they have not been saved. You will also have to rebuild the kernel as the "make menugo" command runs a "make zImage" which usually fails due to the large kernel sizes with 2.2.x. Once the compile is done it should have an error message or two, simply:
| cd /usr/src/linux make bzImage cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.2.10-ipsec |
Now we need to edit lilo.conf, rerun lilo, and reboot to make use of the new kernel.
Lilo.conf should look like:
| boot=/dev/hda map=/boot/map install=/boot/boot.b prompt timeout=100 image=/boot/vmlinuz-2.2.10-ipsec label=linux-ipsec root=/dev/hda1 read-only image=/boot/vmlinuz-2.2.10 label=linux root=/dev/hda1 read-only |
rerun lilo and you should see:
| linux-ipsec * linux |
then reboot and you should be running kernel 2.2.10 with IPSec support. As the machine reboots and starts the IPSec stuff you will see several errors, by default IPSec is set to use the eth999 interface, which of course does not exist. You should also add /usr/local/lib/ipsec to your path statement or else you will have to type the full path in a lot.
Configuring IPSec
We will initially use manual keying (i.e. for now we will ignore the pluto IKE daemon) as this makes life simpler. You will need to edit ipsec.conf and ipsec.conf. These two files will then need to be copied to the other server in a secure manner (ssh, floppy disk, etc.).
Here is a diagram of the network:
You will need to edit the ipsec.conf file, most of the defaults are fine but you will need to change the following:
| conn sample type=tunnel # left security gateway (public-network address) left= # next hop to reach right leftnexthop= # subnet behind left (omit if there is no subnet) leftsubnet= # right s.g., subnet behind it, and next hop to reach left right= rightnexthop= rightsubnet= # spibase=0x200 # (manual) encryption/authentication algorithm and parameters to it esp=3des-md5-96 espenckey= espauthkey= |
replace the espenckey and espauthkey with new keys (using ranbits to generate a number, remmeber to leave the leading 0x that specifies it is a hex number) so that it looks like:
| conn my-tunnel type=tunnel # left security gateway (public-network address) left=1.2.3.4 # next hop to reach right leftnexthop=1.2.3.1 # subnet behind left (omit if there is no subnet) leftsubnet=10.0.0.0/24 # right s.g., subnet behind it, and next hop to reach left right=5.6.7.8 rightnexthop=5.6.7.1 rightsubnet=192.168.0.0/24 # spibase=0x200 # (manual) encryption/authentication algorithm and parameters to it esp=3des-md5-96 espenckey=some_auth_key_here (ranbits 192) espauthkey=some_other_key_here (ranbits 128) |
Once you have done this copy the files ipsec.conf and ipsec.secrets from the machine you edited them on to the other server in a secure manner. Now all that remains to be done is the addition of some firewall rules so that packets do not get masqueraded (instead we simply want them forwarded).
On Server A you should add the following rules:
| ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24 ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24 |
make sure these rules appear before the masquerading rule, it should look like this:
| # # FORWARD RULES # ipchains -P forward DENY # ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24 ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24 ipchains -A forward -p all -j MASQ -s 10.0.0.0/24 -d 0.0.0.0/0 |
And on server B you basically repeat the process:
| ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24 ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24 |
make sure these rules appear before the masquerading rule, it should look like this:
| # # FORWARD RULES # ipchains -P forward DENY # ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 10.0.0.0/24 ipchains -A forward -p all -j ACCEPT -s 10.0.0.0/24 -d 192.168.0.0/24 ipchains -A forward -p all -j MASQ -s 192.168.0.0/24 -d 0.0.0.0/0 |
Starting up your connection
Now you should be able to bring up the ipsec tunnel on both machines manually and the machines on Network A should be able to talk to the machines on Network B with no problems.
| ipsec manual –up my-tunnel |
and it should produce output similar to:
| /usr/local/lib/ipsec/spi: message size is 36 /usr/local/lib/ipsec/spi: message size is 132 /usr/local/lib/ipsec/spi: message size is 132 |
To test it try pinging 192.168.0.2 from the 10.0.0.2 client (you cannot ping from 192.168.0.1 to 10.0.0.1 or the external gateway addresses since you have not configured tunnels to handle those packets). If this works then you have set it up correctly.
Two servers with protected networks attached via the Internet (or some other network)
In this example I will strictly cover the configuration and not the isntall as in the last one.
Here is a diagram of the network:
Commercial IPSec products
I thought it would also be appropriate to list commercial IPSec products briefly, with an emphasis of course on those based on Linux and FreeS/WAN.
i-data
i-data makes a line of products including a VPN server, based on Linux and FreeS/WAN. They are located in Denmark, making their product available world-wide. Their website is at:http://www.i-data.com/networks/.
Windows IPSec client products
There are also a number of software packages to give Windows IPSec capability, one of which is even free.
PGP VPN
The makers of PGP (Network Associates) have now created a “PGP VPN” software package (which has very little to do with PGP). It supports IPSec and has been reported as inter-operable with Linux FreeS/WAN. You can get it from: http://www.nai.com/asp_set/products/tns/pgp_vpn.asp. The free version of PGP from NAI also supports IPSec VPN's and is available from: http://www.pgpi.com/.
IRE
Virtual private networks
Encrypting network services
Virtually all network traffic is unencrypted and easily read by an attacker. If someone cracks a machine on your internet and installs a password sniffer (basically your common packet sniffer with a filter) your entire network can be compromised in a matter of hours. One ISP that shall remain nameless placed co-hosted customer machines on the same LAN, using a normal ethernet hub, meaning all machines could see each others traffic (users retrieving email via pop, telnet sessions, etc). This is one of the major reasons why encrypting data traffic is a good idea.
Various mechanisms exist and/or are being developed to encrypt network data traffic, at various levels of the network stack. Some schemes only encrypt the data sent (such as GnuPG encrypted email), some encrypt the session (SSL), and some encrypt the data payload of the packets (IPSec and other VPN's). Ultimately the best solution will be IPSec (my opinion), as it requires no modifications to the applications, and provides for a very high level of security between computers. Currently there are no widely-used data encryption solutions, in part because Microsoft does not support many, which is a serious hindrance to any mass solution. To be fair Microsoft does have beta IPSec support, but it is not ready yet, and it will be restricted to the North American market because of US law. The best scheme currently available is SSL, Secure Sockets Layer, originally proposed by Netscape. SSL encrypts the data at the session level, thus if your application supports SSL and the server supports SSL you are in luck. Most www browsers, some email/news readers, and a few ftp and telnet clients support SSL currently. For Linux servers most services can be SSL'ified. SSL does however require clients with SSL capabilities, something you won't be able to get most people to support. This means that SSL'ified services are typically restricted to within an organization. The SSL libraries are available at http://www.openssl.org/. For "drilling" through a firewall or perhaps to get by a NAT box (such as Linux with IP Masquerading) please see the firewall section.
Virtual private network solutions
There are a variety of VPN solutions for Linux. I would stronly advise using IPSec if possible since it is the emerging standard for VPN's on the Internet, and will be incorporated with IPv6. On the other hand if you are behind a firewall and want to tunnel out the SSH based solution and so on will do the trick, whereas IPSec will typically fail (since the packet headers are being rewritten).
IPSec
IPSec is covered in it’s own section. I think it is the future of VPN technology (it’s the most commonly supported standard as of today, and an integral part of IPv6).
PPTP (Point to Point Tunneling Protocol)
PPTP is a proprietary protocol created by Microsoft for VPN solutions. To date it has been shown to contain numerous serious flaws. However if you need to integrate Linux into a PPTP environment all is not lost,http://www.moretonbay.com/vpn/pptp.html contains a Linux implementation of PPTP.
CIPE (Crypto IP Encapsulation)
CIPE is a free IP level encryption scheme, meant for use between routers. It is appropriate for 'bridging' networks securely together over insecure networks (like the Internet). The official cite for CIPE is at:http://sites.inka.de/~W1011/devel/cipe.html. I would however recommend FreeS/WAN as a better long term solution.
ECLiPt Secure Tunnel (currently in beta)
Another GNU licensed solution for Linux VPN's. Currently in beta (and not recommended for mass use) but I thought I should mention it anyways since it seems to be a serious effort. The official page is at: http://eclipt.uni-klu.ac.at/projects/est/. Again I would have to recommend FreeS/WAN as a better long term solution.
Stunnel
Stunnel is an SSL based solution for securing network services. It has a server portion that runs on the UNIX server, and a client portion that runs on UNIX or Windows.http://mike.daewoo.com.pl/computer/stunnel/
Virtual Private Server
Virtual Private Server (VPS) uses Perl and SSH to create VPN's. You can get it from: http://www.strongcrypto.com/.
Virtual Tunnel
Virtual Tunnel (VTUN) supports a variety of methods of establishing a link, and several algorithms. You can get it from: http://vtun.netpedia.net/.
Zebedee
Zebedee provides encryption of TCP traffic between hosts and is available for UNIX and windows. You can get it from: http://www.winton.org.uk/zebedee/.
Virtual Private Server
Virtual Private Server is a VPN solution that uses PPP and SSH (basically it provides a nicer interface to it). You can get it from: http://www.strongcrypto.com/.
Administrative tools
Overview
There are a variety of tools to make administration of systems easier, from local tools like sudo which grant limited superuser privileges, to Webmin and Linuxconf which are www based systems. For information on how to login remotely (i.e. via telnet or ssh) please see the shell server section.
Local tools
YaST
YaST (Yet Another Setup Tool) is a rather nice command line graphical interface (very similar to scoadmin) that provides an easy interface to most administrative tasks. It does not however have any provisions for giving users limited access, so it is really only useful for cutting down on errors, and allowing new users to administer their systems. Another problem is unlike Linuxconf it is not network aware, meaning you must log into each system you want to manipulate.
sudo
Sudo gives a user setuid access to a program(s), and you can specify which host(s) they are allowed to login from (or not) and have sudo access (thus if someone breaks into an account, but you have it locked down damage is minimized). You can specify what user a command will run as, giving you a relatively fine degree of control. If you must grant users access, be sure to specify the hosts they are allowed to log in from when using sudo, as well give the full pathnames to binaries, it can save you significant grief in the long run (i.e. if I give a user sudo access to "adduser", there is nothing to stop them editing their path statement, and copying bash to /tmp/adduser and grabbing control of the box.). This tool is very similar to super but with slightly less fine grained control. Sudo is available for most distributions as a core package or a contributed package. Sudo is available at:http://www.courtesan.com/sudo/ just in case your distribution doesn’t ship with it Sudo allows you to define groups of hosts, groups of commands, and groups of users, making long term administration simpler. Several /etc/sudoers examples:
#Give the user ‘seifried’ full access
seifried ALL=(ALL) ALL
#Create a group of users, a group of hosts, and allow then to shutdown the server as root
Host_Alias WORKSTATIONS=localhost, station1, station2
User_Alias SHUTDOWNUSERS=bob, mary, jane
Cmnd_Alias REBOOT=halt, reboot, sync
Runas_Alias REBOOTUSER=admin
SHUTDOWNUSERS WORKSTATIONS=(REBOOTUSER) REBOOT
Super
Super is one of the very few tools that can actually be used to give certain users (and groups) varied levels of access to system administration. In addition to this you can specify times and allow access to scripts, giving setuid access to even ordinary commands could have unexpected consequences (any editor, any file manipulation tools like chown, chmod, even tools like lp could compromise parts of the system). Debian ships with super, and there are rpm's available in the contrib directory. This is a very powerful tool (it puts sudo to shame in some ways), but requires a significant amount of effort to implement properly (like any powerful tool), and I think it is worth the effort. Some example config files are usually in the /usr/doc/super-xxxx/ directory. The primary distribution site for super is at: ftp://ftp.ucolick.org/pub/users/will/.
runas
runas is very similar to sudo and Super with some variations. You create a config file listing the command, what it runs as, and which users/groups/etc. are allowed to run it as such. In addition to this however you can restrict the use of options (arguments), and you can prompt the user for a reason (which is logged to syslog). This is one of my favorite features, as with a little training, you can have your admin staff documenting what they do in a relatively painless fashion (i.e.: “wanted to reboot server because of memory leak”). You can download runas from: http://www.mindspring.com/~carpinello/runas/index.html.
WWW based tools
Webmin
Webmin is one of the better remote administration tools for Linux, written primarily in Perl it is easy to use and easy to setup. You can assign different 'users' (usernames and passwords are held internally by webmin) varying levels of access, for example you could assign bob access to shutdown the server only, and give john access to create/delete and manipulate users only. In addition to this it works on most Linux platforms and a variety of other UNIX platforms. The main 'problem' with webmin is somewhat poor documentation in some areas of usage, and the fact that the username/password pair are sent in clear text over the network (this is minimized slightly by the ability to grant access to only certain hosts(s) and networks). Most importantly it makes the system more accessible to non-technical people who must administer systems in such a way that you do not have to grant them actual accounts on the server. Webmin is available at: http://www.webmin.com/webmin/, and is currently free. Webmin defaults to running on port 10000 and should be firewalled:
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 10000
ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 10000
ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 10000
ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 10000
ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 10000
or in ipchains:
ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 10000
ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 10000
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 10000
ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 10000
ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 10000
Linuxconf
Linuxconf is a general purpose Linux administration tool that is usable from the command line, from within X, or via it's built in www server. It is my preferred tool for automated system administration (I primarily use it for doing strange network configurations), as it is relatively light from the command line (it is actually split up into several modules). From within X it provides an overall view of everything that can be configured (PPP, users, disks, etc.). To use it via a www browser you must first run Linuxconf on the machine and add the host(s) or network(s) you want to allow to connect (Conf > Misc > Linuxconf network access), save changes and quit. Then when you connect to the machine (by default Linuxconf runs on port 98) you must enter a username and password. By default Linuxconf only accepts root as the account, and Linuxconf doesn't support any encryption (it runs standalone on port 901), so I would have to recommend very strongly against using this feature across networks unless you have IPSec or some other form of IP level security. Linuxconf ships with Red Hat Linux and is available at:http://www.solucorp.qc.ca/linuxconf/. Linuxconf also doesn't seem to ship with any man pages/etc, the help is contained internally which is slightly irritating.
COAS
The COAS project (Caldera Open Administration System) is a very ambitious project to provide an open framework for administering systems, from a command line (with semi graphical interface), from within X (using the qt widget set) to the web. It abstracts the actual configuration data by providing a middle layer, thus making it suitable for use on disparate Linux platforms. Version 1.0 was just released, so it looks like Caldera is finally pushing ahead with it. The COAS site is at: http://www.coas.org/.
WebRAT
WebRAT is a web based administration tool for networks. You can get it at: http://hq.hellug.gr/~webrat/.
Other network based tools
Pikt
Pikt is an extremely interesting tool, it is actually more of a scripting language aimed at system administration then a simple program. Pikt allows you to do things such as killing off idle user processes, enforcing mail quotas, monitor the system for suspicious usage patterns (off hours, etc), and much more. About the only problem with Pikt will be a steep learning tools, as it uses it’s own scripting language, but ultimately I think mastering this language will pay off if you have many systems to administer (especially since Pikt runs on Solaris, Linux and FreeBSD currently). Pikt is available at: http://pikt.uchicago.edu/pikt/.
VNC
Virtual Network Computer (VNC) is similar to X or PCAnywhere. You can display a graphical desktop, and control it remotely, with NT or Linux as the server and/or client. VNC across 10 megabit Ethernet is quite good, however it does tend to use a lot of computer power relative to other methods of remote administration. You can get VNC from: https://www.comparitech.com/vpn/what-is-a-vnc-and-how-does-it-differ-from-a-vpn/. Security VNC isn't so great, but there are several sites with information on securing VNC, using SSL, SSH and other methods. MindVNC is a java client that uses SSH, available from: http://www.mindbright.com/english/technology/products/mindvnc.html. There is a patch available to add encryption to VNC here at: http://web.mit.edu/thouis/vnc/. There is also a page on securing VNC with SSH port forwarding at: http://www.zip.com.au/~cs/answers/vnc-thru-firewall-via-ssh.txt.
cfengine
cfengine is a set of tools for automating administration tasks and is network aware. You can get cfegine from: http://www.iu.hioslo.no/cfengine/.
Storm Administration System (SAS)
SAS is currently specific to Stormix (a new Linux distribution), you can get it from: http://www.stormix.com/products/sas/index_html.
MAT
The Monitoring and Administration Tool provides a rather nice GUI for remotely administering machines and checking their status. You can get it from: http://www.ee.ryerson.ca:8080/~sblack/mat/.
Limiting and monitoring users
Limiting users
There are many bad things users can do to a system if they have an interactive shell account. There are also many ways to prevent these things from happening. User quota’s on disk usage, CPU usage, etc. are a good start, more advanced techniques such as monitoring users for large environments also help. One of the simplest things a user can do is use up all the memory by launching many copies of a memory hungry program, or use up all the file descriptors with a “fork bomb”.
PAM
Most modern Linux’s ship with PAM support, one of the things PAM provides is environmental settings. Settings such as limiting the amount of memory a user is allowed to use. In Red Hat and Caldera this is configurable from the /etc/security/ directory which contains a number of files. The most interesting file is: /etc/security/limits.conf, which allows you to define rules for users or groups, whether the rule is “soft” or “hard” (more on this later), and what the rule applies to, which can be CPU, memory, maximum filesize, and so on. For example:
* hard core 0
bob soft nproc 100
bob hard nproc 150
This first rule disabled core dumps for everyone, the second rule sets a soft limit on bob to 100 processes, and the third rule sets a hard limit for bob to 150 processes. A soft limit can be exceeded, and is usually a warning mark, the hard limit cannot be exceeded. As you can imagine this is quite useful since it applies to all login shells, and other services such as ftp.
Bash
Bash has a built in limiter, accessed via “ulimit”. Any hard limits cannot be set higher, so if you have limits defined in /etc/profile, or in the users .bash_profile (assuming they cannot edit/delete those files) you can enforce limits on users with Bash shells. This is useful for older Linux distributions that lack PAM support. You must also ensure that the user cannot change their login shell. Settings the limits is similar to PAM’s method, you define various such as:
ulimit –Sc 0
ulimit –Su 100
ulimit –Hu 150
These three rules would achieve the same result as the ones in the PAM example. The first rule disables core dumps, the second rule sets a soft limit of 100 processes, and the third rule sets a hard limit of 150 processes. More help on ulimit is available by typing “help ulimit” at the bash prompt.
Quota
Quota is a system for restricting disk usage by users. It is built into most distributions and help is available from the man page “man quota”.
Monitoring users
One issue common to shell servers is making sure users do not abuse the server. This is rather easy to monitor for standard resources (such as disk usage, CPU usage, and so forth) but one of the most frequently abused items is bandwidth, luckily there are a variety of ways to monitor this abuse.
ttysnoop
Of course this is all well and good if nothing goes wrong. But what if you actually want to monitor what a user is doing (be warned, there are legal implications that can get you in trouble, ask your lawyers first). This is where a tool such as ttysnoop comes in. ttysnoop allows you to monitor what a user is doing, and record it. You can get ttysnoop from: http://uscan.cjb.net/.
UserIPAcct
UserIPAcct allows you to monitor the bandwidth usage by user, it involves patching the kernel, and setting up rules (similar in concept to firewalling) to monitor the amount of data a user’s programs send or receive. You cannot account for data on PPP connections however since the PPP daemon does not run as the user logging in (although you could hack it to do this). I would recommend this highly for shell servers in order to monitor users (generally speaking a minor percentage of users will make up the bulk of usage). You can download the complete package from: http://zaheer.grid9.net/useripacct/.
Security techniques
Chrooting
Log files and other forms of monitoring
Overview
One integral part of any UNIX system are the logging facilities. The majority of logging in Linux is provided by two main programs, sysklogd and klogd, the first providing logging services to programs and applications, the second providing logging capability to the Linux kernel. Klogd actually sends most messages to the syslogd facility but will on occasion pop up messages at the console (i.e. kernel panics). Sysklogd actually handles the task of processing most messages and sending them to the appropriate file or device, this is configured from within /etc/syslog.conf. By default most logging to files takes place in /var/log/, and generally speaking programs that handle their own logging (most httpd servers handle their logging internally) log to /var/log/program-name/, which allows you to centralize the log files and makes it easier to place them on a separate partition (some attacks can fill your logs quite quickly, and a full / partition is no fun). Additionally there are programs that handle their own interval logging, one of the more interesting being the bash command shell. By default bash
