Security Quick−Start HOWTO for Red Hat Linux Hal Burgiss hal@foobox.net v. 1.2, 2002−07−21 Revision History Revision v. 1.2 2002−07−21 A few small additions, and fix the usual broken links. Revision v. 1.1 2002−02−06 A few fixes, some additions and many touch−ups from the original. Revision v. 1.0 2001−11−07 Initial Release. Revised by: hb Revised by: hb Revised by: hb This document is a an overview of the basic steps required to secure a Linux installation from intrusion.
Security Quick−Start HOWTO for Red Hat Linux Table of Contents 1. Introduction.....................................................................................................................................................1 1.1. Why me?...........................................................................................................................................1 1.2. Notes.......................................................................................................................
Security Quick−Start HOWTO for Red Hat Linux Table of Contents 7. General Tips..................................................................................................................................................40 8. Appendix........................................................................................................................................................43 8.1. Servers, Ports, and Packets......................................................................................
1. Introduction 1.1. Why me? Who should be reading this document and why should the average Linux user care about security? Those new to Linux, or unfamiliar with the inherent security issues of connecting a Linux system to large networks like Internet should be reading. "Security" is a broad subject with many facets, and is covered in much more depth in other documents, books, and on various sites on the Web.
Security Quick−Start HOWTO for Red Hat Linux not the case, further reading is strongly recommended. The principles that will guide us in our quest are: • There is no magic bullet. There is no one single thing we can do to make us secure. It is not that simple. • Security is a process that requires maintenance, not an objective to be reached. • There is no 100% safe program, package or distribution. Just varying degrees of insecurity.
Security Quick−Start HOWTO for Red Hat Linux This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You can get a copy of the GNU GPL at at http://www.gnu.org/copyleft/gpl.html. 1.4. Credits Many thanks to those who helped with the production of this document.
Security Quick−Start HOWTO for Red Hat Linux small additions and clarifications. Version 1.1: Various corrections, amplifications and numerous mostly small additions. Too many to list. Oh yea, learn to spell Red Hat correctly ;−) Version 1.0: This is the initial release of this document. Comments welcomed. 1.7. Feedback Any and all comments on this document are most welcomed. Please make sure you have the most current version before submitting corrections or suggestions! These can be sent to
2. Foreword Before getting into specifics, let's try to briefly answer some questions about why we need to be concerned about security in the first place. It is easy to see why an e−commerce site, an on−line bank, or a government agency with sensitive documents would be concerned about security. But what about the average user? Why should even a Linux home Desktop user worry about security? Anyone connected to the Internet is a target, plain and simple.
Security Quick−Start HOWTO for Red Hat Linux 2.1. The Optimum Configuration Ideally, we would want one computer as a dedicated firewall and router. This would be a bare bones installation, with no servers running, and only the required services and components installed. The rest of our systems would connect via this dedicated router/firewall system. If we wanted publicly accessible servers (web, mail, etc), these would be in a "DMZ" (De−militarized Zone).
3. Step 1: Which services do we really need? In this section we will see which services are running on our freshly installed system, decide which we really need, and do away with the rest. If you are not familiar with how servers and TCP connections work, you may want to read the section on servers and ports in the Appendix first. If not familiar with the netstat utility, you may want to read a quick overview of it beforehand. There is also a section in the Appendix on ports, and corresponding services.
Security Quick−Start HOWTO for Red Hat Linux *:telnet *:finger *:sunrpc *:ftp *:smtp *:1694 *:netbios−ssn *:* *:* *:* *:* *:* *:* *:* LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN 988/inetd 988/inetd 1290/portmap 988/inetd 1738/sendmail: accepting connections 1319/rpc.mountd 422/smbd Red Hat 7.x and Mandrake 8.x and later users will have xinetd in place of inetd. Note the first three columns are cropped above for readability.
Security Quick−Start HOWTO for Red Hat Linux There may be individual situations where it is desirable to make exceptions to the conclusions reached above. See below. 3.2. The Danger Zone (or r00t m3 pl34s3) The following is a list of services that should not be run over the Internet. Either disable these (see below), uninstall, or if you really do need these services running locally, make sure they are the current, patched versions and that they are effectively firewalled.
Security Quick−Start HOWTO for Red Hat Linux below). Also, where xinetd is used, it can control those services as well. chkconfig can tell us what services the system is configured to run, but not necessarily all services that are indeed actually running. Or what services may be started by other means, e.g. from rc.local. It is a configuration tool, more than a real time system auditing too.
Security Quick−Start HOWTO for Red Hat Linux To view only the ones that are "on": # chkconfig −−list | grep "\bon\b" | less The first column is the service name, and the remaining columns are the various runlevels. We need generally only worry about runlevels 3 (boot to text console login) and 5 (boot straight to X11 login). xinetd services won't have columns, since that aspect would be controlled by xinetd itself.
Security Quick−Start HOWTO for Red Hat Linux # the running INETD process, edit this file, then send the # INETD process a SIGHUP signal. # # Version: @(#)/etc/inetd.conf 3.10 05/27/93 # # Authors: Original taken from BSD UNIX 4.3/TAHOE. # Fred N. van Kempen, # # Modified for Debian Linux by Ian A. Murdock # # Echo, discard, daytime, and chargen are used primarily for testing.
Security Quick−Start HOWTO for Red Hat Linux Check your logs for errors, and run netstat again to verify all went well. A quicker way of getting the same information, using grep: $ grep time pop−3 −v '^#' /etc/inetd.conf stream tcp nowait stream tcp nowait root root internal /usr/sbin/tcpd ipop3d Again, do you see anything there that you don't know what it is? Then in all likelihood you are not using it, and it should be disabled.
Security Quick−Start HOWTO for Red Hat Linux /etc/xinetd.d/rlogin: /etc/xinetd.d/rsh: /etc/xinetd.d/telnet: /etc/xinetd.d/wu−ftpd: disable disable disable disable = = = = no no no no At this point, the above output should raise some red flags. In the overwhelming majority of systems, all the above can be disabled without any adverse impact. Not sure? Try it without that service. After disabling unnecessary services, then restart xinetd: # /etc/rc.d/init.d/xinetd restart 3.3.4.
Security Quick−Start HOWTO for Red Hat Linux 3.4. Exceptions Above we used the criteria of turning off all unnecessary services. Sometimes that is not so obvious. And sometimes what may be required for one person's configuration is not the same for another's. Let's look at a few common services that fall in this category. Again, our rule of thumb is if we don't need it, we won't run it. It's that simple.
Security Quick−Start HOWTO for Red Hat Linux 3.5. Summary and Conclusions for Step 1 In this section we learned how to identify which services are running on our system, and were given some tips on how to determine which services may be necessary. Then we learned how to find where the services were being started, and how to stop them. If this has not made sense, now is a good time to re−read the above. Hopefully you've already taken the above steps.
4. Step 2: Updating OK, this section should be comparatively short, simple and straightforward compared to the above, but no less important. The very first thing after a new install you should check the errata notices at http://redhat.com/apps/errata/, and apply all relevant updates. Only a year old you say? That's a long time actually, and not current enough to be safe. Only a few months or few weeks? Check anyway. A day or two? Better safe than sorry.
Security Quick−Start HOWTO for Red Hat Linux are updated according to what Red Hat has made available since the initial release. At least as long as Red Hat is still supporting the release and updates are still being provided. For instance, Red Hat has stopped providing updates for 5.0 and 5.1, but still does for 5.2. 4.
5. Step 3: Firewalls and Setting Access Policies So what is a "firewall"? It's a vague term that can mean anything that acts as a protective barrier between us and the outside world. This can be a dedicated system, or a specific application that provides this functionality. Or it can be a combination of components, including various combinations of hardware and software. Firewalls are built from "rules" that are used to define what is allowed to enter and exit a given system or network.
Security Quick−Start HOWTO for Red Hat Linux generating a very basic set of firewall rules (see below). This may be adequate, but it is still recommended to know the proper syntax and how the various mechanisms work as such tools rarely do more than a few very simple rules. Various examples are given below. These are presented for illustrative purposes to demonstrate some of the concepts being discussed here.
Security Quick−Start HOWTO for Red Hat Linux # ipchains.sh # # An example of a simple ipchains configuration. # # This script allows ALL outbound traffic, and denies # ALL inbound connection attempts from the outside. # ################################################################### # Begin variable declarations and user configuration options ###### # IPCHAINS=/sbin/ipchains # This is the WAN interface, that is our link to the outside world. # For pppd and pppoe users.
Security Quick−Start HOWTO for Red Hat Linux # request is blocked, ie we won't respond to someone else's pings, # but can still ping out.
Security Quick−Start HOWTO for Red Hat Linux −d [port]: This rule only applies to the destination address as specified. Also, it may include port or port range. −l : Any packet that hits a rule with this option is logged (lower case "L"). −j ACCEPT: Jumps to the "ACCEPT" "target". This effectively terminates this chain and decides the ultimate fate for this particular packet, which in this example is to "ACCEPT" it. The same is true for other −j targets like DENY.
Security Quick−Start HOWTO for Red Hat Linux #!/bin/sh # # iptables.sh # # An example of a simple iptables configuration. # # This script allows ALL outbound traffic, and denies # ALL inbound connection attempts from the Internet interface only. # ################################################################### # Begin variable declarations and user configuration options ###### # IPTABLES=/sbin/iptables # Local Interfaces # This is the WAN interface that is our link to the outside world.
Security Quick−Start HOWTO for Red Hat Linux $IPTABLES −A INPUT −m state −−state ESTABLISHED,RELATED −j ACCEPT $IPTABLES −A INPUT −m state −−state NEW −i ! $WAN_IFACE −j ACCEPT $IPTABLES −A INPUT −j LOG −m limit −−limit 30/minute −−log−prefix "Dropping: " echo "Iptables firewall is up `date`." ##−− eof iptables.sh The same script logic is used here, and thus this does pretty much the same exact thing as the ipchains script in the previous section. There are some subtle differences as to syntax.
Security Quick−Start HOWTO for Red Hat Linux /etc/sysconfig/ipchains. As mentioned, this is a fairly minimalist set of rules, and possibly a sufficient starting point. An example /etc/sysconfig/ipchains created by gnome−lokkit: # Firewall configuration written by lokkit # Manual customization of this file is not recommended. # Note: ifup−post will punch the current nameservers through the # firewall; such entries will *not* be listed here.
Security Quick−Start HOWTO for Red Hat Linux /etc/hosts.allow, where specific services are listed, along with the specific host addresses allowed to access these services. While hostnames can be used here, use of hostnames opens the limited possibility for name spoofing. Tcpwrappers is commonly used to protect services that are started via inetd (or xinetd). But also any program that has been compiled with libwrap support, can take advantage of it.
Security Quick−Start HOWTO for Red Hat Linux to only our sshd daemon from any host associated with .myworkplace.com. Note the leading "." in this example. And then also, the single host hostess.mymomshouse.com. In summary, localhost and all our LAN connections have access to any and all tcpwrappered services on bigcat. But only our workplace addresses, and our mother can use sshd on bigcat from outside connections. Everybody else is denied by the default policy in /etc/hosts.deny.
Security Quick−Start HOWTO for Red Hat Linux connections from 192.168.1.0, our LAN. For xinetd's purposes, this denotes any IP address beginning with "192.168.1". Note that the syntax is different from inetd. The server statement in this case is the tftp daemon, in.tftpd. Again, this assumes that libwrap/tcpwrappers support is compiled into xinetd. The user running the daemon will be "nobody".
Security Quick−Start HOWTO for Red Hat Linux using a web proxy like "squid" (http://www.squid−cache.org/), every time we browse to a web site, we would actually be connecting to our locally running squid server. Squid in turn, would relay our request to the ultimate, real destination. And then squid would relay the web pages back to us. It is a go−between. Like "firewalls", a "proxy" can refer to either a specific application, or a dedicated server which runs a proxy application.
Security Quick−Start HOWTO for Red Hat Linux editor. If using xdm (or variants such as gdm, kdm, etc), this option would be specified in /etc/X11/xdm/Xservers (or comparable) as :0 local /usr/bin/X11/X −nolisten tcp. gdm actually uses /etc/X11/gdm/gdm.conf. If using xdm (or comparable) to start X automatically at boot, /etc/inittab can be modified as: xdm −udpPort 0, to further restrict connections. This is typically near the bottom of /etc/inittab.
Security Quick−Start HOWTO for Red Hat Linux As always, anytime you make system changes, backup the configuration file first, restart the appropriate daemon afterward, and then check the appropriate logs for error messages. 5.7. Verifying The final step after getting your firewall in place, is to verify that it is doing what you intended. You would be wise to do this anytime you make even minor changes to your system configuration. So how to do this? There are several things you can do.
Security Quick−Start HOWTO for Red Hat Linux 5.8. Logging Linux does a lot of logging. Usually to more than one file. It is not always obvious what to make of all these entries −− good, bad or indifferent? Firewall logs tend to generate a fair amount of each. Of course, you are wanting to stop only the "bad", but you will undoubtedly catch some harmless traffic as well. The 'net has a lot of background noise. In many cases, knowing the intentions of an incoming packet are almost impossible.
Security Quick−Start HOWTO for Red Hat Linux • http://freshmeat.net/projects/fwlogwatch/ by Boris Wesslowski, is a similar idea, but supports more log formats. 5.9. Where to Start Let's take a quick look at where to run our firewall scripts from. Portsentry can be run as an init process, like other system services. It is not so important when this is done. Tcpwrappers will be automatically be invoked by inetd or xinetd, so not to worry there either.
Security Quick−Start HOWTO for Red Hat Linux implemented any of the above steps yet, now is a good time to take a break, go back to the top, and have at it. The most important steps are the ones above. A few quick conclusions... "What is best iptables, ipchains, tcpwrappers, or portsentry?" The quick answer is that iptables can do more than any of the others. So if you are using a 2.4 kernel, use iptables. Then, ipchains if using a 2.2 kernel.
6. Intrusion Detection This section will deal with how to get early warning, how to be alerted after the fact, and how to clean up from intrusion attempts. 6.1. Intrusion Detection Systems (IDS) Intrusion Detection Systems (IDS for short) are designed to catch what might have gotten past the firewall. They can either be designed to catch an active break−in attempt in progress, or to detect a successful break−in after the fact.
Security Quick−Start HOWTO for Red Hat Linux The first thing an intruder typically does is install a "rootkit". There are many prepackaged rootkits available on the Internet. The rootkit is essentially a script, or set of scripts, that makes quick work of modifying the system so the intruder is in control, and he is well hidden. He does this by installing modified binaries of common system utilities and tampering with log files. Or by using special kernel modules that achieve similar results.
Security Quick−Start HOWTO for Red Hat Linux end. Remember though such changes may not be "visible" to any system tools. Sometimes the intruder is not so smart and forgets about root's .bash_history, or cleaning up log entries, or even leaves strange, leftover files in /tmp. So these should always be checked too. Just don't necessarily expect them to be accurate. Often such left behind files, or log entries, will have obvious script kiddie sounding names, e.g. "r00t.sh".
Security Quick−Start HOWTO for Red Hat Linux The steps to take, in this order: • Pull the plug and disconnect the machine. You may be unwittingly participating in criminal activity, and doing to others what has been done to you. • Depending on the needs of the situation and time available to restore the system, it is advantageous to learn as much as you can about how the attacker got in, and what was done in order to plug the hole and avoid a recurrence.
7. General Tips This section will quickly address some general concepts for maintaining a more secure and reliable system or network. Let's emphasize "maintaining" here since computer systems change daily, as does the environment around them. As mentioned before, there isn't any one thing that makes a system secure. There are too many variables. Security is an approach and an attitude more than it is a reliance on any particular product, application or specific policy. • Do not allow remote root logins.
Security Quick−Start HOWTO for Red Hat Linux /etc/security/*, including /etc/security/limits.conf, where again various sane limits can be imposed. An in depth look at PAM is beyond the scope of this document. The User−Authentication HOWTO (http://tldp.org/HOWTO/User−Authentication−HOWTO/index.html) has more on this. • Make sure someone with a clue is getting root's mail. This can be done with an "alias". Typically, the mail server will have a file such as /etc/aliases where this can defined.
Security Quick−Start HOWTO for Red Hat Linux Even if it is just one LAN box to another. • If you find you need to run a particular service, and it is for just you, or maybe a relatively small number of people, use a non−standard port. Most server daemons support this. For instance, sshd runs on port 22 by default. All worms and script kiddies will expect it there, and look for it there. So, run it on another port! See the sshd man page.
8. Appendix 8.1. Servers, Ports, and Packets Let's take a quick, non−technical look at some networking concepts, and how they can potentially impact our own security. We don't need to know much about networking, but a general idea of how things work is certainly going to help us with firewalls and other related issues. As you may have noticed Linux is a very network oriented Operating System. Much is done by connecting to "servers" of one type or another −− X servers, font servers, print servers, etc.
Security Quick−Start HOWTO for Red Hat Linux computer will open a connection to a "port" on another computer, and thus be able to exchange data via the connection that has been established between their respective ports. Getting back to the phone analogy, and stretching it a bit, think of calling a large organization with a complex phone system. The organization has many "departments": sales, shipping, billing, receiving, customer service, R&D, etc. Each department has it's own "extension" number.
Security Quick−Start HOWTO for Red Hat Linux One more point on ports: ports are only accessible if there is something listening on that port. No one can force a port open if there is no service or daemon listening there, ready to handle incoming connection requests. A closed port is a totally safe port. And a final point on the distinction between clients and servers. The example above did not have a telnet or ftp server in the LISTENER section in the netstat example above.
Security Quick−Start HOWTO for Red Hat Linux 69 − tftp, or Trivial File Transfer Protocol. Extremely insecure. LAN only, if really, really needed. 79 − Finger, used to provide information about the system, and logged in users. Low risk as a crack target, but gives out way too much information and should not be run. 80 − WWW or HTTP standard web server port. The most commonly used service on the Internet. Low risk. 98 − Linuxconf web access administrative port. LAN only, if really needed at all.
Security Quick−Start HOWTO for Red Hat Linux 513 − login, actually rlogin, aka Remote Login. No relation to the standard /bin/login that we use every time we log in. Sounds dangerous, and is. High risk, and LAN only if really needed. 514 (TCP) − shell is the nickname, and how netstat shows it. Actually, rsh is the application for "Remote Shell". Like all the "r" commands, this is a throw back to kindler, gentler times. Very insecure, so high risk, and LAN only usage, if at all.
Security Quick−Start HOWTO for Red Hat Linux 6000 − X11 TCP port for remote connections. Low to moderate risk, but again, this should be LAN only. Actually, this can include ports 6000−6009 since X can support multiple displays and each display would have its own port. ssh's X11Forwarding will start using ports at 6010. 6346 − gnutella. 6667 − ircd, Internet Relay Chat Daemon. 6699 − napster. 7100−7101 − Some font servers use these ports. Low risk, but LAN only.
Security Quick−Start HOWTO for Red Hat Linux $ netstat −tua Active Internet connections (servers and established) Proto Recv−Q Send−Q Local Address Foreign Address tcp 0 0 *:printer *:* tcp 0 0 bigcat:8000 *:* tcp 0 0 *:time *:* tcp 0 0 *:x11 *:* tcp 0 0 *:http *:* tcp 0 0 bigcat:domain *:* tcp 0 0 bigcat:domain *:* tcp 0 0 *:ssh *:* tcp 0 0 *:631 *:* tcp 0 0 *:smtp *:* tcp 0 1 dsl−78−199−139.s:1174 64.152.100.93:nntp tcp 0 1 dsl−78−199−139.s:1175 64.152.100.93:nntp tcp 0 1 dsl−78−199−139.s:1173 64.152.100.
Security Quick−Start HOWTO for Red Hat Linux tcp tcp tcp tcp tcp tcp tcp tcp udp udp udp udp 0 0 0 1 0 400 6648 553 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 169.254.179.139:1175 169.254.179.139:1173 169.254.179.139:1172 169.254.179.139:1199 169.254.179.139:80 127.0.0.1:1152 127.0.0.1:1162 127.0.0.1:1164 0.0.0.0:32768 192.168.1.1:53 127.0.0.1:53 0.0.0.0:631 64.152.100.93:119 64.152.100.93:119 207.153.203.114:80 216.26.129.136:80 63.236.92.144:34197 127.0.0.1:8000 127.0.0.1:8000 127.0.0.1:8000 0.0.0.0:* 0.0.0.
Security Quick−Start HOWTO for Red Hat Linux Looking at /etc/services, we can tell that port 37 is a "time" service, which is a time server. 6000 is X11, and 80 is the standard port for HTTP servers like Apache. There is nothing really unusual here as these are all readily available services on Linux. The first two above are definitely not the kind of services you'd want just anyone to connect to. These should be firewalled so that all outside connections are refused.
Security Quick−Start HOWTO for Red Hat Linux tcp tcp 6648 553 0 127.0.0.1:1162 0 127.0.0.1:1164 127.0.0.1:8000 127.0.0.1:8000 CLOSE_WAIT CLOSE_WAIT There are nine total connections here. The first three is our external interface connecting to a remote host on their port 119, the standard NNTP (News) port. There are three connections here to the same news server. Apparently the application is multi−threaded, as it is trying to open multiple connections to the news server.
Security Quick−Start HOWTO for Red Hat Linux # netstat −tap Active Internet connections (servers and established) Local Address Foreign Address State *:printer *:* LISTEN bigcat:8000 *:* LISTEN *:time *:* LISTEN *:x11 *:* LISTEN *:http *:* LISTEN bigcat:domain *:* LISTEN bigcat:domain *:* LISTEN *:ssh *:* LISTEN *:631 *:* LISTEN *:smtp *:* LISTEN PID/Program name 988/inetd 1064/junkbuster 988/inetd 1462/X 1078/httpd 956/named 956/named 972/sshd 1315/cupsd 1051/master Some of these we already know about.
Security Quick−Start HOWTO for Red Hat Linux 958 959 960 961 1051 1703 1704 1955 1863 2043 2049 2062 ? ? ? ? ? ? ? ? ? ? ? ? S S S S S S S S S S S S 0:46 \_ named −u named 0:47 \_ named −u named 0:00 \_ named −u named 0:11 \_ named −u named 0:30 /usr/libexec/postfix/master 0:00 \_ tlsmgr −l −t fifo −u −c 0:00 \_ qmgr −l −t fifo −u −c 0:00 \_ pickup −l −t fifo −c 0:00 \_ trivial−rewrite −n rewrite −t unix −u −c 0:00 \_ cleanup −t unix −u −c 0:00 \_ local −t unix 0:00 \_ smtpd −n smtp −t inet −u −c A coup
Security Quick−Start HOWTO for Red Hat Linux 631/tcp USER root PID 1315 ACCESS f.... COMMAND cupsd See the man pages for fuser and lsof command syntax. Another place to look for where a service is started, is in the init.d directory, where the actual init scripts live. Something like ls −l /etc/rc.d/init.d/, should give us a list of these. Often the script name itself gives a hint as to which service(s) it starts, though it may not necessarily exactly match the "Program Name" as provided by netstat.
Security Quick−Start HOWTO for Red Hat Linux If all else fails, and you can't find a process owner for an open port, suspect that it may be an RPC (Remote Procedure Call) service of some kind. These use randomly assigned ports without any seeming logic or consistency, and are typically controlled by the portmap daemon. In some cases, these may not reveal the process owner to netstat or lsof. Try stopping portmap, and then see if the mystery service goes away.
Security Quick−Start HOWTO for Red Hat Linux even kernel version, and thus get even more information. "Worms", on the other hand, are automated and scan blindly, generally just looking for open ports, and then a susceptible victim. They are not trying to "learn" anything, the way a cracker might. The distinction between "scan" and "probe"is often blurred. Both can used in good ways, or in bad ways, depending on who is doing it, and why.
Security Quick−Start HOWTO for Red Hat Linux really try very hard. Just scan, look, try, move on if unsuccessful. There is always more IPs to be scanned. If your firewall is effectively bouncing this kind of thing, it is no threat to you at all. Take comfort in that, and don't over re−act. It is worth noting, that these worms cannot "force" their way in. They need an open and accessible port, and a known vulnerability.
Security Quick−Start HOWTO for Red Hat Linux network. In this case, the attacker will look the system over for weaknesses. And possibly make many different kinds of attempts, until he finds a crack to wiggle through. Or gives up. This is more difficult to defend against. The attacker is armed and dangerous, so to speak, and is stalking his prey. Again, this scenario is very unlikely for a typical home system.
Security Quick−Start HOWTO for Red Hat Linux 8.4.9. Viruses And now something not to worry about. Viruses seem to be primarily a Microsoft problem. For various reasons, viruses are not a significant threat to Linux users. This is not to say that it will always be this way, but the current virus explosion that plagues Microsoft systems, can not spread to Linux (or Unix) based systems. In fact, the various methods and practices that enable this phenomena, are not exploitable on Linux.
Security Quick−Start HOWTO for Red Hat Linux Securing Red Hat: http://tldp.org/LDP/solrhe/Securing−Optimizing−Linux−RH−Edition−v1.3/index.html • Tools for creating custom ipchains and iptables firewall scripts: Firestarter: http://firestarter.sourceforge.net Two related projects: http://seawall.sourceforge.net/ for ipchains, and http://shorewall.sourceforge.net/ for iptables.
Security Quick−Start HOWTO for Red Hat Linux Linux Security.com: http://www.linuxsecurity.com/docs/ Linux Newbie: http://www.linuxnewbie.org/nhf/intel/security/index.html The comp.os.linux.security FAQ: http://www.linuxsecurity.com/docs/colsfaq.html The Internet Firewall FAQ: http://www.interhack.net/pubs/fwfaq/ The Site Security Handbook RFC: http://www.ietf.org/rfc/rfc2196.txt • Miscellaneous sites of interest: http://www.bastille−linux.org, for Mandrake and Red Hat only. SAINT: http://www.wwdsi.
Security Quick−Start HOWTO for Red Hat Linux There are a great many types of files, but I'm going to stretch it here, and class them into two really broad families: Text files are just that. Binary files are not. Binary files are meant to be read by machines, text files can be easily edited, and are generally read by people. But text files can be (and frequently are) read by machines. Examples of this would be configuration files, and scripts.
Security Quick−Start HOWTO for Red Hat Linux o Enter insertion mode opening a new line BELOW current line. O Enter insertion mode opening a new line ABOVE current line. h move cursor left one character. l move cursor right one character. j move cursor down one line. k move cursor up one line.
Security Quick−Start HOWTO for Red Hat Linux pico −w file_2_edit Pico is so user friendly, no further instructions are needed. It _should_ be obvious (look at the bottom of the screen for commands). There is an extensive help function. Pico is available with nearly all distributions, although it _may_ not be installed by default. ==> Emergency exit from 'pico' Press and hold the key, and press the letter x. If no changes had been made to the file, this will quit pico.
Security Quick−Start HOWTO for Red Hat Linux 22/tcp 25/tcp 37/tcp 53/tcp 80/tcp 3000/tcp open open open open open open ssh smtp time domain http ppp Nmap run completed −− 1 IP address (1 host up) scanned in 2 seconds If you've read most of this document, you should be familiar with these services by now. These are some of the same ports we've seen in other examples. Some things to note on this scan: it only did 1500+ "interesting" ports −− not all ports.
Security Quick−Start HOWTO for Red Hat Linux This is more than just "interesting" ports −− it is everything. We picked up a couple of new ones in the process too. We've seen these before with netstat, so we know what they are. That is the Junkbuster web proxy on port 8000/tcp and named on 32768/udp. This scan takes much, much longer, but it is the only way to see all ports. So now we have a pretty good idea of what is open on bigcat.
Security Quick−Start HOWTO for Red Hat Linux A brief note on UDP: nmap can not accurately determine the status of these ports if they are "filtered". You probably will get a false−positive "open" condition. This has to do with UDP being a connectionless protocol. If nmap gets no answer (e.g. due to a "DROP"), it assumes the packets reached the target, and thus the port will be reported as "open". This is "normal" for nmap.
Security Quick−Start HOWTO for Red Hat Linux [ −e /proc/sys/net/ipv4/conf/all/log_martians ] &&\ echo 1 > /proc/sys/net/ipv4/conf/all/log_martians [ −e /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts ] &&\ echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts [ −e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] &&\ echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ## Optional from here on down, depending on your situation.
Security Quick−Start HOWTO for Red Hat Linux net.ipv4.ip_dynaddr = 1 # end of example 8.9. Secure Alternatives This section will give a brief run down on secure alternatives to potentially insecure methods. This will be a hodge podge of clients and servers. • telnet, rsh − ssh • ftp, rcp − scp or sftp. Both are part of ssh packages. Also, files can easily be transfered via HTTP if Apache is already running anyway. Apache can be buttoned down even more by using SSL (HTTPS). • sendmail − postfix, qmail.
Security Quick−Start HOWTO for Red Hat Linux # # Set the location of ipchains (default). IPCHAINS=/sbin/ipchains # Local Interfaces # # This is the WAN interface, that is our link to the outside world. # For pppd and pppoe users. # WAN_IFACE="ppp0" WAN_IFACE="eth0" # # Local Area Network (LAN) interface. #LAN_IFACE="eth0" LAN_IFACE="eth1" # Our private LAN address(es), for masquerading. LAN_NET="192.168.1.0/24" # For static IP, set it here! #WAN_IP="1.2.3.4" # Set a list of public server port numbers here..
Security Quick−Start HOWTO for Red Hat Linux # # Let's start clean and flush all chains to an empty state. $IPCHAINS −F # Set the default policies of the built−in chains. If no match for any # of the rules below, these will be the defaults that ipchains uses. $IPCHAINS −P forward DENY $IPCHAINS −P output ACCEPT $IPCHAINS −P input DENY # Accept localhost/loopback traffic. $IPCHAINS −A input −i lo −j ACCEPT # # # # [ Get our dynamic IP now from the Inet interface.
Security Quick−Start HOWTO for Red Hat Linux ## Trusted hosts/nets # # This is our trusted host list. These have access to everything. for i in $TRUSTED; do $IPCHAINS −A input −s $i −j ACCEPT done # # # # # # [ Port Forwarding Which ports get forwarded to which host. This is one to one port mapping (ie 80 −> 80) in this case. NOTE: ipmasqadm is a separate package from ipchains and needs to be installed also.
Security Quick−Start HOWTO for Red Hat Linux ## ICMP (ping) # # ICMP rules, allow the bare essential types of ICMP only. Ping # request is blocked, ie we won't respond to someone else's pings, # but can still ping out.
Security Quick−Start HOWTO for Red Hat Linux # Set a list of public server port numbers here...not too many! # These will be open to the world, so use caution. The example is # sshd, and HTTP (www). Any services included here should be the # latest version available from your vendor. Comment out to disable # all Public services. Do not put any ports to be forwarded here, # this only direct access.
Security Quick−Start HOWTO for Red Hat Linux # already set, so all is not lost here. [ −z "$WAN_IP" ] && echo "$WAN_IFACE not configured, aborting." && exit 1 WAN_MASK=`ifconfig $WAN_IFACE |grep Mask |cut −d : −f 4` WAN_NET="$WAN_IP/$WAN_MASK" ## Reserved IPs: # # We should never see these private addresses coming in from outside # to our external interface. $IPTABLES −A INPUT −i $WAN_IFACE −s 10.0.0.0/8 −j DROP $IPTABLES −A INPUT −i $WAN_IFACE −s 172.16.0.
Security Quick−Start HOWTO for Red Hat Linux −−dport $i −j ACCEPT $IPTABLES −t nat −A PREROUTING −p tcp −d $WAN_IP −−dport $i \ −j DNAT −−to $FORWARD_HOST:$i done ## Open, but Restricted Access ports # # Allow DHCP server (their port 67) to client (to our port 68) UDP # traffic from outside source. [ −n "$DHCP_SERVER" ] &&\ $IPTABLES −A INPUT −p udp −s $DHCP_SERVER −−sport 67 \ −d $ANYWHERE −−dport 68 −j ACCEPT # Allow 'identd' (to our TCP port 113) from mail server only.
Security Quick−Start HOWTO for Red Hat Linux $IPTABLES −A DEFAULT # Enable logging for $IPTABLES −A DEFAULT # Now drop it, if it $IPTABLES −A DEFAULT # # # # −m state −−state NEW −i ! $WAN_IFACE −j ACCEPT anything that gets this far. −j LOG −m limit −−limit 30/minute −−log−prefix "Dropping: " has gotten here. −j DROP This is the 'bottom line' so to speak. Everything winds up here, where we bounce it to our custom built 'DEFAULT' chain that we defined just above.
Security Quick−Start HOWTO for Red Hat Linux 8.10.4. iptables mini−me Just to demonstrate how succinctly iptables can be configured in a minimalist situation, the below is from the Netfilter team's Rusty's Really Quick Guide To Packet Filtering: "Most people just have a single PPP connection to the Internet, and don't want anyone coming back into their network, or the firewall:" ## Insert connection−tracking modules (not needed if built into kernel).
