RE: ACL design.

["ragdelaed" <ragdelaed () gmail com>]

This can be applied to both sides. Remember to switch the acl statements
depending on your perspective and remember that the acl group has to be
applied to the necessary interface.
 Here is a good guide to acls.
http://muse.linuxmafia.org/lost+found/access-list.howto

> From here: http://www.cisco.com/warp/public/707/iacl.html

!--- for log stamp timing
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone

no ip source-route
logging buffered warnings
logging console errors
ntp server <internal_ntp_server_ip>

!--- start the ACL

!--- Deny special-use address sources.
!--- Refer to RFC 3330 for additional special use addresses.

access-list 110 deny ip host 0.0.0.0 any
access-list 110 deny ip 127.0.0.0 0.255.255.255 any
access-list 110 deny ip 192.0.2.0 0.0.0.255 any
access-list 110 deny ip 224.0.0.0 31.255.255.255 any

!--- Filter RFC 1918 space.

!--- access-list 110 deny ip 10.0.0.0 0.255.255.255 any
!--- maybe use these?
!--- access-list 110 allow ip 10.10.10.0 0.0.0.255 any
!--- access-list 110 allow ip 10.20.20.0 0.0.0.255 any
access-list 110 deny ip 172.16.0.0 0.15.255.255 any
access-list 110 deny ip 192.168.0.0 0.0.255.255 any

!--- Permit transit traffic.

access-list 101 permit icmp any any
access-list 101 permit tcp any any established

!--- windows traffic and smtp, if needed
access-list 110 permit tcp <from_cidr_or_host> <to_windows_farm> eq 25 
access-list 110 permit tcp <from_cidr_or_host> <to_windows_farm> eq 445
access-list 110 permit tcp <from_cidr_or_host> <to_windows_farm> eq 135
access-list 110 permit tcp <from_cidr_or_host> <to_windows_farm> eq 139
access-list 110 permit udp <from_cidr_or_host> <to_windows_farm> eq 137
access-list 110 permit udp <from_cidr_or_host> <to_windows_farm> eq 138

!--- allow other services look them up if you don't know them.
!--- access-list 110 permit tcp <from_cidr_or_host> <to_cidr_or_host> eq 53
!--- access-list 110 permit tcp <from_cidr_or_host> <to_cidr_or_host> eq 22
!--- access-list 110 permit tcp <from_cidr_or_host> <to_cidr_or_host> eq
3389
!--- access-list 110 permit tcp <from_cidr_or_host> <to_cidr_or_host> eq
3306
!--- access-list 110 permit tcp <from_cidr_or_host> <to_cidr_or_host> eq
1433
!--- ftp can be tricky depending on PASV or not
!--- access-list 110 permit tcp <from_cidr_or_host> <to_cidr_or_host> eq 21
!--- access-list 110 permit tcp <from_cidr_or_host eq ftp-data
<to_cidr_or_host> gt 1023
!--- access-list 110 permit udp <from_cidr_or_host> <to_windows_farm> eq 69

!--- a permit ip any any pretty much negates your entire access list. Try
not to use it.
!--- access-list 110 permit ip any any

!--- there is an implicit deny, but this allows explicit logging, good for
troubleshooting. 
access-list 110 deny ip any any log

Use the last line, the deny any any log, to find out what is being blocked.
This may clog up your router if there is a lot of traffic so be careful. If
you have a logging server that may be the best bet as you can direct logging
to a syslog server and review them offline. I think all the windows services
allowed will let the file sharing, exchange and (I think) AD authentication.
You might have to allow tcp 88 (Kerberos) but im not too sure.

The acl above will block rfc1918 address, excluding your 10.x.x.x
addressing. You might want to lock that down a bit further, if necessary.
You could almost add the networks by explicitly allowing the ones you use,
then let the deny statement take care of the networks not allowed. See above
in the acl.

Definitely build this out as a test network. Make a huge list of all the
regular activity to test. You might sniff a regular user segment and let it
sniff for the day, the histogram the tcp and udp ports that are used. Winnow
out the ones that are non-business, then add them necessary ones to the acl.
Watch the deny logging and figure out which ports need to be allowed. Rinse,
lather, repeat.

I would agree that acl's are used for more than just allowing and denying
ports. Proper management of roles and responsibilities and especially
accountability and necessary. There are lots of different options for
locking down router access, but they should all include ssh. No telnet.

eddy



-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On
Behalf Of David Gillett
Sent: Monday, May 14, 2007 7:02 PM
To: 'WALI'; security-basics () securityfocus com
Subject: RE: ACL design.

  If I read you right, both sides of this router are on private
addresses and there should be no non-private addresses in the 
traffic.  You could enforce that in ACLs, just as a sanity measure.
(I sometimes see clients come onto our (guest) network with addresses 
from some other network; at one point, it was common to see them
show up with AOL addresses....)

  The other main use of ACLs in this case is to limit who can connect
to the router itself.  (The guest gateway's interface addresses are
not acceptable destinations for traffic originating within that
network.)

David Gillett

> -----Original Message-----
> From: listbounce () securityfocus com 
> [mailto:listbounce () securityfocus com] On Behalf Of WALI
> Sent: Saturday, May 12, 2007 11:00 AM
> To: Alex Nedelcu; security-basics () securityfocus com
> Subject: Re: ACL design.
>
> Off the subject a bit but I thought, I should ask this 
> question since it's been lingering on my mind for some time 
> now. Maybe guys around here can answer in detail.
>
> I have a remote site getting connected to my server farm. 
> It's our branch office. I have a router in the middle with no 
> fire wall and the addresses on both sides of the interface 
> are private, say 10.10.10.0/24 on my side and 10.20.20.0/24 
> on the other.
>
> The only thing the branch users access on this side of the 
> router is AD authentication, Exchange (SMTP) and some file shares.
> What should be my minimal extended ACL? Currently, it' all 
> through and through and I feel that's highly insecure.
>
> Any advise??
>
> At 08:58 AM 5/9/2007 +0300, Alex Nedelcu wrote:
> > It's also important where you place your ACLS.
> >
> > If you have an advanced ACL that takes into consideration 
> the source, 
> > destination, ports, TOS etc you should place it as close to 
> the source 
> > of traffic as possible.
> >
> > If the ACL is based solely on source addresses they should 
> be placed as 
> > close as possible to the destination.
> >
> > Another thing that you should take into consideration is to 
> never apply 
> > ACLs in the core area of your network, in a hierarchical 
> model network 
> > the traffic policies should be applied at the distribution 
> layer. You 
> > should analyze carefully the design of your network and find 
> the ideal 
> > places where you should implement filtering, if you choose badly you 
> > may get decreased perfomance.