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 <cisco4ng AT yahoo DOT com> 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 <hvdkooij AT VANDERKOOIJ DOT ORG> 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
=================================================
|
