4. Securing Your Connection

This section is intended for those who have not previously dealt with the security implications of having a full-time Internet connection. Or may not understand some of the basic concepts of security. This is meant to be just a quick overview, not a comprehensive examination of all the issues! Just enough to give you a quick push in the right direction. Please see the Links section for sites with more details. Also, your distribution surely has plenty of good information as well.

4.1. Security Quick-start

Before going on-line full-time, do not underestimate the need for securing your connection. You will have two things that mischief makers and crackers of the world are looking for: bandwidth, and a Unix-like OS. You instantly become an inviting target. It is just a matter of time before someone comes knocking. Possibly a very short time. A quick start:

4.2. Which Ports?

There are plenty of references around on how to setup firewalls with ipfwadm or ipchains, but a little harder to find just which ports really need to be open. If you are not sure of the answer to this question, then the answer is "as few as possible"! Basic rule #1, your computer cannot be broken into through a port that is not open. A port can't be open if nothing is listening on that port. In other words, if no service or daemon is running that uses that port, the port is closed and inaccessible.

There are 131,072 ports (TCP and UDP) available for use on Linux and these fall into several categories. The ones we are most concerned about are the "privileged" ports, which are those below port 1024. This is where most public services run, like SMTP on port 25, HTTP on port 80, named on port 53, etc. These services are where most vulnerabilities are on Linux. These are the ports that servers accept outside connections on. If you are running the telnetd daemon, it will "listen" for connections on port 23. (Actually if spawned by inetd, it may be inetd that is doing the listening.)

But, if you want to use a telnet client to connect to someone else's telnet server, you do not need to be running the telnetd daemon on your own system. You just need to start the client program named telnet (different animal). Same is true for ftp and other services. These daemons only need to be run for excepting connections to your system from an outside source.

Unless you have a good reason for doing so, and know what you are doing, then you should not be running such publicly accessible services. In fact, you could probably survive quite nicely with all TCP and UDP ports below 1024 closed down, or at least not visible to outside connections (i.e. blocked via a firewall). A few possible exceptions:

It is relatively safe, and in some cases alright, to run identd (port 113). Many mail and irc servers aren't happy without identd there. This is the one possible exception to the "nothing below 1024" rule of thumb. Newer versions are reasonably secure.

Mail is a little more complicated. The only reason to have a publicly accessible SMTP (port 25) server is if you are hosting your own mail server and receiving direct incoming mail connections. If you are retrieving mail via POP3 from your ISP, this port does not need to be open to the world. Such mail does not come in via port 25. It comes in through a higher, randomly assigned port.

But -- it may still be convenient to have a mail daemon like sendmail, qmail, or postfix running to handle local mail delivery. In fact, this is a common default set up. You can get around this by firewalling off SMTP (port 25) from the outside world, or using another method to sort and deliver local mail. One way is to use procmail in conjunction with fetchmail: fetchmail -m /usr/bin/procmail -d hal will do this without having to run sendmail or other mail daemons in daemon mode. These programs are still capable of sending mail in non-daemon mode.

Older versions of BIND required that port 53 UDP be opened (TCP required for zone transfers). BIND is only appropriate if you are running a nameserver (or caching nameserver). The solution here is to upgrade to a newer version that uses unprivileged ports by default.

It is probably safe to run a web server if you want to. Most vulnerabilities there are through CGI. Just keep the web server package updated.

OK, enough exceptions. Shut down, or firewall off, everything else below port 1024.

Those ports above 1023 are known as "non-privileged" ports. These are mostly used for return connections that you have initiated to someone else's server. For instance, if you telnet to someone else, you connect to their port 23. The return data comes back to you on a randomly assigned port above 1023. These are mostly safe, and should as a rule be left alone. The only exceptions are where there are indeed services running on these ports. X Windows runs on ports 6000-6009 for instance. If you are running a font server, it may be on port 7100. Any servers running on these non-privileged ports, should be firewalled too.

4.3. inetd

Let's take a quick look at inetd, since it starts many services. Inetd is a "super" daemon. It is called this because it controls the starting of other daemons. Telnet, ftp, rsh, identd and pop3 are some of the server daemons commonly controlled by inetd. You may not see telnetd running when you use ps or netstat unless inetd is configured to start telnetd, and someone is actually connected to telnetd at the time. So it may not be so obvious which of these servers can be accessed from outside. These sub-services are controlled by the configuration file /etc/inetd.conf. Open this with your favorite text editor, and put a "#" character in front of any service you don't want running. A brief excerpt:

 
 #ftp    stream tcp nowait root /usr/sbin/tcpd in.wuftpd -l -a -L -i -o
 #telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
 #
 # Shell, login, exec, comsat and talk are BSD protocols.
 #
 #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

<snip>
 
 auth   stream  tcp   nowait  nobody /usr/sbin/in.identd in.identd -l -e -o

   

This will prevent them from running. identd may be started from this file, and would be safe to leave uncommented. Then re-initialize: inetd:


 # kill -HUP `pidof inetd`

Note those are "backquotes". For more on fine tuning inetd access via "tcpwrappers", see the hosts_access and tcpd man pages.

xinetd is a similar daemon, and you may have this instead of inetd. It does pretty much the same thing, so the same principles apply. The configuration is a little different however. Each service is either configured in a central configuration file (typically /etc/xinetd.conf), or in a subdirectory (typically /xinetd.d/*.)

 
 # description: The telnet server serves telnet sessions; it uses 
 # unencrypted username/password pairs for authentication.

 service telnet
 {
disable     = yes
flags       = REUSE
socket_type = stream        
wait        = no
user        = root
server      = /usr/sbin/in.telnetd
log_on_failure += USERID
 }

   

To turn off a service, set "disable" to "yes", and restart xinetd.