Security on dialup systems is really not all that difficult. A lot of people seem to think it is, and thus many do not do the little bit it takes to make their system more secure. Those of you that worry that it will take too much work to secure your system should stop worrying and start doing. It really doesn't take that long, and you'll end up with a system that is significantly more secure than what was shipped to you out of the box.
Now that we've established that you should not be afraid of system security, what do you actually do about it? Here's a few really simple tricks that will make your single user system much more secure (note that there is another section for those of you who wish to run network services on your host). What I'm assuming here is that you simple want your system to be as secure as possible while you are connected to the bad ole 'Net. Some of you may notice that I won't be addressing physical security in this section. This is because I feel that if you have physical security issues with your computer that is sitting at home on or under your desk then you have much bigger problems.
First, let's look a little closer at network services.
As a single user system, you really don't need to be providing resources to
anyone else, so why not just disable all network services? For instance, do
you really need to telnet into the system that you're already logged into?
FTP? Do you need to act as a mailserver? These are the first questions you
need to ask yourself. If you use Netscape Navigator/Communicator to read
your e-mail, you probably don't need sendmail running locally (let the mail
server at your ISP deliver all your mail). So, ask yourself, what do you
really need running?
Okay, so now you've put some thought into what services your system really needs to provide and you just couldn't come up with a single one (note: the only service I run on my home systems is ssh, except for my mail server which runs ssh and the postfix mail server), so it's time to disable the services. Well, now you need to know a little bit more about how services are provided on Linux boxes. First, take a look at this sample (acutally, an excerpt from one of my systems) /etc/inetd.conf:
#ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
#telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
#shell stream tcp nowait root /usr/sbin/tcpd in.rshd
#login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
#comsat dgram udp wait root /usr/sbin/tcpd in.comsat
#talk dgram udp wait root /usr/sbin/tcpd in.talkd
#ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
#dtalk stream tcp waut nobody /usr/sbin/tcpd in.dtalkd
#pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
#imap stream tcp nowait root /usr/sbin/tcpd imapd
#finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
#cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd
#systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx
#netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat
-f inet
#auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l
-e -o
#linuxconf stream tcp wait root /bin/linuxconf linuxconf --http
First, note that #'s are comments. As you can see, I've commented out all the commands in my /etc/inetd.conf file. Normally, I have inetd set to not run at boot, but in case I spaz and restart inetd, I will not be leaving myself running services that I thought I had disabled. Also, this is not my entire /etc/inetd.conf (I didn't see a need to add any more useless fluff), merely the more important ones to disable. Also, note the fifth column. That's where inetd is told what account that the service will be run as, paying attention to all the scary 'root' instances. The sixth column tells inetd to launch tcp_wrappers. Tcp_wrappers is a way of protecting who has access to a set of services. More on this later.
Okay, first we have ftpd, which runs as root. Most Linux based systems ship with wu-ftpd or ProFTPD. wu-ftpd has a checkered past, having been remotely exploited through several different holes, one rather recently. ProFTPD was also the victim of a remote exploit (I only know of one, there could have been others). Now, go back to the fact that ftpd runs as root. What this means, is that if an intruder can do something bad to your ftp server, he will be greeted with a root shell on your host. This is not good, and this is one reason you should disable services you don't use -- one less thing to worry about. I should mention that all of the most recent holes were patched resonably quickly in both of those ftp servers, however sites contiue to be vulnerable to those holes do to the fact that administrators have not kept up with updates. However, I've yet to hear of a break-in through a service that did not exist on a system, so if you aren't running wu-ftpd or ProFTPD, you don't have to worry about a remote compromise using either of those services. Comment it out.
Next is the telnet server. It also runs as root and is also somewhat protected by tcp_wrappers. The telnet server makes it so people can remotely access your system. Again, if this is a single user system, there's no reason why anyone should be accessing your system. Comment it out.
Next are three services collectively shunned as the r-services: rshd, rlogind, and rexecd. These services are a throw-back to a different era of the Internet where everybody knew everybody else and security was much less of a concern. Their authentication schemes are quite weak, and they are often used along with another exploit to gain remote access to your system. Even though they are somewhat protected by tcp_wrappers, there is no good reason to have these enabled on a single user system. Comment them out.Comsat used to be used to notify a user that new mail has arrived for them. It does not have much place in the net today as most users' mail clients perform this function. Note that it also runs as root. Again, don't use it -- you don't need it. If it's not already commented out, do so.
The talk services were once used to facilitate live communications between users. This capability has been replaced by other client based services such as ICQ that don't require a server running on your system. Unless you really have a need to run a talk server on your system, don't. There have been security holes in them in the past, so don't run them if you don't need them. Comment them out.
Nobody uses pop-2 anymore, so that should be commented out by default. Don't enable it, there's no reason. The versions of ipop3d and imapd that have shipped in most of the Linux distributions have a worse history than wu-ftpd as far as security holes go. In all honesty, there have probably been more holes in wu-ftpd, but most of those had been patched when Linux got really big. The holes in ipop3d and imapd have been used to gain remote root access on countless numbers of unsuspecting Linux users everywhere. I'm 100% sure that these services are still being used to break into systems. Again, these services have been patched and all of the major Linux distributions have posted fixes. However, as a single user system, you still have no reason to be providing a POP or IMAP server to anyone. Comment them out.
The finger services (finger and cfinger) are used for getting information about users remotely. You probably don't want to be giving out any of this information to people you don't know. Also, note that fingerd (cfingerd, according to the comments in /etc/inetd.conf is for GNU finger, which Red Hat doesn't use -- I'm not sure about other Linux distributions) runs as root. To the best of my recolection, there have also been several holes in fingerd that have allowed remote root access. Honestly, there's no real reason to be running fingerd (note that fingering a local user works just fine without fingerd). Comment them out.
The next two services also provide information about your host. systat will provide a dump of your ps list and netstat will not only show what services you are running, but which port they are bound to, and worse, it will show all current connections, both to that system and from that system. This one should be commented out be default in all Linux distributions (I said should, I only know for sure about Red Hat). Really, they should be removed from inetd.conf completely. You don't need these. Comment them out.
The auth service provided by identd is probably the only debatable item in /etc/inetd.conf. It's used to allow remote servers to connect to your system and ask 'Which user conected to my port X?' Really, I don't see a huge reason to have this running and disable it. Note that it runs as user 'nobody' in my case, but be careful, your Linux distribution of choice may run it as root. I'm not sure of any reported remote root compromises using identd, but there's no real reason to run it as root. I've heard rumors that there are some IRC servers that will not let you connect if you are not running identd. There's enough IRC servers out there that my response is to use another one. I'm not an IRC user, so I don't know if this is true. Really, identd is not needed. Comment it out.
The last really important line in my example /etc/inetd.conf is for the linuxconf web interface. I know that not every distribution ships with linuxconf, but Red Hat does, and linuxconf is a popular add-on for many of the other distributions. Linuxconf is a tool for making the administration of a linux box easier. It attempts to provide a point and click interface, as well as combining seperate steps into one. While I've never heard of a remote linuxconf exploit, there's no real reason to run the web interface on a single-user system. Just because you don't run the web interface does not mean that you can't use linuxconf. There's a mode of linuxconf that runs just fine in a terminal window. Linuxconf -could- be used to gain remote root or gain more information about your system. Again, single-user systems don't need it. Comment it out.
Okay, now you have an entirely commented out inetd.conf. This means that inetd will load no servers and provide no services to other hosts. So, why run inetd at all? The answer is simple: there's no reason to run inetd if everything is commented out. As Jos says in another section 'why waste the memory?' So, you can just kill it, if it's running.
[ ROOT ]# ps -aux |grep inetd root 263 0.0 0.6 972 480 ? S Apr 29 0:00 inetd [ ROOT ]# kill 263Now that inetd is turned off, you need to disable it so it does not even start. A little bit later in this section I'll talk about disabling services so they do not start at boot.
Okay, so we have inetd disabled, so we're not running any more services, right? Wrong.
[ USER ]$ netstat -an |grep 0.0.0.0 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN raw 0 0 0.0.0.0:1 0.0.0.0:*This edited output of netstat shows that there are still some listeners on the system. The raw port really isn't anything to worry about, so ignore that one. Note the 0.0.0.0:(some port number) entries. This is netstat telling you what port numbers are listening (look at /etc/services to translate port numbers to more recognizable names). On this system, we have ports 22, 25 and 80. Port 22 is secure shell, which Jos addresses later. Port 25 is the smtp port, also known as the e-mail port. Port 80 is the www port (web server). So, it would seem that some daemons run without inetd. Don't worry about secure shell (ssh), it's a rather well behaved daemon (though, make sure you are running the latest version). The other two ports are ususally handled by sendmail and apache. Sendmail does not have a very good past when it comes to security. There have been several remote root exploits. Apache, since it runs as a non-priveldged user, isn't really suceptable to remote root exploits. However, it has been used as a tool to gain information about systems (for instance, the password file) that a person who does not have an account on the system would otherwise not have. Again, on a single-user system, there's no need to run Apache, so we'll disable it (I'll show you how a little bit later in this section). For the smtp port, you do not have to be running an e-mail server to send mail locally on your system or to others on the Internet, only to receive. Since you most likely POP your e-mail from your ISP, you should skip the risk of having a mail server listening on this port, so you should disable it.
Disabling services depends on your distribution. Rather than give explicit directions for all the distributions, I'm going to give pointers to the major ones and give you a pretty good idea about how to disable the services you don't want.
The last item I'd like to discuss on securing single-user systems is tcp_wrappers. Jos goes into much more detail later, so I'll just give you the general idea right now. tcp_wrappers is useful if you are running services that you want to restrict to a certain set of users. While we have already disabled all services on your system, there might come a time when you wish to turn something back on so a friend can ssh in to your system, or some such. What tcp_wrappers is let you decide which services are available to which users based on IP address. It's quite simple to use and has saved me a couple times (I run qpopper on one of my servers -- there was an exploit for qpopper that took a few days to patch. In that time period, I had several hosts probe my pop-3 port, but were denied access due to tcp_wrappers). If you are interested in tcp_wrappers, pay attention to Jos' talk about it.
Using a dynamic DNS service slightly increases the difficulty of securing a dialup system. Having a DNS name that points to your system generally implies that you have some service or services that you would like to make available to the outsite world. Because of this, you simply cannot just disable all network services. Basically, you need to disable all services but the one you wish to allow others to use. The one or two that you enable must be protected and watched closely through keeping up with security updates and through actually reading your log files (we'll list tools to make the job of reading log files a little easier later in the guide).