In some mail from eckes, sie said:
>
> Hallo,
>
> > > If you block all tcp packets and only allow through packets which are
> > > part of a connection you know is alive (or start of), then this stops
> > > 90% of stealth scanning. Logging all connection establishment attempts
> > > should give you a record of the other 10%. And yes, IP filter will give
> > > you both.
> >
> > If it's maintaining that sort of state it's not a packet filter any more...
> > it's operating at a higher level in the network stack.
>
> Does this mean that Packetfilter which can observe the syn and ack Flags for
> TCP Connections are not enough?
Correct.
> If I read this right stealth Scanning would be to scan with TVP PAckets
> which look like they are responses to a valid connection and therefore are
> not filtered. What will be the information you get from such Packets if they
> receive the Client? Used Ports? Used Addresses? Sequence Numbers? Is there a
> real gain from 'stealth scanning' which requires statefull packet filters?
> Has anybody any references on technical notes about this?
I'll include my posting on this from last year, below.
Note the date, kernels may have been patched since to prevent this from
working.
> BTW: Linux has now Transparent Proxy Support. Together with the NAT Features
> and Port Redirection it makes a very well Low-Cost Firewall Kernel.
The Linux code in 1.3 and now pre-2.0 is buggy. It will not work 100%.
The Linux people have been told but they're happy with the way it is.
It DOES NOT do transparent proxying (it just thinks it does). If you want
to be sure, read the source code. I did and found problems.
darren
From: Darren Reed <avalon @
coombs .
anu .
edu .
au>
Subject: port scanning.
To: Firewalls @
GreatCircle .
COM (Firewalls Mailing List)
Date: Tue, 5 Dec 1995 00:00:27 +1100 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: firewalls-owner @
GreatCircle .
COM
Precedence: bulk
Status: O
(hopefully this is far enough from being an actual exploit to be
suitable for the firewalls list. Whilst not directly relevant to
firewalls, I believe some of the details herein will be of interest
to its readers).
"Stealth Scanning": etcp
Well since newscan is available, I don't see too much harm in making this
tool available (I was unaware that it existed, previously). There are
"bugs" here for everyone...:-(( Hassle your vendor if you find your
machines susceptible to some of the stranger things below.
This document describes the behaviour of etcp and thus explains to a fair
extent how Stealth Scanning works, how to take advantage of buggy firewalls
which don't send back replies and points out some bugs in TCP.
etcp is the precursor to ipsend (which has diverged from the role of doing
TCP port scans). It ONLY works over Ethernet. It's primary role was to
exercise the short-TCP packet bug, but became a bit more flexible. It will
ONLY run on SunOS4 (NIT or BPF) and 4BSD boxes with BPF. The command line
looks something like this:
etcp [-d device] [-f fragflags] [-g gateway] [-m mtu] [-p min] [-P max]
[-s src] [-S source-port] [-t port] dest flags
Device is obvious (which device you want the packet to go out from).
(defaults to le0)
The "fragflags" field is there to niggle another bug observed in packet
filters (mainly setting the highest bit -ONLY- and sending a packet with
this field as 0x8000, even though it wasn't a fragment).
The gateway allows it to send packets through to another network.
The mtu paramter. This did "most of the damage". The key value for this
field is 28 - enough to put port numbers in one packet and TCP flags in
the next.
The min and max parameters specify the minimum and maximum ports for the
scan. Default is 0 and 1023.
Source allows for a different source address to be specified - almost useless
unless you don't want to see the replies.
Source port sets the given field in the TCP header.
If the port number is given, with the -t option, it will try to make a TCP
connection and then send data across without using in-kernel TCP. This option
work best with an MTU of 28 against a packet screen'd firewall which doesn't
return any ICMP/TCP packets in response to blocked packets. Why ? Because
it relies on the screen remaining silent and not giving the kernel any cause
to close the TCP connection. So, if that bug was available, it'd call
connect(), expect the SYN packet to be dropped, send across a SYN split in
two which would hopefully make it through, assume an answer, and then send
across an ACK (using a system call) with actual data, doing a kernel lookup
to get the sequence/ack numbers from the TCP PCB. Sometimes not sending a
reply is more dangerous than sending one :-)
Destination is the destination IP address.
Flags is any combination of TCP flags (SAFRPU).
This table shows the packets returned to those sent. The target machines
were an Ultrix 4.3 box and a FreeBSD 2.0.5 box. Hopefully two different
`poles' of BSD TCP.
L - Listening, I - Inuse, U - unused
S - SYN, A - ACK, F - FIN, R - RST
All packets should be considered to have bad sequence/ack numbers.
Sent State Received Window*
S L SA !=0
S I - -
S U RA 0
SA L RA/R# !=0
SA I A/- !=0/-#
SA U R 0
F L A/- !=0/-
F I - -
F U RA/R 0
FA L R/- !=0/-
FA I A/- !=0/-
FA U RA 0
FS L RA/SA !=0 &
FS I - -
FS U RA 0
R L R/- !=0/-
R I RA/- !=0/- +
R U - -
RA L RA/- !=0/-
RA I RA !=0 +
RA U - -
* - on Solaris 2, RST packets always have a window of 0.
+ - On some Unixes, where a reply is shown as received, this can close the
connection a la ICMP destination unreachable `nukes' - hassle vendor!
# - FreeBSD 2.0.5 reponses, where different
& - it appears that 4.4BSD treats FS as a S.
When kernels based on BSD networking are targetted, a non-zero window is
returned for sockets which are listening. This is due to them (a) having a
non-zero window in the listening state and (b) a pointer, tp, being non-null
when passed to tcp_close() to send the RST. In case (b), tp points to the
listening socket.
Looking at the above table, we can scan for active listening ports quite
successfully, so long as we know what to expect back. In particular,
using a SYN-ACK instead of a SYN seems particularly fruitful.
It can be found at:
ftp://coombs.anu.edu.au/pub/misc/etcp.tar.Z
darren
p.s. between this and ipsend, I've found `bugs' in TCP/IP on Solaris2.4,
4.4BSDs, Linux, SunOS4, Ultrix 4.3...so there are probably some in
the others too! Some bugs are more benign than others, and at least
two can be made to crash/panic and not reboot.
References:
|
|
