02-21-2010 03:01 PM - edited 03-11-2019 10:13 AM
I have an ASA (8.2.1) running IPSec and Anyconnect. The other day I noticed someone was trying to brute force the Anyconnect connection.
Doing what felt natural, I tried blocking using my outside ACL. It appears that this ACL protects my internal hosts nicely, but fails to do anything for the services sitting on the firewall itself.
I can use shun, but the address range that the attack comes from are from a range my internal hosts might want to utilize for other reasons.
One could assume my outside_in access-list looks as such:
access-list outside_in line 1 extended deny ip 1.2.3.0 255.255.0.0 any
access-group outside_in in interface outside
I would like a way to deny traffic to my ASA's Anyconnect Service, but I would like the granularity to block just HTTPS.
An edge device beyond the ASA is not available to me, so any solution would have to be based in the ASA.
Thanks in advance.
Solved! Go to Solution.
02-25-2010 09:25 AM
Hi,
The only way to restrict by IP address who can or can't establish a VPN connection to the ASA is with an ACL applied to the outside interface (using the control-plane keywork in the access-group command to apply the ACL to traffic intended to the ASA itself as well as traffic passing through).
The problem with this, is that nobody from the IP address will be able to establish a VPN connection to the ASA.
The other alternative is with an ACS server (assuming you have one), create a filter as to which IP addresses can establish a VPN connection. This option is better in the sense that it allows you to do the restrictions based on VPN profiles.
Federico.
02-25-2010 08:21 AM
Hi,
You can use the vpn-filter under the group-policy for the appropiate VPN group on the ASA to block specific traffic.
Federico.
02-25-2010 09:15 AM
The vpn-filter would allow me to limit what access someone who has authenticated into the system could get to. What I am trying
to do is prevent specific public IP ranges from accessing the Anyconnect Login page, preventing them from attempting to authenticate.
If I have a "hacker" who has successfully broken in due to a brute force attack, I'm already in trouble. I want to mitigate who has the opportunity to brute force the system. I know for a fact that
I'm basically looking for the equivalent functionality for the VPN (IPSec and WebVPN/Anyconnect) system that the ssh command provides in an ASA
ssh 10.0.0.0 255.255.255.0 inside
-Peter
02-25-2010 09:25 AM
Hi,
The only way to restrict by IP address who can or can't establish a VPN connection to the ASA is with an ACL applied to the outside interface (using the control-plane keywork in the access-group command to apply the ACL to traffic intended to the ASA itself as well as traffic passing through).
The problem with this, is that nobody from the IP address will be able to establish a VPN connection to the ASA.
The other alternative is with an ACS server (assuming you have one), create a filter as to which IP addresses can establish a VPN connection. This option is better in the sense that it allows you to do the restrictions based on VPN profiles.
Federico.
02-25-2010 11:50 AM
Thank you, the control-plane keyword performed exactly as needed.
I'm providing my configuration for someone else's benefit
access-list outside-control-plane extended deny https 1.2.3.0 255.255.255.0 any
access-group outside-control-plane in interface outside control-plane
Where I have the any keyword, one could also use the interface outside tag too.
This will prevent someone from accessing the https port of the ASA, effectively keeping them from WebVPNing but has no bearing on the regular outside access-list which permits traffic to my public facing web servers for example.
02-25-2010 11:54 AM
Glad to hear its working ;-)
Federico.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide