comp.os.linux.security FAQ

1.1)  Introduction to comp.os.linux.security

Welcome to comp.os.linux.security.  We ask that you please read the FAQ before posting questions to the newsgroup.  Otherwise:  Look, listen, learn, contribute, but above all, enjoy yourself and the interests you share with the other denizens of the newsgroup.

This FAQ is intended to serve as a starting point for those new to the newsgroup, but is also intended to be a survey of  Linux security issues and tools.  This FAQ is aimed at intermediate to experienced Linux users and is intended to not only answer specific questions, but to also facilitate further learning by providing pointers other useful security resources.

This introduction/pointer will be posted to comp.os.linux.security approximately every two weeks.

The latest version of this faq is 2.0, and can be downloaded from:

1.2)  Does comp.os.linux.security have a charter?

1.3)  What is covered in this FAQ?

Specifically, security as it pertains to the Linux operating system.

General installation of Linux is not covered, nor are products by other vendors, except where they impact Linux security.   It is not my intent to re-invent the wheel, and in cases where relevant information has been covered elsewhere it has been linked to, and is accompanied by commentary on Linux specific issues.

Also, I have purposefully left out pointers to 'sploits, and other such naughtiness.  Presentation of such material will benefit those on the offensive end of security more than it will benefit those trying to secure their systems.  A holistic view of system security will serve sysadmins far better than will concentrating on protecting against the 'sploit du jour.

Future additions:

10)  Logfiles
11)  Backups

1.4)  Who is responsible for this faq, and how can I contribute?

Daniel Swan is the creator and maintainer of this FAQ, but it's a large effort, and informed contributions are welcome, particularly suggestions for topics or questions that you feel have been overlooked.

This is a living document, and one that is intended to reflect the issues discussed on comp.os.linux.security.  All participants of comp.os.linux.security are urged to contribute in whatever form possible.

Submissions may be edited for flow, style, and consistency with the rest of the FAQ.  Due credit will be given for all submissions used, whether incorporated verbatim or in an edited form.

If you know of a useful and relevant project or product not mentioned in this faq, by all means, let me know.
 

1.5) Acknowledgments and contributions

This FAQ primarily owes a debt to the many users in comp.os.linux.security, and the discussions therein.  Although not direct contributors, I'd also like to give a nod to those who have contributed to my own knowledge of Linux security:   Kevin Fenzi and Dave Wreski, authors of the Linux Security HOWTO, and Kurt Seifried, author of the Linux Administrators Security guide.

The following deserve credit for significant contributions made to this FAQ:

1.6) Feedback

Feedback may be sent to swan_daniel@hotmail.com

1.7) Disclaimer and Copyright

This material is provided for free, without warranty, and I accept no responsibility for use or misuse of the material contained within.

I also acknowledge that there may be errors in the FAQ, and stress that responsibility for verification of  information provided lies with the end user.

2.1)  How can I protect myself from hackers quickly and easily?

In order of importance:

2.2)  What is security?

Security, in a nutshell, is ensuring the Confidentiality, Integrity, and Availability of your systems and network.

2.3)  How secure should my Linux box be?

Even if it were possible to lock a system down air tight, it is not always practical to invest the time and effort required to do so. The best thing to do is to first determine your risk, and then secure accordingly.

risk=(threat*vulnerability*impact)

Threat:  What is the probability of you coming under attack?  Who will be trying to penetrate you?  Will you be targeted by seasoned hackers with a bone to pick, or are you only concerned with keeping the $cript kiddies out?  Do you have many users, or are you the only one?  Are your users trusted, or are they experienced programmers who like to "play"?  Are you a reviled site, such as microsoft.com, or are you an innocuous cable modem or dialup user?

Vulnerability:  How susceptible to attack is your host?   Do you run many services?  How exploitable are they?  How accessible is your host?  Is your host behind a firewall?  Do you offer remote access, and if so, how?  Do others have physical access to your host?  What other potential points of compromise are there?

Impact:  What are the ramifications if your machine is compromised?   Will proprietary data enter the public domain?  Is there sensitive or potentially embarrassing information on your computer?   Will downtime have a financial impact on you?   How long will it take you to get up and running again, and how much effort will it require?

2.4)  Which is the most secure Linux distribution?

There are many Linux distributions specifically created with security in mind:

Immunix OS:  http://www.immunix.com/ - A commercially available hardened Linuux.

Bastille Linux:  http://www.bastille-linux.org/ - Not really a distribution, but a post--install hardening script, presently available for Redhat up to 7.1.

...Also similar to Bastille Linux, is "harden_suse", a post-install hardening script included in the SuSe distribution.

slinux:  http://www.slinux.org/  - Still in its infant stage, slinux is aa project to develop a hardened version of the Linux kernel.

Security-Enhanced Linux: http://www.nsa.gov/selinux/  -  This isn't actually a distributiion, but an add-on that facilitates "Flexible Support for Security Policies".  Considering the source of this package, an American Intelligence Agency, careful consideration should be made before installing it on machines that store sensitive or proprietary information, at least until a rigorous code audit is done of it.

Engarde Linux:  http://www.engardelinux.com - EnGarde is a secure distribution of Liinux engineered from the ground up to provide organizations with the level of security required to create a complete corporate online presence.  It is commercial, but a trial is available.

Trustix Secure Linux: http://www.trustix.net - Trustix Secure Linux is a server oriennted Linux distribution which focuses on secure default settings.  It is a commercially supported product that can also be downloaded for free.

Kaladix Linux : http://kaladix.linux-provider.net/ - A very promising distribtion still in development.  It comes with security related tools, firewall, and chrooted services.  It is based on LinuxFromScratch, and will appeal to the paranoid.

Astaro Security Linux:  http://www.astaro.com/ - A commercial distribution intended as a replacement for firewall appliances.  Comes with built in content filtering for viruses and IPsec based VPN.

The LNX System:  http://lnxs.org/ - A Sysadmin oriented distribution strivving to incorporate oft-overlooked features such as maintained and integrated security subsystems, and pro-actively-secure and audited code.

SuxOS:  http://www.suxos.org/ - A Free, fast, stable and secure Linux distribution which incorporates LIDS, Formatguard, and the grsecurity kernel.
 

The various other distributions of Linux vary little in the secureness of a default install, but all can be customized to the same high degree of security.   You should never rely on the default installation of any distribution for security.  The relative security of the most popular distributions is discussed in Kurt Siefried's Linux Administrator's Security Guide.  Also by the same author, is the Linux Distribution Security Report.

Although technically not Linuxes, OpenBSD and TrustedBSD deserve a mention.  Both are based on NetBSD and FreeBSD, respectively.  OpenBSD is a free Unix that has been designed with security in mind, and has been subject to very rigorous code auditing.   TrustedBSD is a suite of extensions to FreeBSD intended to make it compliant with the Orange Book B1 security standard.

2.5)  Once secured, how can I *keep* my box secure?

Security is a process, not a permanent state.  Once you've taken the initial steps to secure your box, you must  engage in regular maintenance to ensure that your box continues to remain secure.

To ensure continued security, regularly do the following:

Keep current with patches -  Keep current with your distribution's security updates, and patch on a regular basis.

Monitor Logfiles - Logfiles should be monitored regularly for anomalous events.  Monitoring with automated tools is acceptable (Sometimes even necessary!), provided you do a regular manual audit of logfiles as well.

Audit Password Strength - Run a password auditing tool such as John the Ripper  every month or so to check for insecure passwords.

Check your binaries - Regularly scan your system for trojaned or otherwise altered binaries using both an integrity checker, and a trojan scanner.

Check for Remote Vulnerabilities- Periodically run a current vulnerability scanner against your machine from another box, preferably one outside of your firewall.

3.1)  How do I set up a firewall under Linux?

If you are new to firewalls, you should first read the Firewalls FAQ, and the Linux Firewall and Proxy Server HOWTO.

To configure a Linux firewall, you will likely use the latest implementation of firewalling, called IPTables.  IPTables is a packet filter for kernels 2.4 and above. It is a tremendous improvement over IPChains and provides enhanced features such as stateful packet filtering, Network Address Translation, MAC Address filtering and much more.

For information on configuring and using an IPTables firewall, see:

Linux IPTables HOWTO:  http://www.linuxguruz.org/iptables/howto/iptables-HOWTO.html

Netfilter/IPTables home page:  http://netfilter.samba.org/

IPTables Tutorial:   http://people.unix-fu.org/andreasson/iptables-tutorial/iptables-tutorial.html

Dave Wreski's IPTables Primer:  http://www.linuxsecurity.com/feature_stories/kernel-netfilter.html

James Stephens' IPTables Tutorial:  http://www.cs.princeton.edu/~jns/security/iptables/

3.2)  Where can I get sample/custom firewall rules?

Creating a firewall from scratch can be daunting.  Thankfully, there are plenty of sample rules, as well as sites and utilities that will help you customize a ruleset for your own needs.  Those making use of automatically generated firewalls should use these firewalls as a base, make sure they understand them, and not blindly trust them.  That being said, here is a list of useful tools:

Sample IPTables rules:

3.3)  What is the best way to start-up my firewall at boot time?

There are many different ways to start your firewall, and your choice of method is often one of personal preference.   For most people, it should be adequate to keep thing simple, and initialize your firewall after your network devices come up, either via an init script, or with DHCP, which is covered in the next section.

Those serious about securing their box will want to remove the window of vulnerability between the network device and firewall initialization, and start a minimal, restrictive, pre-firewall before any network devices are brought up.

After the network devices are brought up successfully, the full firewall can be initialized.  To do so, have an init script execute a pre-firewall  just before networking is initialized.  The pre-firewall script could contain some simple and restrictive rules such as:

3.4)  How do I automatically start my firewall after leasing an IP via DHCP?

Pump and dhcpcd are common DHCP clients included with many linux distributions.   These clients obtain a dynamic IP address from a DHCP server, but also offer the added functionality of calling an external program as soon as an IP is successfully leased.  This ensures that the firewall is initialized as soon as the device is brought up.

Here is how to configure some common DHCP clients to call an external program after leasing an IP:

dhcpcd:

3.5)  How do I allow incoming UDP, such as CUseeMe or Battlenet through my masquerading firewall?

Ipchains will not allow remotely initiated udp transmissions to connect to internal hosts, for the main reason that it doesn't know which internal host the connection is for.  Thus, something called 'port forwarding' must come into play. Port forwarding works under the assumption that connections to a particular port are always destined to the same host, and automatically forwards all packets to a specified port on to a specified internal host.

To use port forwarding, you must download and install ipmasqadm, or ipautofw, depending on your kernel level.  Special kernel options must also be enabled during compilation in order to use port forwarding.  See the man pages for the respective commands to find out which particular kernel parameters are.  Below is listed the proper syntax for each of the port forwarding tools:

Battlenet:

IPTables:

/sbin/iptables -t nat -A PREROUTING -p TCP --dport 6112 -j DNAT --to-destination 10.0.0.2:6112
/sbin/iptables -t nat -A PREROUTING -p TCP --dport 6112 -j DNAT --to-destination 10.0.0.2:6112

IPChains:

3.6)  How can I firewall out banner advertising?

There are five different ways to block banner advertising from sites such as doubleclick.net, each with their own advantages and disadvantages:

Hacking your hostfile

3.7)  Should I reject incoming/outgoing pings?

3.8)  How can I track traffic volume going through my firewall?

3.9)   Why should I filter out outgoing X Windows sessions?

3a)  How does IPTables differ  from IPChains?

4.1)  What services should I run?

The ones you need, and only the ones you need. On a desktop system which you don't need to be able to access remotely, this would likely mean no services. If you do need to provide remote access of some type, only run the services necessary to provide the type of access you need. See section 5.7 for lists of common services, their port numbers, and their uses.

Consider running different services on different computers to the greatest extent practical, especially services of different levels of importance. For example, you probably don't want to use the same computer for your mission critical web server and your departmental shell server.

Note: You *don't* need to run a server in order to make outgoing connections of that type. For example, if you want to connect to another computer using SSh, you only need to run the SSh client on your end, not the server, sshd.  Same goes for Telnet and FTP, and all other services.

4.2)  What services should I *not* be running?

Any you don't need.  In particular, ensure you disable Sendmail, BIND, the "r"  services (rcp, rsh, rexec), and FTP/Telnet.  These services are enabled by default in many distributions, but should be disabled if you don't need them.

Other services that should be specifically disabled if you have no particular use for them:  echo, discard, finger, daytime, chargen, and gopher.

4.3)  How do I know what services I am running?

4.4)  How do I disable unnecessary services?

On older Linux releases, services are managed by inetd.  To disable inetd services, edit /etc/inetd.conf and comment out the unwanted services by placing a #  at the beginning of each line you wish disabled, and then restart inetd using the following command: kill -HUP  `pidof inetd`.

Newer Linux releases have replaced inetd with xinetd, which is slightly different to configure.  To disable an xinetd service, edit the file /etc/xinetd.conf and add the line disabled = <service> to the stanza titled "defaults"  here is an example of an xinetd configuration with ftp disabled:

defaults
{
        instances           = 60
        log_type            = SYSLOG authpriv
        log_on_success      = HOST PID
        log_on_failure      = HOST
        disabled            = ftp
}

If you are using a separate configuration file for each service, you can also disable the service by specifying so in the service-specific file.    Keeping with our ftp example, you would edit /etc/xinetd.d/wu-ftpd as follows:
 

service ftp
{
        disable = yes
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/in.ftpd
        server_args             = -l -a
        log_on_success          += DURATION USERID
        log_on_failure          += USERID
        nice                    = 10
}

 

Once you've disabled the desired service, don't forget to restart xinetd with : kill -HUP `pidof xinetd`

There are many unnecessary non-networking or non-inetd services, such as  lpd and linuxconf.  These can be disabled by reconfiguring Linux's startup scripts.  Each distribution differs slightly in the implementation of its startup scripts, but most distributions have a simple utility for modifying the startup scripts, such as 'ntsysv' in Redhat.
 
 

4.5)  What are tcpwrappers, and how do I configure them?

Tcpwrappers, or tcpd, runs as an intermediary between inetd and the service that inetd calls.  Tcpwrappers can be configured to filter, and/or log connections to each service.   When a connection is made to a particular port, inetd passes the request to tcpd, which checks existing rules (/etc/hosts.all, /etc/hosts.deny)  to see if the connection is allowed.  If it is, it passes the request on to the appropriate client daemon.  If the connection is disallowed, it is simply closed.

If you only use your Linux box from home, and don't need to connect to it remotely, it's advisable to deny all remote connections using the following configuration:

4.6)  Should I use Telnet and FTP for remote access?

In a word, No.  The problem with Telnet, FTP, and other non-encrypted protocols is that everything is sent across the network as plain text. This means that someone running a sniffing program on the network, which is very simple under many circumstances, can see all of your traffic - including your login and password.&nbssp; Consider replacing Telnet and FTP with SSh.

4.7)  Is there a more secure alternative to service <X>?

In these days of widespread packet sniffing, which is even taking place at ISPs, it's a good idea to move away from plain-text protocols to their encrypted replacements.  This is by no means a complete list of secure replacements, and is only a survey of the most common one.  It should be mentioned that a recently released sniffing tool has made it possible to sniff SSh/SSL sessions via a man-in-the-middle attack. See section 4.9 for more information.

4.8)  Is there a free SSh Client for MS Windows or Mac?

4.9)  But isn't SSh exploitable?

4.a)  What is Identd?  Can I disable it?

Identd service is an authentication service that identifies the owner of a specific TCP/IP connection to the remote server accepting the connection.  When a user connects to a remote host, inetd on the remote host sends back a query to port 113 asking "Who is the owner of that particular connection to me?", identd then replies back "username jsmith owns that process".

Identd should not be used as a method of authentication - anyone with root access can alter their identd response.  Indeed, on many systems (such as FreeBSD and Windows) even a non-privileged user can specify whatever identd response they want. The protocol is most useful on multiuser systems as a method of tracking down problem users. If one of your users is causing problems on another system, that system's administrator can inform you of the username of the specific user causing problems, saving you a lot of legwork.

Should you run identd? That's really a judgment call. On systems with many users, the benefits could be great, but it doesn't serve any particular purpose on a single user box.  In fact, running it means leaving a service open to the outside world, with all the security risks that entails. Another thing to consider is that identd can allow attackers to find out valuable information about your system, such as whether a certain service is running as root, the operating system you are running, and the usernames of your users. Consider running identd with the -n flag, which sends userid numbers instead of usernames. See the identd manpage and /etc/identd.conf for more information about the available options.

Impact of disabling identd:

1)  Remote hosts may have problems tracking attacks originating at your site down to specific users.   This is only significant if you have many users on your host.   Disabling identd on a multi-user system is not only bad sysadmin-etiquette, it will also make it difficult to track down problem users at your site.

2)  Some FTP and most IRC servers require that identd be running in order to authenticate remote users.  Disabling identd will limit the number of IRC and FTP servers that will accept your connections.   If you don't use IRC, this isn't really an issue either.

    You can block access to identd by commenting out the 'auth' line in /etc/inetd.conf, or by using tcpwrappers and/or firewalling software to disable/restrict access. If you need identd enabled in order to connect to a certain server, you might want to consider allowing access to it only from that server. If you do choose to firewall the identd port, strongly consider using a reject policy rather than deny. Using deny may greatly increase the time it takes you to connect to servers that utilize identd, as they will wait for a response of some type before allowing you to connect.

4.b)  What is xinetd, and how do I configure it?

5.1)  What is Intrusion Detection?

Intrusion detection is the ability to detect people trying to probe or compromise your system.  Intrusion detection is divided into two main categories, host based, and network based.   In simple terms, host based means that you are using a single host to monitor itself, and network based means you are using a host to monitor a complete network segment.  Most home Linux users will only be concerned with host-based Intrusion Detection Systems (IDS).

For more information on Intrusion Detection, check out:

Home Linux boxes are a prime target of computer hackers, as they are often not well secured, and once compromised they can be used as launching points for a more serious attacks.   Compromised boxes can also become DDoS amplifiers, warez servers, or spam relays, to name a few potential abuses.  The high bandwidth of cable/DSL connections is another attraction.

Users of cable or DSL modems are particularly vulnerable, since their extended connectivity time gives hackers a longer window within which to compromise their host.  It is also common for cable users to fall prey to amateur hackers known as "script kiddies" who run automated tools which scan entire subnets for a particular vulnerability.  Casting such a wide net, they are invariably successful in finding a few vulnerable hosts which they then use to compromise other hosts.

Your anonymity and obscurity do not ensure that your computer will not be targeted.

5.3) What Intrusion Detection systems exist for Linux?

There are many excellent Intrusion Detection Systems for Linux.  Here is are some of the more common ones:

Network and Host-based IDSs:

5.4)  How do I know if I've been compromised?

Sometimes, one just gets 'that feeling' that things aren't the way they should be, but you're uncertain where to begin looking for an intruder.

CERT has an excellent Intrusion Detection checklist to help you root out intruders.  It is located at:
http://www.cert.org/tech_tips/intruder_detection_checklist.html.
 
 

5.5)  I've been compromised, what should I do?

5.6)  I'm seeing repeated probes to port xxxx... What does this mean?

Here are some lists of port assignments:

5.7)  What is a 'Honeypot' ?

A Honeypot is a hardened host  that masquerades as a vulnerable host for the purposes of observing crackers, and learning how they operate.   The Honeypot host should be inviting enough to attract an attacker, but not so inviting as to arouse suspicion, and should extensively log attacker activities.

Be sure you know what you're doing before getting into this.  Compromised boxes are most often used to launch attacks against other boxes.  If you don't configure your system to be difficult to launch an attack from, and keep it under constant surveillance, you could very well end up contributing to the problem.  A Honeypot is a serious project, and should be treated as such.

Resources on creating a  Honeypot:

5.8)  I've been scanned by xxx.xxxx.xxx.xxx... Should I flood/hack/mailbomb him?

Most certainly not.  It's possible that this host has already been compromised, and you'd only end up venting on a fellow victim.  Instead, if possible, send a polite note to the Sysadmin of the box (if possible), and CC it to the abuse department of his service provider.  They are in a better position to determine the situation and address it appropriately.

To find out who is responsible for a given domain, use the command 'whois hostname.com' .  If you only have an IP, and no hostname, type:

6.1)   I've read all the docs, and made the suggested changes .. is my computer secure?

No, it's not.  It is both theoretically and practically impossible to completely secure a computer.   Never fall into the trap of believing you are invulnerable.  Remain ever vigilant, and regularly check your logfiles for anomalous activity.

That having been said, the goal is to make your computer secure enough to discourage casual attackers, and to slow down the more persistent attacks, allowing you time to identify and respond to them.

6.2)  My IP is xxx.xxx.xxx.xxx.  Can you test my security by hacking me?

6.3)  Are there any web based security scanners?

Yes, there are many, with more cropping up each day.  These are not only useful to test your security, but also to ensure that your IDS is doing its job.  Take the results of these scans with a grain of salt, and don't let them lull you into a false sense of security.

Here are the most popular security auditing tools for Linux::

6.4)  What vulnerability testing tools are available for Linux?

Here is a list of the most popular remote vulnerability testing tools for Linux.  You should use them against your own system, for you can be sure that others will.  For best results, try running these tools against your own computer from several locations both inside and outside of your firewall.  This will give you a better idea of what an attacker would see than just running it locally.

7.1)  Is Linux Vulnerable to viruses?

In a practical sense, no.  Technically...

Due to the design of Linux, it is difficult for viruses to spread far within a system, as they are confined to infecting the user space of  the user who executes them.  Of course, this is a problem if infected files are launched by root, but as a security conscious individual, you wouldn't be running untrusted files as root, would you?

It is theoretically possible for a virus launched by a regular user to escalate its privileges using system exploits; however, a virus with this capability would be quite sizable, and difficult to write.  As of this date, few viruses have actually been discovered for Linux, and the ones that have been discovered aren't worth losing sleep over.  This will undoubtedly change with time.

Viruses do exist for Linux, but at the present time are the least significant threat you face.  Presently, trojans and worms, which are explained in the following section, pose a greater threat to Linux users.

7.2)  What is a trojan?  What is a worm?

A trojan is a malicious program that masquerades as a legitimate application.  Unlike viruses, they do not self replicate, but instead, their primary purpose is (usually) to allow an attacker remote access to your computer or its resources.   Sometimes, users can be tricked into downloading and installing trojans onto their own computers, but more commonly, trojans are installed by an intruder to allow him future access to your box.

Trojans often come packaged as "root kits".  A "root kit" is a set of trojaned system applications to help mask a compromise and facilitate unauthorized remote access.  A root kit will usually include trojaned versions of ps, getty, passwd, tcp_wrappers, login, and syslogd.

A worm is a self-replicating, auto infecting program that spreads through computer networks.  Unlike a virus, a worm does not require user intervention to be activated.  Worms take advantage of vulnerabilities to propagate themselves across networks.  Once it has infected a machine, a worm may also install a DDOS zombie, a r00tkit to prevent detection, or a trojan to allow unauthorized remote access.  Many worms exist for Linux, including ADM, Ramen, and Lion.
 

7.3)  Are there virus scanners for Linux?

At this point in time, most virus Scanners for Linux are aimed at detecting and disinfecting data served to Windows hosts by a Linux file/mailserver.  This can be useful to help stop the spread of viruses among local, non-Unix machines.   Due to the lack of viruses for Linux, there are presently no scanners to detect viruses within the Linux OS, or its applications. Trojans present a greater threat to the Linux OS itself than do viruses, and can be detected by regularly verifying the integrity of your binaries, or by using a rootkitdetector.

Trojan Detectors:

7.4)  How can I verify the integrity of my binaries?

You can verify binary integrity with dedicated applications, or, if you are a redhat user, you can use RPM.

Integrity Checkers:

Tripwire:  http://www.tripwire.com/downloads/ - Tripwire protects against trojans by cchecking the integrity of your binaries, and alerting you if any binary's signature has changed.

AIDE:  http://www.cs.tut.fi/~rammer/aide.html -  AIDE (Advanced Intrusion Detectiion Environment) is a free replacement for Tripwire. It does the same things as the semi-free Tripwire and more.

FreeVeracity:  http://www.freeveracity.com/ - A newer, free integrity checker for frree Unixes, reputed to be very easy to setup and use.
 

RPM:

The Redhat Package Manager has the built-in capability of verifying binary integrity, which is useful for spot-checking suspicious files.   To show RPM-installed files whose MD5 checksum has changed since installation, use the following command:
  rpm -Va |grep '..5'

99.1)  Security updates for common Linux distributions

99.2)  Linux Security FAQs, HOWTOs, and other References

99.3)  Miscellaneous Linux security resources

99.4)  Linux specific Security web sites

99.5)  Linux related security websites

99.6) Other useful security resources:

99.7)  security Newsgroups

99.99)  Miscellaneous Contributors