Protecting IPSec and Anyconnect via ACL - ASA 5500

Answered Question
Feb 21st, 2010

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.

Correct Answer by Federico Coto F... about 6 years 11 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (2 ratings)
Loading.
Peter Noble Thu, 02/25/2010 - 09:15

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

Correct Answer
Federico Coto F... Thu, 02/25/2010 - 09:25

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.

Peter Noble Thu, 02/25/2010 - 11:50

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.

Actions

This Discussion

Related Content