Re: CBAC

Thank you very much federico

Regards
Anantha Subramanian Natrajan

On Mon, Sep 7, 2009 at 8:17 AM, Federico Cossu
<federico.cossu_at_gmail.com>wrote:

> 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<http://10.1.1.12/>
>> )
>> 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/>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>>
Received on Mon Sep 07 2009 - 08:21:03 ART