Hi Rajeev,
Thank you very much for a very detailed explaination.
Essentially I would like to do the same thing on the CP firewall as I would with
the Cisco Pix. In other words, I want the CP firewall to randomize the Sequence
Number (SN) so that it will break my iBGP with MD5 authentication. Either way,
I would like to enable and disable this feature with CP firewall.
Hugo;
you said:
"At present you make an assumption here based on what 2
> routers do with BGP without the data to tell exactly what is going on.
>
> You may very well be putting Check Point on the wrong foot by not
> including the proper data."
My assumption is a very valid assumption. By having iBGP with md5
authentication working across the CP firewall, it proved that the TCP
sequence number was never randomized by the CP firewall, at least with
BGP traffics. Otherwise, my iBGP would not have worked, as desmonstrated
by the link provided by Cisco.
what do you think?
cisco4ng
Rajeev Gupta <rgup14 AT GMAIL DOT COM> wrote: Okay I have now gone through the
sk and finds what I said about
fingerprinting matches - I had given very high-level view but fundamentally
at every level, CP technique is the same. And also your CISCO link explains
very clearly what MD5 does and what PIX does to SN:"By default, the PIX
offsets the sequence number by a random number, per TCP flow. On the
sending BGP peer, TCP uses the original sequence number to create the
128 bit MD5 hash number and includes this hash number in the packet.
When the receiving BGP peer gets the packet, TCP uses the PIX-modified
sequence number to create a 128 bit MD5 hash number and compares it to
the hash number that is included in the packet.
The hash number is different because the TCP sequence value was
changed by the PIX, and TCP on the BGP neighbor drops the packet..."
Here is what may help you - not enabling fingerprint scrambling but within
SmartDefense enabling BGP under 'routing protocol' - if you are at NGX:
Description:
BGP (Border Gateway Protocol) is an application layer distance vector
routing protocol.
Attack Description:
Attacks on the BGP protocol may target either a vulnerability in the routing
software/hardware used or attack the routing information of the network (for
example, by vicious advertising routers). Authenticating BGP communication
between peers enhances the security of BGP.
SmartDefense Protection:
By enabling this protection, SmartDefense will detect and block BGP traffic
that is non-MD5 authenticated, which is considered insecure.
hope if this does not help - at least points in the right direction for your
conf call.
Rajeev
On 4/7/07, cisco4ng wrote:
>
> Have you checked Secure Knowledge?
>
> Yes I did. I looked at the sk prior to open a TAC case with CP.
>
> I explained to them exactly what I am trying to accomplish. With diamond
> support, I do not deal with CP TAC first line of support. I get a
> dedicated TAC
> engineer to my account. I told him exactly what I want to accomplish and
> provided him with the necessary data (i.e. tcpdump, fw monitor) for him to
> move forward. I even told him that they need to mock this up in their
> own lab
> to test this because this is a very simple scenario. By the way, I am
> doing this
> for my remote trigger black hole scenario where R1 is inside my firewall
> and
> R2 is the perimeter router outside the CP firewall.
>
> The bottom line is that I want to be able to prevent bgp sessions from
> being
> established between R1 and R2 like I would with pix without the keyword
> "norandomseq". See below:
>
>
> http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a008009487d.shtml
>
> When you are configuring BGP peers with MD5 authentication that pass
> through a PIX firewall, it is important to configure the PIX between the
> BGP neighbors so that the sequence numbers for the TCP flows between the
> BGP neighbors are not random. This is because the TCP random sequence
> number feature on the PIX firewall is enabled by default, and it changes
> the TCP sequence number of the incoming packets before it forwards them.
> MD5 authentication is applied on the TCP psuedo-IP header, TCP
> header and data (refer to RFC 2385 ). TCP uses this dataâ??which includes
> the TCP sequence and ACK numbersâ??along with the BGP neighbor password to
> create a 128 bit hash number. The hash number is included in the packet
> in a TCP header option field. By default, the PIX offsets the sequence
> number by a random number, per TCP flow. On the sending BGP peer, TCP
> uses the original sequence number to create the 128 bit MD5 hash number
> and includes this hash number in the packet. When the receiving BGP peer
> gets the packet, TCP uses the PIX-modified sequence number to create a
> 128 bit MD5 hash number and compares it to the hash number that is
> included in the packet.
> The hash number is different because the TCP sequence value was
> changed by the PIX, and TCP on the BGP neighbor drops the packet and logs
> an MD5 failed message similar to this one:
>
>
> The case has been opened for almost 3 weeks with no resolution. I get
> different
> answers from CP regarding this. There is a conf. call next week
>
> Hugo van der Kooij wrote: On Sat, 7 Apr 2007,
> cisco4ng wrote:
>
> > I would have expected the the iBGP session with MD5 authentciation
> > would not have established between R1 and R2 because the Checkpoint
> > firewall will randomize the tcp sequence number and it will screw
> > up the md5 authentication in iBGP. Much to my suprise, it still
> > works. This tells me that the checkpoint firewall does NOT
> > randomize the tcp sequence number at all when traversing from
> > one interface to another interface.
>
> Have you checked Secure Knowledge?
> Details on how these action occur are in sk30331.
>
> The only way to tell what it actually does is by capturing both sides and
> compare packets. At present you make an assumption here based on what 2
> routers do with BGP without the data to tell exactly what is going on.
>
> You may very well be putting Check Point on the wrong foot by not
> including the proper data.
>
> And as a side note. The first line of support is used to deal with people
> who hardly read the manual. You go over the details with them and make
> sure they got sufficient data and take it to the next level.
>
> There is an art to getting Check Point support at the right level. But I
> usually get to bug status swiftly enough in most of the cases.
>
> Some rules of thumbs for support questions:
> - Get cpinfo output in your initial report.
> - Describe it in a way the first line will be able to figure out. (Don't
> assume anything. Explain everything.)
> - Give them a call about 30 minutes after you logged the call to see who
> picked it up and go over it again to make sure they understand you.
> (Note that most of them do not use English as first language so some
> remarks may get misinterpreted. This is not just Check Point. I have
> this some other companies as well.)
>
> Hugo.
>
> --
> hvdkooij AT vanderkooij DOT org http://hugo.vanderkooij.org/
> This message is using 100% recycled electrons.
>
> Some men see computers as they are and say "Windows"
> I use computers with Linux and say "Why Windows?"
> (Thanks JFK, for the insight.)
>
> =================================================
> To set vacation, Out-Of-Office, or away messages,
> send an email to LISTSERV AT amadeus.us.checkpoint DOT com
> in the BODY of the email add:
> set fw-1-mailinglist nomail
> =================================================
> To unsubscribe from this mailing list,
> please see the instructions at
> http://www.checkpoint.com/services/mailing.html
> =================================================
> If you have any questions on how to change your
> subscription options, email
> fw-1-owner AT ts.checkpoint DOT com
> =================================================
>
>
>
> ---------------------------------
> TV dinner still cooling?
> Check out "Tonight's Picks" on Yahoo! TV.
>
> =================================================
> To set vacation, Out-Of-Office, or away messages,
> send an email to LISTSERV AT amadeus.us.checkpoint DOT com
> in the BODY of the email add:
> set fw-1-mailinglist nomail
> =================================================
> To unsubscribe from this mailing list,
> please see the instructions at
> http://www.checkpoint.com/services/mailing.html
> =================================================
> If you have any questions on how to change your
> subscription options, email
> fw-1-owner AT ts.checkpoint DOT com
> =================================================
>
---------------------------------
Don't get soaked. Take a quick peek at the forecast
with theYahoo! Search weather shortcut.
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to LISTSERV AT amadeus.us.checkpoint DOT com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
fw-1-owner AT ts.checkpoint DOT com
=================================================
|
