<HTML
><HEAD
><TITLE
>Appendix</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="Security Quick-Start HOWTO for Red Hat Linux"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="General Tips"
HREF="general.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Security Quick-Start HOWTO for Red Hat Linux</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="general.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
> </TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="APPENDIX">8. Appendix</H1
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="SERVERSETC">8.1. Servers, Ports, and Packets</H2
><P
> 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.</P
><P
> As you may have noticed Linux is a very network oriented Operating System.
Much is done by connecting to <SPAN
CLASS="QUOTE"
>"servers"</SPAN
> of one type or another
-- X servers, font servers, print servers, etc. </P
><P
> Servers provide <SPAN
CLASS="QUOTE"
>"services"</SPAN
>, which provide various capabilities,
both to the local system and potentially other remote systems. The same
server generally provides both functionalities. Some servers
work quietly behind the scenes, and others are more interactive by nature. We
may only be aware of a print server when we need to print something, but it
is there running, listening, and waiting for connection requests whether we
ever use it or not (assuming of course we have it enabled). A typical Linux
installation will have many, many types of servers available to it. Default
installations often will turn some of these <SPAN
CLASS="QUOTE"
>"on"</SPAN
>.</P
><P
> And even if we are not connected to a real network all the time, we are still
<SPAN
CLASS="QUOTE"
>"networked"</SPAN
> so to speak. Take our friendly local X server for
instance. We may tend to think of this as just providing a GUI interface,
which is only true to a point. It does this by <SPAN
CLASS="QUOTE"
>"serving"</SPAN
> to
client applications, and thus is truly a server. But X Windows is also
capable of serving remote clients over a network -- even large networks like
the Internet. Though we probably don't really want to be doing this ;-)</P
><P
> And yes, if you are not running a firewall or have not taken other
precautions, and are connected to the Internet, it is quite possible that
someone -- anyone -- could connect to your X server. X11
<SPAN
CLASS="QUOTE"
>"listens"</SPAN
> on TCP <SPAN
CLASS="QUOTE"
>"port"</SPAN
> 6000 by default. This
principle applies to most other servers as well -- they can be easily
connected to, unless something is done to restrict or prevent connections.</P
><P
> In TCP/IP (Transmission Control Protocol/Internet Protocol) networks like we
are talking about with Linux and the Internet, every connected computer
has a unique <SPAN
CLASS="QUOTE"
>"IP Address"</SPAN
>. Think of this like a phone number.
You have a phone number, and in order to call someone else, you have to know
that phone number, and then dial it. The phone numbers have to be unique for
the system to work. IP address are generally expressed as <SPAN
CLASS="QUOTE"
>"dotted
quad"</SPAN
> notation, e.g. 152.19.254.81. </P
><P
> On this type of network, servers are said to <SPAN
CLASS="QUOTE"
>"listen"</SPAN
>. This
means that they have a <SPAN
CLASS="QUOTE"
>"port"</SPAN
> opened, and are awaiting incoming
connections to that port. Connections may be local, as is typically the case
with our X server, or remote -- meaning from another computer
<SPAN
CLASS="QUOTE"
>"somewhere"</SPAN
>. So servers <SPAN
CLASS="QUOTE"
>"listen"</SPAN
> on a specific
<SPAN
CLASS="QUOTE"
>"port"</SPAN
> for incoming connections. Most servers have a default
port, such as port 80 for web servers. Or 6000 for X11. See
<TT
CLASS="FILENAME"
>/etc/services</TT
> for a list of common ports and their
associated service. </P
><P
> The <SPAN
CLASS="QUOTE"
>"port"</SPAN
> is actually just an address in the kernel's
networking stack, and is a method that TCP, and other protocols, use to
organize connections and the exchange of data between computers. There are
total of 65,536 TCP and UDP ports available, though usually only a relatively
few of these are used at any one time. These are classified as
<SPAN
CLASS="QUOTE"
>"privileged"</SPAN
>, those ports below 1024, and
<SPAN
CLASS="QUOTE"
>"unprivileged"</SPAN
>, 1024 and above. Most servers use the privileged
ports. </P
><P
> Only one server may listen on, or <SPAN
CLASS="QUOTE"
>"bind"</SPAN
> to, a port at a time.
Though that server may well be able to open multiple connections via that one
port. Computers talk to each other via these <SPAN
CLASS="QUOTE"
>"port"</SPAN
> connections.
One computer will open a connection to a <SPAN
CLASS="QUOTE"
>"port"</SPAN
> on another
computer, and thus be able to exchange data via the connection that has been
established between their respective ports. </P
><P
> 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
<SPAN
CLASS="QUOTE"
>"departments"</SPAN
>: sales, shipping, billing, receiving, customer
service, R&D, etc. Each department has it's own <SPAN
CLASS="QUOTE"
>"extension"</SPAN
>
number. So the shipping department might be extension 21, the sales might be
department 80 and so on. The main phone number is the IP Address, and the
department's extension is the port in this analogy. The
<SPAN
CLASS="QUOTE"
>"department's"</SPAN
> number is always the same when we call. And
generally they can handle many simultaneous incoming calls.
</P
><P
> The data itself is contained in <SPAN
CLASS="QUOTE"
>"packets"</SPAN
>, which are small
chunks of data, generally 1500 bytes or less each. Packets are used to
control and organize the connection, as well as carry data. There are
different types of packets. Some are specifically used for controlling the
connection, and then some packets carry our data as their payload. If
there is a lot of data, it will be broken up into multiple packets which is
almost always how it works. The packets will be transmitted one at a time,
and then <SPAN
CLASS="QUOTE"
>"re-assembled"</SPAN
> at the other end. One web page for
instance, will take many packets to transmit -- maybe hundreds or even
thousands. This all happens very quickly and transparently. </P
><P
> We can see a typical connection between two computers in this one line
excerpt from <B
CLASS="COMMAND"
>netstat</B
> output:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> tcp 30 0 169.254.179.139:1359 18.29.1.67:21 CLOSE_WAIT
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> The interesting part is the IP addresses and ports in the fourth and fifth
columns. The port is the number just to the right of the colon. The left side
of the colon is the IP address of each computer. The fourth column is the
local address, or our end of the connection. In the example, 169.254.179.139
is the IP address assigned by my ISP. It is connected to port 21
(FTP) on 18.29.1.67, which is rpmfind.net. This is just after an FTP download
from rpmfind.net. Note that while I am connected to their FTP server on their
port 21, the port on my end that is used by my FTP client is 1359. This is a
randomly assigned <SPAN
CLASS="QUOTE"
>"unprivileged"</SPAN
> port, used for my end of the
two-way <SPAN
CLASS="QUOTE"
>"conversation"</SPAN
>. The data moves in both directions:
me:port#1359 <-> them:port#21. The FTP protocol is actually a little
more complicated than this, but we won't delve into the finer points here.
The <TT
CLASS="LITERAL"
>CLOSE_WAIT</TT
> is the TCP state of the connection at this
particular point in time. Eventually the connection will close completely on
both ends, and <SPAN
CLASS="APPLICATION"
>netstat</SPAN
> will not show anything for
this.
</P
><P
> The <SPAN
CLASS="QUOTE"
>"unprivileged"</SPAN
> port that is used for my end of the
connection, is temporary and is not associated with a locally running server.
It will be closed by the kernel when the connection is terminated. This is
quite different than the ports that are kept open by <SPAN
CLASS="QUOTE"
>"listening"</SPAN
>
servers, which are permanent and remain <SPAN
CLASS="QUOTE"
>"open"</SPAN
> even after a
remote connection is terminated.</P
><P
> So to summarize using the above example, we have client (me) connecting
to a server (rpmfind.net), and the connection is defined and controlled by
the respective ports on either end. The data is transmitted and controlled by
packets. The server is using a <SPAN
CLASS="QUOTE"
>"privileged"</SPAN
> port (i.e. a port
below number 1024) which stays open listening for connections. The
<SPAN
CLASS="QUOTE"
>"unprivileged"</SPAN
> port used on my end by my client application is
temporary, is only opened for the duration of the connection, and only
responds to the server's port at the other end of the connection. This type
of port is not vulnerable to attacks or break-ins generally speaking. The
server's port is vulnerable since it remains open. The administrator of the
FTP server will need to take appropriate precautions that his server is
secure. Other Internet connections, such as to web servers or mail servers,
work similar to the above example, though the server ports are different.
SMTP mail servers use port 25, and web servers typically use port 80.
See the <A
HREF="appendix.html#PORTS"
>Ports section</A
> for other commonly used
ports and services.</P
><P
> 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.
</P
><P
> And a final point on the distinction between clients and servers. The example
above did not have a <B
CLASS="COMMAND"
>telnet</B
> or <B
CLASS="COMMAND"
>ftp</B
>
server in the <TT
CLASS="LITERAL"
>LISTENER</TT
> section in the
<B
CLASS="COMMAND"
>netstat</B
> example above. In other words, no such servers
were running locally. You do not need to run a <B
CLASS="COMMAND"
>telnet</B
> or
<B
CLASS="COMMAND"
>ftp</B
> server daemon in order to connect to
<EM
>somebody else's</EM
> <B
CLASS="COMMAND"
>telnet</B
> or
<B
CLASS="COMMAND"
>ftp</B
> server. These are only for providing these services
to others that would be making connections to you. Which you don't really
want to be doing in most cases. This in no way effects the ability to use
<B
CLASS="COMMAND"
>telnet</B
> and <B
CLASS="COMMAND"
>ftp</B
> client software. </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PORTS">8.2. Common Ports</H2
><P
> A quick run down of some commonly seen and used ports, with the commonly
associated service name, and risk factor. All have <EM
>some</EM
>
risk. It is just that some have historically had more exploits than others.
That is how they are evaluated below, and not necessarily to be interpreted
as whether any given service is safe or not. </P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 1-19, assorted protocols, many of which are antiquated, and probably
none of which are needed on a modern system. If you don't know what
any of these are, then you definitely don't need them.
The <SPAN
CLASS="APPLICATION"
>echo</SPAN
> service (port 7) should not be
confused with the common <B
CLASS="COMMAND"
>ping</B
> program. Leave all these
off.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 20 - FTP-DATA. <SPAN
CLASS="QUOTE"
>"Active"</SPAN
> FTP connections use two
ports: 21 is the control port, and 20 is where the data comes through.
Passive FTP does not use port 20 at all. Low risk, but see below.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 21 - FTP server port, aka File Transfer Protocol. A well entrenched protocol
for transferring files between systems. Very high risk, and maybe the number
one crack target.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 22 - SSH (Secure Shell), or sometimes PCAnywhere. Low to moderate
risk (yes there are exploits even against so called <SPAN
CLASS="QUOTE"
>"secure"</SPAN
>
services).
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 23 - Telnet server. For LAN use only. Use <SPAN
CLASS="APPLICATION"
>ssh</SPAN
>
instead in non-secure environments. Moderate risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 25 - SMTP, Simple Mail Transfer Protocol, or mail server port, used for
sending outgoing mail, and transferring mail from one place to another.
Moderate risk. This has had a bad history of exploits, but has improved
lately.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 37 - Time service. This is the built-in
<SPAN
CLASS="APPLICATION"
>inetd</SPAN
> time service. Low risk. For LAN use
only.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 53 - DNS, or Domain Name Server port. Name servers listen on this port,
and answer queries for resolving host names to IP addresses. High Risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 67 (UDP) - BOOTP, or DHCP, server port. Low risk. If using DHCP on your
LAN, this does not need to be exposed to the Internet.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 68 (UDP) - BOOTP, or DHCP, client port. Low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 69 - tftp, or Trivial File Transfer Protocol. Extremely insecure. LAN
only, if really, really needed.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 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.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 80 - WWW or HTTP standard web server port. The most commonly used service
on the Internet. Low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 98 - Linuxconf web access administrative port. LAN only, if really needed
at all.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 110 - POP3, aka Post Office Protocol, mail server port. POP mail is mail
that the user retrieves from a remote system. Low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 111 - sunrpc (Sun Remote Procedure Call), or portmapper port. Used by NFS
(Network File System), NIS (Network Information Service), and various related
services. Sounds dangerous and is high risk. LAN use only. A favorite crack
target.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 113 - identd, or auth, server port. Used, and sometimes required, by some
older style services (like SMTP and IRC) to validate the connection.
Probably not needed in most cases. Low risk, but could give an attacker
too much information about your system.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 119 -- nntp or news server port. Low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 123 - Network Time Protocol for synchronizing with time servers where a
high degree of accuracy is required. Low risk, but probably not required
for most users. <SPAN
CLASS="APPLICATION"
>rdate</SPAN
> makes an easier and more
secure way of updating the system clock. And then
<SPAN
CLASS="APPLICATION"
>inetd's</SPAN
> built in time service for synchronizing
LAN systems is another option.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 137-139 - NetBios (SMB) services. Mostly a Windows thing. Low risk on
Linux, but LAN use only. 137 is a very commonly seen port attempt. A
rather obnoxious protocol from Redmond that generates a lot of
<SPAN
CLASS="QUOTE"
>"noise"</SPAN
>, much of which is harmless.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 143 - IMAP, Interim Mail Access Protocol. Another mail retrieval protocol.
Low to moderate risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 161 - SNMP, Simple Network Management Protocol. More commonly used in
routers and switches to monitor statistics and vital signs. Not needed
for most of us, and low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 177 - XDMCP, the X Display Management Control Protocol for remote connections
to X servers. Low risk, but LAN only is recommended.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 443 - HTTPS, a secure HTTP (WWW) protocol in fairly wide use. Low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 465 - SMTP over SSL, secure mail server protocol. Low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 512 (TCP) - exec is how it shows in <SPAN
CLASS="APPLICATION"
>netstat</SPAN
>.
Actually the proper name is <B
CLASS="COMMAND"
>rexec,</B
> for Remote
Execution. Sounds dangerous, and is. High risk, LAN only if at all.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 512 (UDP) - biff, a mail notification protocol. Low risk, LAN only.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 513 - login, actually <B
CLASS="COMMAND"
>rlogin</B
>, aka Remote Login. No
relation to the standard <B
CLASS="COMMAND"
>/bin/login</B
> that we use
every time we log in. Sounds dangerous, and is. High risk, and LAN only if
really needed.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 514 (TCP) - shell is the nickname, and how <SPAN
CLASS="APPLICATION"
>netstat</SPAN
>
shows it. Actually, <B
CLASS="COMMAND"
>rsh</B
> is the application for
<SPAN
CLASS="QUOTE"
>"Remote Shell"</SPAN
>. Like all the <SPAN
CLASS="QUOTE"
>"r"</SPAN
> commands, this
is a throw back to kindler, gentler times. Very insecure, so high risk, and
LAN only usage, if at all.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 514 (UDP) - syslog daemon port, only used for remote logging purposes. The
average user does not need this. Probably low risk, but definitely LAN
only if really required.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 515 - lp or print server port. High risk, and LAN only of course. Someone
on the other side of the world does not want to use your printer for it's
intended purpose!
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 587 - MSA, or <SPAN
CLASS="QUOTE"
>"submission"</SPAN
>, the Mail Submission Agent
protocol. A new mail handling protocol supported by most MTA's (mail
servers). Low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 631 - the CUPS (print daemon) web management port. LAN only, low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 635 - mountd, part of NFS. LAN use only.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 901 - SWAT, Samba Web Administration Tool port. LAN only.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 993 - IMAP over SSL, secure IMAP mail service. Very low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 995 - POP over SSL, secure POP mail service. Very low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 1024 - This is the first <SPAN
CLASS="QUOTE"
>"unprivileged"</SPAN
> port, which is
dynamically assigned by the kernel to whatever application requests
it. This can be almost anything. Ditto for ports just above this.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 1080 - Socks Proxy server. A favorite crack target.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 1243 - SubSeven Trojan. Windows only problem.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 1433 - MS SQL server port. A sometimes target. N/A on Linux.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 2049 - nfsd, Network File Service Daemon port. High risk, and LAN
usage only is recommended.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 3128 - Squid proxy server port. Low risk, but for most should be
LAN only.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 3306 - MySQL server port. Low risk, but for most should be
LAN only.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 5432 - PostgreSQL server port. LAN only, relatively low risk.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 5631 (TCP), 5632 (UDP) - PCAnywhere ports. Windows only. PCAnywhere
can be quite <SPAN
CLASS="QUOTE"
>"noisy"</SPAN
>, and broadcast wide address ranges.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 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. <SPAN
CLASS="APPLICATION"
>ssh's</SPAN
> X11Forwarding will
start using ports at 6010.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 6346 - gnutella.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 6667 - ircd, Internet Relay Chat Daemon.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 6699 - napster.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 7100-7101 - Some font servers use these ports. Low risk, but LAN only.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 8000 and 8080 - common web cache and proxy server ports. LAN only.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 10000 - webmin, a web based system administration utility. Low risk at this
point.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 27374 - SubSeven, a commonly probed for Windows only Trojan. Also, 1243.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> 31337 - Back Orifice, another commonly probed for Windows only Trojan.
</TD
></TR
></TBODY
></TABLE
><P
></P
></P
><P
> More services and corresponding port numbers can be found in
<TT
CLASS="FILENAME"
>/etc/services</TT
>. Also, the <SPAN
CLASS="QUOTE"
>"official"</SPAN
>
list is <A
HREF="http://www.iana.org/assignments/port-numbers"
TARGET="_top"
>http://www.iana.org/assignments/port-numbers</A
>. </P
><P
> A great analysis of what probes to these and other ports might mean
from Robert Graham: <A
HREF="http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html"
TARGET="_top"
>http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html</A
>. A very good reference.</P
><P
> Another point here, these are the <EM
>standard</EM
> port
designations. There is no law that says any service has to run on a
specific port. Usually they do, but certainly they don't always have to. </P
><P
> Just a reminder that when you see these types of ports in your firewall logs,
it is not anything to go off the deep end about. Not if you have followed
Steps 1-3 above, and verified your firewall works. You are fairly safe. Much
of this traffic may be <SPAN
CLASS="QUOTE"
>"stray bullets"</SPAN
> too -- Internet
background noise, misconfigured clients or routers, noisy Windows stuff, etc.
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="NETSTAT">8.3. Netstat Tutorial</H2
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN1696">8.3.1. Overview</H3
><P
> <B
CLASS="COMMAND"
>netstat</B
> 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. </P
><P
> 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. </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>
$ 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 *:*
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> This output probably looks very different from what you get on your own
system. Notice the distinction between <SPAN
CLASS="QUOTE"
>"Local Address"</SPAN
> and
<SPAN
CLASS="QUOTE"
>"Foreign Address"</SPAN
>, and how each includes a corresponding port
number (or service name if available) after the colon. <SPAN
CLASS="QUOTE"
>"Local
Address"</SPAN
> is our end of the connection. The first group with
<TT
CLASS="LITERAL"
>LISTEN</TT
> 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 <SPAN
CLASS="QUOTE"
>"listen"</SPAN
> for incoming connections. So they
have a port opened, and this is where they <SPAN
CLASS="QUOTE"
>"listen"</SPAN
>. 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. </P
><P
> Now, the same thing with the <SPAN
CLASS="QUOTE"
>"-n"</SPAN
> flag to suppress converting to
<SPAN
CLASS="QUOTE"
>"names"</SPAN
> so we can actually see the port numbers: </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> $ 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:*
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> Let's look at the first few lines of this in detail. On line one, </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> <SPAN
CLASS="QUOTE"
>"Local Address"</SPAN
> is <TT
CLASS="LITERAL"
>0.0.0.0</TT
>, meaning
<SPAN
CLASS="QUOTE"
>"all"</SPAN
> 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
<TT
CLASS="FILENAME"
>/etc/services</TT
>. </P
><P
> 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 <SPAN
CLASS="QUOTE"
>"Foreign Address"</SPAN
> is also
<TT
CLASS="LITERAL"
>0.0.0.0</TT
>, meaning from <SPAN
CLASS="QUOTE"
>"anywhere"</SPAN
>.</P
><P
> It is also worth noting here, that even though this server is telling the
kernel to listen on all interfaces, the <B
CLASS="COMMAND"
>netstat</B
> 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.</P
><P
> Line two is a little different:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> Notice the <SPAN
CLASS="QUOTE"
>"Local Address"</SPAN
> this time is localhost's address
of <TT
CLASS="LITERAL"
>127.0.0.1</TT
>. 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 <SPAN
CLASS="APPLICATION"
>Junkbuster</SPAN
>. </P
><P
> With the next three entries, we are back to listening on all available
interfaces:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> 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
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> Looking at <TT
CLASS="FILENAME"
>/etc/services</TT
>, we can tell that port 37
is a <SPAN
CLASS="QUOTE"
>"time"</SPAN
> service, which is a time server.
6000 is <SPAN
CLASS="APPLICATION"
>X11</SPAN
>, and 80 is the standard port for HTTP
servers like <SPAN
CLASS="APPLICATION"
>Apache</SPAN
>. There is nothing really
unusual here as these are all readily available services on Linux.</P
><P
> 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.</P
><P
> 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, <SPAN
CLASS="APPLICATION"
>Apache</SPAN
> 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.
</P
><P
> The next two lines are interesting:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> 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
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> Again notice the <SPAN
CLASS="QUOTE"
>"Local Address"</SPAN
> is not <TT
CLASS="LITERAL"
>0.0.0.0</TT
>.
This is good! The port this time is 53, or the DNS port used by nameserver
daemons like <B
CLASS="COMMAND"
>named.</B
> 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.
</P
><P
> The last three <TT
CLASS="LITERAL"
>LISTENER</TT
> entries:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> 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
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> These are back to listening on all available interfaces. Port 22 is
<SPAN
CLASS="APPLICATION"
>sshd</SPAN
>, 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?</P
><P
> 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.</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> 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
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> 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.</P
><P
> Since we gave <B
CLASS="COMMAND"
>netstat</B
> both the <TT
CLASS="LITERAL"
>-t</TT
> and
<TT
CLASS="LITERAL"
>-u</TT
> options, we are getting both the TCP and UDP listening
servers. The last few lines are the UDP ones:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> 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:*
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> 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 <TT
CLASS="FILENAME"
>/etc/services</TT
>. So at first glance
this should be suspicious and pique our curiosity. See the next section for
the explanation.</P
><P
> 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
<B
CLASS="COMMAND"
>netstat</B
> 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. </P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="PID">8.3.2. Port and Process Owners</H3
><P
> 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?</P
><P
> The <TT
CLASS="LITERAL"
>-p</TT
> 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: </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> # 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
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> Some of these we already know about. But we see now that the printer daemon
on port 515 is being started via <B
CLASS="COMMAND"
>inetd</B
> with a
PID of <SPAN
CLASS="QUOTE"
>"988"</SPAN
>. <B
CLASS="COMMAND"
>inetd</B
> is a special situation.
<B
CLASS="COMMAND"
>inetd</B
> is often called the <SPAN
CLASS="QUOTE"
>"super server"</SPAN
>,
since it's main role is to spawn sub-services.
<SPAN
CLASS="APPLICATION"
>xinetd</SPAN
> replaces <SPAN
CLASS="APPLICATION"
>inetd</SPAN
>
as of Red Hat 7.0. If we look at the first line, <B
CLASS="COMMAND"
>inetd</B
>
is listening on port 515 for printer services. If a connection comes for this
port, <B
CLASS="COMMAND"
>inetd</B
> intercepts it, and then will spawn the
appropriate daemon, i.e. the print daemon in this case. The configuration of
how <B
CLASS="COMMAND"
>inetd</B
> handles this is typically done in
<TT
CLASS="FILENAME"
>/etc/inetd.conf</TT
>. This should tell us that if we want to
stop an <B
CLASS="COMMAND"
>inetd</B
> controlled server on a permanent basis, then
we will have to dig into the <B
CLASS="COMMAND"
>inetd</B
> (or perhaps
<B
CLASS="COMMAND"
>xinetd</B
>) configuration. Also the time service above is
started via <B
CLASS="COMMAND"
>inetd</B
> as well. This should also tell us that
these two services can be further protected by
<SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
> (discussed in Step 3 above). This is
one benefit of using <B
CLASS="COMMAND"
>inetd</B
> to control certain system
services. </P
><P
> 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 <B
CLASS="COMMAND"
>cupsd</B
>
(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
<B
CLASS="COMMAND"
>cupsd</B
> does that is indeed a little different than other
print servers. </P
><P
> The last entry above is the SMTP mail server on bigcat. Often, this is
<B
CLASS="COMMAND"
>sendmail</B
>. But
not in this case. The command is <SPAN
CLASS="QUOTE"
>"master"</SPAN
>, which may not ring
any bells. Armed with the program name we could go searching the filesystem
with tools like the <B
CLASS="COMMAND"
>locate</B
> or <B
CLASS="COMMAND"
>find</B
>
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
<B
CLASS="COMMAND"
>ps</B
> output, and see if that helps us any: </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> $ /bin/ps ax |grep 1051 |grep -v grep
1051 ? S 0:24 /usr/libexec/postfix/master
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> We took a shortcut here by combining <B
CLASS="COMMAND"
>ps</B
> with
<B
CLASS="COMMAND"
>grep</B
>. It looks like that this file belongs to
<B
CLASS="COMMAND"
>postfix</B
>, which is indeed a mail server package
comparable to <B
CLASS="COMMAND"
>sendmail</B
> ( and is
included with Powertools, not the base distribution). </P
><P
> Running <B
CLASS="COMMAND"
>ps</B
> with the <TT
CLASS="LITERAL"
>--forest</TT
> flag
(<TT
CLASS="LITERAL"
>-f</TT
> for short) can be helpful in determining what
processes are parent or child process or another process. An edited example:
</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> $ /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
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> A couple of things to note here. We have two by now familiar daemons here:
<B
CLASS="COMMAND"
>named</B
> and <B
CLASS="COMMAND"
>postfix (smtpd)</B
>. Both
are spawning sub-processes. In the case of <B
CLASS="COMMAND"
>named</B
>, what we are
seeing is threads, various sub-processes that it always spawns.
<B
CLASS="COMMAND"
>Postfix</B
> is also spawning sub-processes, but not as
<SPAN
CLASS="QUOTE"
>"threads"</SPAN
>. 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.
</P
><P
> If all this has not shed any light, we might also try <B
CLASS="COMMAND"
>locate</B
>:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> $ 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
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> <B
CLASS="COMMAND"
>find</B
> is perhaps the most flexible file finding utility,
but doesn't use a database the way <B
CLASS="COMMAND"
>locate</B
> does, so is
much slower:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> $ find / -name master
/usr/libexec/postfix/master
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> If <B
CLASS="COMMAND"
>lsof</B
> is installed, it is another command that is useful
for finding who owns processes or ports: </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> # lsof -i :631
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
cupsd 1315 root 0u IPv4 3734 TCP *:631 (LISTEN)
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> This is again telling us that the <B
CLASS="COMMAND"
>cupsd</B
> 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 <B
CLASS="COMMAND"
>fuser</B
>, which should be
installed: </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> # fuser -v -n tcp 631
USER PID ACCESS COMMAND
631/tcp root 1315 f.... cupsd
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> See the man pages for <B
CLASS="COMMAND"
>fuser</B
> and <B
CLASS="COMMAND"
>lsof</B
>
command syntax. </P
><P
> Another place to look for where a service is started, is in the
<TT
CLASS="FILENAME"
>init.d</TT
> directory, where the actual init scripts
live. Something like <TT
CLASS="LITERAL"
>ls -l
/etc/rc.d/init.d/</TT
>, 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 <SPAN
CLASS="QUOTE"
>"Program Name"</SPAN
>
as provided by <B
CLASS="COMMAND"
>netstat</B
>. Or we can use
<B
CLASS="COMMAND"
>grep</B
> to search inside files and match a search pattern.
Need to find where <B
CLASS="COMMAND"
>rpc.statd</B
> is being started, and we
don't see a script by this name? </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> # 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="$?"
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> 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 <SPAN
CLASS="APPLICATION"
>inetd</SPAN
>,
or <SPAN
CLASS="APPLICATION"
>xinetd</SPAN
>. </P
><P
> The <TT
CLASS="FILENAME"
>/proc</TT
> 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? </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> # ls -l /proc/1315/exe
lrwxrwxrwx 1 root root 0 July 4 19:41 /proc/1315/exe -> /usr/sbin/cupsd
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> 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: </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> # 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
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> Now by including the <SPAN
CLASS="QUOTE"
>"PID/Program name"</SPAN
>
option with the <TT
CLASS="LITERAL"
>-p</TT
> flag, we see this also belongs to
<B
CLASS="COMMAND"
>named</B
>, the nameserver daemon. Recent versions of
<SPAN
CLASS="APPLICATION"
>BIND</SPAN
> use an unprivileged port for some types
of traffic. In this case, this is <SPAN
CLASS="APPLICATION"
>BIND 9.x</SPAN
>.
So no real alarms here either. The unprivileged port here is the one
<B
CLASS="COMMAND"
>named</B
> uses to to talk to other nameservers for name
and address lookups, and should not be firewalled. </P
><P
> So we found no big surprises in this hypothetical situation.</P
><P
> 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 <B
CLASS="COMMAND"
>portmap</B
> daemon.
In some cases, these may not reveal the process owner to
<B
CLASS="COMMAND"
>netstat</B
> or <B
CLASS="COMMAND"
>lsof</B
>. Try stopping
<B
CLASS="COMMAND"
>portmap</B
>, and then see if the mystery service goes away. Or
you can use <B
CLASS="COMMAND"
>rpcinfo -p localhost</B
> to see what RPC services
may be running (<B
CLASS="COMMAND"
>portmap</B
> must be running for this to
work).</P
><DIV
CLASS="WARNING"
><P
></P
><TABLE
CLASS="WARNING"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/warning.gif"
HSPACE="5"
ALT="Warning"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
> If you suspect you have been broken into, <EM
>do not trust</EM
>
<B
CLASS="COMMAND"
>netstat</B
> or <B
CLASS="COMMAND"
>ps</B
> 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.
</P
></TD
></TR
></TABLE
></DIV
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="THREATS">8.4. Attacks and Threats</H2
><P
> In this section, we will take a quick look at some of the common threats
and techniques that are out there, and attempt to put them into some
perspective.</P
><P
> The corporate world, government agencies and high profile Internet sites have
to be concerned with a much more diverse and challenging set of threats than
the typical home desktop user. There are many reasons someone may want to
break in to someone else's computer. It may be just for kicks, or any number
of malicious reasons. They may just want a base from which to attack
someone else. This is a very common motivation.
</P
><P
> The most common <SPAN
CLASS="QUOTE"
>"attack"</SPAN
> for most of us is from already
compromised systems. The Internet is littered with computers that have been
broken into, and are now doing their master's bidding blindly, in zombie-like
fashion. They are programmed to scan massively large address ranges, probing
each individual IP address as they go. Looking for one or more open ports,
and then probing for known weaknesses if they get the chance. Very
impersonal. Very methodical. And very effective. We are all in the path of
such robotic scans. All because those responsible for these systems fail to
do what you are doing now - taking steps to protect their system(s), and
avoid being r00ted. </P
><P
> These scans do not look at login banners that may be presented on connection.
It will do little good to change your <TT
CLASS="FILENAME"
>/etc/issue.net</TT
> to
pretend that you are running some obscure operating system. If they find
something listening, they will try all of the exploits appropriate to that
port, without regard to any indications your system may give. If it works,
they are in -- if not, they will move on. </P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="SCANS">8.4.1. Port Scans and Probes</H3
><P
> First, let's define <SPAN
CLASS="QUOTE"
>"scan"</SPAN
> and <SPAN
CLASS="QUOTE"
>"probe"</SPAN
> since these
terms come up quite a bit. A <SPAN
CLASS="QUOTE"
>"probe"</SPAN
> implies testing if a given
port is open or closed, and possibly what might be listening on that port. A
<SPAN
CLASS="QUOTE"
>"scan"</SPAN
> implies either <SPAN
CLASS="QUOTE"
>"probing"</SPAN
> multiple ports on
one or more systems. Or individual ports on multiple systems. So you might
<SPAN
CLASS="QUOTE"
>"scan"</SPAN
> all ports on your own system for instance. Or a
cracker might <SPAN
CLASS="QUOTE"
>"scan"</SPAN
> the 216.78.*.* address range to see who
has port 111 open.
</P
><P
> 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. <SPAN
CLASS="QUOTE"
>"Worms"</SPAN
>, 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
<SPAN
CLASS="QUOTE"
>"learn"</SPAN
> anything, the way a cracker might. </P
><P
> The distinction between <SPAN
CLASS="QUOTE"
>"scan"</SPAN
> and <SPAN
CLASS="QUOTE"
>"probe"</SPAN
>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 <SPAN
CLASS="APPLICATION"
>nmap</SPAN
>. 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 <SPAN
CLASS="QUOTE"
>"out there"</SPAN
>. But more than likely it
is someone or something with not such good intentions. </P
><P
> 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.
</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN1914">8.4.2. Rootkits</H3
><P
> A <SPAN
CLASS="QUOTE"
>"rootkit"</SPAN
> 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 <SPAN
CLASS="QUOTE"
>"rootkits"</SPAN
>. 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. </P
><P
> A rootkit will typically replace critical system files such as
<B
CLASS="COMMAND"
>ls</B
>, <B
CLASS="COMMAND"
>ps</B
>, <B
CLASS="COMMAND"
>netstat</B
>,
<B
CLASS="COMMAND"
>login</B
> 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
<SPAN
CLASS="QUOTE"
>"owner"</SPAN
> 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. </P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN1925">8.4.3. Worms and Zombies</H3
><P
> A <SPAN
CLASS="QUOTE"
>"worm"</SPAN
> is a self replicating exploit. It infects a system,
then attempts to spread itself typically via the same vulnerability. Various
<SPAN
CLASS="QUOTE"
>"worms"</SPAN
> are weaving their way through the entire Internet
address space constantly, spreading themselves as they go. </P
><P
> 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.
</P
><P
> Many of these are Linux systems, looking for other Linux systems to
<SPAN
CLASS="QUOTE"
>"infect"</SPAN
> 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 <SPAN
CLASS="QUOTE"
>"worm"</SPAN
>) will do is
attempt to cover their tracks. A <SPAN
CLASS="QUOTE"
>"rootkit"</SPAN
> 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. </P
><P
> 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 <EM
>your</EM
> 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. </P
><P
> It is worth noting, that these worms cannot <SPAN
CLASS="QUOTE"
>"force"</SPAN
> their way
in. They need an open and accessible port, <EM
>and</EM
> a known
vulnerability. If you remember the <SPAN
CLASS="QUOTE"
>"Iptables Weekly Log Summary"</SPAN
>
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. </P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN1941">8.4.4. Script Kiddies</H3
><P
> A <SPAN
CLASS="QUOTE"
>"script kiddie"</SPAN
> is a <SPAN
CLASS="QUOTE"
>"cracker"</SPAN
> wanna be who
doesn't know enough to come up with his/her own exploits, but instead
relies on <SPAN
CLASS="QUOTE"
>"scripts"</SPAN
> and exploits that have been developed by
others. Like <SPAN
CLASS="QUOTE"
>"worms"</SPAN
>, 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. </P
><P
> The script kiddie has a bag of ready made tricks at his disposal, including
an arsenal of <SPAN
CLASS="QUOTE"
>"rootkits"</SPAN
> 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,
<SPAN
CLASS="QUOTE"
>"Denial of Service"</SPAN
> attacks (see below). They collect
zombies like trophies and use them to carry out whatever their objective is. </P
><P
> Again, the key here is that they are following a <SPAN
CLASS="QUOTE"
>"script"</SPAN
>, 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. </P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN1953">8.4.5. Spoofed IPs</H3
><P
> 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. </P
><P
> 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. </P
><P
> This does have potential for <SPAN
CLASS="QUOTE"
>"DoS"</SPAN
> attacks (see below) where
learning something about the targeted system is not important. And may be
used for some general mischief making as well. </P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN1959">8.4.6. Targeted Attacks</H3
><P
> 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
<SPAN
CLASS="QUOTE"
>"black hats"</SPAN
> that will spend a great deal of effort to get into
a system or network. We'll call these <SPAN
CLASS="QUOTE"
>"targeted"</SPAN
> attacks since
there has been a deliberate decision made to break in to a specific system
or network.
</P
><P
> 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. </P
><P
> 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.
</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="DOS">8.4.7. Denial of Service (DoS)</H3
><P
> <SPAN
CLASS="QUOTE"
>"DoS"</SPAN
> is another type of <SPAN
CLASS="QUOTE"
>"attack"</SPAN
> 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. </P
><P
> 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. </P
><P
> <SPAN
CLASS="QUOTE"
>"DDoS"</SPAN
>, 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 <SPAN
CLASS="QUOTE"
>"slaves"</SPAN
> that are <SPAN
CLASS="QUOTE"
>"owned"</SPAN
>
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.
</P
><P
> 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.
</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN1977">8.4.8. Brute Force</H3
><P
> <SPAN
CLASS="QUOTE"
>"Brute force"</SPAN
> 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
<SPAN
CLASS="APPLICATION"
>telnet</SPAN
> 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.
</P
><P
> 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 <EM
>and</EM
> password. But if root is allowed remote logins,
then the attacker only needs to guess the password!
</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="VIRUSES">8.4.9. Viruses</H3
><P
> And now something <EM
>not</EM
> 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.
</P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="LINKS">8.5. Links</H2
><P
> Some references for further reading are listed below. Not listed is your
distribution's site, security page or ftp download site. You will
have to find these on your own. Then you should bookmark them! </P
><P
> <P
></P
><UL
><LI
><P
> Redhat sites of interest:
</P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> The Redhat watch/security mailing list: <A
HREF="https://listman.redhat.com/mailman/listinfo/redhat-watch-list"
TARGET="_top"
>https://listman.redhat.com/mailman/listinfo/redhat-watch-list</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Red Hat errata and security notices:
<A
HREF="http://redhat.com/errata/"
TARGET="_top"
>http://redhat.com/errata/</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> The Red Hat update FTP site:
<A
HREF="ftp://updates.redhat.com/"
TARGET="_top"
>ftp://updates.redhat.com/</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
></LI
><LI
><P
> Other relevant documents available from the Linux Documentation Project:
</P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Security HOWTO: <A
HREF="http://tldp.org/HOWTO/Security-HOWTO.html "
TARGET="_top"
>http://tldp.org/HOWTO/Security-HOWTO.html</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Firewall HOWTO: <A
HREF="http://tldp.org/HOWTO/Firewall-HOWTO.html"
TARGET="_top"
>http://tldp.org/HOWTO/Firewall-HOWTO.html</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Ipchains HOWTO: <A
HREF="http://tldp.org/HOWTO/IPCHAINS-HOWTO.html "
TARGET="_top"
>http://tldp.org/HOWTO/IPCHAINS-HOWTO.html</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> User Authentication: <A
HREF="http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html"
TARGET="_top"
>http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html</A
>, includes a
nice discussion on PAM.
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> VPN (Virtual Private Network): <A
HREF="http://tldp.org/HOWTO/VPN-HOWTO.html"
TARGET="_top"
>http://tldp.org/HOWTO/VPN-HOWTO.html</A
>
and <A
HREF="http://tldp.org/HOWTO/VPN-Masquerade-HOWTO.html"
TARGET="_top"
>http://tldp.org/HOWTO/VPN-Masquerade-HOWTO.html</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> The Remote X Apps Mini HOWTO,
<A
HREF="http://www.tldp.org/HOWTO/mini/Remote-X-Apps.html"
TARGET="_top"
>http://www.tldp.org/HOWTO/mini/Remote-X-Apps.html</A
>,
includes excellent discussions on the security implications of running
X Windows.
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> The Linux Network Administrators Guide:
<A
HREF="http://tldp.org/LDP/nag2/index.html"
TARGET="_top"
>http://tldp.org/LDP/nag2/index.html</A
>, includes a good overview of networking and TCP/IP, and
firewalling.
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> The Linux Administrator's Security Guide:
<A
HREF="http://www.seifried.org/lasg/"
TARGET="_top"
> http://www.seifried.org/lasg/</A
>,
includes many obvious topics of interest, including firewalling,
passwords and authentication, PAM, and more.
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Securing Red Hat:
<A
HREF="http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/index.html"
TARGET="_top"
>http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/index.html</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
></LI
><LI
><P
> Tools for creating custom <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> and
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> firewall scripts:
</P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Firestarter: <A
HREF="http://firestarter.sourceforge.net"
TARGET="_top"
>http://firestarter.sourceforge.net</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Two related projects: <A
HREF="http://seawall.sourceforge.net/"
TARGET="_top"
>http://seawall.sourceforge.net/</A
> for ipchains,
and <A
HREF="http://shorewall.sourceforge.net/"
TARGET="_top"
>http://shorewall.sourceforge.net/</A
> for iptables.
</TD
></TR
></TBODY
></TABLE
><P
></P
></LI
><LI
><P
> Netfilter and iptables documentation from the netfilter developers
(available in many other languages as well):
</P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> FAQ: <A
HREF="http://netfilter.samba.org/documentation/FAQ/netfilter-faq.html"
TARGET="_top"
>http://netfilter.samba.org/documentation/FAQ/netfilter-faq.html</A
>
</TD
></TR
><TR
><TD
> Packet filtering: <A
HREF="http://netfilter.samba.org/documentation/HOWTO/packet-filtering-HOWTO.html"
TARGET="_top"
>http://netfilter.samba.org/documentation/HOWTO/packet-filtering-HOWTO.html</A
>
</TD
></TR
><TR
><TD
> Networking: <A
HREF="http://netfilter.samba.org/documentation/HOWTO/networking-concepts-HOWTO.html"
TARGET="_top"
>http://netfilter.samba.org/documentation/HOWTO/networking-concepts-HOWTO.html</A
>
</TD
></TR
><TR
><TD
> NAT/masquerading: <A
HREF="http://netfilter.samba.org/documentation/HOWTO/NAT-HOWTO.html"
TARGET="_top"
>http://netfilter.samba.org/documentation/HOWTO/NAT-HOWTO.html</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
></LI
><LI
><P
> Port number assignments, and what that scanner may be scanning for:
</P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <A
HREF="http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html"
TARGET="_top"
>http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <A
HREF="http://www.sans.org/newlook/resources/IDFAQ/oddports.htm"
TARGET="_top"
>http://www.sans.org/newlook/resources/IDFAQ/oddports.htm</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <A
HREF="http://www.iana.org/assignments/port-numbers"
TARGET="_top"
>http://www.iana.org/assignments/port-numbers</A
>, the official assignments.
</TD
></TR
></TBODY
></TABLE
><P
></P
></LI
><LI
><P
> General security sites. These all have areas on documentation, alerts,
newsletters, mailing lists, and other resources.
</P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Linux Security.com: <A
HREF="http://www.linuxsecurity.com"
TARGET="_top"
>http://www.linuxsecurity.com</A
>, loaded with good info, and Linux specific.
Lots of good docs: <A
HREF="http://www.linuxsecurity.com/docs/"
TARGET="_top"
>http://www.linuxsecurity.com/docs/</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> CERT, <A
HREF="http://www.cert.org"
TARGET="_top"
>http://www.cert.org</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> The SANS Institute: <A
HREF="http://www.sans.org/"
TARGET="_top"
>http://www.sans.org/</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> The Coroner's Toolkit (TCT): <A
HREF="http://www.fish.com/security/"
TARGET="_top"
>http://www.fish.com/security/</A
>,
discussions and tools for dealing with post break-in issues (and
preventing them in the first place).
</TD
></TR
></TBODY
></TABLE
><P
></P
></LI
><LI
><P
> Privacy:
</P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Junkbuster: <A
HREF="http://www.junkbuster.com"
TARGET="_top"
>http://www.junkbuster.com</A
>, a
web proxy and cookie manager.
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> PGP: <A
HREF="http://www.gnupg.org/"
TARGET="_top"
>http://www.gnupg.org/</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
></LI
><LI
><P
> Other documentation and reference sites:
</P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Linux Security.com: <A
HREF="http://www.linuxsecurity.com/docs/"
TARGET="_top"
>http://www.linuxsecurity.com/docs/</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Linux Newbie: <A
HREF="http://www.linuxnewbie.org/nhf/intel/security/index.html"
TARGET="_top"
>http://www.linuxnewbie.org/nhf/intel/security/index.html</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> The comp.os.linux.security FAQ: <A
HREF="http://www.linuxsecurity.com/docs/colsfaq.html"
TARGET="_top"
>http://www.linuxsecurity.com/docs/colsfaq.html</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> The Internet Firewall FAQ: <A
HREF="http://www.interhack.net/pubs/fwfaq/"
TARGET="_top"
>http://www.interhack.net/pubs/fwfaq/</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> The Site Security Handbook RFC: <A
HREF="http://www.ietf.org/rfc/rfc2196.txt"
TARGET="_top"
>http://www.ietf.org/rfc/rfc2196.txt</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
></LI
><LI
><P
> Miscellaneous sites of interest:
</P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <A
HREF="http://www.bastille-linux.org"
TARGET="_top"
>http://www.bastille-linux.org</A
>, for Mandrake and Red Hat only.
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> SAINT: <A
HREF="http://www.wwdsi.com/saint/"
TARGET="_top"
>http://www.wwdsi.com/saint/</A
>,
system security analysis.
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> SSL: <A
HREF="http://www.openssl.org/"
TARGET="_top"
>http://www.openssl.org/</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> SSH: <A
HREF="http://www.openssh.org/"
TARGET="_top"
>http://www.openssh.org/</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Scan yourself: <A
HREF="http://www.hackerwhacker.com"
TARGET="_top"
>http://www.hackerwhacker.com</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> PAM: <A
HREF="http://www.kernel.org/pub/linux/libs/pam/index.html"
TARGET="_top"
>http://www.kernel.org/pub/linux/libs/pam/index.html</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Detecting Trojaned Linux Kernel Modules: <A
HREF="http://members.prestige.net/tmiller12/papers/lkm.htm"
TARGET="_top"
>http://members.prestige.net/tmiller12/papers/lkm.htm</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Rootkit checker: <A
HREF="http://www.chkrootkit.org"
TARGET="_top"
>http://www.chkrootkit.org</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Port scanning tool <SPAN
CLASS="APPLICATION"
>nmap's</SPAN
> home page: <A
HREF="http://www.insecure.org"
TARGET="_top"
>http://www.insecure.org</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Nessus, more than just a port scanner: <A
HREF="http://www.nessus.org"
TARGET="_top"
>http://www.nessus.org</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Tripwire, intrusion detection:
<A
HREF="http://www.tripwire.org"
TARGET="_top"
>http://www.tripwire.org</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> Snort, sniffer and more: <A
HREF="http://www.snort.org"
TARGET="_top"
>http://www.snort.org</A
>
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <A
HREF="http://www.mynetwatchman.com"
TARGET="_top"
>http://www.mynetwatchman.com</A
>
and <A
HREF="http://dshield.org"
TARGET="_top"
>http://dshield.org</A
> are
<SPAN
CLASS="QUOTE"
>"Distributed Intrusion Detection Systems"</SPAN
>. They collect
log data from subscribing <SPAN
CLASS="QUOTE"
>"agents"</SPAN
>, and collate the
data to find and report malicious activity. If you want to fight back,
check these out.
</TD
></TR
></TBODY
></TABLE
><P
></P
></LI
></UL
></P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="TEXT">8.6. Editing Text Files</H2
><P
>By Bill Staehle</P
><P
>All the world is a file.</P
><P
>There are a great many types of files, but I'm going to stretch it here,
and class them into two really broad families:</P
><P
> <TT
CLASS="LITERAL"
> <P
CLASS="LITERALLAYOUT"
><br>
<br>
Text files are just that.<br>
Binary files are not.<br>
<br>
</P
>
</TT
></P
><P
>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.</P
><P
>There are a number of different text editors available in *nix. A few
are found on every system. That would be '/bin/ed' and '/bin/vi'. 'vi' is
almost always a clone such as 'vim' due to license problems. The problem with
'vi' and 'ed' is that they are terribly user unfriendly. Another common editor
that is not always installed by default is 'emacs'. It has a lot more features
and capability, and is not easy to learn either.</P
><P
> As to 'user friendly' editors, 'mcedit' and 'pico' are good choices to start
with. These are often much easier for those new to *nix. </P
><P
> The first things to learn are how to exit an editing session, how to save
changes to the file, and then how to avoid breaking long lines that should
not be broken (wrapped). </P
><P
>The 'vi' editor</P
><P
>'vi' is one of the most common text editors in the Unix world, and it's
nearly always found on any *nix system. Actually, due to license problems,
the '/bin/vi' on a Linux system is always a 'clone', such as 'elvis',
'nvi', or 'vim' (there are others). These clones can act exactly like
the original 'vi', but usually have additional features that make it
slightly less impossible to use.</P
><P
>So, if it's so terrible, why learn about it? Two reasons. First, as
noted, it's almost guaranteed to be installed, and other (more user
friendly) editors may not be installed by default. Second, many of the
'commands' work in other applications (such as the pager 'less' which is
also used to view man pages). In 'less', accidentally pressing the 'v' key
starts 'vi' in most installations.</P
><P
>'vi' has two modes. The first is 'command mode', and keystrokes are
interpreted as commands. The other mode is 'insert' mode, where nearly all
keystrokes are interpreted as text to be inserted.</P
><P
>==> Emergency exit from 'vi'
1. press the <esc> key up to three times, until the computer beeps, or the
screen flashes.
2. press the keys :q! <Enter></P
><P
> That is: colon, the letter Q, and then the exclamation point, followed by
the Enter key. </P
><P
>'vi' commands are as follows. All of these are in 'command' mode:</P
><P
> <TT
CLASS="LITERAL"
> <P
CLASS="LITERALLAYOUT"
><br>
a Enter insertion mode after the cursor.<br>
A Enter insertion mode at the end of the current line.<br>
i Enter insertion mode before the cursor.<br>
o Enter insertion mode opening a new line BELOW current line.<br>
O Enter insertion mode opening a new line ABOVE current line.<br>
h move cursor left one character.<br>
l move cursor right one character.<br>
j move cursor down one line.<br>
k move cursor up one line.<br>
/mumble move cursor forward to next occurrence of 'mumble' in <br>
the text<br>
?mumble move cursor backward to next occurrence of 'mumble' <br>
in the text<br>
n repeat last search (? or / without 'mumble' to search for <br>
will do the same thing)<br>
u undo last change made<br>
<br>
^B Scroll back one window.<br>
^F Scroll forward one window.<br>
^U Scroll up one half window.<br>
^D Scroll down one half window.<br>
<br>
:w Write to file.<br>
:wq Write to file, and quit.<br>
:q quit.<br>
:q! Quit without saving.<br>
<br>
<esc> Leave insertion mode.<br>
<br>
</P
>
</TT
></P
><P
>NOTE: The four 'arrow' keys almost always work in 'command' or 'insert'
mode.</P
><P
>The 'ed' editor.</P
><P
>The 'ed' editor is a line editor. Other than the fact that it is virtually
guaranteed to be on any *nix computer, it has no socially redeeming
features, although some applications may need it. A _lot_ of things have
been offered to replace this 'thing' from 1975.</P
><P
>==> Emergency exit from 'ed'</P
><P
>1. type a period on a line by itself, and press <Enter> This gets you to
the command mode or prints a line of text if you were in command mode.
2. type q and press <Enter>. If there were no changes to the file,
this action quits ed. If you then see a '?' this means that the file had
changed, and 'ed' is asking if you want to save the changes. Press q and
<Enter> a second time to confirm that you want out.</P
><P
>The 'pico' editor.</P
><P
>'pico' is a part of the Pine mail/news package from the University of
Washington (state, USA). It is a very friendly editor, with one minor
failing. It silently inserts a line feed character and wraps the line when
it exceeds (generally) 74 characters. While this is fine while creating
mail, news articles, and text notes, it is often fatal when editing system
files. The solution to this problem is simple. Call the program with the
-w option, like this:</P
><P
>pico -w file_2_edit</P
><P
>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.</P
><P
>==> Emergency exit from 'pico'</P
><P
>Press and hold the <Ctrl> key, and press the letter x. If no changes
had been made to the file, this will quit pico. If changes had been made,
it will ask if you want to save the changes. Pressing n will then exit.</P
><P
>The 'mcedit' editor.</P
><P
>'mcedit' is part of the Midnight Commander shell program, a full featured
visual shell for Unix-like systems. It can be accessed directly from the
command line ( mcedit file_2_edit ) or as part of 'mc' (use the arrow keys
to highlight the file to be edited, then press the F4 key).</P
><P
>mcedit is probably the most intuitive editor available, and comes with
extensive help. "commands" are accessed through the F* keys. Midnight
Commander is available with nearly all distributions, although it _may_ not
be installed by default.</P
><P
>==> Emergency exit from 'mcedit'</P
><P
>Press the F10 key. If no changes have been made to the file, this will
quit mcedit. If changes had been made, it will ask if you want to Cancel
this action. Pressing n will then exit.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="NMAP">8.7. nmap</H2
><P
> Let's look at a few quick examples of what <B
CLASS="COMMAND"
>nmap</B
> scans
look like. The intent here is to show how to use <B
CLASS="COMMAND"
>nmap</B
>
to verify our firewalling, and system integrity. <B
CLASS="COMMAND"
>nmap</B
>
has other uses that we don't need to get into. Do NOT use
<B
CLASS="COMMAND"
>nmap</B
> on systems other than your own, unless you have
permission from the owner, and you know it is not a violation of anyone's
Terms of Service. This kind of thing <EM
>will</EM
> be taken as
hostile by most people. </P
><P
> As mentioned previously, <B
CLASS="COMMAND"
>nmap</B
> is a sophisticated
port scanning tool. It tries to see if a host is <SPAN
CLASS="QUOTE"
>"there"</SPAN
>,
and what ports might be open. Barring that, what states those ports
might be in. <B
CLASS="COMMAND"
>nmap</B
> has a complex command line and
can do many types of <SPAN
CLASS="QUOTE"
>"scans"</SPAN
>. See the man page for all
the nitty gritty. </P
><P
> A couple of words of warning first. If using
<SPAN
CLASS="APPLICATION"
>portsentry</SPAN
>, turn it off. It will drop the route
to wherever the scan is coming from. You might want to turn off any logging
also, or at least be aware that you might get copious logs if doing multiple
scans. </P
><P
> A simple, default scan of <SPAN
CLASS="QUOTE"
>"localhost"</SPAN
>:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> # nmap localhost
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on bigcat (127.0.0.1):
(The 1507 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
37/tcp open time
53/tcp open domain
80/tcp open http
3000/tcp open ppp
Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> 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+
<SPAN
CLASS="QUOTE"
>"interesting"</SPAN
> ports -- not all ports. This can be configured
differently if more is desirable (see man page). It only did TCP ports too.
Again, configurable. It only picks up <SPAN
CLASS="QUOTE"
>"listening"</SPAN
> services,
unlike <B
CLASS="COMMAND"
>netstat</B
> that shows all open ports -- listening or
otherwise. Note the last <SPAN
CLASS="QUOTE"
>"open"</SPAN
> port here is 3000 is identified
as <SPAN
CLASS="QUOTE"
>"PPP"</SPAN
>. Wrong! That is just an educated guess by nmap based on
what is contained in <TT
CLASS="FILENAME"
>/etc/services</TT
> for this port number.
Actually in this case it is <SPAN
CLASS="APPLICATION"
>ntop</SPAN
> (a network
traffic monitor). Take the service names with a grain of salt. There is no
way for <B
CLASS="COMMAND"
>nmap</B
> to really know what is on that port. Matching
port numbers with service names can at times be risky. Many do have standard
ports, but there is nothing to say they have to use the commonly associated
port numbers. </P
><P
> Notice that in all our <B
CLASS="COMMAND"
>netstat</B
> examples, we had two classes
of open ports: listening servers, and then established connections that we
initiated to other remote hosts (e.g. a web server somewhere).
<B
CLASS="COMMAND"
>nmap</B
> only sees the first group -- the listening servers!
The other ports connecting us to remote servers are not visible, and thus
not vulnerable. These ports are <SPAN
CLASS="QUOTE"
>"private"</SPAN
> to that single
connection, and will be closed when the connection is terminated.</P
><P
> So we have open and closed ports here. Simple enough, and gives a pretty good
idea what is running on bigcat -- but not necessarily what we look like to
the outside world since this was done from localhost, and wouldn't reflect
any firewalling or other access control mechanisms. </P
><P
> Let's do a little more intensive scan. Let's check all ports -- TCP and UDP. </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> # nmap -sT -sU -p 1-65535 localhost
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on bigcat (127.0.0.1):
(The 131050 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
37/tcp open time
53/tcp open domain
53/udp open domain
80/tcp open http
3000/tcp open ppp
8000/tcp open unknown
32768/udp open unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 385 seconds
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> This is more than just <SPAN
CLASS="QUOTE"
>"interesting"</SPAN
> ports -- it is everything.
We picked up a couple of new ones in the process too. We've seen these before
with <B
CLASS="COMMAND"
>netstat</B
>, so we know what they are. That is the
<B
CLASS="COMMAND"
>Junkbuster</B
> web proxy on port 8000/tcp and
<B
CLASS="COMMAND"
>named</B
> on 32768/udp. This scan takes much, much longer, but it
is the only way to see all ports. </P
><P
> So now we have a pretty good idea of what is open on bigcat. Since
we are scanning localhost from localhost, everything should be visible.
We still don't know how the outside world sees us though. Now I'll
<B
CLASS="COMMAND"
>ssh</B
> to another host on the same LAN, and try again. </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> # nmap bigcat
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on bigcat (192.168.1.1):
(The 1520 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
3000/tcp open ppp
Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> I confess to tampering with the <SPAN
CLASS="APPLICATION"
>iptables</SPAN
> rules
here to make a point. Only two visible ports on this scan. Everything
else is <SPAN
CLASS="QUOTE"
>"closed"</SPAN
>. So says <SPAN
CLASS="APPLICATION"
>nmap</SPAN
>.
Once again: </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> # nmap bigcat
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap run completed -- 1 IP address (0 hosts up) scanned in 30 seconds
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
>Oops, I blocked ICMP (ping) while I was at it this time. One more time: </P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
> # nmap -P0 bigcat
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
All 1523 scanned ports on bigcat (192.168.1.1) are: filtered
Nmap run completed -- 1 IP address (1 host up) scanned in 1643 seconds
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> That's it. Notice how long that took. Notice ports are now
<SPAN
CLASS="QUOTE"
>"filtered"</SPAN
> instead of <SPAN
CLASS="QUOTE"
>"closed"</SPAN
>. How does
<B
CLASS="COMMAND"
>nmap</B
> know that? Well for one, <SPAN
CLASS="QUOTE"
>"closed"</SPAN
> means
bigcat sent a packet back saying <SPAN
CLASS="QUOTE"
>"nothing running here"</SPAN
>, i.e.
port is closed. In this last example, the <SPAN
CLASS="APPLICATION"
>iptables</SPAN
>
rules were changed to not allow ICMP (ping), and to <SPAN
CLASS="QUOTE"
>"DROP"</SPAN
> all
incoming packets. In other words, no response at all. A subtle difference
since <B
CLASS="COMMAND"
>nmap</B
> seems to still know there was a host there,
even though no response was given. One lesson here, is if you want to slow a
scanner down, <SPAN
CLASS="QUOTE"
>"DROP"</SPAN
> (or <SPAN
CLASS="QUOTE"
>"DENY"</SPAN
>) the packets. This
forces a TCP time out for the remote end on each port probe. Anyway, if your
scans look like this, that is probably as well as can be expected, and your
firewall is doing its job. </P
><P
> A brief note on UDP: <B
CLASS="COMMAND"
>nmap</B
> can not accurately determine
the status of these ports if they are <SPAN
CLASS="QUOTE"
>"filtered"</SPAN
>. You probably
will get a false-positive <SPAN
CLASS="QUOTE"
>"open"</SPAN
> condition. This has to do with
UDP being a connectionless protocol. If <B
CLASS="COMMAND"
>nmap</B
> gets no
answer (e.g. due to a <SPAN
CLASS="QUOTE"
>"DROP"</SPAN
>), it assumes the packets reached
the target, and thus the port will be reported as <SPAN
CLASS="QUOTE"
>"open"</SPAN
>.
This is <SPAN
CLASS="QUOTE"
>"normal"</SPAN
> for <B
CLASS="COMMAND"
>nmap</B
>. </P
><P
> We can play with firewall rules in a LAN set up to try to simulate how the
outside world sees us, and if we are smart, and know what we are doing,
and don't have a brain fart, we probably will have a pretty good picture. But
it is still best to try to find a way to do it from outside if possible.
Again, make sure you are not violating any ISP rules of conduct. Do you have
a friend on the same ISP? </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="SYSCTL">8.8. Sysctl Options</H2
><P
> The <SPAN
CLASS="QUOTE"
>"sysctl"</SPAN
> options are kernel parameters that can be
configured via the <TT
CLASS="FILENAME"
>/proc</TT
> filesystem. These can
be dynamically adjusted at run-time. Typically these options are off
if set to <SPAN
CLASS="QUOTE"
>"0"</SPAN
>, and on if set to <SPAN
CLASS="QUOTE"
>"1"</SPAN
>. </P
><P
> Some of these have security implications, and thus is why we are here ;-)
We'll just list the ones we think are relevant. Feel free to cut and
paste these into a firewall script, or other file that is run during boot
(like <TT
CLASS="FILENAME"
>/etc/rc.local</TT
>).
Red Hat provides the <B
CLASS="COMMAND"
>sysctl</B
> command for
dynamically adjusting these values (see man page). Or they can permanently be
set in <TT
CLASS="FILENAME"
>/etc/sysctl.conf</TT
> with your text editor of choice.
<B
CLASS="COMMAND"
>sysctl</B
> is executed during init, and uses these values.
You can read up on what these mean in
<TT
CLASS="FILENAME"
>/usr/src/linux/Documentation/sysctl/README</TT
> and other
files in the kernel Documentation directories.
</P
><P
> The traditional method: </P
><P
> <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
> #!/bin/sh
#
# Configure kernel sysctl run-time options.
#
###################################################################
# Anti-spoofing blocks
for i in /proc/sys/net/ipv4/conf/*/rp_filter;
do
echo 1 > $i
done
# Ensure source routing is OFF
for i in /proc/sys/net/ipv4/conf/*/accept_source_route;
do
echo 0 > $i
done
# Ensure TCP SYN cookies protection is enabled
[ -e /proc/sys/net/ipv4/tcp_syncookies ] &&\
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
# Ensure ICMP redirects are disabled
for i in /proc/sys/net/ipv4/conf/*/accept_redirects;
do
echo 0 > $i
done
# Ensure oddball addresses are logged
[ -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. ############
# Ensure ip-forwarding is enabled if
# we want to do forwarding or masquerading.
[ -e /proc/sys/net/ipv4/ip_forward ] &&\
echo 1 > /proc/sys/net/ipv4/ip_forward
# On if your IP is dynamic (or you don't know).
[ -e /proc/sys/net/ipv4/ip_dynaddr ] &&\
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
# eof
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> The same effect by using <TT
CLASS="FILENAME"
>/etc/sysctl.conf</TT
> instead: </P
><P
> <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
> #
# Add to existing sysctl.conf
#
# Anti-spoofing blocks
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
# Ensure source routing is OFF
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_source_route = 0
# Ensure TCP SYN cookies protection is enabled
net.ipv4.tcp_syncookies = 1
# Ensure ICMP redirects are disabled
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
# Ensure oddball addresses are logged
net.ipv4.conf.default.log_martians = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
## Optional from here on down, depending on your situation. ############
# Ensure ip-forwarding is enabled if
# we want to do forwarding or masquerading.
net.ipv4.ip_forward = 1
# On if your IP is dynamic (or you don't know).
net.ipv4.ip_dynaddr = 1
# end of example
</PRE
></FONT
></TD
></TR
></TABLE
></P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="SECUREALT">8.9. Secure Alternatives</H2
><P
> 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. </P
><P
> <P
></P
><UL
><LI
><P
>
telnet, rsh - ssh
</P
></LI
><LI
><P
> 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).
</P
></LI
><LI
><P
> sendmail - postfix, qmail. Not to imply that current versions of
<SPAN
CLASS="APPLICATION"
>sendmail</SPAN
> are insecure. Just that there
is some bad history there, and just because it is so widely used
that it makes an inviting crack target.
</P
><P
> As noted above, Linux installations often include a fully functional
mail server. While this may have some advantages, it is not necessary
in many cases for simply sending mail, or retrieving mail. This can all
be done without a <SPAN
CLASS="QUOTE"
>"mail server daemon"</SPAN
> running locally.
</P
></LI
><LI
><P
> POP3 - SPOP3, POP3 over SSL. If you really need to run your own
POP server, this is the way to do it. If retrieving your mail from
your ISP's server, then you are at their mercy as to what they provide.
</P
></LI
><LI
><P
> IMAP - IMAPS, same as above.
</P
></LI
><LI
><P
> If you find you need a particular service, and it is for just you or a few
friends, consider running it on a non-standard port. Most server daemons
support this, and is not a problem as long as those who will be
connecting, know about it. For instance, the standard port for
<B
CLASS="COMMAND"
>sshd</B
> is 22. Any worm or scan will probe for this port
number. So run it on a randomly chosen port. See the <B
CLASS="COMMAND"
>sshd</B
>
man page.
</P
></LI
></UL
></P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PFILTERS">8.10. Ipchains and Iptables Redux</H2
><P
> This section offers a little more advanced look at some of things that
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> and <SPAN
CLASS="APPLICATION"
>iptables</SPAN
>
can do. These are basically the same scripts as in Step 3 above, just
with some more advanced configuration options added. These will provide
<SPAN
CLASS="QUOTE"
>"masquerading"</SPAN
>, <SPAN
CLASS="QUOTE"
>"port forwarding"</SPAN
>, allow access to
some user definable services, and a few other things. Read the comments for
explanations. </P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN2316">8.10.1. ipchains II</H3
><P
> <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
> #!/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
</PRE
></FONT
></TD
></TR
></TABLE
></P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN2320">8.10.2. iptables II</H3
><P
> <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
> #!/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
</PRE
></FONT
></TD
></TR
></TABLE
></P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN2324">8.10.3. Summary</H3
><P
> A quick run down of the some highlights... </P
><P
> We added some host based access control rules: <SPAN
CLASS="QUOTE"
>"blacklisted"</SPAN
>,
and <SPAN
CLASS="QUOTE"
>"trusted"</SPAN
>. We then showed several types of service
and port based access rules. For instance, we allowed some very restrictive
access to bigcat's <SPAN
CLASS="APPLICATION"
>POP3</SPAN
> 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. </P
><P
> 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. </P
><P
> 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 <SPAN
CLASS="QUOTE"
>"masqueraded"</SPAN
>, so that it has Internet
access (different HOWTO), by manipulating the <SPAN
CLASS="QUOTE"
>"forward"</SPAN
> 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. </P
><P
> 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. <SPAN
CLASS="APPLICATION"
>PPP</SPAN
> works
differently and such rules are not needed.
</P
><P
> Please don't interpret that running any server as we did in this example is
necessarily a <SPAN
CLASS="QUOTE"
>"safe"</SPAN
> 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.
</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN2339">8.10.4. iptables mini-me</H3
><P
> Just to demonstrate how succinctly <SPAN
CLASS="APPLICATION"
>iptables</SPAN
> can be
configured in a minimalist situation, the below is from the Netfilter team's
<I
CLASS="CITETITLE"
>Rusty's Really Quick Guide To Packet Filtering</I
>:</P
><A
NAME="AEN2344"><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
> <SPAN
CLASS="QUOTE"
>"Most people just have a single PPP connection to the Internet, and
don't want anyone coming back into their network, or the firewall:"</SPAN
>
</P
></BLOCKQUOTE
><P
> <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
> ## 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
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> This simple script will allow all outbound connections that we initiate, i.e.
any <SPAN
CLASS="APPLICATION"
>NEW</SPAN
> connections (since the default policy of
ACCEPT is not changed). Then any connections that are
<SPAN
CLASS="QUOTE"
>"ESTABLISHED"</SPAN
> and <SPAN
CLASS="QUOTE"
>"RELATED"</SPAN
> to these are also
allowed. And, any connections that are not incoming from our WAN side
interface, <TT
CLASS="LITERAL"
>ppp0</TT
>, 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. </P
><P
> This script also demonstrates the creation of a custom chain, defined here
as <SPAN
CLASS="QUOTE"
>"block"</SPAN
>, which is used both for the INPUT and FORWARD
chains.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="general.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
> </TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>General Tips</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
> </TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
