Re: Logging source IP address of a half-open scan

From: amputee (dirty@pakistani.com)
Date: 07/12/02 

From: "amputee" <dirty@pakistani.com>
Date: Fri, 12 Jul 2002 06:22:24 GMT

"Ian Nguyen" <inguyen@netspace.net.au> wrote in message news:aglbb8$2tgl$1@otis.netspace.net.au...
> Hi,
>
> Could someone please clear this up for me: As I understand it (and please
> correct me if I'm wrong), a firewall only log the source IP address of a
> connection only after the TCP three-way handshake is completed.
>
> If a source host initiate a request for a connection, by sending the
> destination host a SYN packet, and upon receiving the SYN, ACK packets from
> the destination host, the source host immediately return a RST (reset)
> packet, thereby closing the connection. This is a typical TCP half-open
> scan, a feature that a port scanner like nmap offers.
>
> My question is: Because a TCP packet is encapsulated in an IP packet, and
> the IP packet itself contains the source IP address, does it not get logged
> by a firewall (or an IDS for that matter) when the first SYN packet is
> received? I would think that upon receiving the SYN packet the firewall
> would need to strip off the MAC frame header, the IP header, and then look
> in the TCP header to evaluate the appropriate fields (in this case the TCP
> flags). During this process does it (the firewall) not see the source IP
> address?
>
> Any explanation is most appreciated and welcome.
>
> Ian

If you look at what you just said, I believe you'll find you answered your own question.
The IP address is contained in the IP header, and has nothing to do with TCP and
half open scans. Now.. not all firewalls work the same, they are designed and coded
by different people, who use different techniques. I don't know of ANY firewall
that would wait until it finished a 3-way handshake in order to log the IP address,
since as we just established, a complete handshake status is irrelevant in determing
IP address.. but it wouldn't surprise me if some fool out there wrote something that
behaved in that manner.

amputee

Relevant Pages

  • RE: First TCP packet
    ... The TCP datagram travels inside an IP packet, ... to B should be the TTL on the IP Header. ... might change depending of devices on the path ...
    (Pen-Test)
  • Re: [fw-wiz] FW and TCP Sessions
    ... >if a FW is said to be a stateful firewall, ... >i haven't sent a TCP SYN to initiate a TCP Session ... >before sending this TCP packet? ... what a "stateful" firewall is or does except that "everyone knows ...
    (Firewall-Wizards)
  • Re: 7.0 BETA3 - slow TCP upload (TSO related?)
    ... I experience very slow TCP upload from this host - cca 50kbps. ... I have some debug prints in kernel (mostly in ip_output and ipfw log) ... 2/ is diverted by firewall ... 3/ Packet appears immediately again in ip_output with ip_len 2924 and ...
    (freebsd-stable)
  • Re: NDIS passthru packet redirection
    ... I solved this with adjusting the TCP checksum. ... Now I must redirect the answer packet to the calling application. ... TCP header or TCP data isn't changed, the you don't need to update the TCP ...
    (microsoft.public.development.device.drivers)
  • Re: 8159 bytes takes 20 ms, 8160 bytes takes 200 ms?
    ... look for Nagle algorithm in TCP ... > this is what etheral shows, a packet with ack and push flag set, and win2k ... > Header length: 20 bytes ... > Fragment offset: 0 ...
    (microsoft.public.win32.programmer.networks)