Strategic Scanning and Assessments of Remote Hosts (SSARH)
Born on: 06.14.99 
[Unix File]


INTRODUCTION:

	This paper is being written for security administrators in hopes that they
will be able to notice security flaws in their networks and systems.  Be it known that
this paper is NOT a hacking text and we will not go into the topic of compromise, but 
this will show our target audience how to begin a strategic attack on a remote host.
We will cover basic assessment techniques involving open ports, RPC Services, open mount points,
and various ways to 'gain' information on your target before the actual attempt at compromise.


WHY:

	I guess we need to get the obvious out of the way.  Why attack a remote host is the first question you 
should ask yourself (out of boredom is not a valid reason).  I could probably go on and on about this but what 
im trying to get you to ask yourself is 'IS IT WORTH COMPROMISING'?  You need to look at the long term not the 
short term affect.  Gaining remote access to a government box or a 'high profile site' will carry some heavy penalties 
if you are caught.  So lets all think before we compromise.... ok?  Be intelligent about your decisions please.
All examples given in this paper should be tested on a local network with permission from the powers that be.

BRIEFING:

	Once you have found a remote host (target) that you would like to learn more about you are ready to move on. 
Before we proceed with any technical information first let me define two types of attacks.  A Passive attack is an 
attack that does not 'touch' a targets network directly so you are not committed to follow through with the compromise
at that time.  The next definition is the Active attack which does 'touch' the system and there is a very good 
possibility that your tracks will be left in the logs therefore, you are then commited to following through with the 
compromise to ensure that you are not found.  Now lets move on to the more technical side of this file.  First, I would 
suggest checking out their webpage and snoop around to see if you can find any of the following:

1.  Email addresses usually found at the bottom of a webpage as a contact.
2.  Look for the 'OS' stamp on a webpage.  Many admins/owners like to
    display their love for their Operating System with little graphics such as 'Run on Linux',
    'FreeBsd', 'Apache', 'IIS'..etc..etc
3.  Does their website look 'professional'?
4.  Do they provide any information about their network setup? (Yes, some are stupid enough 
    to provide network maps online.. duh!)
5.  Do they provide an online X.500 query gateway online?  This is where you can look up 
    email address's, phone numbers, and other various information about the users/employees of
    the company, organization, and the server.
6.  Do they provide an online telephone directory in which you type in
    names of people and get phone numbers and locations (which is great for Social Engineering) or
    visa-versa.
7.  Anything else that would benefit in learning more about the remote host.

-Now that we have scanned over the web pages of a potential target we can then proceed
into the next phase of information gathering.  Write down all of your notes on a piece of paper
or print them from file but I encourage you to never save these files to disk.  If you do intend 
to save these files to disk please make sure that you use the proper means to keep this 
information secure (encryption).  Now, lets take a look at the finger command.  
The finger displays information about the system users.  You can use this information for 
login names for the system which is of great value when gathering information.
Here is an example of some output displayed when the finger command is envoked.

$ finger root@target.com (Active Attack)

[target.com]
Login       Name               TTY         Idle    When    Where
root     Super-User            pts/0        

$ finger -l root@target.com

[target.com]
Login name: root                        In real life: Super-User
Directory: /                            Shell: /bin/csh
Last login Mon Jul 19 13:42 on pts/0
No unread mail
No Plan.

-We see that including the '-l' flag will give us additional information about the users on
the target host.

-Now lets try placing a number before the '@' sign

$ finger 4@target.com

[target.com]
Login       Name               TTY         Idle    When    Where
daemon          ???                               04:51
bin             ???                               05:45 
sys             ???                               08:54
RDoe            ???                               04:34

$ finger -l 4@target.com

[target.com]
Login name: daemon    
Directory: /                        
Never logged in.
No unread mail
No Plan.

Login name: bin       
Directory: /usr/bin                 
Never logged in.
No unread mail
No Plan.

Login name: sys       
Directory: /                        
Never logged in.
No unread mail
No Plan.

Login name: RDoe   
Directory: /export/home/RDoe         Shell: /bin/csh
Never logged in.
No unread mail
No Plan.

-Again, we see that adding the '-l' flag returns more data about the particular users of 
the target host.  Note that finger attempts may be logged in /var/log/messages (in Linux) and especially
if they have an IDS installed.  A sample log would look similiar to the following:  
Aug  2 05:21:25 erudite tcplog: finger connection attempt from 127.0.0.1
Also, finger runs on port 79/TCP and if the target host is not running the finger daemon then you will
not be able to use the finger query remotely to gather the information discussed above.

-We now have an easier account to compromise if we wish to do so.  A users password will usually
be easier to compromise than a root password because many users do not know the importance of
an obscure password.  The reason we obtain this information is because the finger command does
a pattern match on the number '4' and by process of elimination I would tend to guess that the 
number '4' appears in the time field.  You could also do the same thing with characters such as
the letter 'a' for example.  So now that we have built up even more information about our target
host, lets dig deeper into the system and gather even more data.

-Next, lets look at the nslookup command and see if we can dig up even further information
on our target host.   Nslookup is a program to query Internet domain name servers.  Nslookup
has two modes: interactive and non-interactive.  Interactive mode allows the user to query 
name servers for information about various hosts and domains or to print a list of hosts in a 
domain.  Non-interactive mode is used to print just the name and requested information for a 
host or domain.  Here we will show examples of interactive and non-interactive modes.

$ nslookup target.com  (Passive Attack)  

Server:  blah.yourhost.com
Address:  127.0.0.1

Non-authoritative answer:
Name:    target.com
Address:  127.0.0.2

-In Non-interactive mode we simply do [nslookup [target host]] and are returned with the name
of the host and its designated IP address.  The following is a demonstration of Interactive
mode and its associated flags.  

                       A         the host's Internet address.
 		       
                       CNAME     the canonical name for an alias.

                       HINFO     the host CPU and operating system type.

                       MINFO     the mailbox or mail list information.

                       MX        the mail exchanger.

                       NS        the name server for the named zone.

                       PTR       the host name if the query is an Internet ad-
                                 dress; otherwise, the pointer to other infor-
                                 mation.

                       SOA       the domain's ``start-of-authority'' informa-
                                 tion.

                       TXT       the text information.

                       UINFO     the user information.

                       WKS       the supported well-known services.

-To execute nslookup in Interactive mode using the above flags, do the following:

1.  Type the command nslookup

$ nslookup

Default Server:  blah.yourhost.com
Address:  127.0.0.1

>

2.  Set your flags by using [set type=[flag]]

> set type=mx  [Here we are using the 'MX' flag or the 'Mail Exchanger' flag]
> 

3.  Type in the target hostname [i.e. target.com]

> target.com

Server:  blah.yourhost.com
Address:  127.0.0.1

Non-authoritative answer:
target.com   preference = 10, mail exchanger = mail.target.com

Authoritative answers can be found from:
target.com   nameserver = ns1.upstream.com
target.com   nameserver = ns2.upstream.com
mail.target.com  internet address = 127.0.0.2
ns1.upstream.com internet address = 127.0.0.3
ns2.upstream.com internet address = 127.0.0.4

-Look at all this information we receive!  We now know the nameserver this target uses, their 
upstream provider, and the name of their mail server.  As an exercise, try setting the type to 
'any' by using the following syntax [set type=any].  See how much 'more' information you can 
extract from each and every flag.

-We can now move on to the DiG command or Domain Information Groper.  The DiG command is used similarly 
to the nslookup command as both send domain name query packets to nameservers.  Here we will show you an 
example of simple interactive mode which may give you similar data that you had obtained using the nslookup 
command, but DiG may return the slightly different data in a slightly different format.  To use DiG, issue the 
command as follows [dig [target.com]]:

$ dig target.com (Passive Attack)

; <<>> DiG 8.1 <<>> target.com
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;;      target.com, type = A, class = IN

;; ANSWER SECTION:
target.com.             9h51m25s IN A   127.0.0.2

;; AUTHORITY SECTION:
target.com.             8h53m50s IN NS  dns.upstream.com.
target.com.             8h53m50s IN NS  www.upstream.com.

;; ADDITIONAL SECTION:
dns.upstream.com.            9h51m25s IN A   127.0.0.3
www.upstream.com.            9h51m25s IN A   127.0.0.60

;; Total query time: 37 msec
;; FROM: yourmachinename to SERVER: default -- 127.0.0.3
;; WHEN: Mon Aug  2 05:25:16 1999
;; MSG SIZE  sent: 28  rcvd: 119                           


-The only new information we get is the web URL for the upstream provider of this particular target machine.  
Also, if you look closer you will see that various times are reported also as is the indication that the target 
is an internet domain class.  I am partial to nslookup due to the functionality and ease of use.
[man dig for more options regarding the DiG command]

-We will now move on to the whois command which is the TCP/IP Internet user name directory service.  
whois searches for an TCP/IP directory entry for an identifier.  You can obtain a considerable amount of
information using this simple command.  For this command, use the following syntax [whois [target host]]:

$ whois target.com (Passive Attack)

TARGET.COM (TARGET5-DOM)
   0000 Junk Street
   Lost Wages, WA 00000
   US

   Domain Name: TARGET.COM

   Administrative Contact, Technical Contact, Zone Contact:
      wah, chung  (LC0000)  somepoorsoul@TARGET.COM
      000-000-0000 (FAX) private
   Billing Contact:
      wah, chung  (LC0000)  somepoorsoul@TARGET.COM
      000-000-0000 (FAX) private

   Record last updated on 12-Apr-99.
   Record created on 12-Feb-99.
   Database last updated on 2-Aug-99 04:09:46 EDT.

   Domain servers in listed order:

   DNS.UPSTREAM.COM                  127.0.0.3
   DNS2.UPSTREAM.COM                 127.0.0.4     

  
-We now have a technical contact with name, email address, phone number, and sometimes fax number when it is not
marked 'private'.  The technical contact and number can be of great use when social engineering.  Take this time
to put all of the information we have thus far on a sheet of paper and you will see that we know a lot about this 
target host now, but in a few moments we will learn a great deal more as we now lead you into the rpcinfo command.

-The rpcinfo command reports RPC information on a particular host.  rpcinfo makes an RPC call to an RPC server and 
reports what it finds.  Many RPC services are vulnerable to a number of different attacks.  Take the ttdbserver exploit
for instance, due to a bug in the source we could write and manipulate any file on the server it is running on remotely
because this particular program is run as 'root'.  If the portmapper is not running on the remote target host then we 
should receive something along the lines of 'rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused'.  The
reason we receive this error is because we are trying to get a listing of RPC services via the portmapper which isn't running
on this particular host.  If we do successfully contact the portmapper we should get an output as follows.  To use the 
rpcinfo command we would use the following syntax [rpcinfo -p [target host]]:

$ rpcinfo -p www.target.com (Active Attack)
  
    program vers proto   port
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100024    1   udp    808  status
    100024    1   tcp    810  status
    100021    1   udp   2049  nlockmgr
    100021    3   udp   2049  nlockmgr
    100021    4   udp   2049  nlockmgr
    100021    1   tcp   2049  nlockmgr
    100021    3   tcp   2049  nlockmgr
    100021    4   tcp   2049  nlockmgr
    100005    1   tcp   1058  mountd
    100005    1   udp   1036  mountd
    391004    1   tcp   1063
    391004    1   udp   1037
    100001    1   udp   1038  rstatd
    100001    2   udp   1038  rstatd
    100001    3   udp   1038  rstatd        
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100024    1   udp    808  status
    100024    1   tcp    810  status
    100021    1   udp   2049  nlockmgr
    100021    3   udp   2049  nlockmgr
    100021    4   udp   2049  nlockmgr
    100021    1   tcp   2049  nlockmgr
    100021    3   tcp   2049  nlockmgr
    100021    4   tcp   2049  nlockmgr
    100005    1   tcp   1058  mountd
    100005    1   udp   1036  mountd
    391004    1   tcp   1063
    391004    1   udp   1037
    100001    1   udp   1038  rstatd
    100001    2   udp   1038  rstatd
    100001    3   udp   1038  rstatd
    391002    1   tcp   1070
    100083    1   tcp   1073                    

-I won't go into all the technical details here, but the listing shown here would be a goldmine for any hacker.
We see above that program '100083' is running, but the service isn't listed.  The ttdbserver runs as program
'100083' so we could have a vulnerable system on our hands.  There are several other things to check here such as
nfs, nlock, mountd, and rstatd.  We will not go into how to exploit these services, but we want to teach you how to
compile information on a remote target for a well-thought-out, calculated, time-sensitive audit.

-We will now move on to open mount points or better known as an exported list. Showmount shows mount information for
an NFS server.  showmount queries the mount daemon on a  remote  host  for information  about  the  state  of  
the NFS server on that machine.  If you do not include an option with the showmount command you will receive a list
of clients who are mounting from that host.  We usually use the '-e' option which is the 'export option' and is a great
way to find 'anonymous' mounting permissions on remote hosts.  To use the showmount command with the 'export option' use the
following syntax [showmount -e [target host]]. Note that if the mountd daemon is not listed in the RPC services we will not
be able to use showmount on that particular target host:

$ showmount -e www.target.com (Active Attack)

Export list for www.target.com:
/ (anonymous)

-As you can see that the root directory or '/' is allowed to be mounted by anybody with a connection to the internet and 
a *NIX box.  This is probably due to a misconfigured NFS server.  All we would need to do is mount this system and we would
have full control to edit the /etc/passwd and /etc/shadow files not to mention any other file on this particular target
host.  As an exercise, on your own system, try mounting an anonymous exported listing by using the following command:

$ mount -t nfs www.yourhost.com:/ /mnt

-This will give you full control over your own box anonymously.  Now perform the command [cd /mnt] and you should be in 
your boxs' root directory.  Now perform the following command [ls -al].  If all went according to plan you should see a
listing of the files and directories in the root directory.  There are several other tasks we could accomplish once inside
but, we will leave that up to the imagination of the reader.  

-Now lets take a look at a traceroute to the target host.  Traceroute prints the route packets take to a network host.
This will also alert us to any firewalls that stand in our way to the target host (usually indicated with a '*').
Note that the only mandatory parameter is the destination host name or IP number.  The default probe datagram length
is 38 bytes, but this may be increased by specifying a packet size (in bytes) after the destination host name.  
To initialize a traceroute use the following syntax as well as the man pages [traceroute [target host]]   

$ traceroute www.target.com (Active Attack)

traceroute to www.target.com (127.0.0.2), 30 hops max, 40 byte packets
 1  rsm1.yourhost.com (127.0.0.8)  0.791 ms  0.703 ms  0.704 ms
 2  bigdog-gw.yourhost.com (127.0.0.9)  0.592 ms  0.551 ms  0.405 ms
 3  1.atm8-0-0.umab-gw.net.ums.edu (131.118.255.129)  1.422 ms  1.020 ms  1.349
ms
 4  206.181.226.97 (206.181.226.97)  51.923 ms  52.127 ms  69.832 ms
 5  dca1-core3-h4-0.atlas.digex.net (165.117.51.70)  75.446 ms  66.744 ms  71.79
1 ms
 6  dca1-core7-fa6-0-0.atlas.digex.net (165.117.16.7)  79.978 ms  79.756 ms  77.
974 ms
 7  dca1-core9-pos1-1.atlas.digex.net (165.117.59.89)  69.804 ms  82.369 ms  81.
144 ms
 8  atl1-core5-pos1-3.atlas.digex.net (165.117.51.145)  86.819 ms  78.657 ms  52
.745 ms
 9  atl1-core3-pos4-0-0.atlas.digex.net (165.117.59.74)  40.033 ms  63.228 ms  6
8.938 ms
10  atl1-core1-fa3-0-0.atlas.digex.net (165.117.61.21)  78.620 ms  86.860 ms  98
.448 ms
11  500.Hssi11-1-0.GW1.ATL1.ALTER.NET (137.39.140.21)  105.357 ms  89.566 ms  11
6.460 ms
12  104.ATM3-0.XR2.ATL1.ALTER.NET (146.188.232.54)  121.399 ms  106.549 ms  139.
801 ms
13  294.ATM3-0.TR2.ATL1.ALTER.NET (146.188.232.110)  124.997 ms  129.528 ms  110
.989 ms
14  109.ATM6-0.TR2.LAX2.ALTER.NET (146.188.136.54)  201.188 ms  159.915 ms  215.
266 ms
15  198.ATM7-0.XR2.LAX2.ALTER.NET (146.188.248.133)  185.642 ms  142.192 ms  140
.496 ms
16  194.ATM9-0-0.GW1.PHX1.ALTER.NET (146.188.249.125)  158.889 ms  148.169 ms  1
37.867 ms
17  yourtargetsupstream-gw.customer.ALTER.NET (157.130.224.94)  153.436 ms  94.951 ms  140.0 
85 ms
18  * * * 
19  * * *     


-As you can see from this traceroute data that we are looking at a box that resides somewhere in the Phoenix
Arizona area and most likely has some sort of packet filtering device before we reach our remote target indicated
by the '* * *'(hops 18 & 19).  We also get information of what 'path' we take to get to our desired target host along with 
the hop number for each path taken.  Sometimes it may be easier to compromise an upstream and sniff the traffic to compromise 
the target host.  We can get away with a 'full' traceroute by using a technique known as 'Firewalking' (http://www.packetfactory.net/firewalk).  
Firewalking is a technique developed by MDS and DHG that employs traceroute-like techniques to analyze IP packet responses to 
determine gateway ACL filters and map networks. Firewalk the tool employs the technique to determine the filter rules 
in place on a packet forwarding device.  Also, we will be discussing spoofed packets to 'pierce' firewalls as a means to
portscan a machine on an internal network.

-For the remainder of this file we will be discussing portscanning.  Portscanning has become one of the key auditing and
recon techniques amongst hackers today.  There are a variety of portscanning utilities on the internet ranging from your
basic sequential portscanner to scanners that will bounce scans off of other hosts as an attempt to hide the origination of the scan.
The scanner that will be used in this file is a very versitile scanner called Nmap (http://www.insecure.org/nmap).  Nmap is a utility     
for network exploration or security auditing. It supports ping scanning (determine which hosts are up), many port scanning 
techniques (determine what services the hosts are offering), and TCP/IP fingerprinting (remote host operating system 
identification). Nmap also offers flexible target and port specification, decoy scanning, determination of TCP sequence 
predictability characteristics, reverse-identd scanning, and more (try [man nmap] for more details).  Lets take a look
at some of the flags we can use with Nmap along with the data that we obtain with each flag.  First try just typing in the
command 'nmap' so you can see how to use the application.

nmap V. 2.12 usage: nmap [Scan Type(s)] [Options] [host or net #1 ... [#N]]

-Here we have version number of the program and its usage.

-sT    TCP connect() scan:  This is the most basic form of
       TCP scanning.  Establishes a full TCP connection with each port.
       Considered to be a "noisy" scan because it leaves a lot of evidence
       in the logs.   

$ nmap -sT target.com (Active Attack)

Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on target.com (127.0.0.2):
Port    State       Protocol  Service
1       open        tcp        tcpmux
11      open        tcp        systat
15      open        tcp        netstat
22      open        tcp        ssh
25      open        tcp        smtp
79      open        tcp        finger
80      open        tcp        http
110     open        tcp        pop-3
113     open        tcp        auth
119     open        tcp        nntp
143     open        tcp        imap2
443     open        tcp        https
515     open        tcp        printer
540     open        tcp        uucp
2000    open        tcp        callbook
6667    open        tcp        irc
12345   open        tcp        NetBus

Nmap run completed -- 1 IP address (1 host up) scanned in 15 seconds
 
-The output that we receive from the TCP scan is very interesting yet, will be very noisey in the logs.  Any clued admin
will see this as an attempt to gather information for a future attempt at compromise.  Seeing that we are doing an assessment,
this method will suffice and does a wonderful job at identifying open ports.  We also receive a confirmation that Nmap has 
completed its run along with how many IP address's it scanned and how fast it scanned them.  Before we continue on to the other
features of Nmap lets assess this situation and make some sense of what we have here as far as data is concerned.  There are
several services that could be vulnerable to outside attack but, it is up to you to determine which services are vulnerable
and how to compromise each particular service.  Lets take smtp (port 25) for instance, we need to determine what mail service
this target host is running and which version of that particular package they are running.  To do this, simply telnet to that
port and read its header using the following command [telnet [target host] [port]]:

$ telnet www.target.com 25 (Active Attack)

220 target.com ESMTP Sendmail 9.1.12a/9.1.12a/punk-beta; Tue, 10 Aug 1999 08:44:03 -0700

-As you can see here this admin was clever enough to 'spoof' the version of Sendmail he is running.  He did this by editing
the config file for Sendmail which (when done properly) can hide the version number which is a key element for attacking this
particular service for many versions of Sendmail are exploitable remotely to gain root access.  Again, remember to make note
of each header and its respected data for they are valuble parts that make up this entire 'puzzle'.  While we are on the 
smtp service try out the help command by simply typing 'help'.

help

214-This is Sendmail version 9.1.12a
214-Topics:
214-    HELO    EHLO    MAIL    RCPT    DATA
214-    RSET    NOOP    QUIT    HELP    VRFY
214-    EXPN    VERB    ETRN    DSN
214-For more info use "HELP ".
214-To report bugs in the implementation send email to
214-    sendmail-bugs@sendmail.org.
214-For local information send email to Postmaster at your site.
214 End of HELP info
       
-You can now try different commands listed in the topics area.  Try [HELP [topic]] to see further help on a particular topic.
For an exercise, try doing a 'verify' (VRFY) on one of the users on the system, try root.  We will let you figure the command out
on your own so that you get into the 'learn it on your own' frame of mind.  Remember, when you are trying these exercises out
please do them on your own system or have the permission of the owner before you try any of these commands out.  

-Now that we have gone over a brief description of the TCP scan lets move on to a more 'stealthy' way of scanning a remote
host.  

-sS    TCP  SYN  scan: This technique is often referred to
       as "half-open" scanning, because you don't open a
       full TCP connection.
       
       1. Sends SYN packet as if establishing a 3-way handshake
       2. Waits for SYN/ACK from destination
          If SYN/ACK is received then the port is open
          If RST (reset) is received then the port is closed
       3. Rather than send ACK to establish connection, immediatley RST (reset) to
          close connection.

$ nmap -sS www.target.com 

Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on target.com (127.0.0.2):
Port    State       Protocol  Service
1       open        tcp        tcpmux
11      open        tcp        systat
15      open        tcp        netstat
22      open        tcp        ssh
25      open        tcp        smtp
79      open        tcp        finger
80      open        tcp        http
110     open        tcp        pop-3
113     open        tcp        auth
119     open        tcp        nntp
143     open        tcp        imap2
443     open        tcp        https
515     open        tcp        printer
540     open        tcp        uucp
2000    open        tcp        callbook
6667    open        tcp        irc
12345   open        tcp        NetBus

Nmap run completed -- 1 IP address (1 host up) scanned in 17 seconds

-Here we have the same ports open as before but, this time the identity of the account scanning this host is not given away.
The reason this happens is because we never establish a full connection or 'Three-way handshake'.  As soon as the SYN/ACK
is received from the destination, rather than send an ACK to establish a connection we immediatley send a RST or 'reset' to
close the connection therefore, the identity is never known (this is assuming that the target host is not running any 
extended logging features).

-Now we have a pretty good understanding of what services are running on this particular target host.  Now, lets take a look
at OS detection and the concepts of OS Fingerprinting.  There is a great paper on OS Fingerprinting by Fyodor at 
http://www.insecure.org/nmap/nmap-fingerprinting-article.html.  In this example we will show you how to use Nmap 
to detect the OS of our remote target.

-O     This option activates  remote  host  identification
       via TCP/IP fingerprinting.
       1) Takes advantage of nuances found in each OS's TCP/IP stack to determine what OS
          that remote host is running.
       2) Sends specifically crafted packets to a host.
       3) This information is used to generate a "fingerprint" which is then used to match
          from a database of known OS fingerprints.

$ nmap -O www.target.com

Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on localhost (127.0.0.1):
Port    State       Protocol  Service
1       open        tcp        tcpmux
11      open        tcp        systat
15      open        tcp        netstat
21      open        tcp        ftp
22      open        tcp        ssh
25      open        tcp        smtp
79      open        tcp        finger
80      open        tcp        http
110     open        tcp        pop-3
113     open        tcp        auth
119     open        tcp        nntp
143     open        tcp        imap2
443     open        tcp        https
515     open        tcp        printer
540     open        tcp        uucp
2000    open        tcp        callbook
6667    open        tcp        irc
12345   open        tcp        NetBus               

TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
Remote operating system guess: Linux 2.0.32-34

Nmap run completed -- 1 IP address (1 host up) scanned in 15 seconds

-The output of data that we see here are the same services as the previous examples except that we now know the OS of 
the remote target.  This target is running Linux 2.0.32-34 and the TCP Sequence Prediction for Trusted Relationship 
Exploitation or any other HiJacking method is truly random and would be VERY difficult to predict the sequence.  Now if 
we must use a script to compromise we now know what operating system we are looking at.  

-The final two scans we will discuss briefly are Ping Scanning and UDP Scanning.  TCP Ping Scanning is used to determine 
which hosts are up on a network. UDP scanning is a method used to determine which UDP (User  Datagram  Protocol,  RFC 768) ports 
are open on a host.  UDP scanning takes longer due to RFC 1812 section 4.3.2.8 and its limiting the ICMP error message rate.  


-PT    Use TCP "ping" to  determine  what  hosts  are  up.
       Instead  of  sending  ICMP echo request packets and
       waiting for a response, we send out TCP ACK packets
       throughout  the  target  network  (or  to  a single
       machine) and then wait  for  responses  to  return
       Hosts that are up should respond with a RST.
       * To set the destination port:  
         -PT   
       * The default port is 80

-sU    UDP scans: This method is used to determine which
       UDP (User  Datagram  Protocol,  RFC 768) ports are
       open on a host.  Sends a 0 byte UDP packet to each port on the
       target machine.  If we receive an ICMP port unreachable message, then
       the port is closed. 
       Some services that may be found with UDP scanning:
       *BO cDc's backdoor program that hides on a configurable UDP port on Win machines  
       *snmp
       *tftp
       *NFS
       *and others...

-We won't be showing output from these scans.  Rather, we ask you to perform the above flags
as an exercise for yourself.  Now that you have completed this basic auditing paper you should
take all the information learned here and apply it to one conclusive paper and then begin your
compromise.

CONCLUSION:

	In conclusion, we have discussed the basics to auditing a remote host or target host.
Knowing the security of your own network is key to being able to defend your network from 
malicious intent.  The techniques described here are basic techniques used to gather information
on the remote target before compromise.  Look for further papers from the ATTRITION staff on 
Penetration and Auditing of systems.  

GENERAL INFORMATION:

	ATTRITION Security:		http://www.attrition.org/security/newbie
	Nmap Security Scanner:  	http://www.insecure.org/nmap
	Whitepapers & Publications:	http://www.enteract.com/~lspitz/pubs.html
	Security Focus:			http://www.securityfocus.com/
        Packet Factory (Firewalk):      http://www.packetfactory.net/

CONTRIBUTIONS:

	Email all Contributions/Suggestions/Feedback to modify@attrition.org

ACKNOWLEDGMENTS:
	
        The following individuals helped in either review, technical input, or in some other fashion. 
 
        Brian Martin, Dale Coddington, Jay D. Dyson, and Jeremy Rauch  

modify@attrition.org (c) copyright 1998, 1999 Karl Lynn