-The Black Knight, Monty Python, and the Holy Grail
We continue to see attacks from misconfigured VPNs. Today I want to focus on legitimate user's who have VPN access to your networks.
Too often, VPNs expose all of your internal network to an outside endpoint.
Today, I am asking you to audit your VPN users and focus on the following questions:
- Are all the VPN accounts legitimate accounts?
- Do all the VPN accounts have multi-factor authentication?
- Do any of the VPN accounts have more rights inside the network than what is required to perform the task that warrants authorizing VPN access?
- Are all the remote endpoints VPNing into your network endpoints patched, maintained, and monitored by your district?
In addition to the blatant misconfigurations of the VPN itself that I have recently been focusing on, we are uncovering an increasing number of VPNs that expose too much of your network to the outside endpoint.
Here are our significant findings:
- Third-party vendors should only have approved VPN access only to the precise portion of the network that they maintain. Ideally, this network portion should be separate from the entire network.
- If a user is VPNing in to remote into their desktop, they just need their VPN IP address to be allowed to RDP to their desktop IP address. They do not need to see the entire network.
- If a VPN connection comes from an unmanaged machine, you are operationally blind to whether we have exposed our network to an outside threat.
The other day our Managed XDR Service featuring SOC oversight over a client's entire network picked up some unusual Remote Access Tools (RATs) that were VPNed into the network, and actively scanning inside the *ENTIRE* network.
We asked the client about what we saw. They had no idea. That is a "shield's up" moment. We identified the endpoint which was classified as "payroll". More stress. The district investigation uncovered that its "payroll" was contracted to a third-party provider. The district did not manage the machine—even more stress. The third-party provider was contacted and did not know about the remote access tools installed on their system. Now, it was getting scary.
Further investigation by the third-party provider uncovered that the mystery tools were legacy tools that the vendor formerly used. The mystery was solved. It wasn't an attack; it was just a vendor with lax endpoint management.
However, it was then discovered that this outside vendor only needed access to the payroll system via an approved IP address. This vendor had "full" access to the entire district network.
The story ends with the vendor cleaning up their old tools. The district was re-assigning the VPN IP address to an approved vendor VLAN. An ACL was implemented to allow this vendor to access a single outside internet address to run payroll.
None of this would have been discovered or known without CSI's Managed XDR Service with full Security Operations Center (SOC) oversight. The SOC team found what the rest of us would have never found on our own.
We all lucked out that the unmanaged machine was just noisy and not malicious.
Having gone through this event and subsequent investigation, here are my recommendations to you:
- Audit all your VPN users
- Audit their roles and access rights
- Adjust your ACLs only to give out exactly what they need to do their job
- Ensure vendors are only on their own VLAN unless there is a profound functionality reason that warrants broader access.
- Implement a SOC service that oversees your entire network and can see events that humans can't see with their eyes alone.
I fervently believe that the single most important addition to your overall network security strategy is adding a SOC service to oversee the network. Nothing is more important than having 24x7x365 visibility on your network.
Call us if you'd like to discuss what a SOC might look like in your network or need help resolving your VPN situation. We are happy to help.
-Scott Quimby, CISSP
You must be logged in to post a comment.