ACL Standard over Extended

[Senbonzakura]

When it comes to Standard ACL and Extended ACL,

Extended ACL does what Standard does plus more, in what situations would you still use Standard over Extended? Or can you just use Extended for everything instead?

Or

Would you just use Standard for the source, and keep the simple tasks to standard that way you have more room to use Extended?

Thoughts?

[balaji.bandi]

The major difference between Standard & Extended access list as follows:

  The rule of a ACLs is you can apply only on access list on per interface, per direction.

Standard ACL                                                                

 1) Able Restrict, deny & filter packets by Host Ip or subnet only.

 2) Best Practice is put Std. ACL restriction near from Source Host/Subnet (Interface-In-bound).

 3) No Protocol based restriction. (Only HOST IP).

Extended ACL

 1) More flexible then Standard ACL.

 2) You can filter packets by Host/Subnet as well as Protocol/TCPPort/UDPPort.

 3) Best Practice is put restriction near form Destination Host/Subnet. (Interface-Outbound)

https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/23602-confaccesslists.html

example :

https://www.learncisco.net/courses/icnd-1/acls-and-nat/type-of-acls.html

[Giuseppe Larosa]

Hello @Senbonzakura ,

just to add to what has been already written there are some special cases where standard ACLs are the right tool to use:

For  example when configuring an SNMP v2 community you can list the allowed sources that can query the devices using this commuity using a standard ACL.

Under line vty to specify what source IP subnets can telnet/SSH to your devices using standard ACL is to be preferred, They are simpler and we can understand the result of their application.

The same to specify a list of NTP sources to be trusted.

There are also some cases in route-maps used for redistribution or routing manipulation where a standard ACL can be used for example to match the next-hop of a route or the originator of a route (OSPF case )

To be noted in route redistrubution only BGP supports extended ACLs but both standard and extended ACLs have found a better tool in the prefix-list that has been created for this purposes.

A prefix-list can never be used to filter user traffic it is intended to be used for route filtering .

So we cannot say that extended ACLs are better in any case as there are some cases where a standard ACL is better or a prefix-list is the right tool.

Hope to help

Giuseppe

[Senbonzakura]

Okay, all of this makes sense. Now in your experience, lets say you have two networks that are segmented from each other. Would you still want to create an ACL so just in case they couldn't communicate? 

Also, when it comes to TCP/UDP then ports. What is a good general practice on what to block generally all the time? I know it depends on what is being used but what is good?

[balaji.bandi]

Okay, all of this makes sense. Now in your experience, lets say you have two networks that are segmented from each other. Would you still want to create an ACL so just in case they couldn't communicate? 

BB  - segmented from each other. - why do you need ACL ?

Also, when it comes to TCP/UDP then ports. What is a good general practice on what to block generally all the time? I know it depends on what is being used but what is good?

BB - by default Security rule allow what required, Block rest.

[Senbonzakura]

Ah, I see. 
 
So pretty much block every type of port out there but if you only want HTTPS you'd permit 443 and deny all others.

[balaji.bandi]

yes correct , best practice allow DNS/Http/Https / SMTP common ports (if you have only https, then https only)

[Joseph W. Doherty]

BTW, HTTPS can run on ports other than 443 and conversely, other applications can use port 443.  Doing either, though, would be non-standard port usage.

If you really want to permit something like HTTPS traffic, you need something like NBAR (although I don't recall if it can recognize HTTPS regardless of port) which can often do some protocol analysis.  Also note, NBAR is often limited to specific platforms and I believe (?) now requires a separate license.

[Joseph W. Doherty]

Another possible reason to use a standard ACL rather than an extended ACL, it's possible, on some platforms, since less is being examined, the implemention of each ACE's execution might be a tad faster.  This, though, if it applies at all, might only apply to software based routers.  (BTW, this consideration is a bit similar to the suggestion/recommendation of ordering ACEs, in hit frequency, assuming there's no other reason for their sequence.)

Also for efficiency, to your question about using ACLs, just-in-case, when not actually used/needed, again, especially on a software based router, ACLs can slow packet forwarding.

[Martin L]

■ Place extended ACLs as close as possible to the source of the packet. This strategy
allows ACLs to discard the packets early.
■ Place standard ACLs as close as possible to the destination of the packet. This strategy
avoids the mistake with standard ACLs (which match the source IPv4 address only) of
unintentionally discarding packets that did not need to be discarded.
■ Place more specific statements early in the ACL.
■ Disable an ACL from its interface (using the no ip access-group interface subcommand)
before making changes to the ACL.

Source: Odom, W. CCNA 200-301 OCG, Csico Press

Regards, ML
**Please Rate All Helpful Responses **