RE: [fw-wiz] PIX Firewall IP Addresses

From: Ben Nagy (benat_private)
Date: Thu Oct 17 2002 - 13:14:58 PDT

  • Next message: Mike Frantzen: "Re: [fw-wiz] CERT vulnerability note VU# 539363 (fwd)"

    Good luck.
    
    First, you probably want to upgrade your PIX to the latest version
    (memory and flash permitting). 5.2 is not a happy version, from memory,
    and every PIX release contains several security fixes.
    
    Second, don't use conduits. They'll die soon (and should have already).
    Switch to ACLs, and then you'll also know how to do ACLs on Cisco
    routers as a bonus.
    
    Finally, welcome to Netmasks. Either learn to think binary, or do what I
    do and get used to writing out:
    "128 64 32 16 8 4 2 1"
    
    in big rows on scrap paper.
    
    You're looking for bit strings that have a 1 wherever you only want a
    fixed value for a given bit and a 0 when you don't mind any value. For
    example, "192.168.1.0 255.255.255.0" matches only 192.168.1.anything.
    
    In your example, you want 200-202, which means that all the bits except
    2 and 1 MUST be fixed (110001??).
    
    If you allow ANY combination of the last two bits then you actually get
    200 (00) 201 (01) 202 (10) and 203 (11).
    
    That's not quite right, so your rule looks like:
    deny x.x.x.203 255.255.255.255 - we don't want this
    permit x.x.x.200 255.255.255.252 - 203 has been blocked above, so this
    now allows just 200-202
    (252 == 00000011)
    
    Two rules instead of three. Not much of an improvement, but it's a
    start, and it gets better the bigger your ranges are.
    
    (Sideline: IOS ACLs ONLY) For large and tricky ranges you can actually
    use the wilcard masks when all the '1' bits are NOT flush right (many
    people do not know this, for some reason) which often allows some quite
    spectacular, if very hard to understand, ACL compression. Fate sends you
    the request "permit only 192.168.1.2, .16, .18, .32, .34, .48 and .50"?
    Do you curse? No! You just slip one "permit 192.168.1.0 0.0.0.50" into
    your ruleset and wait for confused looks from the auditors. Unluckily
    (or luckily, maybe ;) you can't do that with PIXen. 
    
    I'd recommend a cruise past www.cisco.com and casting an eye over the
    configuration guides. They're pretty good.
    
    Oh, and please don't forget to do a compliance test when you're done.
    
    Cheers,
    
    --
    Ben Nagy
    Network Security Specialist
    Mb: +41792504687  PGP Key ID: 0x1A86E304 
    
    
    > -----Original Message-----
    > From: firewall-wizards-adminat_private 
    > [mailto:firewall-wizards-adminat_private] On Behalf 
    > Of Mark McCreary
    > Sent: Thursday, October 17, 2002 4:41 PM
    > To: firewall-wizardsat_private
    > Subject: [fw-wiz] PIX Firewall IP Addresses
    > 
    > 
    > We are using a CISCO PIX firewall version 5.2(5), with both 
    > NAT and PAT 
    > enabled.  My task is to clean-up/reduce the number of conduit 
    > rules.  I am 
    > new at this. 
    > 
    > While reviewing the rules in place, I noticed many cases 
    > where individual 
    > rules are written for consecutive IP addresses.  My question 
    > is whether 
    > the syntax allows for a "range" of addresses to be used in 
    > one rule.  For 
    > example,
    > 
    > Rules written to allow access from source addresses - 172.165.50.200, 
    > 172.165.50.201, 172.165.50.202
    > 
    > Can a source address on one rule replace the 3 rules above, such as 
    > 172.165.50.200-202
    > 
    > Thank you for any assistance.
    > 
    > Regards,
    > 
    > Mark McCreary
    > _______________________________________________
    > firewall-wizards mailing list firewall-wizardsat_private
    > http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
    > 
    
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizardsat_private
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
    



    This archive was generated by hypermail 2b30 : Thu Oct 17 2002 - 14:45:17 PDT