Cisco ASA set ACL of white list fail to function

[DOUMI]

I added about 500 network objects by IP, and group them into an object group called white-list. 2 days later, I modified ACL access-in from allowing source any to white-list. The action was to delete original access-in ACL (total 6 rules, included implicit deny all at the end), then add 2 modified ACLs, 3 as same original config by original order, and with 1 deny all. 1.5 hours later, we received amounts of unauthorized events try to login. Attacked IPs are not in the white-list. We reload to start-up config and still receiving attacked events, therefore we shut down the interface to internet, which are ACL access-in affected. 

Could anyone help to verify where might be the point to fix this and accomplish our goal to block all but IP of white-list to access in?

[Rob Ingram]

@DOUMI if you created a new ACL did you apply that to the interface - "access-group <ACL NAME> in interface <INTERFACE>" if not the ACL is not in use.

If that is not the issue, please provide your configuration so we can determine the cause.

[DOUMI]

@Rob Ingram 

before set white-list, ACL access-in had applied to interface internet wan1 and internet wan2.

I simplified the original acl config as below:

access-list access_in extended permit object-group SERVICE_300 object-group NETWORK_300 object-group NETWORK_1
access-list access_in extended permit object-group SERVICE_1 any 219.87.82.0 255.255.255.240
access-list access_in extended permit object-group SERVICE_2 any object-group NETWORK_1
access-list access_in extended permit object-group SERVICE_300 object-group NETWORK_300 219.87.82.0 255.255.255.240
access-list access_in extended permit object-group SERVICE_2 any host 219.87.82.21
access-group access_in in interface PUBLIC_WAN_1
access-group access_in in interface PUBLIC_WAN_2

[Rob Ingram]

@DOUMI is the above configuration before or after the change? I don't see a group called white-list

There would be an implict deny, so if you are seeing unauthorised login attempts they must be permitted by another rule? Run packet-tracer to simulate traffic that should be allowed (whitelist) and another that should be denied. Confirm what ACL ACE should be matched.

[DOUMI]

@Rob Ingram this is the configuration before changes. the actions I modified of acl is as below:

no access-list access_in extended permit object-group SERVICE_300 object-group NETWORK_300 object-group NETWORK_1
no access-list access_in extended permit object-group SERVICE_1 any 219.87.82.0 255.255.255.240
no access-list access_in extended permit object-group SERVICE_2 any object-group NETWORK_1
no access-list access_in extended permit object-group SERVICE_300 object-group NETWORK_300 219.87.82.0 255.255.255.240
no access-list access_in extended permit object-group SERVICE_2 any host 219.87.82.21
access-list access_in extended permit object-group SERVICE_300 object-group NETWORK_300 object-group NETWORK_1
access-list access_in extended permit object-group SERVICE_1 object-group white-list 219.87.82.0 255.255.255.240
access-list access_in extended permit object-group SERVICE_2 object-group white-list object-group NETWORK_1
access-list access_in extended permit object-group SERVICE_300 object-group NETWORK_300 219.87.82.0 255.255.255.240
access-list access_in extended permit object-group SERVICE_2 object-group white-list host 219.87.82.21
access-list access_in extended deny ip any any log

I didn't modify access-group access_in

[Rob Ingram]

@DOUMI  so if you are seeing unauthorised login attempts they must be permitted by another rule? Run packet-tracer to simulate traffic that should be allowed (whitelist) and another that should be denied. Confirm what ACL ACE should be matched.

[MHM Cisco World]

When you do show access-list you still see delete ACL?

MHM

[Jonatan Jonasson]

Are the unauthorized log-in attempts to a service that's protected by the ASA, or to the ASA itself (http(s)/ssh/vpn) ?

If the latter, note that the interface access-list (access-in) does not include traffic to the identity ip/self ip of the ASA itself.

If it's a service protected by the ASA, as Rob mentioned, using a packet tracer should show you what access-list entry is permitting the traffic.

[Aref Alsouqi]

I think what you are seeing is expected. The implicit deny at the end of the ACL does not have logging enabled, so any unauthorized attempt that would've matched that implicit deny rule wouldn't have been noticed. Now that you changed the ACL content adding an explicit deny rule with logging enabled you started seeing all those attempts.