Untitled Document

Setting Up A Secure Server/Firewall
Checking The Installation

We have now set up all the items we wished to have running. However, the world being what it is there will almost certainly have been a problem at some point so let's just check what we've done. One thing is most important. One part is dependant on the previous parts. If you haven't got a working network card DON'T waste time trying to configure routing to the local area network.

Shut down and reboot the machine with 'shutdown -r now'. The machine shuts down and reboots but this time you should notice that the modem dials up a connection during reboot.

If your network, routing and DNS have been set up correctly you should be able to type:-

route

and get a short report after a slight delay which contains at least the 2 physical interfaces eth0 and ppp0 on the right hand side. Any problems - have a look at the excellent SuSE manual to see how to correctly set-up routing. It is done in the /etc/route.conf file which should have been edited correctly by the changes we made in yast but check it in joe anyway.

You should also be able to type in

nslookup www.bbc.co.uk

and get the IP addresses of the BBC's web servers.

If that all works OK we are well on the way to getting our server running. Go to one of the network nodes and make sure it is set up to run the TCP/IP protocol. See the 'Network Binding' section in 'Securing your stand alone or network node machine' and that it is set up for DHCP allocation of information in the TCP/IP properties section for the network interface. Reboot the network node and start a DOS prompt. Type in

ping 192.168.1.1

and you should see something like

PING 192.168.1.1 (192.168.1.1): 56 data bytes

64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.478 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.384 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.682 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=255 time=0.879 ms

or something similar. Also run WINIPCFG and it should show something like this:-

Yours may be slightly different but the DNS server, the primary wins Server, the DHCP server and the default gateway should all be set to 192.168.1.1 as that is the IP address of the network card on the server that is offering these services. If you can't ping the server the local area network connection isn't working. If you can ping the server but you don't receive an IP address and network info as in the example winipcfg output above then there is something wrong with your DHCP set up.

We also have to set the node up to use the server as the proxy for web browsing, i.e. Internet Explorer. Right click the Internet explorer icon and select 'Properties'. Select the 'Connection' tab and set the proxy server to be 192.168.1.1 like this:-

As you can see this also tells the browser that we are connecting using our local area network, which is correct. The server is using the modem - not us. If we start getting problems connecting to web sites after making these changes check your settings in the /etc/squid.conf file on the server.

We also need to set the email software, Outlook Express, so that it uses the server. Start up Outlook Express and select 'Tools - Accounts' and select the account you want to edit the connection for. Then select 'Properties - Servers' and edit the values so all incoming and outgoing mail uses the server like this:-

Note that the password is the same one you set up in yast for the user specified. You might also have to change your connection to 'Use your local area network' on the 'Connection' tab if the node was used for a modem dial-up account previously.

Assuming you have been set up on the server as a user and the 'Configure sendmail' has been run as described on the server you should now be able to send/receive email via the server.

If there are any problems it is a good idea to check the server by monitoring the /var/log/messages file which receives a range of data including connection information by running tail -f /var/log/messages. This will produce output like this:-

Dec 12 12:30:49 mcrserver dhcpd: DHCPREQUEST for 192.168.1.22 from 00:48:54:5b:03:9f via eth1

Dec 12 12:30:49 mcrserver dhcpd: DHCPACK on 192.168.1.22 to 00:48:54:5b:03:9f via eth1

Dec 12 12:32:49 mcrserver kernel: Packet log: input ACCEPT ppp0 PROTO=6 194.217.242.7:42629 xxx.xxx.xxx.xxx:25 L=44 S=0x00 I=27241 F=0x4000 T=251 SYN (#27)

The format of the file can be a little cryptic. The beginning of the line is obviously the date and time followed by the name of the server and the name of the program that has created the entry. This is usually followed by some description of what the connection has done. The first couple of lines here indicate that one of the computers on our network has requested an IP address from the DHCP server daemon, dhcpd. The third line indicates that some packets of data have been sent from the IP address 194.217.242.7 on port 42629 to our address xxx.xxx.xxx.xxx on port 25. As we have DHCP running for IP address allocation, (among other things), and smtp/pop3 for our mail server these entries are alright.

It is not practical for me to cover every type of connection you might ever see here. Of course, you should be expecting connections on the eth0 port, (the network card for the local area network), for those services offered. If you see any entries with the word DENY in examine them carefully and see what IP address/port they're coming from and which IP address/port they're connecting to.

It is a good idea to go through the list of users in 'Yast - System Administration - and either remove them altogether in the case of accounts like 'informix', (unless you're going to run the Informix database system, of course), or at the very least change the login shell from /bin/bash rather than /bin/false, except the root user, of course, who will need to login. The latter means that the user selected can't log in at the terminal - it doesn't alter the ability of the system to service email, samba, squid, etc. requests. BE VERY CAREFUL WHEN REMOVING USERS - There are certain system users such as bin and daemon which are required by the system. If in doubt just set the login to /bin/false - this is not as secure but at least your system will still work :-). To repeat myself - DON'T ALTER THE ROOT USERS ACCOUNT LOGIN TO /BIN/FALSE.

The other area we will briefly cover is Intrusion Detection Systems (IDS).

SuSE has it's own detection system called Seccheck, based on a standard Unix one, which creates a checksum signature for the important files in the filesystem which can be compared every so often to see if they have changed. It also does various other checks including ease of password cracking and whether files are world writable, (i.e. if their permissions are set to -rw-rw-rw or similiar), and whether people have accounts and have never logged in. When it is installed the default is to compare them every day, a more substantial check every week and a very substantial system check every month. It sends it's reports to the user given in the environment variable 'SECCHECK_USER =' which, by default, is set to root.. The full details of the reports it runs can be found in the directory /usr/share/doc/packages/seccheck/README which be read in the joe editor or at http://www.suse.de/~marc/README.seccheck

A similar tool is the AIDE package which can be added from the SuSE installation disks. This creates a signature file which can be copied onto a floppy disk so that a copy of it can be removed from the server and kept. This can then be compared to the signature file on the server every so often to see if any files have been changed. The configuration file is located in the /etc directory and the default is to check files that don't alter regularly such as those in the /tmp directory. To state the obvious, if you change the /etc/passwd file by adding a user after you take a 'snapshot' of the important files with the aide program, there will be an inconsistency between new and old /etc/passwd files.

It is probably also a good idea to edit the /etc/aliases file using joe to add a line similar to line 11 like this:-

root: \root, dave

where dave is replaced by one of your user names. That way, any system mail sent to root will also be sent to the user dave. You will need to run the 'newaliases' command after saving and editing this file to register the new alias given.

KEEPING UP TO DATE

After the server is running and configured the first thing you should do is to update any programmes that need it. This is because security holes and other bugs are found in all computer programmes that have a continuous development programme. One of the ways that Linux is more secure than other operating systems is precisely because it isn't a fully commercial product. By commercial I don't mean it can't be used to help run a business I mean that the people who do work on it are not simply doing it to make money so they are more likely to tell their end-users if their is a problem with their product. In fully commercial software the update process is done once every few months so, by definition, there must be a period when the software vendor knows about a particular problem and doesn't tell his customers - Well, unless the bugs all appear on the day the Service Packs are sent out.

Anyway, I do updates in Yast by selecting 'Package Management - Install Packages. If you then press ENTER on the source box and selecting FTP with enter. You then select the default location which should be set correctly by default and press ENTER again.

This will bring up a list, (after a short period), of the package areas to select from. It is roughly equivalent to the package selection listing during installation.

The entries with a single 'o' for old are the ones that need updating. You select them for update by highlighting them using the cursor keys and pressing the space bar. Then it's simply a matter of pressing F10 to install the update. However, be careful when updating the kernel because it is the major part of the operating system and, if there are some inconsistencies between versions, your machine may not restart. The version of SuSE I am installing here is a few months old now so most of the packages will have updates available.

You should also subscribe to the SuSE mailing list service, particularly the Security updates list which will send you an email describing any updates available. It will also give you detailed instructions for the trickier update problems such as how to update your kernel packages, etc.

THAT'S ALL FOLKS!

We will be adding to this documentation from time to time - put your email address on the opening page if you want to be advised of changes as and when they occur. If anyone wants any more help we can be contacted at the 'Contact Details' link on the left. However we do charge for technical support.

There are many other aspects of server security which I haven't even scratched the surface of here. Pluggable authentication modules are a very powerful security tool - Secure shells - Tripwire... - there's almost too many subjects to choose from. That's been part of the problem when creating this documentation - I don't want to scare people off.

It is also worth mentioning the many sites that specialise in advice for system administration such as www.cert.org and www.securityfocus.com which are definitely worth your while taking a look at plus there are various security information sites for end-user worth examining.

Have fun!

Andrew Bennett

Step By Step Installation Guide < Previous - Next > Opening Page