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.