5915493 2001-01-04 09:40 +0100  /1017 rader/ Guido Bakker <guidob@SENTIA.NL>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-04  20:37  av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: guidob@sentia.nl
Mottagare: Bugtraq (import) <14601>
Ärende: analysis of auditable port scanning techniques
------------------------------------------------------------
From: Guido Bakker <guidob@SENTIA.NL>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3A543714.35D8A59A@sentia.nl>

        Examining port scan methods - Analysing Audible Techniques

                    whitepaper by dethy@synnergy.net


Abstract

I  will  attempt  to   enumerate  a  variety  of   ways  to  discover
and   map
internal/external  networks  using  signature-based  packet  replies
and  known
protocol responses when scanning. Specifically, this document presents
all known
techniques used to determine  open/closed ports on a  host and ways an
attacker
may identify the network services running on arbitrary servers.


1.1 Introduction

This paper will provide  an in-depth analysis of  known port scan
methods,  with exhaustive information  for each  technique used  in
the  wild today  to map and identify open and closed ports on various
network servers.

Note: This  paper will  not describe  techniques used  to fingerprint
operating
systems nor identify daemon versions (banner scanning).

With an epidemic of port scan  instances occurring each and everyday,
it  should be recognized the ways an attacker could probe network
hosts using a variety  of techniques aimed to avoid detection  whilst
obscuring the sender's true source.  Understanding actions to defend
against these network oriented scans is first to identify and
acknowledge the ways a scan can present appearing as normal inbound
traffic.

Port scanning is one of the most popular techniques used in the wild
to discover and map services that  are listening on a  specified
port. Using this method an attacker can then create a  list of
potential weaknesses and vulnerabilities in the proposed open port
leading to exploitation and compromise of a remote host.

One of the primary  stages in penetrating/auditing a  remote host is
to firstly compose a  list of  open ports,  using one  or more  of
the techniques described below.  Once  this has  been  established,
the  results  will help  an attacker identify various services that
are  running on that port using  an RFC-compliant port  list,
(/etc/services  in  UNIX,  getservbyport()  function automatically
obtains this)  allowing further  compromisation of  the remote  host
after  this initial discovery.

Port scanning techniques take form in three specific and
differentiated ways.

        * open scanning
        * half-open scanning
        * stealth scanning

Each  of these  techniques allow  an attack  to locate  open/closed
ports  on a server, but  knowing to  use the  correct scan  in a
given environment depends completely on the type of network topology,
IDS, logging features a remote  host has in place.  Although open
scans  log heavily and  are easily detectable  they produce fairly
positive results on open/closed ports.

Alternatively, using a stealth scan,  may avoid certain IDS and
bypass firewall rulesets but the scanning mechanism,  such as packet
flags, used  in identifying these open/closed ports maybe offset by
dropped packets over a network, leading to false positives. Further
discussion of this concept  takes place in the  FIN scan section of
this document.

Focusing more directly  at each of  the above techniques,  these
methods can  be further categorised into individual scan types. Let's
look at a basic scan model which includes PING sweeping:

                                         ___________
                                        |           |
                                        | scan type |
                                        |___________|

__________________________________|___________________________________
           /                  |                 \
|              |
          /                   |                  \
|              |
    _____|_____          _____|_____         _____|_____
____|___       ____|____
   |           |        |           |       |           |     |
|     |         |
   | open scan |        | half-open |       |  stealth  |     | sweeps
|     |  misc.  |
   |___________|        |___________|       |___________|
|________|     |_________|
         |                    |                   |
|               |
   ______|______         _____|____          _____|_____
____|_____      ____|_____
  |             |       |          |        |           |     |
|    |          |
  | TCP connect |       | SYN flag |        | FIN flag  |     | TCP echo
|    | UDP/ICMP |
  |_____________|       |__________|        |___________|
|__________|    |  error   |
         |                    |                   |
|          |__________|
  _______|_______      _______|______        _____|_____
____|_____           |
 |               |    |              |      |           |     |
|     _____|______
 | reverse ident |    | IP ID header |      | ACK flags |     | UDP echo
|    |            |
 |_______________|    | "dumb scan"  |      |___________|
|__________|    | FTP bounce |
                      |______________|            |
|          |____________|
                                             _____|______
____|_____
                                            |            |    |
|
                                            | NULL flags |    | TCP ACK
|
                                            |____________|
|__________|
                                                  |                |
                                             _____|_____
____|_____
                                            |           |     |
|
                                            | ALL flags |     | TCP SYN
|
                                            |  (XMAS)   |
|__________|
                                            |___________|          |
                                                  |
____|______
                                          ________|________
|           |
                                         |                 |  | ICMP
echo |
                                         | tcp fragmenting |
|___________|
                                         |_________________|
                                                  |
                                           _______|_______
                                          |               |
                                          | SYN|ACK flags |
                                          |_______________|

Diagram: known scan methods

The first nodes indicate the scan category which then traverses
downward to list the individual scans for that class.


1.2 open scan methods

Open scanning techniques are blatantly easy  to detect and to filter.
This  type of scan  method involves  opening a  full connection  to a
remote host using a typical three-way TCP/IP handshake. A standard
transaction involves issuing  the following flags to create an
accepted connection:


                        client -> SYN
                        server -> SYN|ACK
                        client -> ACK


The above example shows a port  answering our initial connection
request with  a SYN|ACK. This  response means  the port  the packet
was targeted  to is  in the LISTENING  (open)  state.  Once  this
full  handshake  has  taken effect,  the connection  will  be
terminated by  the  client  allowing a  new socket  to be
created/called allowing  the next  port to  be checked,  until the
maximum port threshold has been reached.

Reversely, taking  a look  at a  response from  a closed  port would
reveal the
following:

                        client -> SYN
                        server -> RST|ACK
                        client -> RST

The RST|ACK flags returned by the server is telling the client to tear
down  the
connection attempt since the port is not in LISTENING state thus is
closed.

This  method  is  created   through  connect()  system  call,
allowing  almost
instantaneous identification of  an open or  closed port. If  the
connect() call
returns true, the port is open, else the port is closed.

Since this  technique issues  a three-way  handshake to  connect to
an arbitrary host,  a spoofed  connection is  impossible, that  is to
say a  client can  not manipulate the true source IP, as a spoofed
connection attempt involves sending a correct sequence number as well
as setting the correct return flags to setup for data transaction.

Obviously this technique is easily  identifiable on any inbound
traffic because it opens a full  connection, thus all IDS  and
firewalls are able  to detect and block against this scan.  However,
because the  connect() method uses the three way handshake, results
of  this scan are about  as accurate as you could get to determine
open/closed ports.

Advantages   :   fast,  accurate,   requires  no   additional  user
privileges
Disadvantages: easily detectable and logged


1.2.1 - reverse ident scanning

This technique  involves issuing  a response  to the  ident/auth
daemon, usually port 113 to  query the service  for the owner  of the
running  process.  The main reason behind this  is to find  daemons
running as  root, obviously this  result would  entice an  intruder
to  find a  vulnerable overflow  and instigate  other suspicious
activities involving  this port. Alternatively,  a daemon running  as
user nobody (httpd) may not be as attractive to a user because of
limited access privileges. Unknowing to most users  is that identd
could release miscellaneous private information such as:

 * user info
 * entities
 * objects
 * processes

Although  the  identification  protocol   would  appear  as  an
authentication
mechanism, it was not designed or intended for this purpose. As the RFC
states,
"At best, it provides some  additional auditing information with
respect  to TCP
connections".  Needless to  say, it  should not  be used  as an  access
control
service nor relied upon added host/username authenticity.

The formal syntax taken from RFC 1413 reveals the following EBNF:

FORMAL SYNTAX

   <request> ::= <port-pair> <EOL>

   <port-pair> ::= <integer> "," <integer>

   <EOL> ::= "015 012"  ; CR-LF End of Line Indicator, octal \r\n
equivalents

   <integer> ::= 1*5<digit> ; 1-5 digits.


Using this grammar applied to the data we send to an arbitrary host
piped to the
ident/auth port  will reveal  the process  owner running  on a  given
port, even
though we initiated the connection.

Advantages   : fast, requires no additional privileges, return vital
service information
Disadvantages: easily detactable


1.3 - half open scan methods

The term  'half-open' applies  to the  way the  client terminates the
connection before the  three-way handshake  is completed.  As such,
this scan method will often go  unlogged by  connection based  IDS',
and  will return  fairly positive results (reliability of open/closed
port recognition).

1.3.1 - SYN scanning

The implementation of this scan method is similar to a full TCP
connect() three way handshake except instead of  sending ACK
responses we immediately tear down the connection. A demonstration of
this technique is necessary  to show a half open transaction:

                        client -> SYN
                        server -> SYN|ACK
                        client -> RST


This example has shown the target port was open, since the server
responded with SYN|ACK flags. The RST bit is kernel oriented, that
is, the client need not send another packet  with this  bit, since
the kernel's  TCP/IP stack code automates this.

Inversely, a closed port will respond with RST|ACK.


                        client -> SYN
                        server -> RST|ACK


As is displayed,  this combination of  flags is indicative  of a non-
listening
port.

Although, this technique has become rather easy to detect by many IDS,
owing  to
the  fact that  a paramount  of Denial  of Service  (DoS) utilities
base their
attacks  by  sending excess  SYN  packets. Fairly  standard  intrusion
detection
systems are  no doubt  capable of  logging these  half-open scans: TCP
wrappers,
SNORT, Courtney, iplog,  to a name  a few, thus  the effectiveness has
dithered
over recent years.

Notoriously, the  SYN method  was first  used to  avoid a  well used
IDS, named
SATAN.

Advantages   : fast, reliable, avoids basic IDS, avoids TCP three-way
handshake
Disadvantages: require root privileges, rulesets block many SYN scan
attempts


1.3.2 - IP ID header aka "dumb" scanning

ID header  scanning is  a rather  obscure scan  method involving
implementation peculiarities in  the TCP/IP  stack of  most operating
systems.  Originally this technique was discovered by antirez,  who
described it's technical details  in a post to bugtraq. Evidently the
basis of this scans implementation is reflective on the SYN scan
method, although involves  a third party host to use as a dummy
source.

Before explaining  any further  it's important  to recognize  what a
so- called
"dumb" host is. Contrasting to a bastion host, a silent or dumb host is
a server
that sends and receives  little to no traffic  at all, hence the
characteristic
name endowed upon it. Locating one of these hosts requires much effort
and  host
sweeping  itself,  and  is  probably  more  trouble  than  what  it
is   worth.
Nevertheless, it is a  genuine and creative scan,  that brings a
thirdhost  into
play adding to it's obscurity.

Involved in this scenario are three hosts:

        * A -> attackers host
        * B -> dumb host
        * C -> target host

Let's examine this cycle.

 * Host A sends a series of PING's analysing the ID field,
encapsulated within
   the IP header to Host B. A dumb host will have the ID increment the
reply by
   1 each time during the PING sequence.


   60 bytes from BBB.BBB.BBB.BBB: seq=1 ttl=64 id=+1 win=0 time=96 ms
   60 bytes from BBB.BBB.BBB.BBB: seq=2 ttl=64 id=+1 win=0 time=88 ms
   60 bytes from BBB.BBB.BBB.BBB: seq=3 ttl=64 id=+1 win=0 time=92 ms


 * Host A sends a spoofed SYN packet to Host C using the source
address of Host B.
   The remote port is any arbitrary port (1-65535) that the attacker
wishes to test
   for open/closed responses. Host C will reply to Host B with one of
two standard
   responses:

   -> SYN|ACK response indicates an open LISTENING port. Host B will
then reply with
      an RST bit flagged in the packet (automated by kernel).
   -> RST|ACK will indicate a NON-LISTENING port, (a standard SYN scan
method reply),
      and Host B will ignore that packet and send nothing in reply.


Now, how could Host A know what flags were sent to Host B ?

Well, assuming the port  was open on the  target server, our series  of
parallel
PING's that Host A  had been sending whilst  the spoofed SYN packets
were being
sent will hold our answers.
Analyzing the ID field  in these PING responses,   one would notice a
higher ID
increment.


   60 bytes from BBB.BBB.BBB.BBB: seq=25 ttl=64 id=+1 win=0 time=92 ms
   60 bytes from BBB.BBB.BBB.BBB: seq=26 ttl=64 id=+3 win=0 time=80 ms
   60 bytes from BBB.BBB.BBB.BBB: seq=27 ttl=64 id=+2 win=0 time=83 ms


Notice the second and third packets ID responses contain values
greater than  1, hence  an  open port  was  located. Any  further
increment of  more than 1  is indicative of an open port in Host B's
responses, during this period.

Originally, the increment  was 1, but  because Host A  sent a spoofed
SYN to an
open port,  Host B  had to  reply to  Host C  with the  SYN|ACK bit
packet, thus
incrementing the ID field. Following this the PING response to Host A
would then
in turn have a higher ID field, as suspected.

On the other hand,  a closed port state  on Host C would  not require
Host B  to
send anything, so the ID field in the PING response would not be
incremented  at
all.

   60 bytes from BBB.BBB.BBB.BBB: seq=30 ttl=64 id=+1 win=0 time=90 ms
   60 bytes from BBB.BBB.BBB.BBB: seq=31 ttl=64 id=+1 win=0 time=88 ms
   60 bytes from BBB.BBB.BBB.BBB: seq=32 ttl=64 id=+1 win=0 time=87 ms


As is shown, the ID field is still bounded by a constant of 1.

Once again  this is  why a  "dumb" host  is required,  so incoming
and outgoing traffic is kept at a bare minimum in order to decrease
false- positive results.

In fact, a  variety of scan  methods could be  used involving a  dumb
host. This scan is not limited to the SYN  scan technique. Any method
involving Host B  to respond  to  Host A's  port  reply could  be
practiced (hint:  inverse mapping techniques).


1.4 - stealth scanning

The definition of a "stealth" scan has varied over recent years from
what  Chris
Klaus, author  of a  paper titled  "Stealth Scanning:  Bypassing
Firewalls/SATAN
Detectors" delineated.   Originally the  term was  used to  describe a
technique
that  avoided  IDS  and  logging, now  know  as  "half-open"  scanning.
However,
nowadays stealth is considered  to be any scan  that is concerned with
a few of
the following:

        * setting individual flags (ACK, FIN, RST, .. )
        * NULL flags set
        * All flags set
        * bypassing filters, firewalls, routers
        * appearing as casual network traffic
        * varied packet dispersal rates

All scan the scans  described below use the  inverse mapping technique
for  open
port assumptions.


1.4.1 - SYN|ACK scanning

This technique has been disregarded in most, if not all, port scanners
to  date.
Ironically, the theory behind this method  is not unlike the SYN
method,  we cut
out the first step in our half-open TCP/IP setup. A standard response
would  act
as follows:

                        client -> SYN|ACK
                        server -> RST


The above flags have denoted to the client that the port is in a non-
listening state. Since the transmission control protocol realizes
that no initial SYN  was sent,  an immediate  termination response
was sent  out. In  other words,  the protocol thinks there has  been
an error in  the connection transaction to  that port when a SYN|ACK
has been received without a SYN, as a result the reset  flag is sent
back.

On the other hand a LISTENING port will not respond to these flags.


                        client -> SYN|ACK
                        server -> -


As is seen, the server ignores the SYN|ACK packet sent to an open
port.  Needless to say the absence of the  server's response packet
to ours, will produce false positives. Imagine  sending a  SYN|ACK
packet  and receiving  no response due to stately packet filters,
firewalls or even timeout limits blocking transmission, thus the
scanner would  then produce  false positives  for that port.
Naturally this scan is not considered as  reliable as TCP connect()
scans because of this very reason.  This type  of assumption  falls
under  what is  known as "inverse mapping".

Advantages   : fast, avoids basic IDS/firewalls, avoids TCP three-way
handshake
Disadvantages: less reliable (false positives)


1.4.2 - FIN scanning

The  FIN   scan  method   uses  inverse   mapping  to   discover
closed  ports.
Unfortunately,  this  techniques  relies  on bad  BSD  network  code
which most
operating  systems  have  based  their TCP/IP  stacks  on  (all  the
better  for
scanning). Ideally, once a FIN flagged packet is sent, a closed port
will resend
with  an  RST  bit. Open  ports,  alternatively  will not  send  a
packet back,
therefore what precisely is not answered with the FIN bit, is assumed to
be open
through this process of inverse mapping.

Take a look at the negotiation for open/closed port recognition
displayed below.


                        client -> FIN
                        server -> -

No  reply  signaled by  the  server is  iconic  of an  open
port. The server's operating system silently dropped the incoming FIN
packet to the service running on that port. Opposing this  is the RST
reply by  the server upon a closed  port reached. Since, no service
is bound on that port, issuing a FIN invokes a  reset (RST) response
from the server.


                        client -> FIN
                        server -> RST


Arguably there are two ways to test  for an open port. The first is
receiving a list of closed port responses and subtracting these port
replies from a list  of the port probes originally sent. For example,
sending 3 packets to ports 1, 2, 3 on a remote host.

If the response back is an RST for  ports 1 and 3, we then compare the
original
port list:  1, 2, 3 to the  received ports: 1, 3 and  deduce that 2 is
the  open
port via comparison.

The second test involves using a timeout for the packet response. If
the timeout limit is reached to receive the packet in question then
we assume it to be open.  Obviously, this method is test for  false
positives and should be avoided  where possible. The responses for
the  packet could be obscured because  of firewalls, filters,
routers, slow links, and heavy traffic, thus is not a solid test to
be used as a rule of thumb for stealth FIN scanning.


Advantages   : avoids many IDS, avoids TCP three-way handshake
Disadvantages: slow false positives


1.4.3 - ACK scanning

Uriel Maimon first described this technique in Phrack 49 article 15.
Needless to
say this  technique revolves  around a  bug in  the IP  layer of a few
operating
systems.

In order to  test for an  open port using  this method an  initial
ACK packet is sent to the target  host. There are actually  two ways
to classify  the response packet.  The  first involves  an
assessment of  the  TTL field,  the second is analyzing the WINDOW
field. Both of  these fields should  be obtained with  the response
packet that has the RST bit set.

The reply should be a reset connection, that is, a packet with the RST
bit  set.
Accompanying the  RST flag,  an analysis  of the  IP header,  for some
operating
systems, will provide a TTL that is lower than the other packets
received from a
closed port. Evidently any TTL sent to an open port would reveal a TTL
less than
or equal to 64, if the upper/lower ports have a higher TTL.


                        client -> FIN
                        server -> RST -> (TTL <= 64)


A real life response is show below:

 packet 1: host XXX.XXX.XXX.XXX port 20: F:RST -> ttl: 70 win: 0 =>
closed
 packet 2: host XXX.XXX.XXX.XXX port 21: F:RST -> ttl: 70 win: 0 =>
closed
 packet 3: host XXX.XXX.XXX.XXX port 22: F:RST -> ttl: 40 win: 0 => open

 packet 4: host XXX.XXX.XXX.XXX port 23: F:RST -> ttl: 70 win: 0 =>
closed


Notice the TTL  of the sequential  packets before and  after packet 3
is higher than 64. As packet 3 is received it is observed that the
TTL for port 22 is less than the boundary 64, indicating an open port.

Using the WINDOW  field method, any  non-zero response packet
received from the server  is indicative  of an  open port.  This is
true for  several early  BSD (FreeBSD,  OpenBSD) and  UNIX (AIX,
DGUX) but  has been  patched/fixed in  more recent versions.

                        client -> FIN
                        server -> RST -> WINDOW (non-zero)


A real life response is shown below:

 packet 6: host XXX.XXX.XXX.XXX port 20: F:RST -> ttl: 64 win: 0 =>
closed
 packet 7: host XXX.XXX.XXX.XXX port 21: F:RST -> ttl: 64 win: 0 =>
closed
 packet 8: host XXX.XXX.XXX.XXX port 22: F:RST -> ttl: 64 win: 512 =>
open
 packet 9: host XXX.XXX.XXX.XXX port 23: F:RST -> ttl: 64 win: 0 =>
closed


Notice that although the  TTL equals 64, the  surrounding packets do
also.  Thus
the TTL method  would not work  on this host,  however the WINDOW
offset method
shows a non-zero value indicative of an open port.

Advantages   : difficult to log, avoids IDS detection
Disadvantages: relies on BSD network code bug, OS incompatible


1.4.4 - NULL scanning

Clearly through it's endowed named, the NULL scan unsets ALL flags
available  in the TCP header. ACK, FIN, RST, SYN, URG, PSH all become
unassigned. The reserved bits (RES1, RES2) actually do not effect the
result of any scan, whether or  not they are set clearly does not
matter.  On arrival of this packet to the server, BSD networking code
informs the kernel to drop the incoming call if the port  is open.


                        client -> NULL (no flags)
                        server -> -


Alternatively, an RST packet will be returned if a closed port has
been reached (yes another inverse mapped scan).


                        client -> NULL (no flags)
                        server -> RST


Owing to  the fact  that the  RFC does  not exclaim  exactly how  a
host  should
respond to these types of packets, various network code for the major
operating
systems will differ in the packet responses, ie Microsoft vs UNIX.

Advantages   : avoids IDS, avoids TCP three-way handshake
Disadvantages: UNIX only, false positives


1.4.5 - XMAS scanning

Contrastedly, a so called XMAS scan is the inverse of the NULL scan
method.  All the available flags in  the TCP header are  set (ASK,
FIN, RST,  SYN, URG, PSH).  XMAS  or "Christmas  Tree" scanning  is
named  rightly so  after the decorative effect the scan has with the
flagging implementation. The reserved bits do  not effect the scan
result, so setting or unsetting is ofno importance.  Once  again,
since this method is based on  BSD networking code the technique will
only work against UNIX hosts.

XMAS scanning works by initializing  all the flags and transmitting
this packet to the remote host. The  kernel will drop the packet  if
an open port is  at the receiving end. A returned RST  flag will
reflect a  closed, NON-LISTENING port again this is an inverse mapped
scan, so false positives is all a client has  to detect an
open/closed port.


                        client -> XMAS (all flags)
                        server -> -


This signature tells us that the port  is in LISTENING state, or the
packet  was
filtered by  a firewall/router.  Alternatively a  closed port  will
produce  the
following reply:

                        client -> XMAS (all flags)
                        server -> RST


The RST would be sent to the client because the server is tricked into
thinking
that the  client has  a connection  on that  port without  negotiating
with  the
standard three-way handshake. Since TCP is stateful the kernel sends a
reset bit
(RST) back to the client to end transmission immediately.

Advantages   : avoids IDS, avoid TCP three-way handshake
Disadvantages: UNIX only, false positives


1.4.6 - TCP Fragmenting

TCP fragmenting is not a scan method  so to speak, although it
employs a  method to obscure  scanning implementations  by splitting
the TCP  header into smaller fragments. IP reassembly on the
server-side can often lead to unpredictable  and abnormal results (IP
headers carrying data  can be fragmented).  Many hosts are unable to
parse and  reassemble the  tiny packets  and thus  may cause crashes,
reboots,  or even  network device  monitoring dumps.  Alternatively,
these  tiny packets may be potentially blocked by  IP fragmentation
queues in the kernel  or caught by a stately firewall ruleset.

Since many intrusion detection systems use signature-based mechanisms
to signify scanning attempts based on IP and/or the TCP header,
fragmentation is often able to defeat this type  of packet filtering
and  detection, and naturally the  scan will go undiscovered.

A  minimally allowable  fragmented TCP  header must  contain a
destination and
source port for the first packet  (8 octect, 64 bit), typically the
initialized
flags  in the  next, allowing  the remote  host to  reassemble the
packet upon
arrival. The actual reassembly is established through an IPM (internet
protocol
module) that identifies  the fragmented packets  by the field
equivalent values
of:

        * source
        * destination
        * protocol
        * identification

Advantages   : avoids IDS, stealth
Disadvantages: may cause network problems on remote host


1.5 Miscellaneous

This category  represents scans  that can  not be  entirely classified
into the
broader open/half-open/stealth classes. The scans here are dissimilar
in  nature
but are techniques still used in the wild today.


1.5.1 - UDP ICMP_PORT_UNREACHABLE scanning

Unlike the above scanning methods, the  User Datagram Protocol (UDP)
is used  to determining open/closed ports on a remote host rather
than TCP.

UDP is  a connectionless  stream protocol  that sends  datagrams as  a
means  of
packet transmission.  Similarly to  the inverse  mapping system,
sending a  UDP
packet to an open port will receive no response from a server. However,
a closed
port will respond with an Internet Control Message Protocol (ICMP)
error  reply.
Using a process of extrapolation it  is simple to identify the open
from closed
ports. The message type, ICMP_PORT_UNREACH (type 3 code 3), does not
technically
need to be sent when a closed  port received a UDP packet, hence the
difficulty
with  this scanning  method. Additionally,  UDP is  known to  be an
unreliable
protocol  since   packets  are   easily  dropped   during
transmission,   hence
retransmission needs  to take  place, otherwise  even more  false
positives  are
assumed  in the  scan result.  Linux kernels  limit ICMP  error message
rates,
destination unreachable are set to 80  per 4 seconds with 1/4 second
penalty if
that is exceeded, adding to the scanning technicality, as Fyodor pointed
out.

An open port signature should send no reply, also a retransmitted
packet is sent to reduce false positives:


                        client -> udp packet
                        server -> -
                        client -> udp packet
                        server -> -


Closed ports will response with the ICMP error.


                        client -> udp packet
                        server -> UDP (ICMP_PORT_UNREACH)


Advantages   : scans non-TCP ports, avoids TCP IDS
Disadvantages: requires root, packets easily dropped, easily detected


1.5.2 FTP server bounce attack

This ingenious method  was described in  a paper by  the
hobbit. Using, the FTP PORT command  to set  a clients  passive mode,
a host  is able to determine the status of a port  by issuing an IP
and port as arbitrary  parameters to connect to. If a connection is
established as a means of active data transfer processing (DTP), the
client knows a  port is open, with a  150 and 226 response issued  by
the server. If the transfer fails a  425 error will be generated with
a refused build data message.

Early versions of WU-FTPD (less than 16) were vulnerable to this type
of attack, nowadays  the  presence of  this  bug has  been  patched
in  most FTPD's. Other vulnerable versions include:

Sun FTP server in SunOS 4.1.x/5.x,  SCO OpenServer 5.0.4, SCO UnixWare
2.1,  AIX
3.2/4.2/4.2./4.3, Caldera 1.2, RedHat 4.X, Slackware 3.1 - 3.3.

An easy way to disallow this kind of attack is to prevent third party
transfers
through modification  of the  PORT command  and/or disallowing
specification of
reserved ports, except port 20 the standard default data port.

Advantages   : bypass firewalls, allows access to local nets, hard to
trace
Disadvantages: slow, most FTPD's have been patched


1.6 Blocking packet anomalies

Isolating and  filtering the  packets used  in all  the above  scans
is one step forward into securing any inter-network  connected
node. Any application of  the following rulesets will yield many port
scanning techniques with false positive information, highlighting the
well known "security through obscurity" objective.

        * block unassigned port traffic  (traffic to ports with
unassigned services)
        * application-layer monitoring
        * deny pass-through traffic
        * monitor transport-layer connections (control of TCP, SYN, RST,
ACK)
        * monitor source address matching well known addresses
        * filter ICMP type 3 and 8
        * active network monitoring


Many audible scanning techniques exist to gather information about
the services that  exist on  a host.  However, none  of these
techniques will  evade a  well configured proxy along with an active
systems analyst to spot potential traffic abnormalities.



References

Art of portscanning by Fyodor     -     http://www.phrack.com
Networking Scanning by Ofir Afkin -     http://www.sys-security.com
FTP bounce attack by hobbit       -
http://www.insecure.org/nmap/hobbit.ftpbounce.txt
-----------------------------------------------------------------------------------------

(C)opyright 2001 by dethy@synnergy.net
Synnergy Networks
(5915493) --------------------------------(Ombruten)