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

[irbk]

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

[MHM Cisco World]

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.

[Rob Ingram]

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

[irbk]

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

[Rob Ingram]

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

[irbk]

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?

[MHM Cisco World]

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 

[irbk]

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.

[Rob Ingram]

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

[irbk]

@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

[MHM Cisco World]

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/

[irbk]

Oh sweet!  Thanks @MHM Cisco World 

[irbk]

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

[Rob Ingram]

@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

[irbk]

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?