Network security is becoming more and more important as people spend more and more time connected. Compromising network security is often much easier than compromising physical or local security, and is much more common.
There are a number of good tools to assist with network security, and more and more of them are shipped with your Mandrake Linux distribution, either in the main CD-ROM, contribs, or through the FTP crypto server (see above).
One of the most common ways intruders gain access to more systems on your network is by employing a packet sniffer on a already compromised host. This "sniffer" just listens on the Ethernet port for things like passwd and login and su in the packet stream and then logs the traffic after that. This way, attackers gain passwords for systems they are not even attempting to break into. Clear-text passwords are very vulnerable to this attack.
Example: Host A has been compromised. Attacker installs a sniffer. Sniffer picks up admin logging into Host B from Host C. It gets the admins personal password as they login to B. Then, the admin does a su to fix a problem. They now have the root password for Host B. Later the admin lets someone telnet from his account to Host Z on another site. Now the attacker has a password/login on Host Z.
In this day and age, the attacker doesn't even need to compromise a system to do this: they could also bring a laptop or PC into a building and tap into your net.
Using ssh or other encrypted password methods thwarts this attack. Things like APOP for POP accounts also prevents this attack. (Normal POP logins are very vulnerable to this, as is anything that sends clear-text passwords over the network.)
Before you put your GNU/Linux system on ANY network the first thing to look at is what services you need to offer. Services that you do not need to offer should be disabled so that you have one less thing to worry about and attackers have one less place to look for a hole.
There are a number of ways to disable services under GNU/Linux. You can look at your /etc/inetd.conf file and see what services are being offered by your inetd. Disable any that you do not need by commenting them out (# at the beginning of the line), and then restart your inetd service.
You can also remove (or comment out) services in your /etc/services file. This will mean that local clients will also be unable to find the service (i.e., if you remove ftp, and try and ftp to a remote site from that computer it will fail with an unknown service message). It's usually not worth the trouble to remove services from /etc/services, since it provides no additional security. If a local person wanted to use ftp even though you had commented it out, they would make their own client that use the common FTP port and would still work fine.
Some of the services you might want to leave enabled are:
If you know you are not going to use some particular package, you can also delete it entirely. rpm -e packagename will erase an entire package.
Additionally, you really want to disable the rsh/rlogin/rcp utilities, including login (used by rlogin), shell (used by rcp), and exec (used by rsh) from being started in /etc/inetd.conf. These protocols are extremely insecure and have been the cause of exploits in the past.
You should check your /etc/rc.d/rc[0-9].d, and see if any of the servers started in that directory are not needed. The files in that directory are actually symbolic links to files in the directory /etc/rc.d/init.d. Renaming the files in the init.d directory disables all the symbolic links that point to that file. If you only wish to disable a service for a particular run level, rename the appropriate symbolic link by replacing the S with a K, like this:
root# cd /etc/rc6.d
root# mv S45dhcpd K45dhcpd
You may also use a command line utility to do that: chkconfig or the graphical interface under KDE: ksysv.
Your Mandrake Linux distributions ships with a tcp_wrapper “wrapping” all your TCP services. The tcp_wrapper (tcpd) is invoked from inetd instead of the real server. tcpd then checks the host that is requesting the service, and either executes the real server, or denies access from that host. tcpd allows you to restrict access to your TCP services. You should edit /etc/hosts.allow and add in only those hosts that need to have access to your computer's services.
If you are a home dial up user, we suggest you deny ALL. tcpd also logs failed attempts to access services, so this can alert you if you are under attack. If you add new services, you should be sure to configure them to use tcp_wrappers if they are TCP-based. For example, a normal dial-up user can prevent outsiders from connecting to his computer, yet still have the ability to retrieve mail, and make network connections to the Internet. To do this, you might add the following to your /etc/hosts.allow:
And of course /etc/hosts.deny would contain:
which will prevent external connections to your computer, yet still allow you from the inside to connect to servers on the Internet.
Keep in mind that tcp_wrappers only protects services executed from inetd, and a select few others. There very well may be other services running on your computer. You can use netstat -ta to find a list of all the services your computer is offering.
Keeping up-to-date DNS information about all hosts on your network can help to increase security. If an unauthorized host becomes connected to your network, you can recognize it by its lack of a DNS entry. Many services can be configured to not accept connections from hosts that do not have valid DNS entries.
identd is a small program that typically runs out of your inetd server. It keeps track of what user is running what TCP service, and then reports this to whoever requests it.
Many people misunderstand the usefulness of identd, and so disable it or block all off site requests for it. identd is not there to help out remote sites. There is no way of knowing if the data you get from the remote identd is correct or not. There is no authentication in identd requests.
Why would you want to run it then? Because it helps you out, and is another data-point in tracking. If your identd is not compromised, then you know it's telling remote sites the user-name or UID of people using TCP services. If the admin at a remote site comes back to you and tells you user so-and-so was trying to hack into their site, you can easily take action against that user. If you are not running identd, you will have to look at lots and lots of logs, figure out who was on at the time, and in general take a lot more time to track down the user.
The identd that ships with most distributions is more configurable than many people think. You can disable it for specific users (they can make a .noident file), you can log all identd requests (We recommend it), you can even have identd return a UID instead of a user name or even NO-USER.
The Postfix mail server was written by Wietse Venema, author of Postfix and several other staple Internet security products, as an “attempt to provide an alternative to the widely-used Sendmail program. Postfix attempts to be fast, easy to administer, and hopefully secure, while at the same time being Sendmail-compatible enough to not upset your users.”
Further information on postfix can be found at the Postfix home and in the Configuring and Securing Postfix.
There are a number of different software packages out there that do port and service-based scanning of computers or networks. SATAN, ISS, SAINT, and Nessus are some of the more well-known ones. This software connects to the target computer (or all the target computers on a network) on all the ports they can, and try to determine what service is running there. Based on this information, you can tell if the computer is vulnerable to a specific exploit on that server.
SATAN (Security Administrator's Tool for Analyzing Networks) is a port scanner with a web interface. It can be configured to do light, medium, or strong checks on a computer or a network of computers. It's a good idea to get SATAN and scan your computer or network, and fix the problems it finds. Make sure you get the copy of SATAN from metalab or a reputable FTP or web site. There was a Trojan copy of SATAN that was distributed out on the net. trouble.org. Note that SATAN has not been updated in quite a while, and some of the other tools below might do a better job.
ISS (Internet Security Scanner) is another port-based scanner. It is faster than Satan, and thus might be better for large networks. However, SATAN tends to provide more information.
TriSentry (formerly Abacus) is a suite of tools to provide host-based security and intrusion detection. look at its home page on the web for more information. http://www.psionic.com/products/
SAINT is an updated version of SATAN. It is web based and has many more up to date tests than SATAN. You can find out more about it at: http://www.wwdsi.com/~saint
Nessus is a free security scanner. It has a GTK graphical interface for ease of use. It is also designed with a very nice plug in setup for new port-scanning tests. For more information, take a look at: http://www.nessus.org
There are some tools designed to alert you to probes by SATAN and ISS and other scanning software. However, if you liberally use tcp_wrappers, look over your log files regularly, you should be able to notice such probes. Even on the lowest setting, SATAN still leaves traces in the logs.
There are also “stealth” port scanners. A packet with the TCP ACK bit set (as is done with established connections) will likely get through a packet-filtering firewall. The returned RST packet from a port that _had no established session_ can be taken as proof of life on that port. I don't think TCP wrappers will detect this.
You might also look at SNORT, which is a free IDS (Intrusion Detection System), which can detect other network intrusions.
One of the most important services you can provide is a mail server. Unfortunately, it is also one of the most vulnerable to attack, simply due to the number of tasks it must perform and the privileges it typically needs.
If you are using sendmail it is very important to keep up on current versions. sendmail has a long long history of security exploits. Always make sure you are running the most recent version from sendmail.
Keep in mind that sendmail does not have to be running in order for you to send mail. If you are a home user, you can disable sendmail entirely, and simply use your mail client to send mail. You might also choose to remove the -bd flag from the sendmail startup file, thereby disabling incoming requests for mail. In other words, you can execute sendmail from your startup script using the following instead:
# /usr/lib/sendmail -q15m
This will cause sendmail to flush the mail queue every fifteen minutes for any messages that could not be successfully delivered on the first attempt.
Many administrators choose not to use sendmail, and instead choose one of the other mail transport agents. You might consider switching over to qmail. qmail was designed with security in mind from the ground up. It's fast, stable, and secure. Qmail can be found at qmail
In direct competition to qmail is postfix, written by Wietse Venema, the author of tcp_wrappers and other security tools. Formerly called vmailer, and sponsored by IBM, this is also a mail transport agent written from the ground up with security in mind. You can find more information about postfix at postfix
A “Denial of Service” (DoS) attack is one where the attacker tries to make some resource too busy to answer legitimate requests, or to deny legitimate users access to your computer.
Denial of service attacks have increased greatly in recent years. Some of the more popular and recent ones are listed below. Note that new ones show up all the time, so this is just a few examples. Read the GNU/Linux security lists and the bugtraq list and archives for more current information.
SYN Flooding - SYN flooding is a network denial of service attack. It takes advantage of a "loophole" in the way TCP connections are created. The newer GNU/Linux kernels (2.0.30 and up) have several configurable options to prevent SYN flood attacks from denying people access to your computer or services. See the section called “Kernel Security” for proper kernel protection options.
Ping Flooding - Ping flooding is a simple brute-force denial of service attack. The attacker sends a “flood” of ICMP packets to your computer. If they are doing this from a host with better bandwidth than yours, your computer will be unable to send anything on the network. A variation on this attack, called “smurfing”, sends ICMP packets to a host with your computer's return IP, allowing them to flood you less detectably. You can find more information about the “smurf” attack at linuxsecurity.com
If you are ever under a ping flood attack, use a tool like tcpdump to determine where the packets are coming from (or appear to be coming from), then contact your provider with this information. Ping floods can most easily be stopped at the router level or by using a firewall.
Ping o' Death - The Ping o' Death attack sends ICMP ECHO REQUEST packets that are too large to fit in the kernel data structures intended to store them. Because sending a single, large (65,510 bytes) "ping" packet to many systems will cause them to hang or even crash, this problem was quickly dubbed the “Ping o' Death”. This one has long been fixed, and is no longer anything to worry about.
You can find code for most exploits, and a more in-depth description of how they work, at insecure.org using their search engine.
NFS is a very widely-used file sharing protocol. It allows servers running nfsd and mountd to “export” entire file systems to other computers using NFS file system support built in to their kernels (or some other client support if they are not GNU/Linux computers). mountd keeps track of mounted file systems in /etc/mtab, and can display them with showmount.
Many sites use NFS to serve home directories to users, so that no matter what computer in the cluster they login to, they will have all their home files.
There is some small amount of security allowed in exporting file systems. You can make your nfsd map the remote root user (UID=0) to the nobody user, denying them total access to the files exported. However, since individual users have access to their own (or at least the same UID) files, the remote root user can login or su to their account and have total access to their files. This is only a small hindrance to an attacker that has access to mount your remote file systems.
If you must use NFS, make sure you export to only those computers that you really need to. Never export your entire root directory; export only directories you need to export.
See the NFS HOWTO for more information on NFS, available at LDP
Network Information Service (formerly YP) is a means of distributing information to a group of computers. The NIS master holds the information tables and converts them into NIS map files. These maps are then served over the network, allowing NIS client computers to get login, password, home directory and shell information (all the information in a standard /etc/passwd file). This allows users to change their password once and have it take effect on all the computers in the NIS domain.
NIS is not at all secure. It was never meant to be. It was meant to be handy and useful. Anyone that can guess the name of your NIS domain (anywhere on the net) can get a copy of your passwd file, and use crack and John the Ripper against your users' passwords. Also, it is possible to spoof NIS and do all sorts of nasty tricks. If you must use NIS, make sure you are aware of the dangers.
There is a much more secure replacement for NIS, called NIS+. Check out the NIS HOWTO for more information: NIS-HOWTO
Firewalls are a means of controlling what information is allowed into and out of your local network. Typically the firewall host is connected to the Internet and your local LAN, and the only access from your LAN to the Internet is through the firewall. This way the firewall can control what passes back and forth from the Internet and your LAN.
There are a number of types of firewalls and methods of setting them up. GNU/Linux computers make pretty good firewalls. Firewall code can be built right into 2.0 and higher kernels. The user-space tools ipchains for 2.2 kernels, and iptables for 2.4 kernels, allows you to change, on the fly, the types of network traffic you allow. You can also log particular types of network traffic.
Firewalls are a very useful and important technique in securing your network. However, never think that because you have a firewall, you don't need to secure the computers behind it. This is a fatal mistake. Check out the very good Firewall-HOWTO at your latest metalab archive for more information on firewalls and GNU/Linux. Firewall-HOWTO
If you have no experience with firewalls, and plan to set up one for more than just a simple security policy, the Firewalls book by or other online firewall document is mandatory reading. Check out O'Reilly site for more information. The National Institute of Standards and Technology have put together an excellent document on firewalls. Although dated 1995, it is still quite good. You can find it at nist.gov. Also of interest includes:
GNU/Linux IP Firewalling Chains is an update to the 2.0 GNU/Linux firewalling code for the 2.2 kernel. It has many more features than previous implementations, including:
Be sure to read the IP Chains HOWTO for further information. It is available at TLDP
In yet another set of advancements to the kernel IP packet filtering code, netfilter allows users to set up, maintain, and inspect the packet filtering rules in the new 2.4 kernel.
The netfilter subsystem is a complete rewrite of previous packet filtering implementations including ipchains and ipfwadm. Netfilter provides a large number of improvements, and it has now become an even more mature and robust solution for protecting corporate networks.
iptables is the command-line interface used to manipulate the firewall tables within the kernel.
Netfilter provides a raw framework for manipulating packets as they traverse through various parts of the kernel. Part of this framework includes support for masquerading, standard packet filtering, and now more complete network address translation. It even includes improved support for load balancing requests for a particular service among a group of servers behind the firewall.
The stateful inspection features are especially powerful. Stateful inspection provides the ability to track and control the flow of communication passing through the filter. The ability to keep track of state and context information about a session not only makes rules simpler but also helps to better interpret higher-level protocols.
Additionally, small modules can be developed to perform additional specific functions, such as passing packets to programs in userspace for processing then reinjecting back into the normal packet flow. The ability to develop these programs in userspace reduces the level of complexity that was previously associated with having to make changes directly at the kernel level.
Other IP Tables references include:
Oskar Andreasson IP Tables Tutorial — Oskar Andreasson speaks with LinuxSecurity.com about his comprehensive IP Tables tutorial and how this document can be used to build a robust firewall for your organization.
Hal Burgiss Introduces Linux Security Quick-Start Guides — Hal Burgiss has written two authoritative guides on securing Linux, including managing firewalling.
Netfilter Home page — The netfilter/iptables home page.
Linux Kernel 2.4 Firewalling Matures: netfilter — This LinuxSecurity.com article describes the basics of packet filtering, how to get started using iptables, and a list of the new features available in the latest generation of firewalling for Linux.
VPN's are a way to establish a “virtual” network on top of some already existing network. This virtual network often is encrypted and passes traffic only to and from some known entities that have joined the network. VPN's are often used to connect someone working at home over the public Internet to a internal company network.
If you are running a GNU/Linux masquerading firewall and need to pass MS PPTP ('s VPN point-to-point product) packets, there is a linux kernel patch out to do just that. See: ip-masq-vpn.
There are several GNU/Linux VPN solutions available:
vpnd. See the http://sunsite.auc.dk/vpnd/.
Free S/Wan, available at http://www.xs4all.nl/~freeswan/
ssh can be used to construct a VPN. See the VPN mini-howto for more information.
vps (virtual private server) at strongcrypto.
vtun (virtual tunnel) at sourceforge.
See also the section on IPSEC for pointers and more information.