cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
382
Views
0
Helpful
6
Replies

Cisco ASA Access lists

James Hoggard
Level 1
Level 1

Hi,

I have taken over a firewall that someone else managed.

Everything working well. However on the outside interface coming in i see an access list which says source-any4 destination-any4 permit service ip.

Am i correct in saying that this rule shouldn't be here as the whole point of the firewall is to be statfull and not allow just any traffic in.

The only other access list on this interface are a few static ones going to internal ip's alloing pptp and https for remote access.

Is there any reason there should be an access list like this on your outside interface going to internal?

Thanks

3 Accepted Solutions

Accepted Solutions

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

There should not really be an "access-list" on your external interface which permits all traffic with "any" source/destination address. I would understand if all TCP/UDP traffic was permitted between certain hosts which people seem to do when they dont know what ports need to be allowed.

It would be best if we could see the actual ACL configuration (naturally WITHOUT any public IP address references away)

But generally you should only allow the services that are needed and only to the hosts that are hosting them.

Naturally in some services cases like HTTP/HTTPS you probably will allow traffic from "any" source address.

Your Static NATed hosts are under biggest risk at the moment as they can be reached now with any destination port/service. The rule might open up some connectivity towards the users that use the Dynamic PAT as long as there is an existing NAT translation on the firewall for the attempted destination port.

So I would suggest only allowing the needed services to needed hosts and blocking all other traffic from the external network. Naturally if there are services that are just allowed with this "permit ip any4 any4" statement then some services might be blocked in the worst case.

- Jouni

View solution in original post

Hi,

Seems there are 3 hosts to which traffic is allowed on certain ports and then all other traffic to them is blocked with a separate Deny rule.

Then there seems to be the rule you mentioned which allows ALL other traffic.

The rule permitting ALL traffic doesn't have anything to do with the 3 hosts 10.80.0.41 , 10.80.0.11 and HK-Remote since you have already blocked ALL traffic to them AFTER allowing the needed services. So in that sense it would also seem useless rule.

I wonder if the original firewall admin accidentally inserted a Permit instead of Deny (even though the Deny would have been useless ince there is already a Implicit Deny at the end of each ACL)

But you should remove the rule allowing ALL traffic since its clearly a risk.

- Jouni

View solution in original post

Also,

If you have some other host than the ones mentioned in the ACL that have Static NAT or Static PAT configured then make sure that traffic to those will not start getting blocked. (As they would match to this Permit rule since they dont have their own rules)

But from what I understood you dont have any other hosts reachable through the external/public network than the ones specifically mentioned.

- Jouni

View solution in original post

6 Replies 6

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

There should not really be an "access-list" on your external interface which permits all traffic with "any" source/destination address. I would understand if all TCP/UDP traffic was permitted between certain hosts which people seem to do when they dont know what ports need to be allowed.

It would be best if we could see the actual ACL configuration (naturally WITHOUT any public IP address references away)

But generally you should only allow the services that are needed and only to the hosts that are hosting them.

Naturally in some services cases like HTTP/HTTPS you probably will allow traffic from "any" source address.

Your Static NATed hosts are under biggest risk at the moment as they can be reached now with any destination port/service. The rule might open up some connectivity towards the users that use the Dynamic PAT as long as there is an existing NAT translation on the firewall for the attempted destination port.

So I would suggest only allowing the needed services to needed hosts and blocking all other traffic from the external network. Naturally if there are services that are just allowed with this "permit ip any4 any4" statement then some services might be blocked in the worst case.

- Jouni

Thanks for the response. Please see attached incmong ACL list on the outside interface. Not sure if you want command line. I how now disabled that rule everything still seems to be working.

Hi,

Seems there are 3 hosts to which traffic is allowed on certain ports and then all other traffic to them is blocked with a separate Deny rule.

Then there seems to be the rule you mentioned which allows ALL other traffic.

The rule permitting ALL traffic doesn't have anything to do with the 3 hosts 10.80.0.41 , 10.80.0.11 and HK-Remote since you have already blocked ALL traffic to them AFTER allowing the needed services. So in that sense it would also seem useless rule.

I wonder if the original firewall admin accidentally inserted a Permit instead of Deny (even though the Deny would have been useless ince there is already a Implicit Deny at the end of each ACL)

But you should remove the rule allowing ALL traffic since its clearly a risk.

- Jouni

Cheers Jouni.

Thanks for the hep.

Also,

If you have some other host than the ones mentioned in the ACL that have Static NAT or Static PAT configured then make sure that traffic to those will not start getting blocked. (As they would match to this Permit rule since they dont have their own rules)

But from what I understood you dont have any other hosts reachable through the external/public network than the ones specifically mentioned.

- Jouni

My NAT rules are source - inside network to PAT using IP address of the interface ( outisde )  it has not affected internet connectivity all is working well.

Thanks

Review Cisco Networking products for a $25 gift card