Re: CBAC

that's good,
the RST packet from the CBAC router is likely forged with the non-existent
ip addres you are trying to contact.
thus in order to let your router having some notification about that
connection. try figuring out to receive
a tcp packets with the RST bit set coming from a different ip , rather than
the ip you are trying to contact.
it's a non sense.

the two RST packets you have are not both from the CBAC router, the second
one has been sent from
the router where the telnet started.

debug ip inspect timers/tcp/events
 and
debug ip tcp
on the telnetting router will clarify you how the flows are working,
capturing the packets will clarify you better.

CBAC, the poor man firewall :)

/R

2009/9/7 Anantha Subramanian Natarajan <anantha.natarajan_at_gravitant.com>

> Federico,
>
> No problem at all and appreciated your help.
>
> Tried telnetting to non-existent ip passing through the CBAC router and
> these below are the respective debug o/p.Session is meant to be between
> 10.1.1.6 and 10.1.1.12.After 30 seconds,tcp synwait time,I see two RST
> messages but couldn't able to understand from where it is generated.For
some
> reason I am guessing from the o/p that it is from the end points but didn't
> make sense for me.
>
> Kindly let know your inputs.
>
> *Mar 1 00:*19:05.959:* FIREWALL sis 658EB810 pak 655CCD80
> SIS_CLOSED/LISTEN *TCP S
> YN SEQ* 573085131 LEN 0 (10.1.1.6:36946) => (10.1.1.12:80)
> Inbetween lines removed
> *Mar 1 00:19:05.959: IP: s=10.1.1.6 (FastEthernet0/1), d=10.1.1.12
> (FastEtherne
> t0/0), g=10.1.1.1, len 44, forward
> *Mar 1 00:19:05.963: TCP src=36946, dst=80, seq=573085131, ack=0,
> win=4128
> SYN
> Inbetween lines removed
> *Mar 1 00:19:35.963: IP: s=10.1.1.12 (FastEthernet0/0), d=10.1.1.6
> (FastEtherne
> t0/1), g=10.1.1.6, len 40, forward
> *Mar 1 00:*19:35.967*: TCP src=80, dst=36946, seq=0, ack=0, win=4128
> *RST
> *Inbetween line removed
> *Mar 1 00:19:35.967: IP: s=10.1.1.6 (FastEthernet0/1), d=10.1.1.12
> (FastEtherne
> t0/0), g=10.1.1.1, len 40, forward
> *Mar 1 00:*19:35.971*: TCP src=36946, dst=80, seq=573085132, ack=0,
> win=0 *RST*
>
> **
> Thank You
>
> Regards
> Anantha Subramanian Natarajan
>
>
>
> On Mon, Sep 7, 2009 at 7:29 AM, Federico Cossu
<federico.cossu_at_gmail.com>wrote:
>
>> sorry anantha,
>> disabling http server is not a good idea because it causes the immediate
>> RST to be sent out.
>>
>> try to telnet on an non-existent ip passing through the CBAC router.
>>
>> this will make your telnet session to last enough time to be RST-ed by the
>> CBAC router
>>
>> /R
>>
>>
>> 2009/9/7 Anantha Subramanian Natarajan <anantha.natarajan_at_gravitant.com>
>>
>> Hi Federico,
>>>
>>> Thank you very much ...I tried your scenario......Where R2 is
>>> performing CBAC HTTP inspection and R3 is initiating session tol R1.Where
in
>>> R1 http server is disabled (no ip http server).The inspection rule was
>>> applied on R2 interface facing toward R1 in outbound direction.On R2
>>> interface facing R3,an inbound access-list is configured to allow all TCP
>>> traffic.In R2 interface facing toward R1,an inbound Extended ACL is
applied
>>> to deny all tcp traffic.
>>>
>>> Increased R3 tcp synwait-time to 300 seconds,which is higher than ip
>>> inspect tcpsynwait-time default time of 30 seconds.
>>>
>>> Enabled audit-trial on R2 and debug ip inspect tcp.Got the below message
>>>
>>> *Mar 1 00:32:27.671: %FW-6-SESS_AUDIT_TRAIL_START: Start http session:
>>> initiato
>>> r (10.1.1.6:32812) -- responder (10.1.1.1:80 <http://10.1.1.1/>)
>>> *Mar 1 00:32:27.671: FIREWALL sis 658EB810 pak 655CE9A0
>>> SIS_CLOSED/LISTEN *TCP S
>>> YN SEQ* 694001311 LEN 0 *(10.1.1.6:32812) =>
(10.1.1.1:80<http://10.1.1.1/>
>>> )
>>> **Mar 1 00:32:27.775: FIREWALL* sis 658EB810 pak 65226C74
SIS_OPENING/*SYNSENT
>>> TC
>>> P RST ACK* 694001312 SEQ 0 LEN 0 *(10.1.1.1:80 <http://10.1.1.1/>) <= (
>>> 10.1.1.6:32812)
>>> **Mar 1 00:32:27.775: FIREWALL* sis 658EB810 http L7 inspect result:
>>> PASS packet
>>> *Mar 1 00:32:32.775: %FW-6-SESS_AUDIT_TRAIL: Stop http session:
>>> initiator (10.1
>>> .1.6:32812) sent 0 bytes -- responder (10.1.1.1:80 <http://10.1.1.1/>)
>>> sent 0 bytes
>>>
>>> From the above it seems that,R1 immediately sends back TCP RST ACK packet
>>> to R3 and so the connection was disconnected.In that case I would assume
>>> that "ip inspect tcp synwait-time" will not even kickoff to see what
>>> messages the router sends assuming the three-way tcp session was not
>>> established before the synwait-timeout.Is my understanding right or I am
>>> missing something.Kindly let me know
>>>
>>> Thanks for the help
>>>
>>> Regards
>>> Anantha Subramanian Natarajan
>>>
>>> On Mon, Sep 7, 2009 at 2:29 AM, Federico Cossu <
>>> federico.cossu_at_gmail.com> wrote:
>>>
>>>> i think you can test it easily with dynamips on a scenario like this
>>>>
>>>> R1 <----> R2 <----->R3
>>>>
>>>> apply CBAC on R2 looking for http connections coming from R3 towards R1,
>>>> on R3 increase the tcp synwait time to something larger than the CBAC
>>>> timeout for tcp port 80,
>>>>
>>>> on R1 http server is disabled, start telnetting R1:80 and capture the
>>>> traffic on both R2 interfaces.
>>>> see what happen as soon as the CBAC SYN timeout expires.
>>>>
>>>> /R
>>>>
>>>>
>>>>
>>>> 2009/9/7 Jacob Uecker <juecker_at_ccbootcamp.com>
>>>>
>>>>> Yersinia is perfect for this! I've always liked to use hping to
>>>>> spoof
>>>>> packets, but anything along that line works. I guess you could create
>>>>> a
>>>>> static route so that the SYN-ACK isn't received by the original sender.
>>>>> An
>>>>> ACL would also work.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jacob Uecker
>>>>> CCIE# 24481
>>>>>
>>>>> Development Engineer
>>>>> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
>>>>> Toll Free: 877-654-2243
>>>>> International: +1-702-968-5100
>>>>> Skype: skype:ccbootcamp?call
>>>>> FAX: +1-702-446-8012
>>>>>
>>>>> YES! We take Cisco Learning Credits!
>>>>> Training And Remote Racks: http://www.ccbootcamp.com
>>>>>
>>>>> ________________________________
>>>>>
>>>>> From: Scott M Vermillion [mailto:scott_ccie_list_at_it-ag.com]
>>>>> Sent: Sun 9/6/2009 8:55 PM
>>>>> To: Jacob Uecker
>>>>> Cc: Anantha Subramanian Natarajan; Cisco certification
>>>>> Subject: Re: CBAC
>>>>>
>>>>>
>>>>> Hi Jacob,
>>>>>
>>>>> Yes, there are likely many ways to check -- assuming you can create the
>>>>> half-open scenario for IOS to react to in the first place. Any
>>>>> thoughts
>>>>> there? Yersinia or something along that line?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Scott
>>>>>
>>>>> On Sep 6, 2009, at 9:07 , Jacob Uecker wrote:
>>>>>
>>>>>
>>>>> I have always heard of using TCP RSTs instead of FINs. You
>>>>> could always use
>>>>> a SPAN port and check :)
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jacob Uecker
>>>>> CCIE# 24481
>>>>>
>>>>> Development Engineer
>>>>> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
>>>>> Toll Free: 877-654-2243
>>>>> International: +1-702-968-5100
>>>>> Skype: skype:ccbootcamp?call
>>>>> FAX: +1-702-446-8012
>>>>>
>>>>> YES! We take Cisco Learning Credits!
>>>>> Training And Remote Racks: http://www.ccbootcamp.com
>>>>> <http://www.ccbootcamp.com/>
>>>>>
>>>>>
>>>>> ________________________________
>>>>>
>>>>> From: nobody_at_groupstudy.com on behalf of Anantha Subramanian
>>>>> Natarajan
>>>>> Sent: Sun 9/6/2009 7:21 PM
>>>>> To: Scott M Vermillion; Cisco certification
>>>>> Subject: Re: CBAC
>>>>>
>>>>>
>>>>>
>>>>> Thank you Scott M Vermillion for your thoughts and inferences.
>>>>>
>>>>> Regards
>>>>> Anantha Subramanian Natarajan
>>>>>
>>>>> On Sun, Sep 6, 2009 at 9:19 PM, Scott M Vermillion <
>>>>> scott_ccie_list_at_it-ag.com> wrote:
>>>>>
>>>>> > My understanding is that it sends TCP RST in both directions,
>>>>> although I
>>>>> > couldn't come up with a direct quote to offer as proof (plenty
>>>>> of quotes
>>>>> > that state that as fact where TCP intercept is concerned, but
>>>>> not CBAC
>>>>> > specifically). A TCP FIN wouldn't be my first guess, as
>>>>> that's the means
>>>>> of
>>>>> > closing an *established* socket. What we're dealing with here
>>>>> is
>>>>> half-open
>>>>> > connections instead. So my vote is on a RST, but I'm not sure
>>>>> how to lab
>>>>> > this up. A means to generate a TCP SYN followed by nothing
>>>>> else would be
>>>>> > required. No doubt such a thing exists but I'm just not sure
>>>>> I have it
>>>>> > readily available on any of my existing lab gear. Anyone
>>>>> else?
>>>>> >
>>>>> >
>>>>> > On Sep 6, 2009, at 5:17 , Andy Reid wrote:
>>>>> >
>>>>> > Hi Ananatha,
>>>>> >>
>>>>> >> I have never noticed that part of the description before :
>>>>> "it notifies
>>>>> >> both parties that the connection has been terminated". I can
>>>>> only assume
>>>>> >> that it sends a FIN packet in both directions after the
>>>>> timeout occurs
>>>>> >> to fully close the connection, though I have not tested this
>>>>> specific
>>>>> >> function in my lab, i.e. CBAC sending TCP packets on behalf
>>>>> of hosts.
>>>>> >> Can anyone else confirm or otherwise explain the action of
>>>>> "ip inspect
>>>>> >> tcp synwait-time".
>>>>> >>
>>>>> >> Thanks, Andy
>>>>> >>
>>>>> >> Anantha Subramanian Natarajan wrote:
>>>>> >>
>>>>> >>> Hi Andy,
>>>>> >>>
>>>>> >>> Thank you very much for the explanation.I am trying to
>>>>> understand
>>>>> >>> the below highlighted statement,how it notifies the parties
>>>>> that the
>>>>> >>> connection is terminated,is it by sending some signal (Some
>>>>> thing like
>>>>> >>> RST or ?) ....Kindly help me to understand
>>>>> >>>
>>>>> >>> "This command specifies how long the cisco IOS waits for a
>>>>> TCP session
>>>>> >>> to be established (to complete three-way handshake).The
>>>>> default is 30
>>>>> >>> seconds.If the three way handshake is not completed by end
>>>>> of this
>>>>> >>> timeout,Cisco IOS removes the entry from its state table and
>>>>> the
>>>>> >>> dynamic entry in the ACL(before FAB) and* it notifies both
>>>>> parties
>>>>> >>> that the connection has been terminated*"
>>>>> >>>
>>>>> >>> Thanks for the help
>>>>> >>>
>>>>> >>> Regards
>>>>> >>> Anantha Subramanian Natarajan
>>>>> >>>
>>>>> >>> On Sun, Sep 6, 2009 at 9:34 AM, Andy Reid <ccie_at_reid.it
>>>>> >>> <mailto:ccie_at_reid.it>> wrote:
>>>>> >>>
>>>>> >>> Hi Anantha,
>>>>> >>>
>>>>> >>> The command "ip inspect tcp finwait-time" is used when
>>>>> waiting for
>>>>> >>> the FIN packets (default is 5 seconds).
>>>>> >>>
>>>>> >>> The "ip inspect tcp synwait-time" is used to protect
>>>>> against half
>>>>> >>> open sessions (default is 30 seconds) where the session
>>>>> never
>>>>> >>> becomes fully established, and therefore FIN packets are
>>>>> never sent.
>>>>> >>>
>>>>> >>> regards Andy
>>>>> >>>
>>>>> >>> Anantha Subramanian Natarajan wrote:
>>>>> >>>
>>>>> >>> Hi All,
>>>>> >>>
>>>>> >>> I was going through CBAC and trying to understand the
>>>>> >>> different global
>>>>> >>> settings on the same.One of that was "ip inspect tcp
>>>>> >>> synwait-time".The way
>>>>> >>> in which understood was as stated below(Actually Just
>>>>> pasting the
>>>>> >>> statements)
>>>>> >>>
>>>>> >>>
>>>>> >>> "This command specifies how long the cisco IOS waits
>>>>> for a TCP
>>>>> >>> session to be
>>>>> >>> established (to complete three-way handshake).The
>>>>> default is
>>>>> >>> 30 seconds.If
>>>>> >>> the three way handshake is not completed by end of
>>>>> this
>>>>> >>> timeout,Cisco IOS
>>>>> >>> removes the entry from its state table and the dynamic
>>>>> entry
>>>>> >>> in the
>>>>> >>> ACL(before FAB) and it notifies both parties that the
>>>>> >>> connection has been
>>>>> >>> terminated"
>>>>> >>>
>>>>> >>> In the above I am trying to understood,what kind of
>>>>> >>> notification it provides
>>>>> >>> to both the parties when the timeout as reached ..Is
>>>>> it TCP
>>>>> >>> RST or something
>>>>> >>> different.
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> Kindly let me know
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> Thanks for the help
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> Regards
>>>>> >>>
>>>>> >>> Anantha Subramanian Natarajan
>>>>> >>>
>>>>> >>>
>>>>> >>> Blogs and organic groups at http://www.ccie.net
>>>>> <http://www.ccie.net/>
>>>>> >>> <http://www.ccie.net/>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> _______________________________________________________________________
>>>>> >>> Subscription information may be found at:
>>>>> >>> http://www.groupstudy.com/list/CCIELab.html
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >> Blogs and organic groups at http://www.ccie.net <
>>>>> http://www.ccie.net/>
>>>>> >>
>>>>> >>
>>>>> _______________________________________________________________________
>>>>> >> Subscription information may be found at:
>>>>> >> http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>>
>>>>> Blogs and organic groups at http://www.ccie.net <
>>>>> http://www.ccie.net/>
>>>>>
>>>>>
>>>>>
Received on Mon Sep 07 2009 - 15:17:40 ART