ACLs, security levels and ASA

Discussion in 'Cisco' started by Jeff Specoli, Aug 6, 2004.

  1. Jeff Specoli

    Jeff Specoli Guest

    Hello,

    Let's say you have three interfaces with the following security
    levels: inside (100), outside (0) and dmz (30).

    If you set an ACL on the DMZ interface with permit ip any any, will
    the DMZ be able to access the outside but not the inside? In other
    words, does the security settings of the interfaces come into play
    after the ACL? (assuming you have the correct NATs, etc...)

    Next question. If you don't set an ACL on the DMZ interface, will DMZ
    hosts be able to access the
    outside, but not the inside due to the security levels?

    The reason I ask is when I run the conduit to ACL conversion utility
    (occ.exe) with the -pde option (which is supposed to simulate the
    default behaviour of the PIX), it puts ACLs on every interface. For
    the DMZ interface it puts an ACL with permit ip any any. Now, when I
    run the occ.exe without the -pde option, it doesn't put in the ACLs
    with the permit ip any any.

    My basic question is why would it matter if you put acls with permit
    ip any any on dmz interfaces or not? Won't the traffic still follow
    the security level rules?

    TIA
     
    Jeff Specoli, Aug 6, 2004
    #1
    1. Advertisements

  2. :Let's say you have three interfaces with the following security
    :levels: inside (100), outside (0) and dmz (30).

    :If you set an ACL on the DMZ interface with permit ip any any, will
    :the DMZ be able to access the outside but not the inside? In other
    :words, does the security settings of the interfaces come into play
    :after the ACL? (assuming you have the correct NATs, etc...)

    You will be able to access the inside to any system which has
    a static (inside,dmz) or for flows which are listed in an
    nat (inside) access-list XXXX control.


    :Next question. If you don't set an ACL on the DMZ interface, will DMZ
    :hosts be able to access the
    :eek:utside, but not the inside due to the security levels?

    That's the theory. People have occasionally reported having problems
    with this that were solved by putting in an explicit ACL.


    :The reason I ask is when I run the conduit to ACL conversion utility
    :(occ.exe) with the -pde option (which is supposed to simulate the
    :default behaviour of the PIX), it puts ACLs on every interface. For
    :the DMZ interface it puts an ACL with permit ip any any. Now, when I
    :run the occ.exe without the -pde option, it doesn't put in the ACLs
    :with the permit ip any any.

    :My basic question is why would it matter if you put acls with permit
    :ip any any on dmz interfaces or not? Won't the traffic still follow
    :the security level rules?

    The behaviour of conduits depends not just on the conduit statement
    but also on whether there is a static. If there is no static then
    the access is permitted to all interfaces. If there is a static
    then the access is permitted only to the interface listed in the
    static. What happens if you have more than one static is not stated.

    Thus, having the explicit access list doesn't harm anything and
    permits access to anything you static'd, whereas without the ACL
    the static to the higher level is only going to have effects on the
    address translation. These correspond to the two different meanings
    of conduits. One of the modes emulates the pix default behaviour
    *for conduits* and the other one is for the pix default behaviour
    *for ACLs and security levels*
     
    Walter Roberson, Aug 7, 2004
    #2
    1. Advertisements

  3. Jeff Specoli

    Jeff Specoli Guest


    Hello Walter. Thanks for taking the time to help me.

    So, let's say you want to have:

    DMZ security 50
    inside security 100
    outside security 0

    On the DMZ interface is the "DMZ_NET", inside is the "INSIDE_NET" and
    the outside is the "OUTSIDE_NET" and you wanted this:

    INSIDE_NET can access the outside network (aka the Internet)
    DMZ_NET can access the outside network (aka the Internet)
    OUTSIDE_NET cannot access either the DMZ_NET or the INSIDE_NET.
    DMZ_NET cannot access the INSIDE_NET.

    and you wanted to use ACLs.

    Would you use nat/global or static (one to one subnet xlate like
    static (dmz,outside) DMZ_NET DMZ_NET netmask 255.255.255.0) to allow
    the DMZ net to access outside with it's own IPs and put an ACL with
    permit ip any any? Would that work and also not allow the DMZ_NET to
    access the INSIDE_NET since there is no static or nat/global from the
    DMZ_NET to the INSIDE_NET?

    Now if you did want to allow one host on the DMZ_NET to access a host
    on the INSIDE_NET would you do a static for that one host, say
    something like:

    static (inside,dmz) DMZ_HOST DMZ_HOST netmask 255.255.255.255

    Would the DMZ host have access at this point to the INSIDE_HOST
    (because your ACL has permit ip any any or simply because of the
    static with no regard to the ACL????)

    I assume you have to have the static and the ACL entry, but in this
    case the ACL entry has permit ip any any. So would the DMZ_HOST have
    complete access to the INSIDE_HOST on all ports? It seems like it
    would be difficult to allow selective traffic from the DMZ_HOST to the
    INSIDE_HOST (e.g. only allowing TCP 3389 from the DMZ_HOST to an
    INSIDE_HOST) and also at the same time allow everything from the DMZ
    out to the OUTSIDE_NET (aka Internet). Am I missing something?

    Again, thanks for taking the time. I've seen your posts before and
    they are always really good.
     
    Jeff Specoli, Aug 7, 2004
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.