8. Appendix

8.3.1. Overview

netstat is a very useful utility for viewing the current state of your network status -- what servers are listening for incoming connections, what interfaces they listen on, who is connected to us, who we are connect to, and so on. Take a look at the man page for some of the many command line options. We'll just use a relative few options here.

As an example, let's check all currently listening servers and active connections for both TCP and UDP on our hypothetical host, bigcat. bigcat is a home desktop installation, with a DSL Internet connection in this example. bigcat has two ethernet cards: one for the external connection to the ISP, and one for a small LAN with an address of 192.168.1.1.

$ netstat -tua Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:printer *:* LISTEN tcp 0 0 bigcat:8000 *:* LISTEN tcp 0 0 *:time *:* LISTEN tcp 0 0 *:x11 *:* LISTEN tcp 0 0 *:http *:* LISTEN tcp 0 0 bigcat:domain *:* LISTEN tcp 0 0 bigcat:domain *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 *:631 *:* LISTEN tcp 0 0 *:smtp *:* LISTEN tcp 0 1 dsl-78-199-139.s:1174 64.152.100.93:nntp SYN_SENT tcp 0 1 dsl-78-199-139.s:1175 64.152.100.93:nntp SYN_SENT tcp 0 1 dsl-78-199-139.s:1173 64.152.100.93:nntp SYN_SENT tcp 0 0 dsl-78-199-139.s:1172 207.153.203.114:http ESTABLISHED tcp 1 0 dsl-78-199-139.s:1199 www.xodiax.com:http CLOSE_WAIT tcp 0 0 dsl-78-199-139.sd:http 63.236.92.144:34197 TIME_WAIT tcp 400 0 bigcat:1152 bigcat:8000 CLOSE_WAIT tcp 6648 0 bigcat:1162 bigcat:8000 CLOSE_WAIT tcp 553 0 bigcat:1164 bigcat:8000 CLOSE_WAIT udp 0 0 *:32768 *:* udp 0 0 bigcat:domain *:* udp 0 0 bigcat:domain *:* udp 0 0 *:631 *:*

This output probably looks very different from what you get on your own system. Notice the distinction between "Local Address" and "Foreign Address", and how each includes a corresponding port number (or service name if available) after the colon. "Local Address" is our end of the connection. The first group with LISTEN in the far right hand column are services that are running on this system. These are servers that are running in the background on bigcat, and "listen" for incoming connections. So they have a port opened, and this is where they "listen". These connections might come from the local system (i.e. bigcat itself), or remote systems. This is very important information to have! The others just below this are connections that have been established from this system to other systems. The respective connections are in varying states as indicated by the key words in the last column. Those with no key word in the last column at the end are servers responding to UDP connections. UDP is a different protocol from TCP altogether, but is used for some types of low priority network traffic.

Now, the same thing with the "-n" flag to suppress converting to "names" so we can actually see the port numbers:

$ netstat -taun Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:37 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp 0 1 169.254.179.139:1174 64.152.100.93:119 SYN_SENT tcp 0 1 169.254.179.139:1175 64.152.100.93:119 SYN_SENT tcp 0 1 169.254.179.139:1173 64.152.100.93:119 SYN_SENT tcp 0 0 169.254.179.139:1172 207.153.203.114:80 ESTABLISHED tcp 1 0 169.254.179.139:1199 216.26.129.136:80 CLOSE_WAIT tcp 0 0 169.254.179.139:80 63.236.92.144:34197 TIME_WAIT tcp 400 0 127.0.0.1:1152 127.0.0.1:8000 CLOSE_WAIT tcp 6648 0 127.0.0.1:1162 127.0.0.1:8000 CLOSE_WAIT tcp 553 0 127.0.0.1:1164 127.0.0.1:8000 CLOSE_WAIT udp 0 0 0.0.0.0:32768 0.0.0.0:* udp 0 0 192.168.1.1:53 0.0.0.0:* udp 0 0 127.0.0.1:53 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:*

Let's look at the first few lines of this in detail. On line one,

tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN

"Local Address" is 0.0.0.0, meaning "all" interfaces that are available. The local port is 515, or the standard print server port, usually owned by the lpd daemon. You can find a listing of common service names and corresponding ports in the file /etc/services.

The fact that it is listening on all interfaces is significant. In this case, that would be lo (localhost), eth0, and eth1. Printer connections could conceivably be made over any of these interfaces. Should a user on this system bring up a PPP connection, then the print daemon would be listening on that interface (ppp0) as well. The "Foreign Address" is also 0.0.0.0, meaning from "anywhere".

It is also worth noting here, that even though this server is telling the kernel to listen on all interfaces, the netstat output does not reflect whether there may be a firewall in place that may be filtering incoming connections. We just can't tell that at this point. Obviously, for certain servers, this is very desirable. Nobody outside your own LAN has any reason whatsoever to connect to your print server port for instance.

Line two is a little different:

tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN

Notice the "Local Address" this time is localhost's address of 127.0.0.1. This is very significant as only connections local to this machine will be accepted. So only bigcat can connect to bigcat's TCP port 8000. The security implications should be obvious. Not all servers have configuration options that allow this kind of restriction, but it is a very useful feature for those that do. Port 8000 in this example, is owned by the web proxy Junkbuster.

With the next three entries, we are back to listening on all available interfaces:

tcp 0 0 0.0.0.0:37 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN

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. Again, we can't tell from this output whether any firewall is in place, much less how effectively implemented it may be.

The web server on port 80 is not a huge security risk by itself. HTTP is a protocol that is often open to all comers. For instance, if we wanted to host our own home page, Apache can certainly do this for us. It is also possible to firewall this off, so that it is for use only to our LAN clients as part of an Intranet. Obviously too, if you do not have a good justification for running a web server, then it should be disabled completely.

The next two lines are interesting:

tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN

Again notice the "Local Address" is not 0.0.0.0. This is good! The port this time is 53, or the DNS port used by nameserver daemons like named. But we see the nameserver daemon is only listening on the lo interface (localhost), and the interface that connects bigcat to the LAN. So the kernel only allows connections from localhost, and the LAN. There will be no port 53 available to outside connections at all. This is a good example of how individual applications can sometimes be securely configured. In this case, we are probably looking at a caching DNS server since a real nameserver that is responsible for handling DNS queries would have to have port 53 open to the world. This is a security risk and requires special handling.

The last three LISTENER entries:

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN

These are back to listening on all available interfaces. Port 22 is sshd, the Secure Shell server daemon. This is a good sign! Notice that the service for port 631 does not have a service name if we look at the output in the first example. This might be a clue that something unusual is going on here. (See the next section for the answer to this riddle.) And lastly, port 25, the standard port for the SMTP mail daemon. Most Linux installations probably will have an SMTP daemon running, so this is not necessarily unusual. But is it necessary?

The next grouping is established connections. For our purposes the state of the connection as indicated by the last column is not so important. This is well explained in the man page.

tcp 0 1 169.254.179.139:1174 64.152.100.93:119 SYN_SENT tcp 0 1 169.254.179.139:1175 64.152.100.93:119 SYN_SENT tcp 0 1 169.254.179.139:1173 64.152.100.93:119 SYN_SENT tcp 0 0 169.254.179.139:1172 207.153.203.114:80 ESTABLISHED tcp 1 0 169.254.179.139:1199 216.26.129.136:80 CLOSE_WAIT tcp 0 0 169.254.179.139:80 63.236.92.144:34197 TIME_WAIT tcp 400 0 127.0.0.1:1152 127.0.0.1:8000 CLOSE_WAIT tcp 6648 0 127.0.0.1:1162 127.0.0.1:8000 CLOSE_WAIT tcp 553 0 127.0.0.1:1164 127.0.0.1:8000 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. The next two entries are connections to a remote web server as indicated by the port 80 after the colon in the fifth column. Probably a pretty common looking entry for most of us. But the one just after is reversed and has the port 80 in the fourth column, so this is someone that has connected to bigcat's web server via its external, Internet-side interface. The last three entries are all connections from localhost to localhost. So we are connecting to ourselves here. Remembering from above that port 8000 is bigcat's web proxy, this is a web browser that is connected to the locally running proxy. The proxy then will open an external connection of its own, which probably is what is going on with lines four and five.

Since we gave netstat both the -t and -u options, we are getting both the TCP and UDP listening servers. The last few lines are the UDP ones:

udp 0 0 0.0.0.0:32768 0.0.0.0:* udp 0 0 192.168.1.1:53 0.0.0.0:* udp 0 0 127.0.0.1:53 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:*

The last three entries have ports that are familiar from the above discussion. These are servers that are listening for both TCP and UDP connections. Same servers in this case, just using two different protocols. The first one on local port 32768 is new, and does not have a service name available to it in /etc/services. So at first glance this should be suspicious and pique our curiosity. See the next section for the explanation.

Can we draw any conclusions from this hypothetical situation? For the most part, these look to be pretty normal looking network services and connections for Linux. There does not seem to be an unduly high number of servers running here, but that by itself does not mean much since we don't know if all these servers are really required or not. We know that netstat can not tell us if any of these are effectively firewalled, so there is no way to say how secure all this might be. We also don't really know if all the listening services are really required by the owner here. That is something that varies widely from installation to installation. Does bigcat even have a printer attached for instance? Presumably it does, or this is a completely unnecessary risk.

8.3.2. Port and Process Owners

We've learned a lot about what is going on with bigcat's networking from the above section. But suppose we see something we don't recognize and want to know what started that particular service? Or we want to stop a particular server and it is not obvious from the above output?

The -p option should give us the process's PID and the program name that started the process in the last column. Let's look at the TCP servers again (with first three columns cropped for spacing). We'll have to run this as root to get all the available information:

# netstat -tap Active Internet connections (servers and established) Local Address Foreign Address State PID/Program name *:printer *:* LISTEN 988/inetd bigcat:8000 *:* LISTEN 1064/junkbuster *:time *:* LISTEN 988/inetd *:x11 *:* LISTEN 1462/X *:http *:* LISTEN 1078/httpd bigcat:domain *:* LISTEN 956/named bigcat:domain *:* LISTEN 956/named *:ssh *:* LISTEN 972/sshd *:631 *:* LISTEN 1315/cupsd *:smtp *:* LISTEN 1051/master

Some of these we already know about. But we see now that the printer daemon on port 515 is being started via inetd with a PID of "988". inetd is a special situation. inetd is often called the "super server", since it's main role is to spawn sub-services. xinetd replaces inetd as of Red Hat 7.0. If we look at the first line, inetd is listening on port 515 for printer services. If a connection comes for this port, inetd intercepts it, and then will spawn the appropriate daemon, i.e. the print daemon in this case. The configuration of how inetd handles this is typically done in /etc/inetd.conf. This should tell us that if we want to stop an inetd controlled server on a permanent basis, then we will have to dig into the inetd (or perhaps xinetd) configuration. Also the time service above is started via inetd as well. This should also tell us that these two services can be further protected by tcpwrappers (discussed in Step 3 above). This is one benefit of using inetd to control certain system services.

We weren't sure about the service on port 631 above since it did not have a standard service name, which means it is something maybe unusual or off the beaten path. Now we see it is owned by cupsd (not included with Red Hat by the way), which is one of several print daemons available under Linux. This happens to be the web interface for controlling the printer service. Something cupsd does that is indeed a little different than other print servers.

The last entry above is the SMTP mail server on bigcat. Often, this is sendmail. But not in this case. The command is "master", which may not ring any bells. Armed with the program name we could go searching the filesystem with tools like the locate or find commands. After we found it, we could then probably discern what package it belonged to. But with the PID available now, we can look at ps output, and see if that helps us any:

$ /bin/ps ax |grep 1051 |grep -v grep 1051 ? S 0:24 /usr/libexec/postfix/master

We took a shortcut here by combining ps with grep. It looks like that this file belongs to postfix, which is indeed a mail server package comparable to sendmail ( and is included with Powertools, not the base distribution).

Running ps with the --forest flag (-f for short) can be helpful in determining what processes are parent or child process or another process. An edited example:

$ /bin/ps -axf 956 ? S 0:00 named -u named 957 ? S 0:00 \_ named -u named 958 ? S 0:46 \_ named -u named 959 ? S 0:47 \_ named -u named 960 ? S 0:00 \_ named -u named 961 ? S 0:11 \_ named -u named 1051 ? S 0:30 /usr/libexec/postfix/master 1703 ? S 0:00 \_ tlsmgr -l -t fifo -u -c 1704 ? S 0:00 \_ qmgr -l -t fifo -u -c 1955 ? S 0:00 \_ pickup -l -t fifo -c 1863 ? S 0:00 \_ trivial-rewrite -n rewrite -t unix -u -c 2043 ? S 0:00 \_ cleanup -t unix -u -c 2049 ? S 0:00 \_ local -t unix 2062 ? S 0:00 \_ smtpd -n smtp -t inet -u -c

A couple of things to note here. We have two by now familiar daemons here: named and postfix (smtpd). Both are spawning sub-processes. In the case of named, what we are seeing is threads, various sub-processes that it always spawns. Postfix is also spawning sub-processes, but not as "threads". Each sub-process has its own specific task. It is worth noting that child processes are dependent on the parent process. So killing the parent PID, will in turn kill all child processes.

If all this has not shed any light, we might also try locate:

$ locate /master /etc/postfix/master.cf /var/spool/postfix/pid/master.pid /usr/libexec/postfix/master /usr/share/vim/syntax/master.vim /usr/share/vim/vim60z/syntax/master.vim /usr/share/doc/postfix-20010202/html/master.8.html /usr/share/doc/postfix-20010202/master.cf /usr/share/man/man8/master.8.gz

find is perhaps the most flexible file finding utility, but doesn't use a database the way locate does, so is much slower:

$ find / -name master /usr/libexec/postfix/master

If lsof is installed, it is another command that is useful for finding who owns processes or ports:

# lsof -i :631 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME cupsd 1315 root 0u IPv4 3734 TCP *:631 (LISTEN)

This is again telling us that the cupsd print daemon is the owner of port 631. Just a different way of getting at it. Yet one more way to get at this is with fuser, which should be installed:

# fuser -v -n tcp 631 USER PID ACCESS COMMAND 631/tcp root 1315 f.... 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. Or we can use grep to search inside files and match a search pattern. Need to find where rpc.statd is being started, and we don't see a script by this name?

# grep rpc.statd /etc/init.d/* /etc/init.d/nfslock: [ -x /sbin/rpc.statd ] || exit 0 /etc/init.d/nfslock: daemon rpc.statd /etc/init.d/nfslock: killproc rpc.statd /etc/init.d/nfslock: status rpc.statd /etc/init.d/nfslock: /sbin/pidof rpc.statd >/dev/null 2>&1; STATD="$?"

We didn't really need all that information, but at least we see now exactly which script is starting it. Remember too that not all services are started this way. Some may be started via inetd, or xinetd.

The /proc filesystem also keeps everything we want to know about processes that are running. We can query this to find out more information about each process. Do you need to know the full path of the command that started a process?

# ls -l /proc/1315/exe lrwxrwxrwx 1 root root 0 July 4 19:41 /proc/1315/exe -> /usr/sbin/cupsd

Finally, we had a loose end or two in the UDP listening services. Remember we had a strange looking port number 32768, that also had no service name associated with it:

# netstat -aup Active Internet connections (servers and established) Local Address Foreign Address State PID/Program name *:32768 *:* 956/named bigcat:domain *:* 956/named bigcat:domain *:* 956/named *:631 *:* 1315/cupsd

Now by including the "PID/Program name" option with the -p flag, we see this also belongs to named, the nameserver daemon. Recent versions of BIND use an unprivileged port for some types of traffic. In this case, this is BIND 9.x. So no real alarms here either. The unprivileged port here is the one named uses to to talk to other nameservers for name and address lookups, and should not be firewalled.

So we found no big surprises in this hypothetical situation.

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. Or you can use rpcinfo -p localhost to see what RPC services may be running (portmap must be running for this to work).

If you suspect you have been broken into, do not trust netstat or ps output. There is a good chance that they, and other system components, has been tampered with in such a way that the output is not reliable.

8.4.1. Port Scans and Probes

First, let's define "scan" and "probe" since these terms come up quite a bit. A "probe" implies testing if a given port is open or closed, and possibly what might be listening on that port. A "scan" implies either "probing" multiple ports on one or more systems. Or individual ports on multiple systems. So you might "scan" all ports on your own system for instance. Or a cracker might "scan" the 216.78.*.* address range to see who has port 111 open.

Black hats can use scan and probe information to know what services are running on a given system, and then they might know what exploits to try. They may even be able to tell what Operating System is running, and 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. You might ask a friend to scan you, for instance, to see how well your firewall is working. This is a legitimate use of scanning tools such as nmap. But what if someone you don't know does this? What is their intent? If it's your ISP, they may be trying to enforce their Terms of Service Agreement. Or maybe, it is someone just playing, and seeing who is "out there". But more than likely it is someone or something with not such good intentions.

Full range port scans (meaning probing of many ports on the same machine) seem to be a not so common threat for home based networks. But certainly, scanning individual ports across numerous systems is a very, very common occurrence.

8.4.2. Rootkits

A "rootkit" is the script kiddie's stock in trade. When a successful intrusion takes place, the first thing that is often done, is to download and install such "rootkits". The rootkit is a set of scripts designed to take control of the system, and then hide the intrusion. Rootkits are readily available on the web for various Operating Systems.

A rootkit will typically replace critical system files such as ls, ps, netstat, login and others. Passwords may be added, hidden daemons started, logs tampered with, and surely one of more backdoors are opened. The hidden backdoors allow easy access any time the attacker wants back in. And often the vulnerability itself may even be fixed so that the new "owner" has the system all to himself. The entire process is scripted so it happens very quickly. The rightful owners of these compromised systems generally have no idea what is going on, and are victims themselves. A well designed rootkit can be very difficult to detect.

8.4.3. Worms and Zombies

A "worm" is a self replicating exploit. It infects a system, then attempts to spread itself typically via the same vulnerability. Various "worms" are weaving their way through the entire Internet address space constantly, spreading themselves as they go.

But somewhere behind the zombie, there is a controller. Someone launched the worm, and they will be informed after a successful intrusion. It is then up to them how the system will be used.

Many of these are Linux systems, looking for other Linux systems to "infect" via a number of exploits. But most Operating Systems share in this threat. Once a vulnerable system is found, the actual entry and take over is quick, and may be difficult to detect after the fact. The first thing an intruder (whether human or "worm") will do is attempt to cover their tracks. A "rootkit" is downloaded and installed. This trend has been exacerbated by the growing popularity of cable modems and DSL. The number of full time Internet connections is growing rapidly, and this makes fertile ground for such exploits since often these aren't as well secured as larger sites.

While this may sound ominous, a few simple precautions can effectively deter this type of attack. With so many easy victims out there, why waste much effort breaking into your system? There is no incentive to 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. If you remember the "Iptables Weekly Log Summary" in the opening section above, many of those may have all been the result of this type of scan. If you've followed the steps in this HOWTO, you should be reasonably safe here. This one is easy enough to deflect.

8.4.4. Script Kiddies

A "script kiddie" is a "cracker" wanna be who doesn't know enough to come up with his/her own exploits, but instead relies on "scripts" and exploits that have been developed by others. Like "worms", they are looking for easy victims, and may similarly scan large address ranges looking for specific ports with known vulnerabilities. Often, the actual scanning is done from already comprised systems so that it is difficult to trace it back to them.

The script kiddie has a bag of ready made tricks at his disposal, including an arsenal of "rootkits" for various Operating Systems. Finding susceptible victims is not so hard, given enough time and address space to probe. The motives are a mixed bag as well. Simple mischief, defacement of web sites, stolen credit card numbers, and the latest craze, "Denial of Service" attacks (see below). They collect zombies like trophies and use them to carry out whatever their objective is.

Again, the key here is that they are following a "script", and looking for easy prey. Like the worm threat above, a functional firewall and a few very basic precautions, should be sufficient to deflect any threat here. By now, you should be relatively safe from this nuisance.

8.4.5. Spoofed IPs

How easy is it to spoof an IP address? With the right tools, very easy. How much of a threat is this? Not much, for most of us, and is over-hyped as a threat.

Because of the way TCP/IP works, each packet must carry both the source and destination IP addresses. Any return traffic is based on this information. So a spoofed IP can never return any useful information to an attacker who is sending out spoofed packets. The traffic would go back to wherever that spoofed IP address was pointed. The attacker gets nothing back at all.

This does have potential for "DoS" attacks (see below) where learning something about the targeted system is not important. And may be used for some general mischief making as well.

8.4.6. Targeted Attacks

The worm and wide ranging address type scans, are impersonal. They are just looking for any vulnerable system. It makes no difference whether it is a top secret government facility, or your mother's Window's box. But there are "black hats" that will spend a great deal of effort to get into a system or network. We'll call these "targeted" attacks since there has been a deliberate decision made to break in to a specific system or 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. There just generally isn't any incentive to take the time and effort when there are bigger fish to fry. For those who may be targets, the best defense here includes many of things we've discussed. Vigilance is probably more important than ever. Good logging practices and an IDS (Intrusion Detection System) should be in place. And subscribing to one or more security related mailing lists like BUGTRAQ. And of course, reading those alerts daily, and taking the appropriate actions, etc.

8.4.7. Denial of Service (DoS)

"DoS" is another type of "attack" in which the intention is to disrupt or overwhelm the targeted system or network in such a way that it cannot function normally. DoS can take many forms. On the Internet, this often means overwhelming the victim's bandwidth or TCP/IP stack, by sending floods of packets and thus effectively disabling the connection. We are talking about many, many packets per second. Thousands in some cases. Or perhaps, the objective is to crash a server.

This is much more likely to be targeted at organizations or high profile sites, than home users. And can be quite challenging to stop depending on the technique. And it generally requires the co-operation of networks between the source(s) and the target, so that the floods are stopped, or minimized, before they reach the targeted destination. Once they hit the destination, there is no good way to completely ignore them.

"DDoS", Distributed Denial of Service, is where multiple sources are used to maximize the impact. Again, not likely to be directly targeted at home users. These are "slaves" that are "owned" by a cracker, or script kiddie, that are woken up and are targeted at the victim. There may be many computers involved in the attack.

If you are home user, and with a dynamic IP address, you might find disconnecting, then re-connecting to get a new IP, an effective way out if you are the target. Maybe.

8.4.8. Brute Force

"Brute force" attacks are where the attacker makes repetitive attempts at the same perceived weakness(es). Like a battering ram. A classic example would be where someone tries to access a telnet server simply by continually throwing passwords at it, hoping that one will eventually work. Or maybe crash the server. This doesn't require much imagination, and is not a commonly used tactic against home systems.

By the way, this is one good argument against allowing remote root logins. The root account exists on all systems. It is probably the only one that this is true of. You'd like to make a potential attacker guess both the login name and password. But if root is allowed remote logins, then the attacker only needs to guess the password!

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. So Anti-Virus software is not recommended as part of our arsenal. At least for the time being with Linux only networks.

8.10.1. ipchains II

#!/bin/sh # # ipchains.sh # # An example of a simple ipchains configuration. This script # can enable 'masquerading' and will open user definable ports. # ################################################################### # Begin variable declarations and user configuration options ###### # # 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...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. #PUBLIC_PORTS="22 80 443" PUBLIC_PORTS="22" # If we want to do port forwarding, this is the host # that will be forwarded to. #FORWARD_HOST="192.168.1.3" # A list of ports that are to be forwarded. #FORWARD_PORTS="25 80" # If you get your public IP address via DHCP, set this. DHCP_SERVER=66.21.184.66 # If you need identd for a mail server, set this. MAIL_SERVER= # A list of unwelcome hosts or nets. These will be denied access # to everything, even our 'PUBLIC' services. Provide your own list. #BLACKLIST="11.22.33.44 55.66.77.88" # A list of "trusted" hosts and/or nets. These will have access to # ALL protocols, and ALL open ports. Be selective here. #TRUSTED="1.2.3.4/8 5.6.7.8" ## end user configuration options ################################# ################################################################### # The high ports used mostly for connections we initiate and return # traffic. LOCAL_PORTS=`cat /proc/sys/net/ipv4/ip_local_port_range |cut -f1`:\ `cat /proc/sys/net/ipv4/ip_local_port_range |cut -f2` # Any and all addresses from anywhere. ANYWHERE="0/0" # Start building chains and rules ################################# # # 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. WAN_IP will be our # IP address we are protecting from the outside world. Put this # here, so default policy gets set, even if interface is not up # yet. [ -z "$WAN_IP" ] &&\ WAN_IP=`ifconfig $WAN_IFACE |grep inet |cut -d : -f 2 |cut -d \ -f 1` # Bail out with error message if no IP available! Default policy is # 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. $IPCHAINS -A input -l -i $WAN_IFACE -s 10.0.0.0/8 -j DENY $IPCHAINS -A input -l -i $WAN_IFACE -s 172.16.0.0/12 -j DENY $IPCHAINS -A input -l -i $WAN_IFACE -s 192.168.0.0/16 -j DENY $IPCHAINS -A input -l -i $WAN_IFACE -s 127.0.0.0/8 -j DENY $IPCHAINS -A input -l -i $WAN_IFACE -s 169.254.0.0/16 -j DENY $IPCHAINS -A input -l -i $WAN_IFACE -s 224.0.0.0/4 -j DENY $IPCHAINS -A input -l -i $WAN_IFACE -s 240.0.0.0/5 -j DENY # Bogus routing $IPCHAINS -A input -l -s 255.255.255.255 -d $ANYWHERE -j DENY ## LAN access and masquerading # # Allow connections from our own LAN's private IP addresses via the LAN # interface and set up forwarding for masqueraders if we have a LAN_NET # defined above. if [ -n "$LAN_NET" ]; then echo 1 > /proc/sys/net/ipv4/ip_forward $IPCHAINS -A input -i $LAN_IFACE -j ACCEPT $IPCHAINS -A forward -s $LAN_NET -d $LAN_NET -j ACCEPT $IPCHAINS -A forward -s $LAN_NET -d ! $LAN_NET -j MASQ fi ## Blacklist hosts/nets # # Get the blacklisted hosts/nets out of the way, before we start opening # up any services. These will have no access to us at all, and will be # logged. for i in $BLACKLIST; do $IPCHAINS -A input -l -s $i -j DENY done ## 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. Check first! [ -n "$FORWARD_HOST" ] && ipmasqadm portfw -f &&\ for i in $FORWARD_PORTS; do ipmasqadm portfw -a -P tcp -L $WAN_IP $i -R $FORWARD_HOST $i done ## Open, but Restricted Access ports/services # # Allow DHCP server (their port 67) to client (to our port 68) UDP traffic # from outside source. [ -n "$DHCP_SERVER" ] &&\ $IPCHAINS -A input -p udp -s $DHCP_SERVER 67 -d $ANYWHERE 68 -j ACCEPT # Allow 'identd' (to our TCP port 113) from mail server only. [ -n "$MAIL_SERVER" ] &&\ $IPCHAINS -A input -p tcp -s $MAIL_SERVER -d $WAN_IP 113 -j ACCEPT # Open up PUBLIC server ports here (available to the world): for i in $PUBLIC_PORTS; do $IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $i -j ACCEPT done # So I can check my home POP3 mailbox from work. Also, so I can ssh # in to home system. Only allow connections from my workplace's # various IPs. Everything else is blocked. $IPCHAINS -A input -p tcp -s 255.10.9.8/29 -d $WAN_IP 110 -j ACCEPT # Uncomment to allow ftp data back (active ftp). Not required for 'passive' # ftp connections. #$IPCHAINS -A input -p tcp -s $ANYWHERE 20 -d $WAN_IP $LOCAL_PORTS -y -j ACCEPT # Accept non-SYN TCP, and UDP connections to LOCAL_PORTS. These are # the high, unprivileged ports (1024 to 4999 by default). This will # allow return connection traffic for connections that we initiate # to outside sources. TCP connections are opened with 'SYN' packets. # We have already opened those services that need to accept SYNs # for, so other SYNs are excluded here for everything else. $IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS ! -y -j ACCEPT # We can't be so selective with UDP since that protocol does not know # about SYNs. $IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS -j ACCEPT # Allow access to the masquerading ports conditionally. Masquerading # uses it's own port range -- on 2.2 kernels ONLY! 2.4 kernels, do not # use these ports, so comment out! [ -n "$LAN_NET" ] &&\ $IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP 61000: ! -y -j ACCEPT &&\ $IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP 61000: -j ACCEPT ## 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. $IPCHAINS -A input -p icmp --icmp-type echo-reply \ -s $ANYWHERE -i $WAN_IFACE -j ACCEPT $IPCHAINS -A input -p icmp --icmp-type destination-unreachable \ -s $ANYWHERE -i $WAN_IFACE -j ACCEPT $IPCHAINS -A input -p icmp --icmp-type time-exceeded \ -s $ANYWHERE -i $WAN_IFACE -j ACCEPT ####################################################################### # Set the catchall, default rule to DENY, and log it all. All other # traffic not allowed by the rules above, winds up here, where it is # blocked and logged. This is the default policy for this chain # anyway, so we are just adding the logging ability here with '-l'. # Outgoing traffic is allowed as the default policy for the 'output' # chain. There are no restrictions on that. $IPCHAINS -A input -l -j DENY echo "Ipchains firewall is up `date`." ##-- eof ipchains.sh

8.10.2. iptables II

#!/bin/sh # # iptables.sh # # An example of a simple iptables configuration. This script # can enable 'masquerading' and will open user definable ports. # ################################################################### # Begin variable declarations and user configuration options ###### # # Set the location of iptables (default). IPTABLES=/sbin/iptables # 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...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. #PUBLIC_PORTS="22 80 443" PUBLIC_PORTS="22" # If we want to do port forwarding, this is the host # that will be forwarded to. #FORWARD_HOST="192.168.1.3" # A list of ports that are to be forwarded. #FORWARD_PORTS="25 80" # If you get your public IP address via DHCP, set this. DHCP_SERVER=66.21.184.66 # If you need identd for a mail server, set this. MAIL_SERVER= # A list of unwelcome hosts or nets. These will be denied access # to everything, even our 'Public' services. Provide your own list. #BLACKLIST="11.22.33.44 55.66.77.88" # A list of "trusted" hosts and/or nets. These will have access to # ALL protocols, and ALL open ports. Be selective here. #TRUSTED="1.2.3.4/8 5.6.7.8" ## end user configuration options ################################# ################################################################### # Any and all addresses from anywhere. ANYWHERE="0/0" # These modules may need to be loaded: modprobe ip_conntrack_ftp modprobe ip_nat_ftp # Start building chains and rules ################################# # # Let's start clean and flush all chains to an empty state. $IPTABLES -F $IPTABLES -X # Set the default policies of the built-in chains. If no match for any # of the rules below, these will be the defaults that IPTABLES uses. $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT ACCEPT $IPTABLES -P INPUT DROP # Accept localhost/loopback traffic. $IPTABLES -A INPUT -i lo -j ACCEPT # Get our dynamic IP now from the Inet interface. WAN_IP will be the # address we are protecting from outside addresses. [ -z "$WAN_IP" ] &&\ WAN_IP=`ifconfig $WAN_IFACE |grep inet |cut -d : -f 2 |cut -d \ -f 1` # Bail out with error message if no IP available! Default policy is # 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.0/12 -j DROP $IPTABLES -A INPUT -i $WAN_IFACE -s 192.168.0.0/16 -j DROP $IPTABLES -A INPUT -i $WAN_IFACE -s 127.0.0.0/8 -j DROP $IPTABLES -A INPUT -i $WAN_IFACE -s 169.254.0.0/16 -j DROP $IPTABLES -A INPUT -i $WAN_IFACE -s 224.0.0.0/4 -j DROP $IPTABLES -A INPUT -i $WAN_IFACE -s 240.0.0.0/5 -j DROP # Bogus routing $IPTABLES -A INPUT -s 255.255.255.255 -d $ANYWHERE -j DROP # Unclean $IPTABLES -A INPUT -i $WAN_IFACE -m unclean -m limit \ --limit 15/minute -j LOG --log-prefix "Unclean: " $IPTABLES -A INPUT -i $WAN_IFACE -m unclean -j DROP ## LAN access and masquerading # # Allow connections from our own LAN's private IP addresses via the LAN # interface and set up forwarding for masqueraders if we have a LAN_NET # defined above. if [ -n "$LAN_NET" ]; then echo 1 > /proc/sys/net/ipv4/ip_forward $IPTABLES -A INPUT -i $LAN_IFACE -j ACCEPT # $IPTABLES -A INPUT -i $LAN_IFACE -s $LAN_NET -d $LAN_NET -j ACCEPT $IPTABLES -t nat -A POSTROUTING -s $LAN_NET -o $WAN_IFACE -j MASQUERADE fi ## Blacklist # # Get the blacklisted hosts/nets out of the way, before we start opening # up any services. These will have no access to us at all, and will # be logged. for i in $BLACKLIST; do $IPTABLES -A INPUT -s $i -m limit --limit 5/minute \ -j LOG --log-prefix "Blacklisted: " $IPTABLES -A INPUT -s $i -j DROP done ## Trusted hosts/nets # # This is our trusted host list. These have access to everything. for i in $TRUSTED; do $IPTABLES -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. [ -n "$FORWARD_HOST" ] &&\ for i in $FORWARD_PORTS; do $IPTABLES -A FORWARD -p tcp -s $ANYWHERE -d $FORWARD_HOST \ --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. [ -n "$MAIL_SERVER" ] &&\ $IPTABLES -A INPUT -p tcp -s $MAIL_SERVER -d $WAN_IP --dport 113 -j ACCEPT # Open up Public server ports here (available to the world): for i in $PUBLIC_PORTS; do $IPTABLES -A INPUT -p tcp -s $ANYWHERE -d $WAN_IP --dport $i -j ACCEPT done # So I can check my home POP3 mailbox from work. Also, so I can ssh # in to home system. Only allow connections from my workplace's # various IPs. Everything else is blocked. $IPTABLES -A INPUT -p tcp -s 255.10.9.8/29 -d $WAN_IP --dport 110 -j ACCEPT ## 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. $IPTABLES -A INPUT -p icmp --icmp-type echo-reply \ -s $ANYWHERE -d $WAN_IP -j ACCEPT $IPTABLES -A INPUT -p icmp --icmp-type destination-unreachable \ -s $ANYWHERE -d $WAN_IP -j ACCEPT $IPTABLES -A INPUT -p icmp --icmp-type time-exceeded \ -s $ANYWHERE -d $WAN_IP -j ACCEPT # Identd Reject # # Special rule to reject (with rst) any identd/auth/port 113 # connections. This will speed up some services that ask for this, # but don't require it. Be careful, some servers may require this # one (IRC for instance). #$IPTABLES -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset ################################################################### # Build a custom chain here, and set the default to DROP. All # other traffic not allowed by the rules above, ultimately will # wind up here, where it is blocked and logged, unless it passes # our stateful rules for ESTABLISHED and RELATED connections. Let # connection tracking do most of the worrying! We add the logging # ability here with the '-j LOG' target. Outgoing traffic is # allowed as that is the default policy for the 'output' chain. # There are no restrictions placed on that in this script. # New chain... $IPTABLES -N DEFAULT # Use the 'state' module to allow only certain connections based # on their 'state'. $IPTABLES -A DEFAULT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A DEFAULT -m state --state NEW -i ! $WAN_IFACE -j ACCEPT # Enable logging for anything that gets this far. $IPTABLES -A DEFAULT -j LOG -m limit --limit 30/minute --log-prefix "Dropping: " # Now drop it, if it has gotten here. $IPTABLES -A DEFAULT -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. This is for both the FORWARD and # INPUT chains. $IPTABLES -A FORWARD -j DEFAULT $IPTABLES -A INPUT -j DEFAULT echo "Iptables firewall is up `date`." ##-- eof iptables.sh

8.10.3. Summary

A quick run down of the some highlights...

We added some host based access control rules: "blacklisted", and "trusted". We then showed several types of service and port based access rules. For instance, we allowed some very restrictive access to bigcat's POP3 server so we could connect only from our workplace. We allowed a very narrow rule for the ISP's DHCP server. This rule only allows one port on one outside IP address to connect to only one of our ports and only via the UDP protocol. This is a very specific rule! We are being specific since there is no reason to allow any other traffic to these ports or from these addresses. Remember our goal is the minimum amount of traffic necessary for our particular situation.

So we made those few exceptions mentioned above, and all other services running on bigcat should be effectively blocked completely from outside connections. These are still happily running on bigcat, but are now safe and sound behind our packet filtering firewall. You probably have other services that fall in this category as well.

We also have a small, home network in the above example. We did not take any steps to block that traffic. So the LAN has access to all services running on bigcat. And it is further "masqueraded", so that it has Internet access (different HOWTO), by manipulating the "forward" chain. And the LAN is still protected by our firewall since it sits behind the firewall. We also didn't impose any restrictive rules on the traffic leaving bigcat. In some situations, this might be a good idea.

Of course, this is just a hypothetical example. Your individual situation is surely different, and would require some changes and likely some additions to the rules above. For instance, if your ISP does not use DHCP (most do not), then that rule would make no sense. PPP works differently and such rules are not needed.

Please don't interpret that running any server as we did in this example is necessarily a "safe" thing to do. We shouldn't do it this way unless a) we really need to and b) we are running the current, safe version, and c) we are able to keep abreast of security related issues that might effect these services. Vigilance and caution are part of our responsibilities here too.

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). insmod ip_conntrack insmod ip_conntrack_ftp ## Create chain which blocks new connections, except if coming from inside. iptables -N block iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT iptables -A block -j DROP ## Jump to that chain from INPUT and FORWARD chains. iptables -A INPUT -j block iptables -A FORWARD -j block

This simple script will allow all outbound connections that we initiate, i.e. any NEW connections (since the default policy of ACCEPT is not changed). Then any connections that are "ESTABLISHED" and "RELATED" to these are also allowed. And, any connections that are not incoming from our WAN side interface, ppp0, are also allowed. This would be lo or possibly a LAN interface like eth1. So we can do whatever we want, but no unwanted, incoming connection attempts are allowed from the Internet. None.

This script also demonstrates the creation of a custom chain, defined here as "block", which is used both for the INPUT and FORWARD chains.