TUCoPS :: Linux :: Discontinued :: colsfaq.htm

comp.os.linux.security FAQ
comp.os.linux.security FAQ

comp.os.linux.security FAQ

Version 2.0,  Released Canada Day, 2002.  Last updated June 29, 2002.

Creator and maintainer:  Daniel Swan

Table of Contents

1)  FAQ Administrativia

1.1)  Introduction to comp.os.linux.security
1.2)  Does comp.os.linux.security have a charter?
1.3)  What is covered in this FAQ?
1.4)  Who is responsible for this faq, and how can I contribute?
1.5)  Acknowledgments and contributions
1.6)  Feedback
1.7)  Disclaimer and Copyright

2)  General Linux Security

2.1)  How can I protect myself from hackers, quickly and easily?
2.2)  What is security?
2.3)  How secure should my Linux box be?
2.4)  Which is the most secure Linux distribution?
2.5)  Once secured, how can I *keep* my box secure?

3)  Firewalling and Masquerading

3.1)  How do I  set up a firewall under Linux?
3.2)  Where can I get sample IPTables rules?
3.3)  What is the best way to start-up my firewall at boot time?
3.4)  How do I automatically start my firewall after leasing an IP via DHCP?
3.5)  How do I allow incoming UDP, such as CUseeMe or Battlenet through my firewall?
3.6)  How can I firewall out banner advertising?
3.7)  How do 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?
3.a)  How is IPTables different than IPChains?

4)  Services

4.1)  What services should I run?
4.2)  What services should I not be running?
4.3)  How do I know what services I am running?
4.4)  How do I disable unnecessary services?
4.5)  What are tcpwrappers, and how do I use them?
4.6)  Should I use Telnet and FTP for remote access?
4.7)  Is there a more secure alternative to service <X>?
4.8)  Is there a free SSh Client for MS Windows or Mac?
4.9)  But hasn't SSh/SSL been cracked?
4.a)  What is Identd?  Can I disable it?
4.b)  What is xinetd, and how do I configure it?
4.c)  How do I secure service <X>?

5)  Intrusion Detection

5.1)  What is Intrusion Detection?
5.2)  But why would someone want to hack *my* computer?
5.3)  What Intrusion Detection programs exist for Linux?
5.4)  How do I determine if I've been compromised?
5.5)  I've been compromised, what should I do?
5.6)  I'm seeing repeated probes to port xxxx... What does this mean?
5.7)  What is a 'Honeypot' ?
5.8)  I've been scanned by xxx.xxx.xxx.xxx... Should I flood/hack/mailbomb him?

6)  Testing your security

6.1)  I've read all the docs, and made the suggested changes .. is my computer secure?
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?
6.4)  What vulnerability testing tools are available for Linux?

7)  Viruses and Trojans

7.1)  Is Linux vulnerable to viruses?
7.2)  Is there a virus scanner for Linux?
7.3)  What is a trojan?
7.4)  How can I verify the integrity of my binaries?

8)  Encryption

8.1)  What's PGP/GPG?
8.2)  How do I configure and use GPG?
8.3)  What GPG related utilities are available for Linux?
8.4)  How do I encrypt a filesystem?

9)  Miscellaneous

9.1)  Why can't I Telnet into my Linux box as root?
9.2)  Why am I seeing "-- Mark --" in my syslog?

99)  Appendices

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 websites
99.5)  Linux related security websites
99.6)  Other useful security resources
99.7)  Security Newsgroups
99.99)  Miscellaneous Contributors

1)  FAQ Administrativia

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?

  The newsgroup does have a charter.  We ask that you please abide by it when participating in comp.os.linux.security. The charter was written by the original newsgroup proponent Erik de Castro Lopo <erikd@zip.com.au>, in April 1999:  
"This newsgroup is dedicated to the discussion of issues related to establishing and maintaining the security of machines running the Linux Operating System on all processor architectures.

Open discussion of techniques and software for protecting machines against remote attacks (via a network connection) as well as attacks from untrusted local users are welcome. This discussion can include information about which applications are vulnerable, the form of the vulnerability and snippets of source code for demonstrating the vulnerability.

The posting of commercial information to this group is permitted only if the information is directly relevant to security and the Linux Operating System.

Messages which are cross-posted to or from any advocacy newsgroup are not welcome. As this is a discussion group, the posting [of] binaries is strongly discouraged. Spamming, ECP and EMP of any sort is absolutely not tolerated."

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
-Jan. 1, 2001:    Initial release of FAQ, version 1.0.
-Feb. 8, 2001:   Post-release suggestions and corrections completed. -> v1.1.
-Oct. 3, 2001:   Various links updated, minor cosmetic changes.  -> v1.2
-Oct 22, 2001:  Various link corruptions fixed.  A few faqs added.  -> v1.3
-June 1, 2001:   Overhaul, and addition IPTables and xinetd information. -> v2.0

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:
Jessica Luedtke, who co-authored section four (services), and made many useful suggestions.

Ravi Parimi, for contributing almost all IPTables-related updates.

Dave Wreski, for his support and for hosting this FAQ at linuxsecurity.com.

Recognition also goes to Joel Klammer, my best friend, deceased.

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.
This document is Copyright 2000/2001 by Daniel Swan. Permission is granted for it to be reproduced electronically on any system, so long as it is reproduced in its entirety, unedited, and with this copyright notice intact.  Commercial use is allowed, provided that I am notified beforehand.

2)  General Linux Security

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

In order of importance:
1.  Install the most recent security patches for your distribution.
2.  Turn off unused services, and tcpwrapper/xinetd the rest.
3.  If accessing your computer remotely, replace Telnet and Ftp with more secure equivalents.
4.  Maintain current backups (via a spare HD, tape drive, backup server, etc).
5.  Read the rest of this FAQ.
Do these simple things, and you'll have covered most of your bases.   If you still want to learn more about security, a couple of other recommended documents are the Linux Security HOWTO, and the Linux Administrator's Security Guide.  Familiarize yourself with these documents,  make use of their suggestions, and you're well on your way to being secure.
Also, see CERT Australia's Unix security checklist at http://www.bris.ac.uk/is/selfhelp/supportstaff/auscert_checklist.html.  It's a bit dated, but its step-by-step walkthrough of locking down a Unix box is nonetheless quite useful.
As well, reading and participating in comp.os.linux.security will assist in your understanding of the finer points, and also help you keep current with new developments.

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.
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)  Firewalling and Masquerading

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/

10 minutes to an IPTables-based Linux firewall:  http://www.linuxworld.com/site-stories/2001/0920.ipchains.html
Commercial firewalls available for Linux:
Listed below are commercial application-level firewalls for Linux.

Firewall-1 for Linux:  http://www.checkpoint.com/products/firewall-1/pbrief.html

Xsentry Internet Firewall:  http://www.trustix.com/products/xsentry/
Smoothwall:  http://www.smoothwall.org/ - A distribution designed to act specifiically as a firewall and dialup PPP server.

Phoenix Adaptive Firewall:  http://www.progressive-systems.com/products/phoenix/ - An enterprise-capable firewall appliannce.

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:
Sample IPChains, IPFWADM, and IPtables rules at Linuxdoc.org.

Sample scripts for iptables can be found at http://www.linuxguruz.org/iptables

Jomorris also has a very mature rc.firewall package available through freshmeat.

Endosheild:  http://endoshield.sourceforge.net/ - Easy to configure firewall script thatt works with both IPchains and IPtables.

Sample IPTables rules by David Whitmarsh - Well commented and easy to customize

Web-based rule generators:
Linux Firewall Design tool:  http://linux-firewall-tools.com/linux/firewall/index.html - A very nice way to configure a basic ffirewall.  It's fairly flexible in its configurability, and also offers instructions on installing the rules generated.
Rule generation utilities:
PMfirewall:  http://www.pointman.org/pmfirewall/ - PMFirewall is an IPchains Firewall andd Masquerading Configuration Utility for Linux that allows a beginner to build a custom firewall with little or no IPchains experience.
mason:  http://users.dhp.com/~whisper/mason/ -  "Mason is a tool that interactively builds a firewall using Linux' ipfwadm, IPchains, or IPtables firewalling. You leave mason running on the firewall machine while you are making all the kinds of connections that you want the firewall to support (and want it to block). Mason gives you a list of firewall rules that exactly allow and block those connections."
Nstreams:  http://www.hsc.fr/ressources/outils/nstreams/index.html.en - Nstreams analyzes the streams that occcur on a network, and  optionally generates the IPchains or ipfw rules that will match these streams, thus only allowing what is required for the users, and nothing more.

fBuilder Plus:  http://www.icewalkers.com/softlib/app/app_01535.html - Web-based frontend for IPTables.

Freshmeat:  http://freshmeat.net/search/?q=iptables+firewall - Freshmeat hosts scores of IPTables configuration utilities.

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:
/sbin/iptables -P INPUT         -j DROP
/sbin/iptables -P OUTPUT     -j DROP
/sbin/iptables -P FORWARD -j DROP
In Redhat, your pre-firewall could reside in /etc/rc.d/rc.pre-firewall, which would be symbolically linked to by /etc/rc.d/rc3.d/S9pre-firewall (assuming runlevel 3), which would execute just before /etc/rc.d/rc3.d/S10networking.   After the networking, /etc/rc.d/rc3.d/S11firewall (linked to /etc/rc.d/rc.firewall) would execute, fully initializing your firewall.  This example need not be followed to the detail, but is intended to conceptually outline a possible method to start your firewall.  You will have to familiarize yourself with the exact location of startup scripts for your particular distribution.

For more information on Linux startup scripts, see: http://www.linuxdoc.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO-6.html

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 can be instructed to call another script after leasing an IP, using the syntax "/etc/dhcpcd eth0 -c /etc/rc.d/rc.firewall'.  Make the appropriate changes to your network device initialization scripts to make the change permanent.
Upon execution, Pump reads the file /etc/pump.conf.  Within the file, you may specify a 'script' parameter, which points towards a script to execute upon the leasing, releasing, or renewal of an IP address.  Depending on the event occurring, different parameters are sent to the executable script.  See the Pump(8) man page for full details on the parameters.  Here's a sample /etc/pump.conf:
# sample /etc/pump.conf file
domainsearch "my.own.org own.org at.work.com"
retries 3
script /etc/rc.d/rc.firewall
device eth1 {

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:
/sbin/iptables -t nat -A PREROUTING -p TCP --dport 6112 -j DNAT --to-destination
/sbin/iptables -t nat -A PREROUTING -p TCP --dport 6112 -j DNAT --to-destination
/usr/sbin/ipmasqadm autofw -A -r tcp 6112 6112 -h
/usr/sbin/ipmasqadm autofw -A -r udp 6112 6112 -h
  /sbin/iptables -t nat -A PREROUTING -p TCP --dport 7648 -j DNAT --to-destination
/sbin/iptables -t nat -A PREROUTING -p TCP --dport 7649 -j DNAT --to-destination
/usr/sbin/ipmasqadm autofw -A -r tcp 7648 7649 -h
/usr/sbin/ipmasqadm autofw -A -r udp 7648 7649 -h
Other Services:  You get the idea...

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
Add the names of doubleclick servers to your hostfile, and point them towards (loopback) like this:    ad.doubleclick.net    ad.ca.doubleclick.net    ad.uk.doubleclick.net
etc, etc...
Although simple to implement, this may cause annoying delays due to timeouts, in which case another option should be considered.

For a complete list of advertiser hostnames to block, see the list of sources below.

Block ad sites with your firewall.
Blocking incoming traffic from doubleclick can cause troublesome delays, but a superior solution is to block the outgoing requests to doubleclick.net.


/sbin/iptables -A OUTPUT -o eth0 -d    -j DROP
/sbin/iptables -A OUTPUT -o eth0 -d    -j DROP
etc, etc...
/sbin/ipchains -A output -i eth0 -d -j REJECT
/sbin/ipchains -A output -i eth0 -d -j REJECT
etc, etc...
For a complete list of advertiser hostnames to block, see the list of sources below.

Use a filtering web proxy.

Junkbuster is an ad-blocking proxy available from:  http://www.junkbuster.com.
Doubleclick's 'opt out' program.
This doesn't really block ads, but should be mentioned for the purpose of clarification.  By registering with doubleclick to 'opt out', all you are doing is asking them not to track you via cookies, but does not prevent you from seeing advertising banners.  To find out more, see:  http://www.doubleclick.net/optout/default.asp.
Sources for lists of ad sites to block:

These lists can be easily converted to hostfile or firewall format using sed or awk.

Peter Lowe's list:  http://www.yoyo.org/~pgl/adservers/serverlist.php?format=plain&showintro=0

Earl Hood's list;  http://www.oac.uci.edu/indiv/ehood/gems/ad-blocking.html

AtMan's List:  http://www.ecst.csuchico.edu/~atman/spam/adblock.shtml

3.7)  Should I reject incoming/outgoing pings?

Incoming pings can present a danger, in that they can be used to detect your presence, map your firewall, or used to cause a denial of service.  For these reasons, pings should be rejected.  There seems to be a widespread, but fellatious, belief that denying incoming pings will render your host completely invisible to the outside world.  In a narrow sense, this is true, in that your server will no longer respond to pings, but it doesn't take into account other ports that may be open on your host that can still give you away.

Disabling pings will render you invisible to casual door-knockers and those doing a 'ping sweep', but it won't fool a serious portscan of your subnet.    It can't hurt too much to DENY incoming pings, but you should also ensure that other external services are disabled, and not filtered, as this would also alert an attacker that you are using a firewall.  Don't overestimate the benefits of this measure.

Ping requests are called echo requests, or ICMP type 8.  Incoming echo-requests and outgoing echo-replies can be disabled with IPTables using the following commands:

/sbin/iptables -I INPUT     -p icmp --icmp-type echo-request -d $EXTERNALIP  -j DROP
/sbin/iptables -I OUTPUT -p icmp --icmp-type echo-reply    -s $EXTERNALIP  -j DROP

Or, for those using IPChains:

/sbin/ipchains -I input -j DENY -p icmp -s echo-request -d $EXTERNALIP
/sbin/ipchains -I output -j DENY -p icmp -s $EXTERNALIP echo-reply -d

There are both pros and cons to disabling outgoing ping requests.   The ability to ping other hosts is indispensable to some, and if filtered, will hamper their ability to work.  On the other hand,  some trojans use outgoing pings to broadcast their presence back to their home server.  If you have no need to ping other hosts, it can't hurt to filter outgoing echo-requests, and incoming echo-replies with the following commands:

/sbin/iptables -I OUTPUT -p icmp --icmp-type echo-request -s $EXTERNALIP -j DROP
/sbin/iptables -I INPUT     -p icmp --icmp-type echo-reply    -d $EXTERNALIP -j DROP

Or, for those using IPChains:

/sbin/ipchains -I output -j DENY -p icmp -s echo-request -d $EXTERNALIP
/sbin/ipchains -I input -j DENY -p icmp -s echo-reply -d $EXTERNALIP
Other ICMP types that should be disabled to prevent denial of service attacks, are incoming redirect, and outgoing destination unreachable, or ICMP type 5, and ICMP type 3.  Disable them with the following commands:
  /sbin/iptables -I INPUT     -p icmp --icmp-type redirect                           -d $EXTERNALIP -j DROP
/sbin/iptables -I OUTPUT -p icmp --icmp-type destination-unreachable -s $EXTERNALIP -j DROP

Or, for those still using IPChains:

/sbin/ipchains -I input -j DENY -p icmp -s redirect -d $EXTERNALIP
/sbin/ipchains -I output -j DENY -p icmp -s destination-unreachable -d $EXTERNALIP
Don't filter other types of ICMP, for most are essential to normal network functionality..

In some instances,  blocking ICMP may break a server's ability to lease an address via DHCP.  If you find this to be the case, you may consider selectively allowing  ICMP from your ISP's IP block.

For more information, on ICMP, and the different ICMP types, see RCF 792: The Internet Control Message Protocol.

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

There are several packages out there, each varying in power and ease of configuration.  Here are some of the packages available:
  Multi Routing Traffic Grapher:  http://www.mrtg.org - MRTG is a tool to monitor the traffic load on network-links.  MRTG is based on Perl and C and generates HTML pages containing GIF images which provide a LIVE visual representation of this traffic.  MRTG is well suited to enterprise applications.

IPAC:  http://www.comlink.apc.org/~moritz/ipac.html - Ipac collects, summarizes, and nicely displays IP accounting data. The output of ipac can be a simple ASCII table, an ASCII graph, or even images with graphs showing traffic progression. ipac can be used for IP traffic analysis and for accounting purposes.

Traffic-vis:  http://www.mindrot.org/traffic-vis.html - traffic-vis is a suite of tools to hellp determine which hosts have been communicating on an IP network, with whom they have been communicating and the volume of communication taking place on a host by host basis. Reports can be generated in ASCII, HTML, Postscript, and include charts in GIF format.

UserIPacct:  http://rsmeyers.3ti.org/useripacct/ - UserIPacct is a fairly new package, buut looks interesting enough to mention.  UserIPacct adds per user IP accounting to the kernel via a kernel patch, and contains programs to control and use this accounting data.

IPtraf:  http://cebu.mozcom.com/riker/iptraf/ -   IPTraf is a console-based network statistics utility.  IPtraf gathers a variety of figures such as TCP connection packet and byte counts, interface statistics and activity indicators, TCP/UDP traffic breakdowns, and LAN station packet and byte counts.

IOG:  http://www.dynw.com/iog/ - IOG is a network traffic I/O Grapher mmade to graph cumulative KB/MB/GB totals for hours/days and months. It is intended to be simple and fast.

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

X-windows sessions can be used by an intruder to create a back-channel to their own machine.   Xterms are simple to launch using remote buffer overflow vulnerabilities, and should be disallowed to make things just that much more difficult for intruders.  Ideally, your firewall box should have all X-windowing packages and binaries removed to prevent this.   If it is not possible to disable this functionality, X-windows can still be blocked by at the firewall level.  Disable outgoing X-sessions using the following IPTables commands:
  /sbin/iptables -A OUTPUT -p tcp -s $EXTIP -o $EXTIF --dport 6000:6010  -j DROP
/sbin/iptables -A OUTPUT -p udp -s $EXTIP -o $EXTIF --dport 6000:6010  -j DROP

Or, for those using IPChains:

/sbin/ipchains -A output -j REJECT -i $EXTIF -p tcp -s $EXTIP -d 6000:6010
/sbin/ipchains -A output -j REJECT -i $EXTIF -p udp -s $EXTIP -d 6000:6010
Although blocking X-traffic at the firewall will defeat automated tools, this solution is easily overcome by the attacker reconfiguring his X-server to listen on non-standard ports.

3a)  How does IPTables differ  from IPChains?

There are many differences between iptables and ipchains. The most prominent of them are listed here:

Traversal of chains

In IPChains, all incoming packets pass through the input chain, irrespective of whether they are destined for the local machine or some other machine. Similarly, all outgoing packets are sent through the output chain, even if they are meant to be forwarded. iptables clearly classifies traffic into either the INPUT, OUTPUT or FORWARD chains, thus making packet filtering more efficient.

Connection tracking

This feature of IPTables is perhaps the most significant improvement over ipchains. iptables can keep track of all the aspects of a TCP/IP connection like destination and source IP addresses, port numbers associated, timeouts, retransmissions, TCP sequencing etc. Thus, spurious packets which do not belong to an existing connection are easily recognized and can be conveniently logged/dropped. This stateful firewalling is more powerful than the simple packet filtering provided by ipchains.

For an explanation of stateful packet filtering, see the SANS article "Anatomy of a Stateful Firewall".

New extensions

IPTables provides advanced features like rate-limited packet matching, filtering based on a combination of tcp flags, MAC addresses, user, group and process ids. Unlike IPChains, IPTables handles tasks such as NAT and packet mangling with separate modules. There are many differences between the two in terms of syntax as well. A few differences noted by Rusty Russell (the author of iptables) are at http://netfilter.samba.org/documentation/HOWTO//packet-filtering-HOWTO-10.html

Those migrating from IPChains to IPTables should read: "How does IPTables differ  from IPChains?"

4)  Services

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?

To get a list of all running processes, enter the command "ps auxw". You might also want to try using "ps auxf" (or "ps auxfw" if the lines get truncated) - this prints everything in a nice tree format that may give you a better understanding of how and why things are running.

To get a complete listing of all listening network services using netstat, enter:  netstat -altpu

You can also get similar information using lsof by entering: lsof -i | egrep -i 'LISTEN|UDP'

To get a "hackers-eye view" of what services you are running, use a port scanner such as Nmap.   Remember to port scan from outside of your firewall to get an accurate picture of what others see.

Be advised that port scanning hosts other than your own is not a good idea and may be treated seriously by a few system administrators.

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:

        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:
To deny all connections from all remote hosts, add the following line to /etc/hosts.deny:
To allow all connections from all local hosts, add the following line to /etc/hosts.allow:

For more information on configuring tcpwrappers, see http://www.cats.wright.edu/catsweb/ns/osxs_sec/tcpw_install.html.

Although it is possible to use tcpwrappers along with xinetd, it's generally unnecessary.  xinetd incorporates the logging and access control features of tcpwrappers.  If you still want to do so, see the following section of the xinetd FAQ: "Does xinetd support tcpwrappers?"

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.
Insecure Services and Their More Secure Replacements
 Insecure Secure 
Telnet SSh
http https
pop3 IMAP w/ SSL
rexec SSh
rsh SSh
Sendmail qmail


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

SSh clients for MS Windows:  
Putty:  http://www.chiark.greenend.org.uk/~sgtatham/putty/ - A popular open source Windows SSH Clieent.

PSCP:  http://www.chiark.greenend.org.uk/~sgtatham/putty/ - An Scp clone that allows secure file ttransfer via SSh.

TSSH:  http://www.zip.com.au/~roca/ttssh.html - An add-on for the terminal emulation pprogram TeraTerm Pro.

SSHWin:  ftp://ftp.ssh.org/pub/ssh/ - SSh2/Sftp Client from SSH Communicatioons Security.  Free for non-commercial use.

SecureCRT:  http://www.vandyke.com/products/securecrt/index.html - Not free, but worth mentioning.

SSh clients for Macintosh:
  NiftyTelnet w/ SSh:  http://www.lysator.liu.se/~jonasw/freeware/niftyssh/ - SSh enhanced version of NiftyTelnet.

MacSSh:  http://www.macssh.com/ - MacSSH is a modified version of BetterrTelnet with SSH2 support

4.9)  But isn't SSh exploitable?

A few versions of SSh are exploitable, but generally the releases of SSh have been quit solid.

That being said, SSh is far more secure than its plaintext counterparts.  Tools have been released to subvert SSh authentication, but these only take advantage of the mismanagement and misconfiguration of SSh.  As with any service, it is important that SSh is properly installed, configured, and managed, and that patchlevels are kept current.

 To learn more about SSh, see the following links:

The OpenSSh FAQ: http://www.openssh.com/faq.html
The SSh FAQ:  http://www.ssh.org/faq.html
Linux SSh tutorial:  http://www.linux.ie/articles/tutorials/ssh.php
Ten Risks of PKI:  http://www.counterpane.com/pki-risks.html

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?

xinetd, or the Extended Internet Services Daemon, is a next-generation replacement for inetd, the Internet Services Daemon.  xinetd provides greater flexibility in configuration and logging, along with TCPwrapper-like access control capabilities.   In addition to the main configuration file, /etc/xinetd.conf, there are service-specific configuration files located in the /etc/xinetd.d directory.  For more information, see the man pages for xinetd and xinetd.conf, as well as the following resouces:

The xinetd home page:  http://www.xinetd.org/

An Unofficial Xinetd Tutorial:  http://www.macsecurity.org/resources/xinetd/tutorial.shtml

Frédéric Raynal's article at linuxfocus.org: http://www.linuxfocus.org/English/November2000/article175.shtml


4.c)  How do I secure service <X>?

    Aside from general solutions such as xinetd and firewalling, each service has its own unique security requirements.  Where possible, you may consider using a secure replacement.

    There's not enough room in this FAQ to completely completely cover the securing of each service, but here are some pointers to information on securing some common Linux network services:


"Securing FTP" - Securing and Optimizing Redhat Linux:  http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap29sec301.html "Anonymous FTP Configuration Guidelines" - Cert:  http://www.eits.uga.edu/wsg/security/FTP/anonymous_ftp_config.html
Securing DNS - http://www.guides.sk/psionic/dns/dns-linux/
Securing DNS and BIND - http://www.linuxjournal.com/article.php?sid=4198
Security and Apache - http://www.linuxplanet.com/linuxplanet/tutorials/1527/1/
Security Tips for Apache Server - http://httpd.apache.org/docs/misc/security_tips.html
  Securing Sendmail - http://www.sendmail.net/000705securitygeneral.shtml
Securing Sendmail on Four Types of Systems - http://sendmail.net/000710securitytaxonomy.shtml
  There is an excellent section on securing various services in the "Securing Debian HOWTO":  http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html  

5) Intrusion Detection

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:
Robert Graham's Intrusion Detection FAQ: http://www.robertgraham.com/pubs/network-intrusion-detection.html
The SANS Institute's Intrusion Detection FAQ:  http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm

Intrusion Detection - Know when someone's knocking on your door: http://www.enteract.com/~lspitz/ids.html

Intrusion Detection Primer:  http://www.linuxsecurity.com/feature_stories/feature_story-8.html

5.2)  But why would someone want to hack *my* computer?

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:
Snort:  http://www.snort.org - Possibly the most popular Linux IDS.&nnbsp; Its free, highly customizable, and easy to use.  There are also many third party add-ons and utilities available for Snort.
Portsentry:  http://www.psionic.com/abacus/portsentry/ - Portsentry is a portscan detector withh the ability to automatically drop routes to attacking hosts, making your system inaccessible to them.
LIDS:  http://www.lids.org  - The Linux Intrusion Detection System iis a combination Intrusion Detection and hardening patch for the Linux kernel.

FireStorm: http://www.scaramanga.co.uk/firestorm/index.html - Fully featured, free, uses Snort ruless, and supports open standards.

Snare:  http://www.intersectalliance.com/projects/Snare/ - A loadable Kernel module which providees host intrusion detection and C2-style auditing/event logging.

rkdet:  http://vancouver-webpages.com/rkdet/ - An innoccuous daemon which sends out aalerts if a rootkit is installed.

Hostsentry:  http://www.psionic.com/products/hostsentry.html - A host based intrusion detection tool that performs Login Anomaly Detection .

For a further list of Intrusion detection tools and applications, see: http://www.whitehats.com/cgi/tools/BrowseTree?field=Category&separator=:&recurse=1&value=Intrusion%20Detection%3aNIDS.

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:

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

1.  Disconnect your computer from all networks.
2.  Remount filesystems as read-only to avoid changing timestamps.
3.  Copy logfiles to a floppy for later analysis.
4.  Verify your binaries using either Tripwire or RPM, save output to floppy.
5.  Analyze saved data to determine time and method of compromise.
6.  Restore system, either from scratch, or from guaranteed pre-compromise backup (you have backups, right?!).
7.  Post to c.o.l.s. and share your experience, along with relevant technical details that may help others a similar experience.
For a more in depth guide, see CERT's paper:  "Steps for Recovering from a UNIX or NT System Compromise", located at: http://www.cert.org/tech_tips/win-UNIX-system_compromise.html.

If information gathering is required for educational, legal, or reseach purposes, see AusCERT's article: "Collecting Electronic Evidence After a System Compromise": http://www.auscert.org.au/Information/Auscert_info/Papers/Collecting_Evidence_After_A_System_Compromise.html

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

Here are some lists of port assignments:
IANA Port Assignments :  http://www.isi.edu/in-notes/iana/assignments/port-numbers - "Official" port assignment from the Innternet Assigned Numbers Authority.
Port list at NetworkIce:  http://advice.networkice.com/advice/Exploits/Ports - List of ports and hyper linked explanaations that includes 'less standard' ports.
List of Trojans:  http://www.tlsecurity.net/trojanh.htm - The most complete list of trojan portss available.
Port Search Engine:  http://www.cotse.com/cgi-bin/port.cgi - Very nice search engine for ports, linnks results to relevant RFCs.
For a more in depth analysis of what you're seeing, see Robert Graham's Firewall forensics FAQ:   http://www.robertgraham.com/pubs/firewall-seen.html

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:
The SANS Institute's Intrusion Deception Faq: http://www.sans.org/newlook/resources/IDFAQ/honeypot.htm
Lance Spitzner's  "Honeypot Project": http://project.honeynet.org
The Deception Tool Kit:  http://www.all.net/dtk/dtk.html - Dummy services that send false responsses and log remote queries.

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:
Redhat Linux:   whois xxx.xxx.xxx.xxx@whois.arin.net
Other Linuxes:  whois -h arin.net xxx.xxx.xxx.xxx
Also, this is a good opportunity to discuss 'automated response' tools that will react offensively upon detecting a portscan.  This has the opportunity to get you in all sorts of trouble, including infinite loops leading to self-DoS, or even legal trouble.  It's about as wise as setting up bear traps in your own home, and is highly discouraged.
Do unto others...

6)  Testing your own Security

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?

Most certainly not!  This is an ethical no-man's-land, in which both parties put themselves at a considerable risk of legal liability.  Not to mention that it's an old gag to post someone else's IP, and encourage others to hack it.

If you truly require penetration testing, there are many commercial organizations who offer professional penetration testing services, although they can be costly.

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::

Hackerwhacker :  http://www.hackerwhacker.com  - Services, Ports, Samba, etc.  A wwell rounded scanner.
Shields Up:  http://www.grc.com - Also known as "Shields Up".  Basiic testing, but easy to use.
Privacy.net:  http://privacy.net/analyze - Not exactly a scanner, but shows you wwhat information you give out as you surf.  A worthwhile look.
Secure-Me:  http://www.secure-me.net/ - A very busy remote port scanner.

Security Space:  https://secure1.securityspace.com/smysecure/basic_index.html#run - A nessus-based web scanner.  Regiistration gets you a basic scan, but there's a fee for more intensive scans.

Sygate Online Services:  http://scan.sygatetech.com/ - A fairly simple scan that also checks for Samba information leakage.

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.
Nmap:  http://www.insecure.org/nmap - A very powerful port scanner that doess stealth scans and OS fingerprints, to mention a few of its features.  Undoubtedly the best in its class, with lots of third-party addons available.
SAINT:  http://www.wwdsi.com/saint/index.html - A next generation version of SATAN.&nbbsp; Well rounded and thorough.
SARA:  http://www-arc.com/sara/ - A third generation auditing tool basedd on SATAN.
Nessus:  http://www.nessus.org/intro.html - A client/server vulnerability scanner..  Also well rounded and thorough.
Cybercop Scanner: http://www.pgp.com/products/cybercop-scanner/default.asp  - A commercial scanner with demo availabble.
Net IQ Security Analyzer:  http://www.netiq.com/products/sa/default.asp - Another commercial scanner with a demoo available.
An honorable mention also goes out to some old-timers to which today's security scanners owe a great debt:  SATAN, COPS, and Tiger.

7)  Viruses and Trojans

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:
Chkrootkit:  http://www.chkrootkit.org/ - Checks Linux system for evidence of haaving been rootkitted.
Root Kit Detector:  http://www.vancouver-webpages.com/rkdet/ - A daemon that alerts you if someone atttempts to rootkit you.

Rkscan: http://www.hsc.fr/ressources/outils/rkscan/index.html.en - Rkscan detects rootkits packaged as Looadable Kernel Modules.

Carbonite:  http://www.foundstone.com/knowledge/proddesc/carbonite.html - A Loadable Kernel Module which lists pprocesses at the Kernel level,

Virus Scanners for Linux File Servers:

AMaViS:  http://www.amavis.org/amavis.html - A sendmail plugin that scans incoming mail for viruses.
AntiVir for Linux:  http://www.hbedv.com/ - Scans incoming mail and ftp for virusees.
Interscan Viruswall: http://www.antivirus.com/products/isvw/ - A Firewall-1 add-on that scans ftp, htttp, and smtp for  viruses.
Sophos AntiVirus:  http://www.sophos.com/products/antivirus/savunix.html - Checks shares, mail attachments, ftp, etc for viruses.
Network Associates:  http://www.nai.com/international/uk/asp_set/buy_try/try/product_evals.asp - Scanner for Unix/Linux (demo).
The Anomy e-mail sanitizer:  http://mailtools.anomy.net/ - An email scanner that strives to emboddy best features of similar products.

Bitdefender:  http://www.bitdefender.com/html/bd_linux.php -

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.


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'

8)  Encryption

8.1)  What's PGP, OPENPGP, and GPG?

PGP, short for "Pretty Good Privacy",  is an encryption tool that used public and private key pairs to encrypt communications.  Although it is very flexible in its applications, it is primarily used for email and file encryption.

PGP was developed and released by Philip Zimmerman in 1991, and eventually founded PGP, Inc.  In 1996 PGP, Inc. was acquired by Network Associates in 1997, who eventually ceased developing and supporting the product.

Also in 1997, the OpenPGP Working Group was formed to develop an open Inernet encryption standard based upon PGP.   Their Standard, released a year later, became the standard upon which GPG is based.

GPG, short for "Gnu Privacy Guard", is the latest incarnation of PGP, and  is the most popular implementation of PGP among with Linux community.

To learn more about PGP, its background, and its various permutations, see:

A Newcomer's Introduction to PGP:  http://www.mindspring.com/~aegreene/pgp/

8.2)  How do I use GPG?

Ensure that you are comfortable with the ins and outs of using GPG before you use it to encrypt anything critical.  Improper use of GPG can result in data that can be easily decrypted.

The following primers are recommended to learn more about GPG:

The GNU Privacy Guard HandBook:   http://www.gnupg.org/gph/en/manual.html

PGP/GPG basics;  http://www.aplawrence.com/Basics/gpg.html

An Introduction to GNU Privacy Guard:  http://www.linuxsecurity.com/feature_stories/feature_story-10.html

8.3)  What PGP/GPG related ultilities are available?

There are many GPG related utilities available, including graphical front ends, key managers, and GPG interfaces to other applications.
Tools at GnuPG.org:  http://www.gnupg.org/tools.html

Tools at Sourceforce:  http://sourceforge.net/search/?type=soft&exact=&q=gpg

Tools at Freshmeat:  http://freshmeat.net/search/?q=gpg&section=projects

8.4)  How do I encrypt a filesystem?

Filesystems can be encrypted to further secure data from prying eyes.  There are many different methods available to encrypt filesystems, which are covered in the links below.  For best results, all filesystems should be encrypted, including swap and root.

Useful Resources on Filesystem Encryption:

StegFS - A Steganographic File System for Linux:  http://www.mcdonald.org.uk/StegFS/

The Linux Encryption Howto:  http://encryptionhowto.sourceforge.net/Encryption-HOWTO.html

Linux Tips - Filesystem Encryption Methods:  http://www.linuxsecurity.com/tips/tip-15.html

9)  Miscellaneous

9.1)  Why can't I telnet into my Linux box as root?

By default, some distributions prohibit root from logging in remotely, unless you first log in as a regular user, and then "su" to root.  This feature provides an extra layer of security in case the password of the root account is compromised.

Although it is not recommended, this restriction can be removed by deleting the file /etc/securetty.  For more information, type "man securetty".

9.2)  Why am I seeing "-- Mark --" in my syslog?

This is a timestamp which is automatically generated by syslogd, and is syslogd's way of stating that it has nothing to report.  The default interval between two -- MARK -- lines is 20 minutes.

This can be changed by locating the syslodg startup script, and changing the parmeter after the "-m" option to suit your needs.  To disable these timestamps completely, set "-m" to 0.  For more information, type "man syslogd".


99)  Appendices

99.1)  Security updates for common Linux distributions

  Redhat: http://www.redhat.com/support/errata/index.html

Mandrake:  http://www.linux-mandrake.com/en/updates/

Suse:  http://www.suse.com/us/support/download/updates/

Debian:  http://www.debian.org/security/

Slackware:  Information on Slackware security updates are only released via their mailing list.  See http://www.slackware.org/lists for details.

Caldera:  http://www.caldera.com/support/security/

TurboLinux:  http://www.turbolinux.com/security/


99.2)  Linux Security FAQs, HOWTOs, and other References

The Linux Security HOWTO:   http://www.linuxsecurity.com/docs/LDP/Security-HOWTO.html

The Linux Administration FAQ:  http://www.kalug.lug.net/linux-admin-FAQ/

The Linux Administrators Security Guide:  http://www.seifried.org/lasg/

The Secure Programming for Linux and Unix HOWTO: http://www.dwheeler.com/secure-programs

The Suse Security Faq:  http://www.susesecurity.com/faq/

99.3)  Miscellaneous Linux security resources

Here's a list of odds and ends well worth looking at:

The Linux Security Quick Reference Card:  http://www.linuxsecurity.com/docs/QuickRefCard.pdf

Advisories for all Linux distributions:  http://www.linuxsecurity.com/advisories/

Linux Security Mailing Lists:  http://www.linuxsecurity.com/general/mailinglists.html

Securing and Optimizing Linux: Redhat Editon:  http://www.linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/

Securing Your Linux System 101:  http://userpages.umbc.edu/~jjasen1/unix/linux.html

Linux Security Configuration Document: http://www.intersectalliance.com/projects/LinuxConfig/index.html


99.4)  Linux specific Security web sites

The Linux Security Homepage: http://www.linuxsecurity.com/

The Linux Firewall and Security Site:  http://www.linux-firewall-tools.com/linux/

David Ranch's Site:  http://www.ecst.csuchico.edu/~dranch/LINUX

The Suse Security Site:  http://www.susesecurity.com/faq/

99.5)  Linux related security websites

Infosec:  http://www.infosyssec.net/ - "The Security Portal for Information SSystem Security Professionals".

SecurityFocus: http://www.securityfocus.net/unix - A very high-fibre news and discussion site.

Lance Spitzner's site:  http://www.enteract.com/~lspitz/ - Some great publications, white papers,, and articles.

Robert Graham's site:  http://www.robertgraham.com/ - Security news, and a pointer to Robertt's excellent infosec FAQs.

Packetstorm:  http://packetstormsecurity.org/ - Linux/Unix security news sprinkled witth some windows.

CERT:  http://www.cert.org/ - A federally funded computer security RR+D center operated by Carnegie Mellon University.

Whitehats:  http://www.whitehats.com/ - "...empowering network and system admiinistrators with the knowledge and tools required to defend their networks in an ongoing struggle against irresponsible or malevolent attack."

LSec:  http://www.linux-sec.net/ - A site with tons of great links to Linnux security resources.

99.6) Other useful security resources:

The Internet Engineering Task Force's Site Security Handbook: http://www.ietf.org/rfc/rfc2196.txt   The Internet Engineering Task Force's Users' Security Handbook:

99.7)  security Newsgroups

Newsgroups are essential to keeping current on, and learning more about, computer security.  There are many security related newsgroups, but here's a list of the ones that Linux users will also find useful.

comp.os.linux.security:  The newsgroup this faq is from.  Focus is on security as it pertains to Linux.

comp.security.announce:  A low-traffic group that carries the CERT advisories as they are announced.

comp.security.unix:   A fairly high traffic group dealing with security as it pertains to all flavors of Unix.

comp.security.firewalls:  Discussions relating to firewalls.

comp.security.misc:  Discussions relating to general computer security.

99.99)  Miscellaneous Contributors

Credit for error spotting, suggestions for subject matter, constructive picking of nits, and other miscellaneous contributions:
Cliff Rayman   Scott Bronson  

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH