What do you think of my acces list?

What do you think of my acces list?
NewsGroups | Search | Tools
User Password
Register Now! Lost Password?
 comp.dcom.sys.cisco  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
What do you think of my acces list? Steven V.A. 06-10-2008
Posted by Steven V.A. on June 10, 2008, 4:34 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Hi all,

I have played with the access list of my Cisco 857.
I've comr up with the following tru searching the web, usenet and
cisco manuals, sdm ....

What do you think I should improve, change....
This is acces list 102 -- incoming traffic from the wan/atm interface

Situation: soho usage, and 1 bittorent client.
Thanks in advance


access-list 102 remark DNS verkeer inkomend toelaten
access-list 102 permit udp any eq domain any
access-list 102 remark Web inkomend toelaten en dyndns antwoord
access-list 102 permit tcp any eq www any
access-list 102 remark NTP inkomend toelaten (123) 207.46.197.32
access-list 102 permit udp host 207.46.197.32 eq ntp any eq ntp
access-list 102 remark BitTorent verkeer toelaten -- PC1
access-list 102 permit tcp any any eq 11478
access-list 102 permit udp any any eq 11478
access-list 102 remark Bittorent verkeer toelaten -- PC2
access-list 102 permit tcp any any eq 56658
access-list 102 permit udp any any eq 56658
access-list 102 remark ICMP instellingen hieronder
access-list 102 permit icmp any any echo-reply
access-list 102 permit icmp any any time-exceeded
access-list 102 permit icmp any any unreachable
access-list 102 permit udp any any eq ntp
access-list 102 remark Prive adressen niet toestaan vanop internet
access-list 102 deny ip 10.0.0.0 0.255.255.255 any
access-list 102 deny ip 172.16.0.0 0.15.255.255 any
access-list 102 deny ip 192.168.0.0 0.0.255.255 any
access-list 102 deny ip 127.0.0.0 0.255.255.255 any
access-list 102 deny ip host 255.255.255.255 any
access-list 102 deny ip host 0.0.0.0 any
access-list 102 deny ip any any log
dialer-list 1 protocol ip permit



Extended IP access list 102
10 permit udp any eq domain any (1500 matches)
20 permit tcp any eq www any (24 matches)
30 permit udp host 207.46.197.32 eq ntp any eq ntp (28 matches)
40 permit tcp any any eq 11478 (21347 matches)
50 permit udp any any eq 11478 (26 matches)
60 permit tcp any any eq 56658
70 permit udp any any eq 56658
80 permit icmp any any echo-reply (10 matches)
90 permit icmp any any time-exceeded (12 matches)
100 permit icmp any any unreachable (411 matches)
110 permit udp any any eq ntp
120 deny ip 10.0.0.0 0.255.255.255 any
130 deny ip 172.16.0.0 0.15.255.255 any
140 deny ip 192.168.0.0 0.0.255.255 any
150 deny ip 127.0.0.0 0.255.255.255 any
160 deny ip host 255.255.255.255 any
170 deny ip host 0.0.0.0 any
180 deny ip any any log (83 matches)





NMFall 20%
Posted by News Reader on June 10, 2008, 5:41 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Steven V.A. wrote:
> Hi all,
>
> I have played with the access list of my Cisco 857.
> I've comr up with the following tru searching the web, usenet and
> cisco manuals, sdm ....
>
> What do you think I should improve, change....
> This is acces list 102 -- incoming traffic from the wan/atm interface
>
> Situation: soho usage, and 1 bittorent client.
> Thanks in advance
>
>
> access-list 102 remark DNS verkeer inkomend toelaten
> access-list 102 permit udp any eq domain any
> access-list 102 remark Web inkomend toelaten en dyndns antwoord
> access-list 102 permit tcp any eq www any
> access-list 102 remark NTP inkomend toelaten (123) 207.46.197.32
> access-list 102 permit udp host 207.46.197.32 eq ntp any eq ntp
> access-list 102 remark BitTorent verkeer toelaten -- PC1
> access-list 102 permit tcp any any eq 11478
> access-list 102 permit udp any any eq 11478
> access-list 102 remark Bittorent verkeer toelaten -- PC2
> access-list 102 permit tcp any any eq 56658
> access-list 102 permit udp any any eq 56658
> access-list 102 remark ICMP instellingen hieronder
> access-list 102 permit icmp any any echo-reply
> access-list 102 permit icmp any any time-exceeded
> access-list 102 permit icmp any any unreachable
> access-list 102 permit udp any any eq ntp
> access-list 102 remark Prive adressen niet toestaan vanop internet
> access-list 102 deny ip 10.0.0.0 0.255.255.255 any
> access-list 102 deny ip 172.16.0.0 0.15.255.255 any
> access-list 102 deny ip 192.168.0.0 0.0.255.255 any
> access-list 102 deny ip 127.0.0.0 0.255.255.255 any
> access-list 102 deny ip host 255.255.255.255 any
> access-list 102 deny ip host 0.0.0.0 any
> access-list 102 deny ip any any log
> dialer-list 1 protocol ip permit
>
>
>
> Extended IP access list 102
> 10 permit udp any eq domain any (1500 matches)
> 20 permit tcp any eq www any (24 matches)
> 30 permit udp host 207.46.197.32 eq ntp any eq ntp (28 matches)
> 40 permit tcp any any eq 11478 (21347 matches)
> 50 permit udp any any eq 11478 (26 matches)
> 60 permit tcp any any eq 56658
> 70 permit udp any any eq 56658
> 80 permit icmp any any echo-reply (10 matches)
> 90 permit icmp any any time-exceeded (12 matches)
> 100 permit icmp any any unreachable (411 matches)
> 110 permit udp any any eq ntp
> 120 deny ip 10.0.0.0 0.255.255.255 any
> 130 deny ip 172.16.0.0 0.15.255.255 any
> 140 deny ip 192.168.0.0 0.0.255.255 any
> 150 deny ip 127.0.0.0 0.255.255.255 any
> 160 deny ip host 255.255.255.255 any
> 170 deny ip host 0.0.0.0 any
> 180 deny ip any any log (83 matches)
>
>
>
>

ACEs 10 and 20 appear to be used for provisioning of return traffic from
external servers. These ACEs would not be necessary if you were using
"inspection" on an internal interface to provision the return path
(temporary dynamic holes in the firewall).


The following ACE's are redundant:

30 permit udp host 207.46.197.32 eq ntp any eq ntp (28 matches)
110 permit udp any any eq ntp

... both permit NTP to destination "any". If host 207.46.197.32 is using
source port "ntp" it is matched earlier in the ACL, but it would still
be matched by the second ACE regardless of source port.


For your permit ACEs, consider placing those that will be matched most
frequently, above those matched less frequently.

e.g.:
40 permit tcp any any eq 11478 (21347 matches)
30 permit udp host 207.46.197.32 eq ntp any eq ntp (28 matches)


You might supplement ACEs 80 through 100 with:

permit icmp any any administratively-prohibited
permit icmp any any packet-too-big
permit icmp any any source-quench
permit icmp any any parameter-problem


You could consider denying fragments. If you do, place them at the top
of your ACL.:

deny tcp any any log fragments
deny udp any any log fragments
deny icmp any any log fragments


The ACEs 120 - 170 should precede the permit ACEs, otherwise there is a
risk of permitting traffic from these sources. There are other source
ranges commonly denied which are absent. Investigate the Land attack as
well (source IP same as the WAN interface IP).


Current IOS releases support the use of non-contiguous ports in an ACE
provided the protocol, source, and destinations are common.

e.g.:
permit tcp any any eq www 443 ftp

... only drawback is the single counter for the ACE.


Best Regards,
News Reader

Posted by Steven V.A. on June 11, 2008, 11:52 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Hi!

Thank you for the very informative reply.
I have modifyied my access-list.

> 30 permit udp host 207.46.197.32 eq ntp any eq ntp (28 matches)
>110 permit udp any any eq ntp

Fixed.


>For your permit ACEs, consider placing those that will be matched most
>frequently, above those matched less frequently.

I have put the bittorrent rules more to the top of the list

> permit icmp any any administratively-prohibited
> permit icmp any any packet-too-big
> permit icmp any any source-quench
> permit icmp any any parameter-problem

Added.

> deny tcp any any log fragments
> deny udp any any log fragments
> deny icmp any any log fragments

I have put these on top.

So far this give me now:

Extended IP access list 102
10 deny tcp any any log fragments
20 deny udp any any log fragments
30 deny icmp any any log fragments
40 permit udp any eq domain any (42 matches)
50 permit tcp any eq www any (4 matches)
60 permit udp any any eq ntp (5 matches)
70 permit tcp any any eq 11478
80 permit udp any any eq 11478 (30 matches)
90 permit tcp any any eq 56658
100 permit udp any any eq 56658
110 permit icmp any any echo-reply
120 permit icmp any any time-exceeded (6 matches)
130 permit icmp any any unreachable (126 matches)
140 permit icmp any any parameter-problem
150 permit icmp any any source-quench
160 permit icmp any any packet-too-big
170 permit icmp any any administratively-prohibited
180 deny ip 10.0.0.0 0.255.255.255 any
190 deny ip 172.16.0.0 0.15.255.255 any
200 deny ip 192.168.0.0 0.0.255.255 any
210 deny ip 127.0.0.0 0.255.255.255 any
220 deny ip host 255.255.255.255 any
230 deny ip host 0.0.0.0 any
240 deny ip any any log



>The ACEs 120 - 170 should precede the permit ACEs, otherwise there is a
>risk of permitting traffic from these sources. There are other source
>ranges commonly denied which are absent. Investigate the Land attack as
>well (source IP same as the WAN interface IP).

Will look after this.

However I have on thing you mentioned that I can't get to work "right"
It's the following:

>ACEs 10 and 20 appear to be used for provisioning of return traffic from
>external servers. These ACEs would not be necessary if you were using
>"inspection" on an internal interface to provision the return path
>(temporary dynamic holes in the firewall).

I have added:

ip inspect name firewall tcp
ip inspect name firewall udp

and to my inside interface vlan 1:

ip inspect firewall in

And when I remove:
" permit udp any eq domain any (54 matches) "
My incoming DNS does not get thru anymore :(
It shows in the logs as:

000036: Jun 11 16:48:50.295 GMT: %SEC-6-IPACCESSLOGP: list 102 denied
udp 208.67
.220.220(53) -> 88.197.151.124(3), 1 packet
000037: Jun 11 16:49:01.724 GMT: %SEC-6-IPACCESSLOGP: list 102 denied
udp 208.67
.222.222(53) -> 88.197.151.124(5), 1 packet

Can you help me with this, so I can remove "permit udp any eq domain
any (54 matches) "

Many thanks!

Steven

Posted by News Reader on June 11, 2008, 12:52 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
>
>> ACEs 10 and 20 appear to be used for provisioning of return traffic from
>> external servers. These ACEs would not be necessary if you were using
>> "inspection" on an internal interface to provision the return path
>> (temporary dynamic holes in the firewall).
>
> I have added:
>
> ip inspect name firewall tcp
> ip inspect name firewall udp
>
> and to my inside interface vlan 1:
>
> ip inspect firewall in
>
> And when I remove:
> " permit udp any eq domain any (54 matches) "
> My incoming DNS does not get thru anymore :(
> It shows in the logs as:
>
> 000036: Jun 11 16:48:50.295 GMT: %SEC-6-IPACCESSLOGP: list 102 denied
> udp 208.67
> .220.220(53) -> 88.197.151.124(3), 1 packet
> 000037: Jun 11 16:49:01.724 GMT: %SEC-6-IPACCESSLOGP: list 102 denied
> udp 208.67
> .222.222(53) -> 88.197.151.124(5), 1 packet
>
> Can you help me with this, so I can remove "permit udp any eq domain
> any (54 matches) "
>
> Many thanks!
>
> Steven

I used the word "appears" because I am not familiar with your environment.

If you were trying to accommodate DNS "responses" resulting from queries
initiated by internal clients, I would have expected the generic UDP
inspection to provision the return path for this return traffic.
However, I would have used DNS inspection (ip inspect name firewall dns)
instead.

If you were trying to accommodate DNS "responses" resulting from queries
initiated by the router, you would likely need to apply DNS inspection
"outbound" on the "external" interface, or retain the existing ACE.

If you were trying to accommodate DNS "queries" inbound to a DNS server
residing on your internal network, you would need to accommodate
connection initiation with an ACL applied inbound on the external
interface. You would apply inbound inspection on the external interface
to provision the return path (responses going back to the Internet).


You are now using generic TCP and UDP inspection, which serves as a
starting point. Moving forward, you could refine your inspection rules
to inspect the specific protocols you use, and eventually eliminate the
generic TCP and UDP inspection.

Port Application Mapping (PAM) and Granular Protocol Inspection (GPI)
would get you there. You might also want to investigate the Application
Firewall (APPFW) for inspection of HTTP, IM, P2P, and port 80 tunneling,
at a later date.


A "partial" example:

ip port-map http port tcp 8080 8081 81 description "Expanded HTTP Ports"
ip port-map user-tcp-43 port tcp 43 description "Whois"

ip inspect log drop-pkt
ip inspect audit-trail
ip inspect max-incomplete low <value removed>
ip inspect max-incomplete high <value removed>
ip inspect one-minute low <value removed>
ip inspect one-minute high <value removed>
ip inspect udp idle-time 15
ip inspect dns-timeout 15
ip inspect tcp idle-time 300
ip inspect tcp finwait-time 1
ip inspect tcp synwait-time 15
ip inspect tcp max-incomplete host <value removed> block-time 0
ip inspect name firewall appfw httpfw
ip inspect name firewall dns
ip inspect name firewall esmtp max-data 5000000
ip inspect name firewall ftp
ip inspect name firewall https
ip inspect name firewall ipsec-msft
ip inspect name firewall nntp
ip inspect name firewall pop3
ip inspect name firewall snmp
ip inspect name firewall ssh
ip inspect name firewall tftp
ip inspect name firewall user-tcp-43
ip inspect name firewall icmp timeout 10
ip inspect name firewall fragment maximum 254 timeout 1

appfw policy-name httpfw
application http
strict-http action allow alarm
content-type-verification match-req-rsp action allow alarm
port-misuse default action reset alarm
request-method rfc put action reset alarm

Note the absence of generic UDP or TCP inspection.

Best Regards,
News Reader

Posted by Steven V.A. on June 11, 2008, 2:40 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
wrote:

>If you were trying to accommodate DNS "responses" resulting from queries
>initiated by internal clients, I would have expected the generic UDP
>inspection to provision the return path for this return traffic.

Hi!

You are absolutly right!!
Because....I use my cisco as a DNS forwarder:
Set up like this article: http://www.nil.com/ipcorner/RouterDNS/
And when I set up my PC to use my ISP's DNS server directly....the
incoming DNS answer come trough!

However letting when my router doing the resolving....
Setting my dns back to my cisco as a forwarder gives:
000036: Jun 11 16:48:50.295 GMT: %SEC-6-IPACCESSLOGP: list 102 denied
udp 208.67
.220.220(53) -> 88.197.151.124(3), 1 packet
...and so on.
Setting "ip inspect in/out" on every interface possible does not help
to get the packets trough the firewall.


Resolving hosts from the CLI fails always whithout:
"access-list 102 permit udp any eq domain any"

I suppose I will have to put the
"access-list 102 permit udp any eq domain any"
back in place ?

Greetings and thanks in advance.

Steven

ps: thanks for the IP inspect example


>However, I would have used DNS inspection (ip inspect name firewall dns)
>instead.
>
>If you were trying to accommodate DNS "responses" resulting from queries
>initiated by the router, you would likely need to apply DNS inspection
>"outbound" on the "external" interface, or retain the existing ACE.
>
>If you were trying to accommodate DNS "queries" inbound to a DNS server
>residing on your internal network, you would need to accommodate
>connection initiation with an ACL applied inbound on the external
>interface. You would apply inbound inspection on the external interface
>to provision the return path (responses going back to the Internet).
>


Similar ThreadsPosted
VPDN L2TP pb for routing on virtual acces interface July 13, 2007, 1:39 pm
BGP list April 28, 2005, 1:13 pm
Access List and VPN November 25, 2004, 2:33 pm
help on this access-list September 25, 2005, 3:57 am
top uptime list ? April 5, 2006, 3:31 pm
Access List Help May 1, 2006, 10:02 am
access list May 17, 2006, 9:39 am
PIX & access-list June 1, 2006, 2:51 pm
White list June 26, 2006, 8:46 am
dynamic ban-list July 7, 2006, 5:14 am

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map