As soon as a computer is connected to the network, all kinds of abuse becomes possible, be it a UNIX-based or any other system. Admittedly, mountains of papers have been spilled on this subject and it would lead us too far to discuss the subject of security in detail. There are, however, a couple of fairly logical things even a novice user can do to obtain a very secure system, because most break-ins are the result of ignorant or careless users.
Maybe you are asking yourself if this all applies to you, using your computer at home or working at your office on a desktop in a fairly protected environment. The questions you should be asking yourself, however, are more on the lines of:
Do you want to be in control of your own system?
Do you want to (unwittingly) participate in criminal activities?
Do you want your equipment to be used by someone else?
Do you want to take risks on losing your Internet connection?
Do you want to rebuild your system every time it has been hacked?
Do you want to risk personal or other data loss?
Presuming you don't, we will quickly list the steps you can take to secure your machine. Extended information can be found in the Linux Security HOWTO.
The goal is to run as few services as possible. If the number of ports that are open for the outside world are kept to a minimum, this is all the better to keep an overview. If services can't be turned off for the local network, try to at least disable them for outside connections.
A rule of thumb is that if you don't recognize a particular service, you probably won't need it anyway. Also keep in mind that some services are not really meant to be used over the Internet. Don't rely on what should be running, check which services are listening on what TCP ports using the netstat command:
[elly@mars ~] netstat -l | grep tcp tcp 0 0 *:32769 *:* LISTEN tcp 0 0 *:32771 *:* LISTEN tcp 0 0 *:printer *:* LISTEN tcp 0 0 *:kerberos_master *:* LISTEN tcp 0 0 *:sunrpc *:* LISTEN tcp 0 0 *:6001 *:* LISTEN tcp 0 0 *:785 *:* LISTEN tcp 0 0 localhost.localdom:smtp *:* LISTEN tcp 0 0 *:ftp *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 ::1:x11-ssh-offset *:* LISTEN |
Things to avoid:
exec, rlogin and rsh, and telnet just to be on the safe side.
X11 on server machines.
No lp if no printer is physically attached.
No MS Windows hosts in the network, no Samba required.
Don't allow FTP unless an FTP server is required.
Don't allow NFS and NIS over the Internet, disable all related services on a stand-alone installation.
Don't run an MTA if you're not actually on a mail server.
...
Stop running services using the chkconfig command, the initscripts or by editing the (x)inetd configuration files.
Its ability to adapt quickly in an ever changing environment is what makes Linux thrive. But it also creates a possibility that security updates have been released even while you are installing a brand new version, so the first thing you should do (and this goes for about any OS you can think of) after installing is getting the updates as soon as possible. After that, update all the packages you use regularly.
Some updates may require new configuration files, and old files may be replaced. Check the documentation, and ensure that everything runs normal after updating.
Most Linux distributions provide mailing list services for security update announcements, and tools for applying updates to the system. General Linux only security issues are reported among others at Linuxsecurity.com.
Updating is an ongoing process, so it should be an almost daily habit.
In the previous section we already mentioned firewall capabilities in Linux. While firewall administration is one of the tasks of your network admin, you should know a couple of things about firewalls.
Firewall is a vague term that can mean anything that acts as a protective barrier between us and the outside world, generally the Internet. A firewall can be a dedicated system or a specific application that provides this functionality. Or it can be a combination of components, including various combinations of hardware and software. Firewalls are built from "rules" that are used to define what is allowed to enter and/or exit a given system or network.
After disabling unnecessary services, we now want to restrict accepted services as to allow only the minimum required connections. A fine example is working from home: only the specific connection between your office and your home should be allowed, connections from other machines on the Internet should be blocked.
The first line of defense is a packet filter, which can look inside IP packets and make decisions based on the content. Most common is the Netfilter package, providing the iptables command, a next generation packet filter for Linux.
One of the most noteworthy enhancements in the newer kernels is the stateful inspection feature, which not only tells what is inside a packet, but also detects if a packet belongs or is related to a new or existing connection.
The Shoreline Firewall or Shorewall for short is a front-end for the standard firewall functionality in Linux.
More information can be found at the Netfilter/iptables project page.
TCP wrapping provides much the same results as the packet filters, but works differently. The wrapper actually accepts the connection attempt, then examines configuration files and decides whether to accept or reject the connection request. It controls connections at the application level rather than at the network level.
TCP wrappers are typically used with xinetd to provide host name and IP-address-based access control. In addition, these tools include logging and utilization management capabilities that are easy to configure.
The advantages of TCP wrappers are that the connecting client is unaware that wrappers are used, and that they operate separately from the applications they protect.
The host based access is controlled in the hosts.allow and hosts.deny files. More information can be found in the TCP wrapper documentation files in /usr/share/doc/tcp_wrappers[-<version>/] or /usr/share/doc/tcp and in the man pages for the host based access control files, which contain examples.
Proxies can perform various duties, not all of which have much to do with security. But the fact that they are an intermediary make proxies a good place to enforce access control policies, limit direct connections through a firewall, and control how the network behind the proxy looks to the Internet.
Usually in combination with a packet filter, but sometimes all by themselves, proxies provide an extra level of control. More information can be found in the Firewall HOWTO or on the Squid website.
Some servers may have their own access control features. Common examples include Samba, X Window, Bind, Apache and CUPS. For every service you want to offer check which configuration files apply.
If anything, the UNIX way of logging all kinds of activities into all kinds of files confirms that "it is doing something." Of course, log files should be checked regularly, manually or automatically. Firewalls and other means of access control tend to create huge amounts of log files, so the trick is to try and only log abnormal activities.
Intrusion Detection Systems are designed to catch what might have gotten past the firewall. They can either be designed to catch an active break-in attempt in progress, or to detect a successful break-in after the fact. In the latter case, it is too late to prevent any damage, but at least we have early awareness of a problem. There are two basic types of IDS: those protecting networks, and those protecting individual hosts.
For host based IDS, this is done with utilities that monitor the file system for changes. System files that have changed in some way, but should not change, are a dead give-away that something is amiss. Anyone who gets in and gets root access will presumably make changes to the system somewhere. This is usually the very first thing done, either so he can get back in through a backdoor, or to launch an attack against someone else, in which case, he has to change or add files to the system. Some systems come with the tripwire monitoring system, which is documented at the Tripwire Open Source Project website.
Network intrusion detection is handled by a system that sees all the traffic that passes the firewall (not by portscanners, which advertise usable ports). Snort is an Open Source example of such a program. Whitehats.com features an open Intrusion detection database, arachNIDS.
Some general things you should keep in mind:
Do not allow root logins. UNIX developers came up with the su over two decades ago for extra security.
Direct root access is always dangerous and susceptible to human errors, be it by allowing root login or by using the su - command. Rather than using su, it is even better to use sudo to only execute the command that you need extra permissions for, and to return afterwards to your own environment.
Take passwords seriously. Use shadow passwords. Change your passwords regularly.
Try to always use SSH or SSL. Avoid telnet, FTP and E-mail clients and other client programs which send unencrypted passwords over the network. Security is not only about securing your computer, it is also about securing your passwords.
Limit resources using quota and/or ulimit.
The mail for root should be delivered to, or at least read by, an actual person.
The SANS institute has more tips and tricks, sorted per distribution, with mailing list service.
Check the origin of new software, get it from a trusted place/site. Verify new packages before installing.
When using a non-permanent Internet connection, shut it down as soon as you don't need it anymore.
Run private services on odd ports instead of the ones expected by possible hackers.
Know your system. After a while, you can almost feel when something is happening.
How can you tell? This is a checklist of suspicious events:
Mysterious open ports, strange processes.
System utilities (common commands) behaving strange.
Login problems.
Unexplained bandwidth usage.
Damaged or missing log files, syslog daemon behaving strange.
Interfaces in unusual modes.
Unexpectedly modified configuration files.
Strange entries in shell history files.
Unidentified temporary files.
In short, stay calm. Then take the following actions in this order:
Disconnect the machine from the network.
Try to find out as much as you can about how your security was breached.
Backup important non-system data. If possible, check these data against existing backups, made before the system was compromised, to ensure data integrity.
Re-install the system.
Use new passwords.
Restore from system and data backups.
Apply all available updates.
Re-examine the system: block off unnecessary services, check firewall rules and other access policies.
Reconnect.