Block specific IP's from attempting to establish an SSLVPN connection - Page 2

irbk · ‎06-09-2023

Logged into my ASA this AM and I'm seeing a ton of "authentication rejected" warnings coming across from 3 different IP's. Seems like someone trying to brute force SSLVPN. I want to block these IP's from even being able to connect to my ASA (which is a 5525 if it makes any difference). It doesn't seem like there is a straightforward way to block them because the VPN terminates on the ASA itself. What's the best way to block this attack while still allowing legitimate SSLVPN connections?

Thanks

Rob Ingram · ‎06-09-2023

@irbk actually for management (control plane) ACLs, which control to-the-box traffic, there is no implicit deny at the end of a set of management rules for an interface. Instead, any connection that does not match a management access rule is then evaluated by regular access control rules.

...but you could define create a permit any if you wish.

MHM Cisco World · ‎06-09-2023

Sorry @Rob Ingram already answer you.

Thanks

MHM

irbk · ‎09-08-2023

@Rob Ingram or @MHM Cisco World

I've been able to do some Lab work in EVE-NG and while it's not the live environment, I added some control-plane rules and managed to not break everything. It worked as you explained it would. What I wanted to do was create a "black list" that contained all the IP's that hit my ASA with obviously fake creds. The black list would be dropped by a control-plane rule. I'd check out where these black list IPs were and block the entire subnet of that IP. I'd also create a "white list" of all the IP's that should be hitting the ASA, put the white list rule first, and that way I could allow an individual IP in the white list to connect even if it was part of a black listed IP subnet. Info sec disagreed with my approach and wanted to setup a default deny instead. Basically if the IP's weren't on the white list, then they didn't connect. It seemed to work correctly in the Lab so I said I'd go for it. Then I went to production and ran across a snag, what I tried was this

access-list outside_access_in_1 extended permit ip object-group ToASAWhitelist any
access-list outside_access_in_1 extended deny ip any any
access-group outside_access_in_1 in interface outside control-plane

This seemed to work at first, but then I got reports that access to our internal websites was failing. I disabled the "deny ip any any" and was able to access our site again. I'm not really sure where I went wrong? I ended up going with my OG idea

access-list outside_access_in_1 extended permit ip object-group ToASAWhitelist any
access-list outside_access_in_1 extended deny ip object-group BlackListedIPs any
access-group outside_access_in_1 in interface outside control-plane

It seems to work but it's not the "default deny" that info sec wanted. I'm not sure where I went wrong? Access to an internal website should be traffic through the ASA and not to the ASA so a control-plane rule shouldn't have affected it, right? Ideas as to where I went wrong?