[c-nsp] acl to block traffic one way

[Dan]

Roland Dobbins wrote:
> 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.
>
>   
I work for a school district and the school with subnet 192.168.1.0/24
has a curious group of people that just don't need to see any of the
devices on 192.168.75.0/24 , but the devices on 75.0/24 need to see 1.0/24.
>> 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).
>   
Do you have an example of an ACL constructed in a modular/static fashion?
> 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
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   
I have netflow setup on my 2801 router but I have not figured out how or
if the 3560 can export netflow stats.

Excellent tips for setting up and maintaining ACL's.  I will use these
on a daily basis.

Thanks,
Dan.