>>> On 4/9/2007 at 10:11 AM, cisco4ng <cisco4ng AT YAHOO DOT COM> wrote:
> R1--(Internal)CP_NGx_R61_hfa_01(External)--R2
>
> I found something interesting during the troubleshooting
> process:
>
> scenario #1: In the security policy, I allowed R1 to
> establish bgp session with R2 but I did NOT allow R2 to
> establish bgp session with R1 in the security policy.
>
> Even with everything enable in the smartdefense fingerprint
> section, R1 can establish bgp session using md5 authentication.
> Looking at the tcpdump on both the internal and external
> interfaces, I notice that the Sequence Number (SN) does not
> change when traversing the interface when R1 inititate it
> bgp session with R2. That's why I am suspecting BGP with
> md5 authentication works between R1 and R2 across the
> checkpoint firewall.
>
> Scenario #2: In the security policy, I allowed R2 to
> establish bgp session with R1 but I did not allow R1 to
> establish bgp session with R2 in the security policy.
> Furthermore, I have all the smartdefense fingerprinting
> in place as I did with scenario #1.
>
> To my suprise, I successfully BREAK bgp sessions between
> R1 and R2. Upon looking at the tcpdump on both the
> External and Internal interfaces, I do see that the
> Sequence Number (SN), the first packet, SYN , when going from
> R2 to R1, when it traverses the firewall, stays the same.
> However, the "SYN-ACK" when coming back from R1 to R2,
> it was completely different when it leaves the External
> interface compared to when it arrives to the Internal
> interface. That's why it breaks bgp with md5 authentication.
>
> Basically, when R1 initiated that bgp session, everything works
> and the SN stays the same. However, when R2 initiated the
> bgp session, it breaks because the SN got modified on the return.
>
> Very interesting problem.
Not really. This follows exactly the scenario that the SK article
Hugo first pointed to you,
"The ISN scrambler counters this attack by creating a
difference between the sequence numbers used by the
server and the sequence numbers perceived by the client."
You found it works exactly like it says, it changes the ISN
the SERVER sends to the CLIENT. It doesn't touch client to
server.
This is a feature, not a bug. There is no security advantage
to scrambling the client's ISN. ISN-guessing attacks are about
guessing the server's response to the client. And doing this
way, as you have seen, doesn't break TCP MD5 auth. It's actually
cool, huh?
This is also why there is a big warning about only enabling
this when you have your antispoofing set up correctly.
B¼information contained in this e-mail message is confidential, intended
only for the use of the individual or entity named above. If the reader
of this e-mail is not the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient, you are hereby
notified that any review, dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this e-mail
in error, please contact postmaster AT globalstar 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
=================================================
|
