OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: open ports and your linux box
From: macker (mackerRTHONET.HAPPYLAND.NET)
Date: Tue Aug 29 2000 - 22:12:04 CDT

I've seen a lot of traffic on the list lately regarding "What's this port
that's open", etc.

It occurred to me that we're seeing a lot of traffic with largely
duplicated answers, as well as diff threads with same question, just a
different port #.

I decided to model this after the HOWTO's somewhat, to make it easier to
navigate. It should be noted this is lengthy, and has lots of detail for
novices. I try to stay away from any scripts or advanced sets of
commands, trying to keep it simple and easy to understand.

Some feedback here on the list would be appreciated. Thanks.

So, to chip in my own fifty cents <clink crack..oops> here goes...

0.0 Table of Contents
----------------------
1.0 - Introduction
  1.1 - Revision History
2.0 - Open sockets
  2.1 - Finding open sockets
  2.2 - What owns this socket?
  2.3 - Other Programs
  2.4 - Ok, now what?
    2.4a User-installed Programs
    2.4b System programs
    2.4c Strange locations
    2.4d Running unknown programs

3.0 - Conclusion
A - Appendix A
  A.1 - Glossary
  A.2 - Commands

1.0 Introduction
-----------------
This is a brief guide to help novice users with their Linux box. In
particular, identifying ports that are open, and what's running on those
ports. That's section 2. If this turns into something more, other
sections will be added for other topics.

If someone needs to get hold of me personally, e-mail mackerhappyland.net

If you just have general questions, please address them to the Focus Linux
list, or your local guru.

1.1 Revision History
---------------------
First release - 08/29/00 - mackerhappyland.net
  1st, completed in a few hours... if there's errors, don't sue me :)

2.0 Open sockets
-----------------
This section is about open sockets, determining what is open (without
methods like running a port-scanner on yourself), and determining why it's
open, or at least what owns it.

2.1 Finding open sockets
-------------------------
There are several ways to find open ports on your system. My favorite is
as follows:

netstat -tea | grep "LIST"

The "t" option specifies TCP sockets only.. one could remove the "t" to
see UDP sockets as well.

The "e" is for extended info, i.e. UID of owner.

The "a" specifies all connections, not just connected ones and the like.

A person could also speed this up by using the "n" switch, to specify all
output in numeric IP form, removing the need to resolve IP's to DNS on the
fly.

Lastly, if watching for UDP as well, one should subsitute the keyword
"LIST" for "*", which works equally as well.

2.2 What owns this socket?
---------------------------
Now, as for determining what owns a socket, there's 3 ways that i'm aware
of...

You can use "netstat -anp" or "netstat -ap" as root. If you used the "n"
switch previously, you should use it now. If you didn't, don't. The
reason is that the "n" switch also causes it to show port #'s as numbers,
instead of looking up in /etc/services.

Sample output of this would be:

tcp 0 0 *:smtp *:* LISTEN
7694/sendmail: acce

or

tcp 0 0 *:113 *:* LISTEN
7663/inetd

In both cases we see that it is a tcp socket.

Next (of importance) we see that it is bound to *, meaning it will listen
to any interface, not just one single IP. This is important if, for
instance, we have an internal network and an external network, and our
proxy server should only listen to a socket on the internal interface.

Next it shows the port in question. In the first example, it's the "smtp"
port, which is port 25 as found in /etc/services. In the second example,
it says port "113", which if we do some looking (as in /etc/services), we
see is "auth", aka identd. With some services, the program looks in
/etc/services to see what port # it should operate on... just because it
says "telnet" doesn't mean it has to be port 23. Normally, this isn't a
problem unless someone's been adjusting /etc/services.

Now we see "*:*" .. this is the remote address field. This is stating it
is listening for connections from any address and any source port. The
connection could come from anywhere. This is normal behavior.

Next, we see that it is in a "LISTENING" state. This is where we get the
"LIST" keyword for grep, because it normally will never be duplicated in
all caps.

Finally we see the owning process, and it's PID. In these cases, it's
sendmail and inetd. If we do a "ps aux" we can see more info about these
processes, including their owners (root). As a quick note, a service can
not bind to a port less than 1024 without being root. To explain the
how "httpd" can be on port 80 as "nobody", it starts out as root, and then
after binding to port 80, drops is privs and goes to "nobody".

2.3 Other Programs
-------------------
A person could also use the programs "lsof" and "fuser". The "fuser"
program can be useful for this, and other things. The "lsof" program,
while somewhat 'raw', can be extremely useful, especially for finding
backdoors that have been installed and the like.

For full fuser syntax, just type 'fuser' at the prompt.

Briefly, fuser can be used to identify an open port's owner with the
following command (for TCP, where ### is the port #):

fuser -u -v -n tcp ###

The lsof program could be used to identify open connections and their
owners, as well as listening connections, with ease. Briefly, the
following command will provide process name, pid, owner, protocol
(tcp/udp), address(es) in use, and state (established, listening):

lsof -i
lsof -i | grep LIST

The latter will show only listening TCP sockets.

2.4 Ok, now what?
------------------
Now you know what program is on that port, and even who is running it,
along with its pid. Often times, this is enough, you know what the
program is now... "Oh, okay, that's my Quake3 server!" But what if you're
still unsure as to what this program is?

Well, there's two ways this can go. Either it's a system program,
probably setup when you first installed Linux, or it's something installed
by a user (possibly even you).

2.4a User-installed Programs

First we'll consider the user-installed scenario.

First thing is first, if we don't already have a clear idea of where it's
running, let's do the following commands:

whereis program
  which program
lsof -c program
locate program

These should be done in order... 'whereis' will tell you all instances of
files which seem to match that it has found in common places. The 'which'
command can be used to give a better idea which one you are looking for,
if you come back with a dozen results that look probable.

Now if this didn't help, run 'lsof -c program'... you may need to do 'lsof
-c program | more'. This will dump a *lot* of information on you, about
all kinds of files and libraries and directories that the program may be
accessing, as well as network connections. Look for "txt REG" .. this
will normally be the program itself. On the far right will be the full
path to the program. Now you know where it is running from!

The lsof program should always work, but sometimes you want to find
related files.. doing "locate program" can often find files/directories on
the drive with the info. This will have mixed results, often unsuccessful
on systems running RedHat or SuSE or Debian, as by default "locate" will
not probe directories that it can't see running as "nobody" (vs. root).

Poke around the directory the program resides in, and possibly places
'locate' turns up. Your worst-case scenarios here are to search the web
for the name the program is running as, or usually much easier, run
'strings'.

'strings' is a wonderful unix program that can take a binary file, and
give you text strings from it, often revealing the nature of the program.
Syntax is simply "strings filename | more" (you'll nearly always need to
use more).

There is one other thing, which technically is an option... you can run
the program to see what it appears to do. I strongly recommend *NOT* to
do this. This can be one of the worst things you can do. And by all
means, never ever ever do this as root... if you must do it, try to do it
as a no-name user on a box with no network/internet connectivity, and do
it in a chroot jail. This should not be considered an option, though.

2.4b System programs

If it is a system program, then things are much easier. All of the
tactics for identifying a 'user-installed' program apply here, with the
addition of a few more:

On a system using a package manager, such as RPM, you can do "rpm -q -f
/path/to/file" and it will tell you what package it is... then just do
"rpm -q -i package". Tah-dah! A full list of files in the package can be
obtained by doing "rpm -q -l package".

Often, doing "man program" will turn something up, if it has a man page...
whereis will often reveal a manpage, if one exists.

If it is a system program, looking for config files often are effective.
If, when doing hunting (including a pstree), you see "inetd", be sure to
check /etc/inetd.conf for references to the program. On most default
installations, inetd accounts for at least half of listening ports.

2.4c Strange locations

One should always beware of names or paths which seem "off", like
/bin/telneted, or for a program that you don't recall being installed.
Something like /dev/in.telnetd should also be considered *extremely*
suspicious... this is a popular place to put backdoors and network
sniffers and the like. Don't automatically jump to 'rm -rf', but do
beware.

2.4d Running unknown programs

This is the worst thing I can think of. A hacker could run a program that
sits in memory when started by him, but if anyone but root or him starts
it, it just exits with some sort of error, or nothing at all. Then, along
comes Joe Admin, who runs the program as root... this program, actually
evilHacker-2001(tm) in disguise, goes ahead and installs backdoors for the
hacker, and proceeds to randomly erase important files from the system, as
root.

This is not a good thing, and is completely possible and very easy.

DO NOT RUN PROGRAMS YOU ARE UNSURE OF.

The only time this should be attempted is by a programmer, on an isolated
system, on an isolated account, using a debugger (such as gdb). This is
an advanced topic, and not even the author would attempt this.

3.0 Conclusion
---------------
Well... that's it for now. Hope this was informational, educational,
and/or helpful.

Questions/comments/suggestions can be addressed to mackerhappyland.net or
Focus-Linux mailing list. General questions regarding your system, or an
open port/program on your system, should probably be addressed to
Focus-Linux. If mailing the author, please start the subject with
"[Ports-Howto]" (case is not important).

A. Appendix A
--------------
Here's some useful stuff that I didn't want to clutter the main text with.

A.1 Glossary
-------------
Port:
  Well... if you don't know this, this howto is beyond you, but: a port
is like an ordering window at the drive-thru.. someone can pull up to it
(if it accepts orders), someone can have a conversation at it (2-way), and
someone behind the window can use it to call out to somewhere else (e.g.
someone in the parking lot)

Socket:
  Basically, a socket is another term for a port, referring to one that is
in use. A person can be talking about a port in another context, such as
a list of ports to be blocked on a firewall, where-as a socket almost
always refers to a port that's being used or listened to.

PID:
  process id. This is the number assigned to each program (process)
started on the system. They are assigned sequentially, and the counter
'rolls over' at around 32,000. Generally, something below 1,000 was
started around the time the system booted up, though there are exceptions.
Look at "ps aux" and "pstree -u" often... get to know your system...

netstat: tool to show active network connections and listening sockets.

lsof: tool to show open files/devices/ports and related information.

fuser: another tool, similar to lsof.

grep: pattern-matching program... a "word search" program.

ps: program to show active (running) processes.

pstree:
  does the same as ps, but gives a "pretty" format to show both the
processes, and where they started.

A.2 - Commands
--------------
ps is our friend:

There's several useful options to "ps" we should know about now...

ps -w .. wide format. Is something getting chopped? This shows it all.

ps e .. show environment. Most useful when combined with -w.. this will
show (easily) some of the environment settings... something like
"/home/eviluser/hackit-1.0/" in the environment is probably a
bad-thing(tm).

ps -H .. show heirarchy. Somewhat like pstree, this lets you easily
identify "chains", e.g. login -> bash -> pico /etc/passwd