This is Security-HOWTO.info, produced by makeinfo version 4.0b from /tmp/sgml-tools-dir-18269/sgmltmp.Security-HOWTO18269.info.2. \input texinfo  File: Security-HOWTO.info, Node: System services and tcp[lowbar]wrappers, Next: Verify Your DNS Information, Prev: Packet Sniffers, Up: Network Security System services and tcp[lowbar]wrappers ======================================= Before you put your Linux system on `ANY' network the first thing to look at is what services you need to offer. Services that you do not need to offer should be disabled so that you have one less thing to worry about and attackers have one less place to look for a hole. There are a number of ways to disable services under Linux. You can look at your `/etc/inetd.conf' file and see what services are being offered by your `inetd'. Disable any that you do not need by commenting them out (`[num ]' at the beginning of the line), and then sending your inetd process a SIGHUP. You can also remove (or comment out) services in your `/etc/services' file. This will mean that local clients will also be unable to find the service (i.e., if you remove `ftp', and try and ftp to a remote site from that machine it will fail with an "unknown service" message). It's usually not worth the trouble to remove services from `/etc/services', since it provides no additional security. If a local person wanted to use `ftp' even though you had commented it out, they would make their own client that used the common FTP port and would still work fine. Some of the services you might want to leave enabled are: * `ftp' * `telnet' (or `ssh') * mail, such as `pop-3' or `imap' * `identd' If you know you are not going to use some particular package, you can also delete it entirely. `rpm -e `packagename" under the Red Hat distribution will erase an entire package. Under Debian `dpkg -remove' does the same thing. Additionally, you really want to disable the rsh/rlogin/rcp utilities, including login (used by `rlogin'), shell (used by `rcp'), and exec (used by `rsh') from being started in `/etc/inetd.conf'. These protocols are extremely insecure and have been the cause of exploits in the past. You should check `/etc/rc.d/rc[0-9].d' (on Red Hat; `/etc/rc[0-9].d' on Debian), and see if any of the servers started in those directories are not needed. The files in those directories are actually symbolic links to files in the directory `/etc/rc.d/init.d' (on Red Hat; `/etc/init.d' on Debian). Renaming the files in the `init.d' directory disables all the symbolic links that point to that file. If you only wish to disable a service for a particular run level, rename the appropriate symbolic link by replacing the upper-case `S' with a lower-case `s', like this: root# cd /etc/rc6.d root# mv S45dhcpd s45dhcpd If you have BSD-style `rc' files, you will want to check `/etc/rc*' for programs you don't need. Most Linux distributions ship with tcp[lowbar]wrappers "wrapping" all your TCP services. A tcp[lowbar]wrapper (`tcpd') is invoked from `inetd' instead of the real server. `tcpd' then checks the host that is requesting the service, and either executes the real server, or denies access from that host. `tcpd' allows you to restrict access to your TCP services. You should make a `/etc/hosts.allow' and add in only those hosts that need to have access to your machine's services. If you are a home dial up user, we suggest you deny ALL. `tcpd' also logs failed attempts to access services, so this can alert you if you are under attack. If you add new services, you should be sure to configure them to use tcp[lowbar]wrappers if they are TCP-based. For example, a normal dial-up user can prevent outsiders from connecting to his machine, yet still have the ability to retrieve mail, and make network connections to the Internet. To do this, you might add the following to your `/etc/hosts.allow': ALL: 127. And of course /etc/hosts.deny would contain: ALL: ALL which will prevent external connections to your machine, yet still allow you from the inside to connect to servers on the Internet. Keep in mind that tcp[lowbar]wrappers only protects services executed from `inetd', and a select few others. There very well may be other services running on your machine. You can use `netstat -ta' to find a list of all the services your machine is offering.  File: Security-HOWTO.info, Node: Verify Your DNS Information, Next: identd, Prev: System services and tcp[lowbar]wrappers, Up: Network Security Verify Your DNS Information =========================== Keeping up-to-date DNS information about all hosts on your network can help to increase security. If an unauthorized host becomes connected to your network, you can recognize it by its lack of a DNS entry. Many services can be configured to not accept connections from hosts that do not have valid DNS entries.  File: Security-HOWTO.info, Node: identd, Next: Configuring and Securing the Postfix MTA, Prev: Verify Your DNS Information, Up: Network Security identd ====== `identd' is a small program that typically runs out of your `inetd' server. It keeps track of what user is running what TCP service, and then reports this to whoever requests it. Many people misunderstand the usefulness of `identd', and so disable it or block all off site requests for it. `identd' is not there to help out remote sites. There is no way of knowing if the data you get from the remote `identd' is correct or not. There is no authentication in `identd' requests. Why would you want to run it then? Because it helps `you' out, and is another data-point in tracking. If your `identd' is un compromised, then you know it's telling remote sites the user-name or uid of people using TCP services. If the admin at a remote site comes back to you and tells you user so-and-so was trying to hack into their site, you can easily take action against that user. If you are not running `identd', you will have to look at lots and lots of logs, figure out who was on at the time, and in general take a lot more time to track down the user. The `identd' that ships with most distributions is more configurable than many people think. You can disable it for specific users (they can make a `.noident' file), you can log all `identd' requests (We recommend it), you can even have identd return a uid instead of a user name or even NO-USER.  File: Security-HOWTO.info, Node: Configuring and Securing the Postfix MTA, Next: SATAN ISS and Other Network Scanners, Prev: identd, Up: Network Security Configuring and Securing the Postfix MTA ======================================== The Postfix mail server was written by Wietse Venema, author of Postfix and several other staple Internet security products, as an "attempt to provide an alternative to the widely-used Sendmail program. Postfix attempts to be fast, easy to administer, and hopefully secure, while at the same time being sendmail compatible enough to not upset your users." Further information on postfix can be found at the Postfix home and in the Configuring and Securing Postfix.  File: Security-HOWTO.info, Node: SATAN ISS and Other Network Scanners, Next: sendmail qmail and MTA's, Prev: Configuring and Securing the Postfix MTA, Up: Network Security SATAN ISS and Other Network Scanners ==================================== There are a number of different software packages out there that do port and service-based scanning of machines or networks. SATAN, ISS, SAINT, and Nessus are some of the more well-known ones. This software connects to the target machine (or all the target machines on a network) on all the ports they can, and try to determine what service is running there. Based on this information, you can tell if the machine is vulnerable to a specific exploit on that server. SATAN (Security Administrator's Tool for Analyzing Networks) is a port scanner with a web interface. It can be configured to do light, medium, or strong checks on a machine or a network of machines. It's a good idea to get SATAN and scan your machine or network, and fix the problems it finds. Make sure you get the copy of SATAN from metalab or a reputable FTP or web site. There was a Trojan copy of SATAN that was distributed out on the net. http://www.trouble.org/~zen/satan/satan.html. Note that SATAN has not been updated in quite a while, and some of the other tools below might do a better job. ISS (Internet Security Scanner) is another port-based scanner. It is faster than Satan, and thus might be better for large networks. However, SATAN tends to provide more information. Abacus is a suite of tools to provide host-based security and intrusion detection. Look at it's home page on the web for more information. http://www.psionic.com/abacus/ SAINT is a updated version of SATAN. It is web-based and has many more up-to-date tests than SATAN. You can find out more about it at: http://www.wwdsi.com/~saint Nessus is a free security scanner. It has a GTK graphical interface for ease of use. It is also designed with a very nice plug in setup for new port-scanning tests. For more information, take a look at: http://www.nessus.org * Menu: * Detecting Port Scans::  File: Security-HOWTO.info, Node: Detecting Port Scans, Up: SATAN ISS and Other Network Scanners Detecting Port Scans -------------------- There are some tools designed to alert you to probes by SATAN and ISS and other scanning software. However, if you liberally use tcp[lowbar]wrappers, and look over your log files regularly, you should be able to notice such probes. Even on the lowest setting, SATAN still leaves traces in the logs on a stock Red Hat system. There are also "stealth" port scanners. A packet with the TCP ACK bit set (as is done with established connections) will likely get through a packet-filtering firewall. The returned RST packet from a port that `[lowbar]had no established session[lowbar]' can be taken as proof of life on that port. I don't think TCP wrappers will detect this. You might also look at SNORT, which is a free IDS (Intrusion Detection System), which can detect other network intrusions. http://www.snort.org  File: Security-HOWTO.info, Node: sendmail qmail and MTA's, Next: Denial of Service Attacks, Prev: SATAN ISS and Other Network Scanners, Up: Network Security sendmail qmail and MTA's ======================== One of the most important services you can provide is a mail server. Unfortunately, it is also one of the most vulnerable to attack, simply due to the number of tasks it must perform and the privileges it typically needs. If you are using `sendmail' it is very important to keep up on current versions. `sendmail' has a long long history of security exploits. Always make sure you are running the most recent version from http://www.sendmail.org. Keep in mind that sendmail does not have to be running in order for you to send mail. If you are a home user, you can disable sendmail entirely, and simply use your mail client to send mail. You might also choose to remove the "-bd" flag from the sendmail startup file, thereby disabling incoming requests for mail. In other words, you can execute sendmail from your startup script using the following instead: # /usr/lib/sendmail -q15m This will cause sendmail to flush the mail queue every fifteen minutes for any messages that could not be successfully delivered on the first attempt. Many administrators choose not to use sendmail, and instead choose one of the other mail transport agents. You might consider switching over to `qmail'. `qmail' was designed with security in mind from the ground up. It's fast, stable, and secure. Qmail can be found at http://www.qmail.org In direct competition to qmail is "postfix", written by Wietse Venema, the author of tcp[lowbar]wrappers and other security tools. Formerly called vmailer, and sponsored by IBM, this is also a mail transport agent written from the ground up with security in mind. You can find more information about postfix at http://www.postfix.org  File: Security-HOWTO.info, Node: Denial of Service Attacks, Next: NFS (Network File System) Security-, Prev: sendmail qmail and MTA's, Up: Network Security Denial of Service Attacks ========================= A "Denial of Service" (DoS) attack is one where the attacker tries to make some resource too busy to answer legitimate requests, or to deny legitimate users access to your machine. Denial of service attacks have increased greatly in recent years. Some of the more popular and recent ones are listed below. Note that new ones show up all the time, so this is just a few examples. Read the Linux security lists and the bugtraq list and archives for more current information. * `SYN Flooding' - SYN flooding is a network denial of service attack. It takes advantage of a "loophole" in the way TCP connections are created. The newer Linux kernels (2.0.30 and up) have several configurable options to prevent SYN flood attacks from denying people access to your machine or services. See *Note Kernel Security:: for proper kernel protection options. * `Pentium "F00F" Bug' - It was recently discovered that a series of assembly codes sent to a genuine Intel Pentium processor would reboot the machine. This affects every machine with a Pentium processor (not clones, not Pentium Pro or PII), no matter what operating system it's running. Linux kernels 2.0.32 and up contain a work around for this bug, preventing it from locking your machine. Kernel 2.0.33 has an improved version of the kernel fix, and is suggested over 2.0.32. If you are running on a Pentium, you should upgrade now! * `Ping Flooding' - Ping flooding is a simple brute-force denial of service attack. The attacker sends a "flood" of ICMP packets to your machine. If they are doing this from a host with better bandwidth than yours, your machine will be unable to send anything on the network. A variation on this attack, called "smurfing", sends ICMP packets to a host with `your' machine's return IP, allowing them to flood you less detectably. You can find more information about the "smurf" attack at http://www.quadrunner.com/~chuegen/smurf.txt If you are ever under a ping flood attack, use a tool like `tcpdump' to determine where the packets are coming from (or appear to be coming from), then contact your provider with this information. Ping floods can most easily be stopped at the router level or by using a firewall. * `Ping o' Death' - The Ping o' Death attack sends ICMP ECHO REQUEST packets that are too large to fit in the kernel data structures intended to store them. Because sending a single, large (65,510 bytes) "ping" packet to many systems will cause them to hang or even crash, this problem was quickly dubbed the "Ping o' Death." This one has long been fixed, and is no longer anything to worry about. * `Teardrop / New Tear' - One of the most recent exploits involves a bug present in the IP fragmentation code on Linux and Windows platforms. It is fixed in kernel version 2.0.33, and does not require selecting any kernel compile-time options to utilize the fix. Linux is apparently not vulnerable to the "newtear" exploit. You can find code for most exploits, and a more in-depth description of how they work, at http://www.rootshell.com using their search engine.  File: Security-HOWTO.info, Node: NFS (Network File System) Security-, Next: NIS (Network Information Service) (formerly YP)-, Prev: Denial of Service Attacks, Up: Network Security NFS (Network File System) Security- =================================== NFS is a very widely-used file sharing protocol. It allows servers running `nfsd' and `mountd' to "export" entire file systems to other machines using NFS filesystem support built in to their kernels (or some other client support if they are not Linux machines). `mountd' keeps track of mounted file systems in `/etc/mtab', and can display them with `showmount'. Many sites use NFS to serve home directories to users, so that no matter what machine in the cluster they login to, they will have all their home files. There is some small amount of security allowed in exporting file systems. You can make your `nfsd' map the remote root user (uid=0) to the `nobody' user, denying them total access to the files exported. However, since individual users have access to their own (or at least the same uid) files, the remote root user can login or `su' to their account and have total access to their files. This is only a small hindrance to an attacker that has access to mount your remote file systems. If you must use NFS, make sure you export to only those machines that you really need to. Never export your entire root directory; export only directories you need to export. See the NFS HOWTO for more information on NFS, available at http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html  File: Security-HOWTO.info, Node: NIS (Network Information Service) (formerly YP)-, Next: Firewalls, Prev: NFS (Network File System) Security-, Up: Network Security NIS (Network Information Service) (formerly YP)- ================================================ Network Information service (formerly YP) is a means of distributing information to a group of machines. The NIS master holds the information tables and converts them into NIS map files. These maps are then served over the network, allowing NIS client machines to get login, password, home directory and shell information (all the information in a standard `/etc/passwd' file). This allows users to change their password once and have it take effect on all the machines in the NIS domain. NIS is not at all secure. It was never meant to be. It was meant to be handy and useful. Anyone that can guess the name of your NIS domain (anywhere on the net) can get a copy of your passwd file, and use "crack" and "John the Ripper" against your users' passwords. Also, it is possible to spoof NIS and do all sorts of nasty tricks. If you must use NIS, make sure you are aware of the dangers. There is a much more secure replacement for NIS, called NIS+. Check out the NIS HOWTO for more information: http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html  File: Security-HOWTO.info, Node: Firewalls, Next: IP Chains - Linux Kernel 2-2-x Firewalling, Prev: NIS (Network Information Service) (formerly YP)-, Up: Network Security Firewalls ========= Firewalls are a means of controlling what information is allowed into and out of your local network. Typically the firewall host is connected to the Internet and your local LAN, and the only access from your LAN to the Internet is through the firewall. This way the firewall can control what passes back and forth from the Internet and your LAN. There are a number of types of firewalls and methods of setting them up. Linux machines make pretty good firewalls. Firewall code can be built right into 2.0 and higher kernels. The user-space tools `ipfwadm' for 2.0 kernels and `ipchains' for 2.2 kernels, allows you to change, on the fly, the types of network traffic you allow. You can also log particular types of network traffic. Firewalls are a very useful and important technique in securing your network. However, never think that because you have a firewall, you don't need to secure the machines behind it. This is a fatal mistake. Check out the very good `Firewall-HOWTO' at your latest metalab archive for more information on firewalls and Linux. http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html More information can also be found in the IP-Masquerade mini-howto: http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html More information on `ipfwadm' (the tool that lets you change settings on your firewall, can be found at it's home page: http://www.xos.nl/linux/ipfwadm/ If you have no experience with firewalls, and plan to set up one for more than just a simple security policy, the Firewalls book by O'Reilly and Associates or other online firewall document is mandatory reading. Check out http://www.ora.com for more information. The National Institute of Standards and Technology have put together an excellent document on firewalls. Although dated 1995, it is still quite good. You can find it at http://csrc.nist.gov/nistpubs/800-10/main.html. Also of interest: * The Freefire Project - a list of freely-available firewall tools, available at http://sites.inka.de/sites/lina/freefire-l/index_en.html * SunWorld Firewall Design - written by the authors of the O'Reilly book, this provides a rough introduction to the different firewall types. It's available at http://www.sunworld.com/swol-01-1996/swol-01-firewall.html * Mason - the automated firewall builder for Linux. This is a firewall script that learns as you do the things you need to do on your network! More info at: http://www.pobox.com/~wstearns/mason/  File: Security-HOWTO.info, Node: IP Chains - Linux Kernel 2-2-x Firewalling, Next: Netfilter - Linux Kernel 2-4-x Firewalling, Prev: Firewalls, Up: Network Security IP Chains - Linux Kernel 2-2-x Firewalling ========================================== Linux IP Firewalling Chains is an update to the 2.0 Linux firewalling code for the 2.2 kernel. It has many more features than previous implementations, including: * More flexible packet manipulations * More complex accounting * Simple policy changes possible atomically * Fragments can be explicitly blocked, denied, etc. * Logs suspicious packets. * Can handle protocols other than ICMP/TCP/UDP. If you are currently using `ipfwadm' on your 2.0 kernel, there are scripts available to convert the `ipfwadm' command format to the format `ipchains' uses. Be sure to read the IP Chains HOWTO for further information. It is available at http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html  File: Security-HOWTO.info, Node: Netfilter - Linux Kernel 2-4-x Firewalling, Next: VPNs - Virtual Private Networks, Prev: IP Chains - Linux Kernel 2-2-x Firewalling, Up: Network Security Netfilter - Linux Kernel 2-4-x Firewalling ========================================== In yet another set of advancements to the kernel IP packet filtering code, netfilter allows users to set up, maintain, and inspect the packet filtering rules in the new 2.4 kernel. The netfilter subsystem is a complete rewrite of previous packet filtering implementations including ipchains and ipfwadm. Netfilter provides a large number of improvements, and it has now become an even more mature and robust solution for protecting corporate networks. iptables is the command-line interface used to manipulate the firewall tables within the kernel. Netfilter provides a raw framework for manipulating packets as they traverse through various parts of the kernel. Part of this framework includes support for masquerading, standard packet filtering, and now more complete network address translation. It even includes improved support for load balancing requests for a particular service among a group of servers behind the firewall. The stateful inspection features are especially powerful. Stateful inspection provides the ability to track and control the flow of communication passing through the filter. The ability to keep track of state and context information about a session makes rules simpler and tries to interpret higher-level protocols. Additionally, small modules can be developed to perform additional specific functions, such as passing packets to programs in userspace for processing then reinjecting back into the normal packet flow. The ability to develop these programs in userspace reduces the level of complexity that was previously associated with having to make changes directly at the kernel level. Other IP Tables references include: * `Oskar Andreasson IP Tables Tutorial' - Oskar Andreasson speaks with LinuxSecurity.com about his comprehensive IP Tables tutorial and how this document can be used to build a robust firewall for your organization. * `Hal Burgiss Introduces Linux Security Quick-Start Guides' - Hal Burgiss has written two authoritative guides on securing Linux, including managing firewalling. * `Netfilter Homepage' - The netfilter/iptables homepage. * `Linux Kernel 2.4 Firewalling Matures: netfilter' - This LinuxSecurity.com article describes the basics of packet filtering, how to get started using iptables, and a list of the new features available in the latest generation of firewalling for Linux.  File: Security-HOWTO.info, Node: VPNs - Virtual Private Networks, Prev: Netfilter - Linux Kernel 2-4-x Firewalling, Up: Network Security VPNs - Virtual Private Networks =============================== VPN's are a way to establish a "virtual" network on top of some already-existing network. This virtual network often is encrypted and passes traffic only to and from some known entities that have joined the network. VPNs are often used to connect someone working at home over the public Internet to an internal company network. If you are running a Linux masquerading firewall and need to pass MS PPTP (Microsoft's VPN point-to-point product) packets, there is a Linux kernel patch out to do just that. See: ip-masq-vpn. There are several Linux VPN solutions available: * vpnd. See the http://sunsite.auc.dk/vpnd/. * Free S/Wan, available at http://www.xs4all.nl/~freeswan/ * ssh can be used to construct a VPN. See the VPN mini-howto for more information. * vps (virtual private server) at http://www.strongcrypto.com. * yawipin at http://yavipin.sourceforge.net See also the section on IPSEC for pointers and more information.  File: Security-HOWTO.info, Node: Security Preparation (before you go on-line), Next: What To Do During and After a Breakin, Prev: Network Security, Up: Top Security Preparation (before you go on-line) ******************************************** Ok, so you have checked over your system, and determined it's as secure as feasible, and you're ready to put it online. There are a few things you should now do in order to prepare for an intrusion, so you can quickly disable the intruder, and get back up and running. * Menu: * Make a Full Backup of Your Machine:: * Choosing a Good Backup Schedule:: * Testing your backups:: * Backup Your RPM or Debian File Database:: * Keep Track of Your System Accounting Data:: * Apply All New System Updates-::  File: Security-HOWTO.info, Node: Make a Full Backup of Your Machine, Next: Choosing a Good Backup Schedule, Up: Security Preparation (before you go on-line) Make a Full Backup of Your Machine ================================== Discussion of backup methods and storage is beyond the scope of this document, but here are a few words relating to backups and security: If you have less than 650mb of data to store on a partition, a CD-R copy of your data is a good way to go (as it's hard to tamper with later, and if stored properly can last a long time), you will of course need at least 650MB of space to make the image. Tapes and other re-writable media should be write-protected as soon as your backup is complete, and then verified to prevent tampering. Make sure you store your backups in a secure off-line area. A good backup will ensure that you have a known good point to restore your system from.  File: Security-HOWTO.info, Node: Choosing a Good Backup Schedule, Next: Testing your backups, Prev: Make a Full Backup of Your Machine, Up: Security Preparation (before you go on-line) Choosing a Good Backup Schedule =============================== A six-tape cycle is easy to maintain. This includes four tapes for during the week, one tape for even Fridays, and one tape for odd Fridays. Perform an incremental backup every day, and a full backup on the appropriate Friday tape. If you make some particularly important changes or add some important data to your system, a full backup might well be in order.  File: Security-HOWTO.info, Node: Testing your backups, Next: Backup Your RPM or Debian File Database, Prev: Choosing a Good Backup Schedule, Up: Security Preparation (before you go on-line) Testing your backups ==================== You should do periodic tests of your backups to make sure they are working as you might expect them to. Restores of files and checking against the real data, sizes and listings of backups, and reading old backups should be done on a regular basis.  File: Security-HOWTO.info, Node: Backup Your RPM or Debian File Database, Next: Keep Track of Your System Accounting Data, Prev: Testing your backups, Up: Security Preparation (before you go on-line) Backup Your RPM or Debian File Database ======================================= In the event of an intrusion, you can use your RPM database like you would use `tripwire', but only if you can be sure it too hasn't been modified. You should copy the RPM database to a floppy, and keep this copy off-line at all times. The Debian distribution likely has something similar. The files `/var/lib/rpm/fileindex.rpm' and `/var/lib/rpm/packages.rpm' most likely won't fit on a single floppy. But if compressed, each should fit on a seperate floppy. Now, when your system is compromised, you can use the command: root# rpm -Va to verify each file on the system. See the `rpm' man page, as there are a few other options that can be included to make it less verbose. Keep in mind you must also be sure your RPM binary has not been compromised. This means that every time a new RPM is added to the system, the RPM database will need to be rearchived. You will have to decide the advantages versus drawbacks.  File: Security-HOWTO.info, Node: Keep Track of Your System Accounting Data, Next: Apply All New System Updates-, Prev: Backup Your RPM or Debian File Database, Up: Security Preparation (before you go on-line) Keep Track of Your System Accounting Data ========================================= It is very important that the information that comes from `syslog' not be compromised. Making the files in `/var/log' readable and writable by only a limited number of users is a good start. Be sure to keep an eye on what gets written there, especially under the `auth' facility. Multiple login failures, for example, can indicate an attempted break-in. Where to look for your log file will depend on your distribution. In a Linux system that conforms to the "Linux Filesystem Standard", such as Red Hat, you will want to look in `/var/log' and check `messages', `mail.log', and others. You can find out where your distribution is logging to by looking at your `/etc/syslog.conf' file. This is the file that tells `syslogd' (the system logging daemon) where to log various messages. You might also want to configure your log-rotating script or daemon to keep logs around longer so you have time to examine them. Take a look at the `logrotate' package on recent Red Hat distributions. Other distributions likely have a similar process. If your log files have been tampered with, see if you can determine when the tampering started, and what sort of things appeared to be tampered with. Are there large periods of time that cannot be accounted for? Checking backup tapes (if you have any) for untampered log files is a good idea. Intruders typically modify log files in order to cover their tracks, but they should still be checked for strange happenings. You may notice the intruder attempting to gain entrance, or exploit a program in order to obtain the root account. You might see log entries before the intruder has time to modify them. You should also be sure to separate the `auth' facility from other log data, including attempts to switch users using `su', login attempts, and other user accounting information. If possible, configure `syslog' to send a copy of the most important data to a secure system. This will prevent an intruder from covering his tracks by deleting his login/su/ftp/etc attempts. See the `syslog.conf' man page, and refer to the `@' option. There are several more advanced `syslogd' programs out there. Take a look at http://www.core-sdi.com/ssyslog/ for Secure Syslog. Secure Syslog allows you to encrypt your syslog entries and make sure no one has tampered with them. Another `syslogd' with more features is syslog-ng. It allows you a lot more flexibility in your logging and also can has your remote syslog streams to prevent tampering. Finally, log files are much less useful when no one is reading them. Take some time out every once in a while to look over your log files, and get a feeling for what they look like on a normal day. Knowing this can help make unusual things stand out.  File: Security-HOWTO.info, Node: Apply All New System Updates-, Prev: Keep Track of Your System Accounting Data, Up: Security Preparation (before you go on-line) Apply All New System Updates- ============================= Most Linux users install from a CD-ROM. Due to the fast-paced nature of security fixes, new (fixed) programs are always being released. Before you connect your machine to the network, it's a good idea to check with your distribution's ftp site and get all the updated packages since you received your distribution CD-ROM. Many times these packages contain important security fixes, so it's a good idea to get them installed.  File: Security-HOWTO.info, Node: What To Do During and After a Breakin, Next: Security Sources, Prev: Security Preparation (before you go on-line), Up: Top What To Do During and After a Breakin ************************************* So you have followed some of the advice here (or elsewhere) and have detected a break-in? The first thing to do is to remain calm. Hasty actions can cause more harm than the attacker would have. * Menu: * Security Compromise Underway-:: * Security Compromise has already happened::  File: Security-HOWTO.info, Node: Security Compromise Underway-, Next: Security Compromise has already happened, Up: What To Do During and After a Breakin Security Compromise Underway- ============================= Spotting a security compromise under way can be a tense undertaking. How you react can have large consequences. If the compromise you are seeing is a physical one, odds are you have spotted someone who has broken into your home, office or lab. You should notify your local authorities. In a lab, you might have spotted someone trying to open a case or reboot a machine. Depending on your authority and procedures, you might ask them to stop, or contact your local security people. If you have detected a local user trying to compromise your security, the first thing to do is confirm they are in fact who you think they are. Check the site they are logging in from. Is it the site they normally log in from? No? Then use a non-electronic means of getting in touch. For instance, call them on the phone or walk over to their office/house and talk to them. If they agree that they are on, you can ask them to explain what they were doing or tell them to cease doing it. If they are not on, and have no idea what you are talking about, odds are this incident requires further investigation. Look into such incidents , and have lots of information before making any accusations. If you have detected a network compromise, the first thing to do (if you are able) is to disconnect your network. If they are connected via modem, unplug the modem cable; if they are connected via Ethernet, unplug the Ethernet cable. This will prevent them from doing any further damage, and they will probably see it as a network problem rather than detection. If you are unable to disconnect the network (if you have a busy site, or you do not have physical control of your machines), the next best step is to use something like `tcp[lowbar]wrappers' or `ipfwadm' to deny access from the intruder's site. If you can't deny all people from the same site as the intruder, locking the user's account will have to do. Note that locking an account is not an easy thing. You have to keep in mind `.rhosts' files, FTP access, and a host of possible backdoors. After you have done one of the above (disconnected the network, denied access from their site, and/or disabled their account), you need to kill all their user processes and log them off. You should monitor your site well for the next few minutes, as the attacker will try to get back in. Perhaps using a different account, and/or from a different network address.  File: Security-HOWTO.info, Node: Security Compromise has already happened, Prev: Security Compromise Underway-, Up: What To Do During and After a Breakin Security Compromise has already happened ======================================== So you have either detected a compromise that has already happened or you have detected it and locked (hopefully) the offending attacker out of your system. Now what? * Menu: * Closing the Hole:: * Assessing the Damage:: * Backups Backups Backups!:: * Tracking Down the Intruder-::  File: Security-HOWTO.info, Node: Closing the Hole, Next: Assessing the Damage, Up: Security Compromise has already happened Closing the Hole ---------------- If you are able to determine what means the attacker used to get into your system, you should try to close that hole. For instance, perhaps you see several FTP entries just before the user logged in. Disable the FTP service and check and see if there is an updated version, or if any of the lists know of a fix. Check all your log files, and make a visit to your security lists and pages and see if there are any new common exploits you can fix. You can find Caldera security fixes at http://www.caldera.com/tech-ref/security/. Red Hat has not yet separated their security fixes from bug fixes, but their distribution errata is available at http://www.redhat.com/errata Debian now has a security mailing list and web page. See: http://www.debian.org/security/ for more information. It is very likely that if one vendor has released a security update, that most other Linux vendors will as well. There is now a Linux security auditing project. They are methodically going through all the user-space utilities and looking for possible security exploits and overflows. From their announcement: "We are attempting a systematic audit of Linux sources with a view to being as secure as OpenBSD. We have already uncovered (and fixed) some problems, but more help is welcome. The list is unmoderated and also a useful resource for general security discussions. The list address is: security-audit@ferret.lmh.ox.ac.uk To subscribe, send a mail to: security-audit-subscribe@ferret.lmh.ox.ac.uk" If you don't lock the attacker out, they will likely be back. Not just back on your machine, but back somewhere on your network. If they were running a packet sniffer, odds are good they have access to other local machines.  File: Security-HOWTO.info, Node: Assessing the Damage, Next: Backups Backups Backups!, Prev: Closing the Hole, Up: Security Compromise has already happened Assessing the Damage -------------------- The first thing is to assess the damage. What has been compromised? If you are running an integrity checker like `Tripwire', you can use it to perform an integrity check; it should help to tell you what has been compromised. If not, you will have to look around at all your important data. Since Linux systems are getting easier and easier to install, you might consider saving your config files, wiping your disk(s), reinstalling, then restoring your user files and your config files from backups. This will ensure that you have a new, clean system. If you have to restore files from the compromised system, be especially cautious of any binaries that you restore, as they may be Trojan horses placed there by the intruder. Re-installation should be considered mandatory upon an intruder obtaining root access. Additionally, you'd like to keep any evidence there is, so having a spare disk in the safe may make sense. Then you have to worry about how long ago the compromise happened, and whether the backups hold any damaged work. More on backups later.  File: Security-HOWTO.info, Node: Backups Backups Backups!, Next: Tracking Down the Intruder-, Prev: Assessing the Damage, Up: Security Compromise has already happened Backups Backups Backups! ------------------------ Having regular backups is a godsend for security matters. If your system is compromised, you can restore the data you need from backups. Of course, some data is valuable to the attacker too, and they will not only destroy it, they will steal it and have their own copies; but at least you will still have the data. You should check several backups back into the past before restoring a file that has been tampered with. The intruder could have compromised your files long ago, and you could have made many successful backups of the compromised file! Of course, there are also a raft of security concerns with backups. Make sure you are storing them in a secure place. Know who has access to them. (If an attacker can get your backups, they can have access to all your data without you ever knowing it.)  File: Security-HOWTO.info, Node: Tracking Down the Intruder-, Prev: Backups Backups Backups!, Up: Security Compromise has already happened Tracking Down the Intruder- --------------------------- Ok, you have locked the intruder out, and recovered your system, but you're not quite done yet. While it is unlikely that most intruders will ever be caught, you should report the attack. You should report the attack to the admin contact at the site from which the attacker attacked your system. You can look up this contact with `whois' or the Internic database. You might send them an email with all applicable log entries and dates and times. If you spotted anything else distinctive about your intruder, you might mention that too. After sending the email, you should (if you are so inclined) follow up with a phone call. If that admin in turn spots your attacker, they might be able to talk to the admin of the site where they are coming from and so on. Good crackers often use many intermediate systems, some (or many) of which may not even know they have been compromised. Trying to track a cracker back to their home system can be difficult. Being polite to the admins you talk to can go a long way to getting help from them. You should also notify any security organizations you are a part of (CERT (http://www.cert.org/) or similar), as well as your Linux system vendor.  File: Security-HOWTO.info, Node: Security Sources, Next: Glossary, Prev: What To Do During and After a Breakin, Up: Top Security Sources **************** There are a LOT of good sites out there for Unix security in general and Linux security specifically. It's very important to subscribe to one (or more) of the security mailing lists and keep current on security fixes. Most of these lists are very low volume, and very informative. * Menu: * LinuxSecurity-com References:: * FTP Sites:: * Web Sites:: * Mailing Lists:: * Books - Printed Reading Material::  File: Security-HOWTO.info, Node: LinuxSecurity-com References, Next: FTP Sites, Up: Security Sources LinuxSecurity-com References ============================ The LinuxSecurity.com web site has numerous Linux and open source security references written by the LinuxSecurity staff and people collectively around the world. * `Linux Advisory Watch' - A comprehensive newsletter that outlines the security vulnerabilities that have been announced throughout the week. It includes pointers to updated packages and descriptions of each vulnerability. * `Linux Security Week' - The purpose of this document is to provide our readers with a quick summary of each week's most relevant Linux security headlines. * `Linux Security Discussion List' - This mailing list is for general security-related questions and comments. * `Linux Security Newsletters' - Subscription information for all newsletters. * `comp.os.linux.security FAQ' - Frequently Asked Questions with answers for the comp.os.linux.security newsgroup. * `Linux Security Documentation' - A great starting point for information pertaining to Linux and Open Source security.  File: Security-HOWTO.info, Node: FTP Sites, Next: Web Sites, Prev: LinuxSecurity-com References, Up: Security Sources FTP Sites ========= CERT is the Computer Emergency Response Team. They often send out alerts of current attacks and fixes. See ftp://ftp.cert.org for more information. ZEDZ (formerly Replay) (http://www.zedz.net) has archives of many security programs. Since they are outside the US, they don't need to obey US crypto restrictions. Matt Blaze is the author of CFS and a great security advocate. Matt's archive is available at ftp://ftp.research.att.com/pub/mab (ftp://ftp.research.att.com/pub/mab) `tue.nl' is a great security FTP site in the Netherlands. ftp.win.tue.nl  File: Security-HOWTO.info, Node: Web Sites, Next: Mailing Lists, Prev: FTP Sites, Up: Security Sources Web Sites ========= * The Hacker FAQ is a FAQ about hackers: The Hacker FAQ * The COAST archive has a large number of Unix security programs and information: COAST * SuSe Security Page: http://www.suse.de/security/ * Rootshell.com is a great site for seeing what exploits are currently being used by crackers: http://www.rootshell.com/ * BUGTRAQ puts out advisories on security issues: BUGTRAQ archives * CERT, the Computer Emergency Response Team, puts out advisories on common attacks on Unix platforms: CERT home * Dan Farmer is the author of SATAN and many other security tools. His home site has some interesting security survey information, as well as security tools: http://www.trouble.org * The Linux security WWW is a good site for Linux security information: Linux Security WWW * Infilsec has a vulnerability engine that can tell you what vulnerabilities affect a specific platform: http://www.infilsec.com/vulnerabilities/ * CIAC sends out periodic security bulletins on common exploits: http://ciac.llnl.gov/cgi-bin/index/bulletins * A good starting point for Linux Pluggable Authentication modules can be found at http://www.kernel.org/pub/linux/libs/pam/. * The Debian project has a web page for their security fixes and information. It is at http://www.debian.com/security/. * WWW Security FAQ, written by Lincoln Stein, is a great web security reference. Find it at http://www.w3.org/Security/Faq/www-security-faq.html  File: Security-HOWTO.info, Node: Mailing Lists, Next: Books - Printed Reading Material, Prev: Web Sites, Up: Security Sources Mailing Lists ============= Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org containing the message body subscribe bugtraq. (see links above for archives). CIAC: Send e-mail to majordomo@tholia.llnl.gov. In the BODY (not subject) of the message put (either or both): subscribe ciac-bulletin Red Hat has a number of mailing lists, the most important of which is the redhat-announce list. You can read about security (and other) fixes as soon as they come out. Send email to redhat-announce-list-request@redhat.com with the Subject Subscribe See https://listman.redhat.com/mailman/listinfo/ for more info and archives. The Debian project has a security mailing list that covers their security fixes. See http://www.debian.com/security/ for more information.