Re: [FW1] Stopping a Spoof Alert

["Young, Roger" <youngr@erinet.com>]

Ray,

When you see the 255.255.255.255 destination and no source address you
probably are receiving a DHCP discover packet which is a UDP port 68 packet
- this is not the same as a bootp UDP port 67 service as pre-defined in
FW-1. If so, you would have to create a user-defined service. Name this
service something like dhcp_discover using UDP port 68.  Combine this new
service with the normal bootp service in your rule.  AllZeros (w/ mask
0.0.0.0) should be your source and Broadcast (w/ mask 255.255.255.255) the
destination as you describe.

Let me know if things change from rule 0 to a value in your rule base.
I've spent some time looking into your e-mail and was successful in pulling
these broadcasts out of the spoof condition. Let me know if things still
don't work the way you expect....(my testing was only on 3.0b SP8, but I'm
curious if the UDP port 68 issue applies whether using 3.0 or 4.0).

Roger

At 04:43 PM 4/1/99 -0500, Ray Lodato wrote:
>
>Hi all,
>
>We just installed FW-1 4.0 SP2 on a test machine, and we ran into an
>interesting situation.
>
>The firewall object has anti-spoofing defined on its interfaces.  The
>external interface has "Others", and the internal interface has "Specific -
>LocalSpoof".  LocalSpoof is a group with 3 objects:  AllZeros (defined as
>0.0.0.0), Broadcast (defined as 255.255.255.255), and localnet (defined as
>our entire internal network).  We've asked it to log any internal spoofing.
>
>We are getting quite a number of log entries for bootp packets.  The source
>field is blank, and the destination field is 255.255.255.255.  We have a
>rule in the rule based to drop these packets without logging, but the log
>entries show them as being rejected by rule 0 (the anti-spoofing rule).
>
>We had this exact same configuration running (correctly) under 3.0b patch
>3045.  I thought that by including the AllZeros entry in LocalSpoof, and
>putting that on the internal interface, that it wouldn't consider a bootp
>packet a spoof attempt.  That way, we could handle it via the rulebase.
>
>Has anyone else had this problem?  If so, how do you fix it?  Thanks in
>advance.
>
>Ray
>
>
>
>============================================================================
>====
>     To unsubscribe from this mailing list, please see the instructions at
>               http://www.checkpoint.com/services/mailing.html
>============================================================================
>====




================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================