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:

Turn off any daemons and services that aren't absolutely essential, and can be accessed from outside. You can't get compromised through a port that isn't open. Use ps and netstat to see what services are running. (See man pages for specifics). Do you really need named, sendmail, telnet, ftp running and accessible to one and all? If not sure, then they should not be running. Then take whatever steps necessary to make sure they don't start again on the next boot. See your distribution's documentation on this.
Many distributions start some well known services by default. You may not have done anything yourself explicitly to start these. And may not even realize these are indeed running. But it is up to you to know what is running, and how safe it is. Don't rely on a "default" installation of any distribution to do this for you, or to be secure. Chances are it isn't.
If you decide some services are essential, make sure you are running the most current version. Exploits are found, and then get fixed quickly. Don't get caught with your pants down. A full-time connection makes staying updated very easy -- and very important. Check with your distribution to see what new packages are available. Then stay in touch. If they have a security mailing list, get on it.
Set up a firewall to limit access, and log connection attempts. This will be different depending on which kernel series you are using: ipfwadm for 2.0, ipchains for 2.2, and iptables for 2.4. See these HOWTOs for details:
Additional references are in the Links Section below.
Take passwords seriously, using non-dictionary "words". Use shadow passwords (this should be a standard feature of newer distributions). Do not allow remote root logins. See the Security HOWTO for more details and ideas.
Use ssh, or OpenSSH, instead of telnet.

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 65,536 ports 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 couple of 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.

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".