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)