topic Re: Block specific IP's from attempting to establish an SSLVPN connect in Network Security

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

irbk — Fri, 09 Jun 2023 13:01:33 GMT

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

Re: Block specific IP's from attempting to establish an SSLVPN connect

MHM Cisco World — Fri, 09 Jun 2023 13:03:36 GMT

If these user use same public ip' then use acl control plane apply to outside with IN direction

This will prevent these user to try sslvpn to asa.

Re: Block specific IP's from attempting to establish an SSLVPN connect

Rob Ingram — Fri, 09 Jun 2023 13:04:45 GMT

@irbk from the ASA itself you can use a control-plane ACL to restrict those IP addresses and permit other VPN connections..

Or block those IP addresses on an ACL on the upstream ISP router.

Re: Block specific IP's from attempting to establish an SSLVPN connect

irbk — Fri, 09 Jun 2023 13:07:24 GMT

I'm a bit hesitant to do that as I don't want to accidently block all incoming traffic. My ASA is in a remote datacenter so if I flub up a command, I can't lay hands on it to fix it. 2 questions, is it possible to do in the ASDM? What might the rule look like if I had an object group called "BlackListedIPs"?

Re: Block specific IP's from attempting to establish an SSLVPN connect

Rob Ingram — Fri, 09 Jun 2023 13:13:44 GMT

@irbk connections "through" the ASA do not apply as they are controlled via a normal interface ACL and SSH/ASDM connections "to" the box are controlled separately to an ACL applied to an interface.

Here is an example from the CLI.

Notice the access-group has control-plane appended to the end to signify it's used by the control plane.

Re: Block specific IP's from attempting to establish an SSLVPN connect

irbk — Fri, 09 Jun 2023 13:15:31 GMT

How about something like

shun 179.60.149.83

That will block the IP for some period of time with out the chance of breaking anything else?

Re: Block specific IP's from attempting to establish an SSLVPN connect

MHM Cisco World — Fri, 09 Jun 2023 13:19:33 GMT

To be more tune your access list use deny (ip of host) any tcp port 443 in acl and permit any any

Then apply it to outside directions IN with keyword control plane

Re: Block specific IP's from attempting to establish an SSLVPN connect

irbk — Fri, 09 Jun 2023 13:38:55 GMT

I was able to block the connections (there were only 4 IP's banging the ASA then another 2 once I blocked the original 4) using SHUN which is all I needed to do. I'm sorry but the control-plane access list just scares me.

Re: Block specific IP's from attempting to establish an SSLVPN connect

Rob Ingram — Fri, 09 Jun 2023 13:42:04 GMT

@irbk no worries, shun will work. Note that the shun configuration is not displayed in the ASA configuration.

FYI, you'd not lock yourself out via SSH/ASDM as these are control independantly from an normal interface ACL and the control plane ACL.

Re: Block specific IP's from attempting to establish an SSLVPN connect

irbk — Fri, 09 Jun 2023 13:48:13 GMT

@Rob Ingram yeah, thanks. I'm aware that SHUN isn't displayed in the ASDM and also it doesn't survive a router reboot I believe? I'm not super sure if "shun 179.60.149.83" will only block it for 15 min or until I either remove it or reboot the ASA. I think if you use the "threat detection" within the ASA itself, by default, it only SHUNs for like 15 min. I'm not sure if I put in a manual command if that will stay persistent. It's been 20ish minutes now and I'm not seeing the connection attempts come back, so either the SHUN lasts longer than 15 min or the bot/script kiddie moved onto a different IP

Re: Block specific IP's from attempting to establish an SSLVPN connect

irbk — Fri, 09 Jun 2023 13:56:47 GMT

Out of curiosity, is there a place within the ASDM to do the control-plane blocking or is that CLI only?

Re: Block specific IP's from attempting to establish an SSLVPN connect

MHM Cisco World — Fri, 09 Jun 2023 13:59:36 GMT

I'm not super sure if "shun 179.60.149.83" will only block it for 15 min or until I either remove it or reboot the ASA
you need manual no shun to remove it, there no timeout for this command
https://www.networkstraining.com/block-attacks-with-a-cisco-asa-firewall-and-ids-using-the-shun-command/

Re: Block specific IP's from attempting to establish an SSLVPN connect

irbk — Fri, 09 Jun 2023 14:07:29 GMT

Oh sweet! Thanks @MHM Cisco World

Re: Block specific IP's from attempting to establish an SSLVPN connect

Rob Ingram — Fri, 09 Jun 2023 14:13:14 GMT

@irbk yes you can configure control plane ACLs in ASDM.

Step 1

Choose Configuration > Device Management > Management Access > Management Access Rules.

The rules are organized by interface. Each group is equivalent to the extended ACL that is created and assigned to the interface as a control plane ACL. These ACLs also appear on the Access Rules and ACL Manager pages.

https://www.cisco.com/c/en/us/td/docs/security/asa/asa919/asdm719/firewall/asdm-719-firewall-config/access-rules.html?bookSearch=true

Re: Block specific IP's from attempting to establish an SSLVPN connect

MHM Cisco World — Fri, 09 Jun 2023 14:21:10 GMT

Sorry @Rob Ingram already answer you.

Thanks

MHM

Re: Block specific IP's from attempting to establish an SSLVPN connect

irbk — Fri, 09 Jun 2023 14:21:57 GMT

Ok, I *thought* that might be it. Right now, I have no rules in there. If I were to create 1 rule to block traffic, would I also have to create a 2nd "any/any" rule to allow all the other traffic? I'm assuming there is the usual "deny any" that would take effect if I put a rule in here?

Re: Block specific IP's from attempting to establish an SSLVPN connect

Rob Ingram — Fri, 09 Jun 2023 14:31:40 GMT

@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.

Re: Block specific IP's from attempting to establish an SSLVPN connect

irbk — Fri, 08 Sep 2023 12:34:23 GMT

@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?