What do you think of my acces list?

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

Hi!

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

Fixed.

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

Added.

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

Will look after this.

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

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 ip inspect max-incomplete high ip inspect one-minute low ip inspect one-minute high 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 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

Hi!

You are absolutly right!! Because....I use my cisco as a DNS forwarder: Set up like this article:

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

I tried:

"ip inspect firewall out" on "dialer0" my external interface. Is this right?

It did not work. Still get blocked in the logs. DNS queries directly to my ISP's dns server do work

Greetings, Steven

For those who are interested I found some extra info on ip inspect here:

Greetings

Good to know.

We don't let our routers do DNS lookups, and don't apply inspection outbound (it was just a suggestion). We apply inspection inbound on all interfaces that see connection initiation. If I had to accommodate return traffic addressed to the router itself, I would use the interface ACL (i.e.: the second suggestion, retain the existing ACE).

Best Regards, News Reader

To clarify, it wasn't my suggestion to apply inbound and outbound inspection on every interface. I was suggesting that you might try outbound inspection on a particular interface. The inspection feature available in newer IOS releases does provide support for some router-generated traffic (when configured to do so), although I have not chosen to implement it.

You might consider:

access-list 102 permit udp any eq domain host

Best Regards, News Reader

Indeed. Was getting desperate so I added it to every interface possible ;) But that did not help much ;-)

Great tip! I found this with the suggestion you gave:

works!

My configuration is now as follows:

ip inspect name firewall dns ip inspect name firewall udp ip inspect name firewall tcp

---> (these lines above were already present from yesterday) ip inspect name router udp router-traffic ip inspect name router tcp router-traffic ip inspect name router icmp router-traffic

interface Vlan1 ip inspect firewall in

interface Dialer0 ip inspect router out

And now my access list now looks like this: (note that the DNS rule and web rules are removed now -- and everything works now, including dns queries from the router to the net)

10 deny tcp any any log fragments 20 deny udp any any log fragments 30 deny icmp any any log fragments 40 permit tcp any any eq 11478 (56 matches) 50 permit udp any any eq 11478 (13 matches) 60 permit tcp any any eq 56658 70 permit udp any any eq 56658 80 permit icmp any any echo-reply 90 permit icmp any any time-exceeded (6 matches) 100 permit icmp any any unreachable (93 matches) 110 permit icmp any any parameter-problem 120 permit icmp any any source-quench 130 permit icmp any any packet-too-big 140 permit icmp any any administratively-prohibited 150 deny ip 10.0.0.0 0.255.255.255 any 160 deny ip 172.16.0.0 0.15.255.255 any 170 deny ip 192.168.0.0 0.0.255.255 any 180 deny ip 127.0.0.0 0.255.255.255 any 190 deny ip host 255.255.255.255 any 200 deny ip host 0.0.0.0 any 210 deny ip any any log (49 matches)

Would have done this if I did not got the above working. Thanks for the suggestion.

I am very pleased, I believe the solution I have now is more secure (?) then allowing the traffic via acces-list 102 since is creates a permanent hole (?)

If there is anything you (or others) would want to say about my access list. go ahaed ;)

Many thanks in advance.

Steven

Note to readers: vlan 1 is my internal interface dialer0 is my external (internet) facing interface

So vlan 1 recieves the traffic ( firwall IN) and dialer0 makes oubound connections -- router initiated (router OUT)

If I said that correctly ;)

Steven

You have forgotten to re-visit the deny entries.

Remember it was communicated that the following ACEs:

150 deny ip 10.0.0.0 0.255.255.255 any 160 deny ip 172.16.0.0 0.15.255.255 any 170 deny ip 192.168.0.0 0.0.255.255 any 180 deny ip 127.0.0.0 0.255.255.255 any 190 deny ip host 255.255.255.255 any 200 deny ip host 0.0.0.0 any

... should precede the permit ACEs, otherwise there is a risk of permitting traffic from unintended source.

Also, this list may not be as complete as you would like.

Land attack (external interface IP as source), perhaps multicast addresses, reserved address space, etc.

Best Regards, News Reader

I have fixed it. Thanks. One question: how do you easily move a rule in an acces list? Say move rule 200 to 40. I did cut & paste in notepad, wich I assume isn't the right way to do it, but coulden't find it on the 'net.

Will investigate it - thanks.

So my list is now as follows: (/me wants to give something back to the group - if anyone wants to make an acces list ;)

10 deny tcp any any log fragments 20 deny udp any any log fragments 30 deny icmp any any log fragments 40 deny ip 10.0.0.0 0.255.255.255 any 50 deny ip 172.16.0.0 0.15.255.255 any 60 deny ip 192.168.0.0 0.0.255.255 any 70 deny ip 127.0.0.0 0.255.255.255 any 80 deny ip host 255.255.255.255 any 90 deny ip host 0.0.0.0 any 100 permit tcp any any eq 11478 110 permit udp any any eq 11478 120 permit tcp any any eq 56658 130 permit udp any any eq 56658 140 permit icmp any any echo-reply 150 permit icmp any any time-exceeded 160 permit icmp any any unreachable 170 permit icmp any any parameter-problem 180 permit icmp any any source-quench 190 permit icmp any any packet-too-big 200 permit icmp any any administratively-prohibited 210 deny ip any any log

Steven

Extrapolated from another recent response:

sh access-list 101

Note the sequence numbers beside the ACEs (they probably start at 10, and increment by 10's).

Lets assume you saw this:

10 permit tcp any any eq www 20 permit tcp any any eq smtp . . 50 permit tcp any any eq ftp

If you wanted to move the sequence #50 ACE so that it resided between the ACEs with sequence numbers 10 and 20, you could delete the sequence #50 ACE, and establish a new one in the sequence desired.

Note: You could probably create the new (identical) one first, before deleting the original so as to not disrupt traffic. I don't think the IOS CLI would complain about the duplication of ACE's, but you'd have to try it to be sure.

hostname # config t hostname(config) # ip access-list extended 101 hostname(config-ext-nacl) # no 50

hostname(config-ext-nacl) # 15 permit tcp any any eq ftp

... and if you wanted to resequence the ACEs:

hostname(config-ext-nacl) exit hostname(config) # ip access-list resequence 101 10 10

This would resequence the ACEs in access-list 101, starting at 10, and incrementing by 10.

sh access-list 101 would verify that the undesirable ACE was removed, and the new one was added. Note that the ACE that had sequence #20 now has sequence #30 due to the resequencing performed.

result:

10 permit tcp any any eq www 20 permit tcp any any eq ftp 30 permit tcp any any eq smtp . .

Best Regards, News Reader

Thanks for the explanation. Actually I did it mostly the way you described. I tought there was another way to move up an acces list entry. (w/o removing them)

Like this:

conf t ip access-list extended 102

80 move 80 -> 21

That would then move up acces list entry 80 to 21.

Thanks for all the help!

Greetings Steven

I don't see that happening.

router(config)#ip access-list extended router-f0.20-in router(config-ext-nacl)#140 ? deny Specify packets to reject dynamic Specify a DYNAMIC list of PERMITs or DENYs evaluate Evaluate an access list exit Exit from access-list configuration mode permit Specify packets to forward

Note that carriage return "" is not an option. Note that "move" is not an option.

router(config)#ip access-list extended router-f0.20-in router(config-ext-nacl)#? Ext Access List configuration commands: Sequence Number default Set a command to its defaults deny Specify packets to reject dynamic Specify a DYNAMIC list of PERMITs or DENYs evaluate Evaluate an access list exit Exit from access-list configuration mode no Negate a command or set its defaults permit Specify packets to forward remark Access list entry comment

Note that "move" is not an option.

Best Regards, News Reader

I know. But woulden't it be nice if it was possible? ;)

Anyway. News Reader thank you for all the help. My access list is now better then ever. Learned ip inspect (will work on that further)

Topic closed for me. Thanks!

Steven