Sadiq Yakasai @ 11/07/2012 18:17 -0300 dixit:
> Well, a simple test will confirm.
>
> Carlos, I dont know which it is but you either did not read my post well
> or did not understand it altogether. Whichever, read it once again and
> you will see that I said if there is an ACL on the interface where the
> traffic originates, yes, the traffic is subjected to the ACL rule.
I did read your post as well as I can. Even after a reread, I still see
that you mention "explicit deny" there, when it really does not matter
if it is explicit or implicit. And in a previous post you mention that
the security level could be used as a fall back of an ACL, which I think
is not the case. ACLs either permit or deny, no way to "fail".
(because "failing" would hit the implicit deny)
> Is there is no ACL on the interface the traffic originates from, and
> there is an ACL on the return path interface, then the firewall will not
> subject the traffic to the return path ACL.
This is, in my view, making matters more confusing. The return traffic
is never subject to any access control. Not ACLs nor sec level.
The ASA does access control only on the initiating packet of a connection.
> This can be demostrated on the ASA below. I have configured a DENY ALL
> ACL on the outside (network interface) and I was able to initiate a
> telnet session from a device behind the ASA just fine. Why did the
> traffic allow this? Simply because of the security level rule of
> firewalling, which if I understand well is Sameer's first question.
Agreed. In this example, there are no ACLs in the initial packet path,
so the security level rule works. Also, keep in mind that ACLs can be
applied inbound and outbound, so to be strict about the way something is
configured, you have to make the direction of the ACL explicit.
-Carlos
>
> Sadiq
>
> DC-ASA1(config)#
> DC-ASA1(config)# sh run int
> !
> interface GigabitEthernet0/0
> nameif network
> security-level 0
> ip address 10.241.1.68 255.255.255.248 standby 10.241.1.69
> pim dr-priority 120
> !
> interface GigabitEthernet0/1
> nameif datacenter
> security-level 100
> ip address 10.243.100.1 255.255.255.0 standby 10.243.100.2
> !
> DC-ASA1(config)# access-group DENY_ALL in in network
> DC-ASA1(config)#
> DC-ASA1(config)# sh run route
> route network 0.0.0.0 0.0.0.0 10.241.1.67 1
> DC-ASA1(config)# sh run access-group
> access-group DENY_ALL in interface network
> DC-ASA1(config)#
> DC-ASA1(config)# sh run policy-map
> !
> policy-map type inspect dns migrated_dns_map_1
> parameters
> message-length maximum client auto
> message-length maximum 512
> policy-map global_policy
> class inspection_default
> inspect dns migrated_dns_map_1
> inspect ftp
> inspect netbios
> inspect rsh
> inspect skinny
> inspect esmtp
> inspect sqlnet
> inspect sunrpc
> inspect tftp
> inspect sip
> inspect xdmcp
> class sxp-class
> set connection advanced-options tcp-state-bypass
> !
> DC-ASA1(config)#
> DC-ASA1(config-pmap-c)#
> DC-ASA1(config-pmap-c)# show conn
> 19 in use, 68 most used
> TCP network 10.241.1.67:23 <http://10.241.1.67:23> datacenter
> 10.243.100.5:5325 <http://10.243.100.5:5325>, idle 0:00:03, bytes 158,
> flags UIO
> DC-ASA1(config-pmap-c)#
> DC-ASA1(config-pmap-c)# sh run access-group
> access-group DENY_ALL in interface network
> DC-ASA1(config-pmap-c)#
> DC-ASA1(config-pmap-c)# sh run access-list
> access-list DENY_ALL extended deny ip any any
> DC-ASA1(config-pmap-c)#
> DC-ASA1(config-pmap-c)# logging on
> DC-ASA1(config)# %ASA-5-111008: User 'enable_15' executed the 'logging
> on' command.
> %ASA-5-111010: User 'enable_15', running 'CLI' from IP 0.0.0.0, executed
> 'logging on'
> %ASA-7-609001: Built local-host datacenter:10.243.100.5
> %ASA-7-609001: Built local-host network:10.241.1.67
> %ASA-6-302013: Built outbound TCP connection 1012 for
> network:10.241.1.67/23 <http://10.241.1.67/23> (10.241.1.67/23
> <http://10.241.1.67/23>) to datacenter:10.243.100.5/5823
> <http://10.243.100.5/5823> (10.243.100.5/5823 <http://10.243.100.5/5823>)
> DC-ASA1(config)#
> DC-ASA1(config)#
> DC-ASA1(config)#
> DC-ASA1(config)# no logging
> DC-ASA1(config)# %ASA-5-111008: User 'enable_15' executed the 'no
> logging on' command.
> %ASA-5-111010: User 'enable_15', running 'CLI' from IP 0.0.0.0, executed
> 'no logging on'
> DC-ASA1(config)#
> DC-ASA1(config)#
> DC-ASA1(config)# sh conn
> 20 in use, 68 most used
> TCP network 10.241.1.67:23 <http://10.241.1.67:23> datacenter
> 10.243.100.5:5823 <http://10.243.100.5:5823>, idle 0:00:11, bytes 158,
> flags UIO
>
> On Wed, Jul 11, 2012 at 7:52 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar
> <mailto:tron_at_huapi.ba.ar>> wrote:
>
> No, you are not.
> Marc said "implicit", you said "explicit".
> Marc says "ACL will render sec level useless", you say it will be used.
>
> I would say Marc is right, but a simple test would confirm.
> Any ACL in the path of the initiating packet will define the fate of
> the connection. The ACL will rule. If you happen to have two ACLs in
> the path, then both should permit the packet for the connection to
> be permitted.
>
> -Carlos
>
> Sadiq Yakasai @ 11/07/2012 15:14 -0300 dixit:
>
> Hi Marc,
>
> Yes, you are right on the implicit deny on the ACL. Perhaps my
> statement
> was not very clear the first time.
>
> What I meant to say is that when ACL's are present on the
> interfaces (*
> typically* on the lower security level, outside/dmz), then
> traffic is
>
> subjected to these ACL's when it comes in via those interfaces. When
> traffic comes in via a higher security level that has no ACL,
> then it will
> be allowed back in even if the ACL on the exit interface does
> not allow
> this - this is implicitly done because of the firewall
> inspection rule
> (higher->lower flow).
>
> But I agree with you, if there is an explicit deny on the ACL on any
> interface, then yes, the firewall shall drop that traffic.
>
> I think we are both saying the same thing. Right?
>
> Thanks,
> Sadiq
>
> On Wed, Jul 11, 2012 at 6:06 PM, marc edwards
> <renorider_at_gmail.com <mailto:renorider_at_gmail.com>> wrote:
>
> And the more I think about it. It is due to implicit deny
> that comes with
> the ACL.
>
> Marc
>
>
> On Wed, Jul 11, 2012 at 10:05 AM, marc edwards
> <renorider_at_gmail.com <mailto:renorider_at_gmail.com>>wrote:
>
> Sadiq,
>
> With my experiences, if the interface has ACLS it won't
> pass traffic to
> lower zones but I will defer to expert to confirm.
> Thanks for pointing out
> for clarification.
>
> Regards,
>
> Marc
>
>
> On Wed, Jul 11, 2012 at 10:00 AM, Sadiq Yakasai
> <sadiqtanko_at_gmail.com <mailto:sadiqtanko_at_gmail.com>>wrote:
>
> Thats all right Marc. One point to add; even with
> access-lists, the
> security levels are infact used, but the ACL's will
> take precedence. This
> means for traffic streams that dont have entries in
> the ACL, the security
> levels' rules can permit (or otherwise) the traffic.
>
> Right?
>
>
> On Wed, Jul 11, 2012 at 5:50 PM, marc edwards
> <renorider_at_gmail.com <mailto:renorider_at_gmail.com>>wrote:
>
> Is this an ASA? If so by default the secruity
> zones only allow higher to
> lower access and inside is always higher than DMZ
>
> You can change this behavior either leveling the
> zones (not the best
> idea
> for DMZ) or creating access-lists. When entering
> access lists keep in
> mind
> that security levels will no longer be used.
>
> HTH
>
> Marc
>
> On Wed, Jul 11, 2012 at 7:59 AM, sameer inam
> <i_sameer_at_hotmail.com <mailto:i_sameer_at_hotmail.com>>
> wrote:
>
> Gents ,
> Need some help , I m trying to access from
> DMZ to inside it wont
>
> work
>
> form
> some reason but other way Inside to DMZ
> working fine , Can any one
>
> give me
>
> some kind of Document or idea ,
> It will be much appreciated
> Thanks in advance
> Sameer
>
>
> Blogs and organic groups at http://www.ccie.net
>
>
> ___________________________________________________________________________
>
> Subscription information may be found at:
> http://www.groupstudy.com/__list/CCIELab.html <http://www.groupstudy.com/list/CCIELab.html>
>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> ___________________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/__list/CCIELab.html
> <http://www.groupstudy.com/list/CCIELab.html>
>
>
>
>
>
>
>
>
>
>
> --
> CCIEx2 (R&S|Sec) #19963
>
>
>
>
>
>
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
> LW7 EQI Argentina
>
>
>
>
>
> --
> CCIEx2 (R&S|Sec) #19963
-- Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina Blogs and organic groups at http://www.ccie.netReceived on Wed Jul 11 2012 - 18:33:07 ART
This archive was generated by hypermail 2.2.0 : Wed Aug 01 2012 - 15:55:23 ART