Re: pcap processing

[Ron <ron () skullsecurity net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yeah, like Kris said, it's your OS responding to a SYN/ACK it didn't know about. 

If you're on Linux and have iptables, here is the simplest command:
 iptables -t filter -A OUTPUT -p tcp --tcp-flags RST RST -j DROP

That'll block any outbound packet with RST set. It's a little overkill, and will definitely have some side effects, but 
it'll do the trick. You can also narrow it down more from there by giving ip addresses and ports. 

Ron

On Thu, 23 Sep 2010 12:43:58 -0400 Robert Kat <r33dtard () gmail com> wrote:
> Thanks!  I was afraid that it was the OS but just needed to be sure.
> I take it then that the connect function registers the outgoing
> connection with the kernel which is why it works.
>
> Good thing this was just an exercise.
>
> Thanks again guys.
>
> On Thu, Sep 23, 2010 at 12:35 PM, Kris Katterjohn
> <katterjohn () gmail com>wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 09/23/2010 09:48 AM, Robert Kat wrote:
> > > Could it be something in my TCP or IP header thats causing this
> > > issue.  I just threw them together by looking at the ipidseq
> > > script and what telnet was using in wireshark.  Is there a flag
> > > that I should be
> > setting/unsetting?
> > > I hate to have to create a firewall rule every time I want to run
> > > this
> > scan.
> > >
> >
> > Sorry, but the RST being sent by your OS is just an artifact of the
> > response
> > to your raw packet send.  Normally when a TCP connection is made,
> > the kernel
> > takes care of everything and knows about its connections
> > (address/port pairs,
> > etc).  However, when you send out a SYN packet over a raw socket,
> > the kernel
> > keeps no record of this.  When a SYN/ACK is received in response,
> > the kernel
> > only views it as an invalid acknowledgment for the port (the source
> > port you
> > chose, which is probably closed).
> >
> > Run a SYN scan with Nmap and watch it in Wireshark.  The SYN/ACK
> > responses it
> > receives cause RSTs to be sent out.  Closed ports respond with a
> > RST/ACK, which don't cause RSTs to be sent back.  (RFC 793 has more
> > details, starting
> > at page 65).
> >
> > There are things you can do to avoid this, but setting a firewall
> > rule is probably the easiest (most straightforward, anyway)
> > solution.
> >
> > Cheers,
> > Kris Katterjohn
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iQIcBAEBAgAGBQJMm4HVAAoJEEQxgFs5kUfu2ZUQAJVvlIdXNf/CZdNRtkyR8QUM
> > UYtrWgxAsL7BqKz+B3ZuvuiXSRZuB3Dv6NbJTc7pCYsexjWVGixGkFW+WXkEf3fl
> > O5PzGBnGo7jHaXg0jxlVv+uVuIhfGENb+ReJRZBIUxcMgVnz1m4VZI8VB/vhoHcI
> > wmoOR0wR+zQmqBrxHKaQFxsVEuLbbgWSjTiFR6DRDYAUNSnBGFuhQNFmzTSEV7X7
> > obgvgJK1upo+pdhCxmzRSkcyeevswxdg7JYYe/uRfEFSoEb1i4nGjxbTQ1xNWQYy
> > 4SMvMhlrRpeDkzv9A/i2SB8q1z5PJOwGZ98oqEy7vTwkRxAFZ03d/Y2MyyIjPYJo
> > 2kqdfCbNmPsl5jVu1dpR2bNbCsl2OSAgUUXXP9pxtitLdY9VNpiJFyKH0dsnU0sf
> > 62WONqUaP39fEtx/H6ukp8wZHAvsiXij0x2NaZTZI1WC0g6XF9+e07oiL8D61L5x
> > XWcSz7iONTqY8lGx7dgrds34lEp14lRxK+4ihcY87H6Mg2z+AULRn1Qa5irqXIew
> > vj+H1gLcEjmXb6vdIhfIDNKIA1KaTHyexl8KiC9AAZaeMddzKRjlcK421k9669wN
> > Fjck1uO16QtbIBwCebPBJCvI4tkgyd2wVCPopkCblCUsByYJER7V3iq4/9AFLlNA
> > NFTYP2B3secBmWVEmOJo
> > =02P8
> > -----END PGP SIGNATURE-----
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkyboMUACgkQ2t2zxlt4g/Qe7ACfSewBSuCnFpj/UN7vO6+SokoM
61UAniDx3VtVAMuWAgN/zFu5rnKV5EnJ
=znCv
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/