First of all, I would like to say a good word for you - you have generally
enriched this list with your very inquisitive mind and I have personally
enjoyed your conversations very much - some times challenging and sometime
very raw but that makes this list very colorful:-)! Thanks.
Secondly, from a high-level CP view, I would like to say that Fingerprinting
scrambling/ISN spoofing from CP perspective, in my understanding, is not
supposed to do what you are interpreting it to do. As I understand it, ISN
spoofing is simply to scramble the SNs. RFC defines these SNs but each
vendor's TCP/IP stack implementation leaves a 'fingerprint' specific to its
own implementation through these SNs that can, thus, be used to identify the
host OS leading to potential vulnerability for attacks. If you enable
'fingerprint scrambling'/'ISN spoofing' in SD, CP would scrambles those SNs
but would not itself lose track of those real SNs - it would mediate to
ensure the communication does not break because of the firewall doing
SN/Fingerprint scrambling.
So, as you can see in CP ISN spoofing/Fingerprinting scrambling, no
'hashing' is involved that needs any comparison at either ends to ensure the
integrity of the data.
I am not sure of iBGP maneuvers of TCP/IP headers as much as you would be
from CISCO/PIX perspective but from gerneric MD5 hashing technique, it
appears when you enable MD5 auth, PIX is doing some hashing that would
change during its TCP sessions which when done at the other end does not
calculate to the same value as the originator seemed to have appended to the
packet leading to breakdown of the communication and 'needing what CISCO
tells to do 'norandomseq' WHICH would undo what PIX appears to be doing in
its normal communications - say, changing some SN, for example.
Thirdly, I would agree with your experiences with CP TAC support in general
but objectively speaking without appearing to be attempting to be a CP
advocate, I would like to say that even though the TAC support is not as
responsive, CP has some of the 'smartest' techies in their backwaters who
would spurt out answers to such questions very spontaneously, though. But
same is true of most of the TAC support in general from all vendors - they
are supposed to know the techniques but generally few who have attempted to
understand the science behind the products they support. Hope you would get
some answer from CP diamond support soon and I would look forward to your
sharing with us what you find out ultimately.
Again, want to express my sincere thanks for inquisitive experimentations!
Regards,
Rajeev
On 4/7/07, cisco4ng <cisco4ng AT yahoo DOT com> wrote:
R1---CP_Firewall----R2
R1 ip is 192.168.1.11/24 and R2 IP is 192.168.2.22/24
Firewall internal ip is 192.168.1.1/24 and external
ip is 192.168.2.1/24
I am doing ibgp with MD5 authentication between R1 and R2.
Keep in mind that the firewall just routes the traffic, no
nat whatsoever here.
In checkpoint SmartDefense, under the Fingerprint Scrambing,
I selected the checkbox for "apply fingerprint scrambing
configuration only to outgoing packets (requires proper
anti spoofing configuratoin) and spoof fingerprint for
"encrypted and plain" connections). Furthermore,
I also selected the checkbox for ISN spoofing, TTL and IP ID
under the Fingerprint SCrambling option. I selected
16 bits for minimal ISN entropy, 128 for TTL and do not
scramble traceroute packets, and under IP ID, I have random
for IP ID sequence generation mode.
On my checkpoint rule, I only allow R1 to initiate BGP
sessions with R2. R2 is NOT permitted to initiate iBGP
session with R1. In other words, one way iBGP traffics.
After all this, I went ahead and push the policy.
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.
If I replace the CP firewall with Cisco pix 6.3(5), the iBGP
will fail unless I do this:
static (inside,outside) 192.168.1.11 192.168.1.11 norandomseq
Basically, what I would like to do is to break the iBGP session
between R1 and R2 via the Checkpoint firewall by randomizing the
tcp sequence number on the checkpoint. How do I go about doing it?
By the way, I opened a TAC case with Checkpoint diamond support
but I don't think the TAC engineer knows what he is doing. I
do not think he understands how bgp works in order to assist me.
Thanks in advance.
cisco4ng
---------------------------------
Now that's room service! Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
=================================================
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
=================================================
=================================================
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
=================================================
|
