RE: ACL design.



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@xxxxxxxxxxxxxxxxx [mailto:listbounce@xxxxxxxxxxxxxxxxx] On
Behalf Of David Gillett
Sent: Monday, May 14, 2007 7:02 PM
To: 'WALI'; security-basics@xxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxx
[mailto:listbounce@xxxxxxxxxxxxxxxxx] On Behalf Of WALI
Sent: Saturday, May 12, 2007 11:00 AM
To: Alex Nedelcu; security-basics@xxxxxxxxxxxxxxxxx
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.




Relevant Pages

  • Re: Cisco ACL vs. iptables semantics
    ... is equivilent to "deny ssh, ... That's -every- Cisco IOS or PIX ACL, ... routing-table routing of none of the PBRs matched the packet. ... If, instead, the router is a host running iptables, the packet could be ...
    (comp.security.firewalls)
  • RE: deny access
    ... If this is an edge router you'd like secure it a bit more, ... Subject: deny access ... ACL to block one host would effectively block all hosts. ... From interface config mode, ...
    (Security-Basics)
  • RE: ACL design.
    ... both sides of this router are on private ... from some other network; at one point, it was common to see them ... What should be my minimal extended ACL? ...
    (Security-Basics)
  • Re: [Full-disclosure] RE: Example firewall script
    ... > of every ACL. ... > DENY ANY ANY at the end of their ACL's ... > should have a deny statement at the end, ... situations where large numbers of disparate hosts ...
    (Full-Disclosure)
  • Re: Hiding NATs with PF
    ... Even with my transparent squid setup I still get OpenBSD ... +acl snmppublic snmp_community somecommunitystring ... +http_access deny contextclick ... routing disabled between them cannot be described as a 'router' per-ce. ...
    (comp.unix.bsd.openbsd.misc)