[fw-wiz] Auditing a firewall rulebase - Firewalls

This is a discussion on [fw-wiz] Auditing a firewall rulebase - Firewalls ; Hey Guys, What parameters would you look for if you audited a large rulebase for an enterprise firewall? These are a few I could think of. Anything else that you guys consistently look at when managing/auditing your firewalls? Do take ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: [fw-wiz] Auditing a firewall rulebase

  1. [fw-wiz] Auditing a firewall rulebase

    Hey Guys,
    What parameters would you look for if you audited a large rulebase for
    an enterprise firewall? These are a few I could think of. Anything
    else that you guys consistently look at when managing/auditing your
    firewalls? Do take note that I'm talking just singularly about the
    rule-base and not other configuration information i.e: I'm not looking
    at things like -- Low console session timeout OR Telnet admin
    interface open etc. I'm looking at just the rulebase this time around.
    Here are my parameters:

    Rules which have "any" or an equivalent keyword in them
    Rules where an entire subnet has been granted access to a resource
    Rules where a range of IP addresses has been granted access to a resource
    Rules where a large range of ports has been opened to an IP Address / Addresses
    Rules where there are design issues in the protocol itself
    eg. Unencrypted traffic
    Rules which are redundant and can be removed from the rulebase

    Thanks
    Arvind
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


  2. Re: [fw-wiz] Auditing a firewall rulebase

    > Rules which have "any" or an equivalent keyword in them
    > Rules where an entire subnet has been granted access to a resource
    > Rules where a range of IP addresses has been granted access to a resource
    > Rules where a large range of ports has been opened to an IP Address /

    Addresses
    > Rules where there are design issues in the protocol itself eg. Unencrypted

    traffic
    > Rules which are redundant and can be removed from the rulebase


    That's a pretty good list, actually. I would add; rules that allow access
    to the firewall. You will also want to audit for what kind of logging is
    turned on/off and whether or not that poses a risk. Also think in terms of
    implied rules (like interface security levels in a PIX or Global Policy in
    Check Point) and whether or not those create any of the situations you
    mention above.

    PaulM

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


  3. Re: [fw-wiz] Auditing a firewall rulebase

    2008/5/14 arvind doraiswamy :
    > Hey Guys,
    > What parameters would you look for if you audited a large rulebase for
    > an enterprise firewall? These are a few I could think of. Anything
    > else that you guys consistently look at when managing/auditing your
    > firewalls? Do take note that I'm talking just singularly about the
    > rule-base and not other configuration information i.e: I'm not looking
    > at things like -- Low console session timeout OR Telnet admin
    > interface open etc. I'm looking at just the rulebase this time around.
    > Here are my parameters:
    >
    > Rules which have "any" or an equivalent keyword in them
    > Rules where an entire subnet has been granted access to a resource
    > Rules where a range of IP addresses has been granted access to a resource
    > Rules where a large range of ports has been opened to an IP Address / Addresses
    > Rules where there are design issues in the protocol itself
    > eg. Unencrypted traffic
    > Rules which are redundant and can be removed from the rulebase
    >
    > Thanks
    > Arvind
    > _______________________________________________
    > firewall-wizards mailing list
    > firewall-wizards@listserv.icsalabs.com
    > https://listserv.icsalabs.com/mailma...rewall-wizards
    >


    I always spend a decent amount of time making sure that rules are in
    the correct order, so a more general deny rule doesnt end up blocking
    access to a specific resource just because it was higher on the list,
    or vice versa

    also comments, any rule with out a comment gets deleted, if it wasnt
    important enough to have a comment, its not important enough to still
    be here.

    high use rules at the top of the list

    other than that just what you already said

    hope that helps

    Lawrence


    --
    -Lawrence
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


  4. Re: [fw-wiz] Auditing a firewall rulebase

    If its an external firewall then you can check to make sure that bogon
    lists are being filtered. In addition check to make sure that
    internal ip space is being denied as the source coming from anywhere
    else. Make sure denied rule hits are being logged. Also check for
    ports and protocols that should be denied such as telnet, 1433,
    finger, etc inbound.

    On Wed, May 14, 2008 at 11:19 AM, arvind doraiswamy
    wrote:
    > Hey Guys,
    > What parameters would you look for if you audited a large rulebase for
    > an enterprise firewall? These are a few I could think of. Anything
    > else that you guys consistently look at when managing/auditing your
    > firewalls? Do take note that I'm talking just singularly about the
    > rule-base and not other configuration information i.e: I'm not looking
    > at things like -- Low console session timeout OR Telnet admin
    > interface open etc. I'm looking at just the rulebase this time around.
    > Here are my parameters:
    >
    > Rules which have "any" or an equivalent keyword in them
    > Rules where an entire subnet has been granted access to a resource
    > Rules where a range of IP addresses has been granted access to a resource
    > Rules where a large range of ports has been opened to an IP Address / Addresses
    > Rules where there are design issues in the protocol itself
    > eg. Unencrypted traffic
    > Rules which are redundant and can be removed from the rulebase
    >
    > Thanks
    > Arvind
    > _______________________________________________
    > firewall-wizards mailing list
    > firewall-wizards@listserv.icsalabs.com
    > https://listserv.icsalabs.com/mailma...rewall-wizards
    >

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


  5. Re: [fw-wiz] Auditing a firewall rulebase


    Here's my two cents:

    -Look for a default deny.
    -Make sure all rules are performance-based, e.g. most hit rule first in line, etc. to cut down on cpu and bandwidth.

    --Patrick Darden


    -----Original Message-----
    From: firewall-wizards-bounces@listserv.icsalabs.com
    [mailto:firewall-wizards-bounces@listserv.icsalabs.com]On Behalf Of
    arvind doraiswamy
    Sent: Wednesday, May 14, 2008 11:19 AM
    To: firewall-wizards@listserv.icsalabs.com
    Subject: [fw-wiz] Auditing a firewall rulebase


    Hey Guys,
    What parameters would you look for if you audited a large rulebase for
    an enterprise firewall? These are a few I could think of. Anything
    else that you guys consistently look at when managing/auditing your
    firewalls? Do take note that I'm talking just singularly about the
    rule-base and not other configuration information i.e: I'm not looking
    at things like -- Low console session timeout OR Telnet admin
    interface open etc. I'm looking at just the rulebase this time around.
    Here are my parameters:

    Rules which have "any" or an equivalent keyword in them
    Rules where an entire subnet has been granted access to a resource
    Rules where a range of IP addresses has been granted access to a resource
    Rules where a large range of ports has been opened to an IP Address / Addresses
    Rules where there are design issues in the protocol itself
    eg. Unencrypted traffic
    Rules which are redundant and can be removed from the rulebase

    Thanks
    Arvind
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


  6. [fw-wiz] null routes and VPN's

    Hello,

    is it a wise idea to put a default route on the inside (trusted) side of
    a firewall with a high metric for when a VPN drops. Essentially,
    blackholing all traffic until the VPN comes back and the default route
    is again the end of the VPN?

    Assuming there is a rule on the outside which allows only VPN traffic
    from the other end (point to point and only traffic allowed through the
    VPN) should both ends of the VPN have null routes for when its down (
    for traffic within the VLAN for this VPN)?

    What would be the implementation side affects, something along the lines
    of once the VPN is up its a matter of timeout on the routing protocol
    (say OSPF) to propagate the default route? Should a modernish firewall
    do this automagically anyway??

    Cheers,
    Kerry.



    --
    The Wellcome Trust Sanger Institute is operated by Genome Research
    Limited, a charity registered in England with number 1021457 and a
    company registered in England with number 2742969, whose registered
    office is 215 Euston Road, London, NW1 2BE.
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


  7. Re: [fw-wiz] Auditing a firewall rulebase

    Darden, Patrick S. wrote:
    > Here's my two cents:
    >
    > -Look for a default deny.
    > -Make sure all rules are performance-based, e.g. most hit rule first in line, etc. to cut down on cpu and bandwidth.
    >
    > --Patrick Darden
    >
    >
    > -----Original Message-----
    > From: firewall-wizards-bounces@listserv.icsalabs.com
    > [mailto:firewall-wizards-bounces@listserv.icsalabs.com]On Behalf Of
    > arvind doraiswamy
    > Sent: Wednesday, May 14, 2008 11:19 AM
    > To: firewall-wizards@listserv.icsalabs.com
    > Subject: [fw-wiz] Auditing a firewall rulebase
    >
    >
    > Hey Guys,
    > What parameters would you look for if you audited a large rulebase for
    > an enterprise firewall? These are a few I could think of. Anything
    > else that you guys consistently look at when managing/auditing your
    > firewalls? Do take note that I'm talking just singularly about the
    > rule-base and not other configuration information i.e: I'm not looking
    > at things like -- Low console session timeout OR Telnet admin
    > interface open etc. I'm looking at just the rulebase this time around.
    > Here are my parameters:
    >
    > Rules which have "any" or an equivalent keyword in them
    > Rules where an entire subnet has been granted access to a resource
    > Rules where a range of IP addresses has been granted access to a resource
    > Rules where a large range of ports has been opened to an IP Address / Addresses
    > Rules where there are design issues in the protocol itself
    > eg. Unencrypted traffic
    > Rules which are redundant and can be removed from the rulebase
    >
    > Thanks
    > Arvind
    > _______________________________________________
    > firewall-wizards mailing list
    > firewall-wizards@listserv.icsalabs.com
    > https://listserv.icsalabs.com/mailma...rewall-wizards
    > _______________________________________________
    > firewall-wizards mailing list
    > firewall-wizards@listserv.icsalabs.com
    > https://listserv.icsalabs.com/mailma...rewall-wizards
    >
    >

    If you can tell from logs or otherwise, look for rules that are no
    longer in use.
    Look for rules that you do not have a written justification for; if a
    rule is for a single application or user group, ask if it is still
    justified.

    I have eliminated a lot of deadwood with these checks over the years,
    cruft accumulates.

    Chuck Benson

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


  8. Re: [fw-wiz] Auditing a firewall rulebase

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    >
    > also comments, any rule with out a comment gets deleted, if it wasnt
    > important enough to have a comment, its not important enough to still
    > be here.
    >


    Hmm, I can see this causing an alert and investigation, but not a
    deletion. straight out decisions like this are security incidents waiting
    to happen as well.

    Thanks,


    Ron DuFresne
    - --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    admin & senior security consultant: sysinfo.com
    http://sysinfo.com
    Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629

    ....We waste time looking for the perfect lover
    instead of creating the perfect love.

    -Tom Robbins
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)

    iD8DBQFIOyiqst+vzJSwZikRAjtJAJ4zbdj668uLVHcasgge5u lYF5WgEgCfYTqg
    I4WY48OLDOwP85ajQTwyXU0=
    =Idan
    -----END PGP SIGNATURE-----
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


  9. Re: [fw-wiz] Auditing a firewall rulebase

    Hey Guys,
    Thanks for all your inputs. I got a few valuable points that I managed
    to integrate together in a Perl script which will assist in auditing a
    firewall rulebase. It can be useful both for a third party auditor as
    well as a firewall admin who has his hands very full.

    The POC is available at: http://sourceforge.net/projects/fwauto

    Right now it supports just Cisco PIX - but the framework is there for
    other firewalls as well. Do go through the ReadMe which is part of the
    file and provide me with feedback on where I have messed up - if
    anwyhere.

    Thanks again
    Arvind
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


  10. [fw-wiz] easy way to scan for issues with path mtu discovery?


    Hi all,

    Does anyone know of an easy way to scan for issues with path mtu discovery along a hop path? E.g. if you think someone is black-holing along a route, or even on the endpoint host, could you use some obscure nmap flag to find out for sure, and also to identify the offending hop/router/host? What tool would you use to test for this, and how would you do such a test?

    Seems to me this happens often enough that someone has already figured it out, so I am trying not to reinvent the wheel. All I can think of would be to handcraft packets (which is laborious at best). Google has not been kind to my researches so far.

    I appreciate any help!
    --Patrick Darden
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


  11. Re: [fw-wiz] easy way to scan for issues with path mtu discovery?

    Hello,

    > Does anyone know of an easy way to scan for issues with path mtu
    > discovery along a hop path? E.g. if you think someone is black-holing
    > along a route, or even on the endpoint host, could you use some obscure
    > nmap flag to find out for sure, and also to identify the offending
    > hop/router/host? What tool would you use to test for this, and how
    > would you do such a test?


    traceroute to identify the outbound route and then iteratively
    ping -s for the interesting hops.

    Worked sufficiently last time I needed it ;-)

    Kind regards,
    Patrick M. Hausen
    Leiter Netzwerke und Sicherheit
    --
    punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
    Tel. 0721 9109 0 * Fax 0721 9109 100
    info@punkt.de http://www.punkt.de
    Gf: Jürgen Egeling AG Mannheim 108285
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


  12. Re: [fw-wiz] easy way to scan for issues with path mtu discovery?

    Patrick,

    If you think you are having this type of issue you can try to run a
    tcptraceroute on a port that is allowed to the destination (such as 80
    for a web server). This is will obviously give you the hops along
    path to your destination. Then you can try using the following
    command to get the mss (max segment size) for each hop starting with
    the destination and working your way back.

    sudo nmap -sS -PN -p 80 --packet-trace -mtu 1504 x.x.x.x

    this will perform a packet trace showing what nmap is doing under the
    hood and will set your mtu to 1504. Typically your interface is
    already set to an mss of 1460 so to use something higher you will have
    to change that on your interface using the ifconfig command. Go ahead
    and just use the 1460 (if you run the command above your interface
    will automagically set it to 1460 until you change it). Once the
    command is run you will see a packet trace from nmap showing the
    packet it sent and mss and then the target device will respond with
    its mss also. From here its a process of elimination.

    Note that setting the mtu higher will usually cause fragmentation and
    fragmented packets are sometimes dropped or denied along the way
    (which is probably your issue). For example, if you are doing this
    over an IPSec tunnel then note that the ESP encryption header adds to
    the packet as it sends it along. So if your sending this data over an
    IPSec tunnel then you will want to run a tcpdump or debug (preferrably
    debug ip icmp on your router if you have access to it) and look for
    icmp errors of type 3 code 4 (fragmentation needed and do not fragment
    bit set). If you see this then packets that are at say 1460 then add
    the encrypt header will put you above the typical mss of 1460 and the
    packet will be dropped.

    On Mon, Jun 23, 2008 at 10:52 AM, Darden, Patrick S. wrote:
    >
    > Hi all,
    >
    > Does anyone know of an easy way to scan for issues with path mtu discovery along a hop path? E.g. if you think someone is black-holing along a route, or even on the endpoint host, could you use some obscure nmap flag to find out for sure, and also to identify the offending hop/router/host? What tool would you use to test for this, and how would you do such a test?
    >
    > Seems to me this happens often enough that someone has already figured it out, so I am trying not to reinvent the wheel. All I can think of would be to handcraft packets (which is laborious at best). Google has not been kind to my researches so far.
    >
    > I appreciate any help!
    > --Patrick Darden
    > _______________________________________________
    > firewall-wizards mailing list
    > firewall-wizards@listserv.icsalabs.com
    > https://listserv.icsalabs.com/mailma...rewall-wizards
    >

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@listserv.icsalabs.com
    https://listserv.icsalabs.com/mailma...rewall-wizards


+ Reply to Thread