5522 lines
128 KiB
HTML
5522 lines
128 KiB
HTML
<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
|
|
> |