Home page logo

bugtraq logo Bugtraq mailing list archives

analysis of auditable port scanning techniques
From: Guido Bakker <guidob () sentia nl>
Date: Thu, 4 Jan 2001 09:40:52 +0100

        Examining port scan methods - Analysing Audible Techniques

                    whitepaper by dethy () synnergy net


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
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
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
Understanding actions to defend against these network oriented scans is
first to
identify and acknowledge the ways a scan can present appearing as normal

Port scanning is one of the most popular techniques used in the wild to
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
compose a  list of  open ports,  using one  or more  of the techniques
below.  Once  this has  been  established, the  results  will help  an
identify various services that are  running on that port using  an
port  list,  (/etc/services  in  UNIX,  getservbyport()  function
obtains this)  allowing further  compromisation of  the remote  host
after  this
initial discovery.

Port scanning techniques take form in three specific and differentiated

        * 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
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
rulesets but the scanning mechanism,  such as packet flags, used  in
these open/closed ports maybe offset by dropped packets over a network,
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

                        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

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
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
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
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
Disadvantages: easily detectable and logged

1.2.1 - reverse ident scanning

This technique  involves issuing  a response  to the  ident/auth daemon,
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
private information such as:

 * user info
 * entities
 * objects
 * processes

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

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


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

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

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

   <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
before the  three-way handshake  is completed.  As such,  this scan
method will
often go  unlogged by  connection based  IDS', and  will return  fairly
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

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-

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
systems are  no doubt  capable of  logging these  half-open scans: TCP
SNORT, Courtney, iplog,  to a name  a few, thus  the effectiveness has
over recent years.

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

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

1.3.2 - IP ID header aka "dumb" scanning

ID header  scanning is  a rather  obscure scan  method involving
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
on the SYN scan method, although involves  a third party host to use as
a dummy

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
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
   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

   -> 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
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

   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

   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
traffic is kept at a bare minimum in order to decrease false- positive

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

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
Detectors" delineated.   Originally the  term was  used to  describe a
that  avoided  IDS  and  logging, now  know  as  "half-open"  scanning.
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-
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.
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
thus the  scanner would  then produce  false positives  for that port.
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

Advantages   : fast, avoids basic IDS/firewalls, avoids TCP three-way
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
operating system silently dropped the incoming FIN packet to the service
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
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
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
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

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
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
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 =>
 packet 2: host XXX.XXX.XXX.XXX port 21: F:RST -> ttl: 70 win: 0 =>
 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 =>

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 =>
 packet 7: host XXX.XXX.XXX.XXX port 21: F:RST -> ttl: 64 win: 0 =>
 packet 8: host XXX.XXX.XXX.XXX port 22: F:RST -> ttl: 64 win: 512 =>
 packet 9: host XXX.XXX.XXX.XXX port 23: F:RST -> ttl: 64 win: 0 =>

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
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
BSD networking code informs the kernel to drop the incoming call if the
port  is

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

Alternatively, an RST packet will be returned if a closed port has been
(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
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,
XMAS  or "Christmas  Tree" scanning  is named  rightly so  after the
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,
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
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
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
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
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
flags  in the  next, allowing  the remote  host to  reassemble the
packet upon
arrival. The actual reassembly is established through an IPM (internet
module) that identifies  the fragmented packets  by the field
equivalent values

        * 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.


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
need to be sent when a closed  port received a UDP packet, hence the
with  this scanning  method. Additionally,  UDP is  known to  be an
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
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

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
to. If a connection is established as a means of active data transfer
(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
build data message.

Early versions of WU-FTPD (less than 16) were vulnerable to this type of
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
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
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
information, highlighting the well known "security through obscurity"

        * 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,
        * 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
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


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

(C)opyright 2001 by dethy () synnergy net
Synnergy Networks

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]