[c-nsp] acl to block traffic one way

[Roland Dobbins]

On Mar 24, 2007, at 8:10 PM, Dan wrote:

> I was wondering if there would be a way to block traffic one way on a
> 3560 switch.  I would like to block any traffic from 192.168.1.0/24  
> from
> seeing anything 192.168.75.0/24.  But I would like to be able to have
> the reverse possible.

If your platform supports ACLs, sure.  ACLs are applied to interfaces  
directionally.  So, you'd have the permit on the side from which  
traffic from the permitted source network is applied (or applied  
outbound on the interface facing the destination network, but the  
former's the better way to go) and that's that.

Out of curiosity, what's your application?  Typically, TCP/IP  
communications require some bidirectionality for any meaningful use,  
even it it's restricted.

>
> Also is there a way to insert a line into an access list?

ACLs should be composed offline using a text-editor or script or  
provisioning system, not typed by hand directly into a device.  It's  
also a good idea to keep them versioned; rcs is available on all the  
free *NIXes, I'd suggest getting started using that plus the text  
editor of your choice.

One technique some folks use to update ACLs is that they've actually  
two versions of an ACL for each relevant interface, and they flip- 
flop them.  So, if you have ACL 110 applied inbound on fa0/1, you'd  
also have ACL 120 in the config of the device, but not applied at the  
interface (ACL 110 would be applied and active on the interface).   
You'd check ACL 120 out of RCS, modify it, and then copy it over to  
the device, then go into the interface configuration sub-mode for the  
relevant interface and then change the ACL line to reflect ACL 120 as  
the current/applied ACL, and ACL 110 would then be the inactive/ 
rollover ACL.

ACLs should also be constructed in a modular fashion, with more  
static sections for rarely-updated policies, and a dynamic section  
used for reaction and other types of more dynamic changes.  Pay close  
attention to the fall-through of the ACL so as to guard against  
problems such as early permit statements masking later denies, or  
vice versa.  Any platform-specific ACL construction considerations  
should also be taken into account and documented in comments in the  
ACL file (I strongly recommend that you heavily comment your ACL  
files so that it's easy for folks to figure out the intended purpose  
of each section/stanza).

It's also a good idea to consider a) using DNS names for /32s in ACLs  
*where appropriate* in order to make the intent that much clearer,  
deal with hosts which end up being renumbered, etc., and b) using a  
script to *perform the DNS lookups on the ACL file and substitute the  
appropriate IP addresses just prior to copying them over to the  
router* (expecting the router do this can be a bad idea, for a number  
of reasons).  An alternative to DNS names for /32s is strong  
commenting, but you'll end up with more comments; and, of course,  
sometimes there are /32s which need to go into ACLs which for one  
reason or another don't have DNS mappings.  This is very  
situationally-specific, just something to think about.

Note that comments ('!') are different from remarks ('rem'); the  
former don't show up in the router config, the latter do.   
Personally, I hate seeing rems in configs because it makes them  
harder to parse via sh commands, but that's something you should  
decide for yourself.

It seems like a simple thing, but I've found ACL construction and  
maintenance/version control to be a big issue for lots of  
organizations.  Taking the time to think through some of the issues  
denoted above and determining what's best for your network can end up  
making it a lot easier to maintain ACLs long-term, as well as making  
the update process more efficient and less prone to operator error.

My $.02, FWIW.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at cisco.com> // 408.527.6376 voice

         Words that come from a machine have no soul.

                       -- Duong Van Ngo