It’s been an eventful 12 months. With people working from home, there’s been an over 40% surge in machines accessible from the internet running RDP, with RDP attacks up over 400%.¹ This site even has instructions for how to create more than one RDP instance on the same Windows 10 machine.² There are also  these instructions for Windows 2016, that create a larger attack surface that by allowing multiple RDP connections into the same endpoint.³ Lots of companies enable access to critical systems via web portals with logins requiring you pass identity authentication, but SolarWinds SUPERNOVA and Microsoft Exchange ProxyLogon showed how quickly a vulnerability compromises that security. 

But are hackers really scanning the internet, looking for places to attack? Have you wondered how often an average IP address gets scanned and then attacked? I decided to find the truth in the humorous movie quote, “If you build it, he will come” by setting up a basic honeypot with a boring name in an out-of-the-way web hosting center. This, I thought, might answer the question of whether attacks are focused on the big IaaS/PaaS providers, or whether an SMB (that I’d be mimicking) might be found, scanned, and then attacked—and how quickly.

What is a honeypot, you may ask? The term comes from the world of espionage, wherein spies used romance as a way to steal secrets, which was called setting a ‘honey trap’ or ‘honeypot’. The cyber version works in a similar way – creating a sacrificial computer system that is designed to sit on the internet and look innocent and unprotected, mimicking a target for hackers. It uses their attacks to gain information about the tactics, techniques, and procedures (TTPs) used by malicious actors.

The Experiment- Setting up the honeypot trap

Here are the four simple steps I used to mimic an SMB on a budget.

1. Signed up for an account with a cloud provider that isn’t one of the well-known three AWS, Azure, GCP.
2. Spun up a Linux VM and deployed a multi-spectrum honeypot.
3. Attached a public IP to this VM.
4. Monitored the logs.

Why An Account on a Smaller Cloud Provider?

For this test, why did I not want to sign up with the top three cloud providers? I suspect their public CIDR blocks are perhaps too well known and top of the list for botnet scanning. I know people are constantly looking for insecure AWS configurations, S3 buckets with clear text passwords, and, likewise, Azure blobs for configuration errors that are easy to hack.

Deploying the Honeypot

While you could run various opensource honeypots a la carte, there is no substitute for a full spectrum package like T-Pot. It containerizes 19 honeypot projects, each specializing in a particular service, that has them working together like a complex organism. The included ELK Stack was the cherry on top to present all collected data in a beautiful dashboard. Data is broken down in multiple ways to help you visualize patterns quickly from most popular ports probed by origin country to Username/Password combos attempted most often. Every organization should have at least one T-Pot running. I can’t recommend this Github project enough.

I was expecting plenty of scanning—everyone gets scanned, all the time. If you have no services open and you are only listening to the traffic, you have little to worry about. Being port scanned, while mildly annoying from generating extra logs on your firewall, does no actual damage. At high volumes, the constant scanning could cause your threat hunting team to miss an actual attack commencement amongst the noise, but that’s a topic for another post.

I thought about spinning up a regular server with WWW/RDP/SSH/VPN services to mimic a real-world machine in the wild. However, the logging facilities are geared towards the day-to-day operations and not optimized for detecting port scans and interactive hacking attempts.

Attaching the Public IP

I purposely did not advertise my IP to the hackers with an exciting DNS record like:

• portal.acme.com
• webmail.acme.com
• ssh1.acme.com
• F5APM.acme.com
• Solarwinds.acme.com

Monitoring the Logs

I bet you have a number in mind for how long it took for crawlers and botnets to find my anonymous IP and start scanning it. I wondered too—would it take them an hour? 1 day? 1 week?  
How about 30 seconds? Yes, within 30 seconds the scans started showing up. Within 60 seconds, I had my first login to Cowrie (SSH honeypot service). And within 3 minutes, the first exploits were being uploaded and captured by Dionaea, the malware and exploit capture honeypot. (All this visibility was achieved by running T-Pot, which will open your eyes quickly to the unseen internet.)

I let the experiment run for only two weeks, and here are my results:

Adding up the stats from all 19 honeypots, I was hit by roughly 2 million attacks against my single public IP. That’s not scans—that’s active toolkits and scans and attempts to compromise through my (fake) available services.

Doesn’t VPN or VDI Technology Make You Safer?

Yes, I introduced an attack surface to the world that looked ripe for the plucking. But this is no different than every enterprise out there who has needed to host publicly facing Web/SSH/RDP/VPN services for their employees to access internal tools they need to do their work. Working from home was not merely an option due to Covid, it was a requirement for most jobs requiring a computer.
Many organizations are attempting to minimize their IP attack surface by hiding their internal services behind the VPN Concentrator or a Secured Portal like F5’s APM. But as illustrated by F5’s recent announcement of critical vulnerability CVE-2021-22986 that allows Remote Command Execution, by just having the F5 BIG-IP exposed and listening on the internet introduces a lot of risk. And attacks against VPNs themselves are rising; Citrix and Fortinet have both had their VPN modules hacked. Virtual Desktop Interfaces (VDIs) are under siege as well.

What About Patching management?

As all long time Microsoft administrators know, patch Tuesday brings a bounty of bug announcements with their fixes from Microsoft. Exploit Wednesday quickly follows as bad actors waste no time in modifying their weapons with the newfound knowledge. Unfortunately, this is often followed by ‘Uninstall Thursday’ as patches, not just from Microsoft, have resulted in introducing other critical issues to the patched system. 

When you’re patching a single node, the risks are fairly low. However, if you’re patching a VPN gateway or F5 APM that all your employees depend on daily, the risks of patching are substantially higher. As one VPN vendor support engineer once told me, “We urge you to apply the patch to your VPN ASAP, but there is a 40-50% chance you might, just might, brick the box. So be at a location where you can physically reboot the box and have access to lights out management to undo the patch.”

Conclusion

You can’t leave your network open, but you can’t always patch reliably; what should a responsible CISO to do? There is a better choice in a Zero Trust Network Access model. A SaaS ZTNA solution makes your old VPN attack surface disappear. Hackers can’t attack what they can’t see. The Axis Security Application Access Cloud provides complete ZTNA protection using a SASE overlay approach, so no matter where the applications live or where the users are logging in from, you get end-to-end protection from device to network to app. It even includes features like adaptive access controls, user monitoring for dangerous activity, and the ability to revoke access and end sessions if threats are identified.

¹ RDP attacks up over 400%: https://www.zdnet.com/article/ten-disturbing-coronavirus-related-cybercrime-statistics-to-keep-you-awake-tonight/

² Increase in RDP connections: https://www.thewindowsclub.com/increase-the-number-of-remote-desktop-connections-in-windows-10

³ Enable concurrent RDP sessions: https://social.technet.microsoft.com/Forums/en-US/c52b6da7-cdf2-4e1f-95d1-6471c6f2f6b0/easiest-way-to-enable-more-than-2-concurrent-rdp-sessions-on-windows-server-2016?forum=winserverTS

The post How do Hackers Hack – An Experiment in Open Portal Attacks appeared first on Axis Security.

You know where it is on Friday night, with your apps and data on your servers, not cruising the internet or making out on someone’s BYOD. It seems safe since it forces web access through the ‘house’ security stack and requires an ID check at the front door. It can be exclusively available  only to users on your network via VPN, SD-WAN, or local network connection.  

A VDI is nice to the old folks – offering legacy app support for older operating systems that you keep getting told “can’t upgrade – it’s too expensive” (but you still have to secure it.) VDI looks like a cheaper “per date” expense for those looking to spend less on laptops. VDI also looks like a convenient way to date partners and contractors with laptops you don’t manage. But in the big picture, costs are not cheap.

Comparing VDIs with Zero Trust Network Access solutions

So let’s compare typical remote access scenarios (including VDI) with Zero Trust Network Access (such as with Axis Security), when you’re looking for a fulfilling secure access relationship that doesn’t empty your wallet.

1. Using a VDI solution for remote application access can cost $1,200 per person per year. This cost varies depending on if you use a VPN, if you still need that WAN, or if you offer web access with a gateway. And remember, if you use a portal to the web, you need your full perimeter security stack to protect your organization. 
2. Using company-owned laptops with agents, VPN, and a WAN for remote access can cost $1k per laptop. This option offers the least visibility, control, and certainly isn’t zero trust.
3. If you skip VDI and go for something like AWS AppStream to remotely access applications, you might spend $500 per user/year. This assumes AppStream even covers your use cases.
4. Alternatively Zero Trust Network Access (ZTNA) such as the Axis Security Application Access Cloud costs under $150/user/year. Plus you get better visibility, granular control, and end-to-end zero trust connectivity with security for your apps. That’s a much more affordable and secure long-term relationship.

VDI can be “high maintenance”, requiring a lot of setup and accessories when, in the end, all most IT architects want it for is secure access. Also, VDI doesn’t give you zero trust. There’s a lot more to a Zero Trust architecture model than what you get from standard VDI access – which doesn’t answer more than one use case in a good Secure Access Service Edge (SASE) solution.

The best secure access solution for remote access

Axis Security App Access Cloud is a comforting voice of reason all the time, providing continuous authorization, and monitoring of any user accessing any app in any location. Beyond that initial knock on the door and the obligatory authentication before letting the kids out on their date, Axis Security monitors and governs the entire access session like a high-class chaperon. The App Access Cloud looks out for the youngsters by tracking activity and providing application behavior during each session to make sure that no one is behaving oddly or aggressively in a way that’s out of character.  And if they do, it cuts them off.

And lest we drift into creepy Big Brother territory, that just means Axis monitors each user session in context based on adaptive policies which can change as the risk changes. This includes the ability to revoke or change access permissions if the session runs past the end of business hours. It also includes context-based limitations on copy and paste, print, or downloads based on attributes such as the user device — checking device security posture and hygiene – that’s a touch of data loss/leak prevention.

VDI doesn’t walk you home, although it may integrate with your directory or IdP there’s no end-to-end zero trust connectivity.  VDI’s rely on public internet-facing portals or VPNs for connectivity, with weak encryption and IP or DNS Leaks. These have been specifically targeted with a year+ of Remote employees. (Pondering the NordVPN hack, the Cisco VPN Zero-Day, Pulse Connect Secure, and all those RCE attacks on web facing applications.)

And if things ever go really wrong, the Axis Security App Access Cloud is there for you when your security team needs a step-by-step log of activity for incident investigations – or hey, for future capacity planning in the event that the relationship brings more kids into the picture later on.

The post What to Consider Before Using VDIs for Secure Access appeared first on Axis Security.

The Problem

Modern Requirements

Organizations need a better way to securely connect users to apps and resources. This is no small task for an enterprise that often has more than 250 different company sanctioned applications in regular use. It is common for a modern enterprise to need secure user access for resources across on-premises data centers, private cloud, and public cloud including access for:

• Email, messaging, file transfer, web apps
• Thick client apps
• VOIP, video, peer-to-peer apps
• Remote desktops
• Databases
• Admin logins
• Developer resources
• Public SaaS & IaaS

A typical enterprise also has to provide secure access to different types of users and a range of devices, including:

• Employees with company laptops
• Employees working from their own devices (BYOD)
• Supply chain vendors and partners with 3rd party owned devices
• Contractors and consultants who may or may not have company issued devices
• Employees of acquired companies and subsidiaries
• Temporary users with their own devices
• Development teams
• Privileged users and administrators

With so many different types of applications, devices, and users that need secure access, organizations are hard pressed to find a simple way to solve for all their use cases. And remember, they still need to secure the enterprise against attacks. As a result, many companies have resorted to using multiple solutions, ending up with a complicated and fractured approach spread across multiple teams — IT Security, Networking, Infrastructure, Identity, and Cloud.

Old Methods

The VPN

The VPN is the most common default method for granting secure access to applications and resources. This is too bad. It is decades old technology. No one likes the VPN. Let me count the ways:

1. Users find it inconvenient to navigate and it is especially bad for organizations with lots of acquisitions as you can only be on one VPN at a time.
2. VPNs are expensive to scale and complicated to deploy, a problem many companies dealt with this year when their VPN’s overloaded with a suddenly all remote workforce.
3. VPNs are very inefficient for cloud. No one likes the idea of tunneling remote traffic back to the enterprise network and then back out to the cloud. The alternative is to use split tunneling which is problematic for security.
4. And speaking of security, VPNs overall are fundamentally not secure enough since they tunnel users directly into the open internal network of the company where a malicious or compromised user can wreak havoc on vulnerable applications and gain access to precious data.
5. VPNs also require agents on the endpoint, except sometimes for web apps, but not every use case is a web app — making it very hard to solve for BYOD and 3rd party owned devices.

What about VDI?

Virtual Desktop Infrastructure is one of the work-arounds for secure access use cases that can’t be solved with a VPN. Specifically all those use cases with users on unmanaged devices who need to access resources and applications that are not web apps. Secure access is not the only reason to use VDI but it is increasingly common for organizations to turn to VDI for what should be a simple remote access requirement.

VDI is problematic, too. Let me count the ways:

1. Users don’t love it because it can tax their productivity with painful, painful latency. The lag time for the user trying to accomplish something on a virtual desktop can be maddening.
2. VDI is expensive and complicated. In addition to the virtual desktop infrastructure with servers, storage, etc, VDI still requires a network gateway to enable remote users to access the virtual desktop where the applications and resources are located. So you have to buy and manage infrastructure and network gateways.
3. And that virtual desktop, where the user ends up, is inside the perimeter sitting in the data center or in the corporate cloud. Also you may not be able to protect those virtual desktops with EDR because auto updates can cause the whole virtualized system to seize up and non-persistent virtual environments may not be around long enough for EDR to work at all. Once again you have a security issue with users getting very close to critical and potentially vulnerable assets.

And then there’s CASB, Web Gateways, and Public Cloud

Neither VPNs nor VDI are friendly solutions for public cloud. So, many organizations add even more secure access solutions into the mix. They turn to inline Cloud Access Security Broker (CASB) or Secure Web Gateway (SWG) capabilities to control and monitor use of public cloud and web apps. They may also try to use native capabilities in individual cloud apps and services. This adds even more complexity to the secure access mix because these solutions are only for public web and cloud apps and services. They come with their own policies, management, visibility and integrations.

It’s all too much

It is madness that the one simple business requirement for remote secure access has become such a quagmire of complexity and cost. VPNs, network gateways, VDI, CASB, Secure Web Gateway, IaaS, and SaaS are often managed by different people or even completely separate departments. Each system has its own policies, visibility, integrations, and deployments.

The Solution

There’s no denying that organizations need a solution that is cloud friendly but also good for both cloud and on-prem applications, and can also cover users no matter where they are working from. A solution that is agentless most of the time (not just for web apps) makes it much easier to deliver secure access to users on devices not managed by the company. A solution that supports secure access for the full range of applications and use cases. This includes users with thick client apps or using peer-to-peer apps, VOIP, and video. And this solution needs to meet modern security standards so it should be a zero trust approach to protect vulnerable corporate resources.

This may sound too good to be true, but it shouldn’t be.

One Secure Access Solution for All

What if there was a solution that supported all these enterprise use cases with the myriad of different applications, users, and devices? What if you could deliver secure access with a single fast-to-deploy cloud service that is agentless first and doesn’t require you change your network? What if you had one central place for policies; consistent visibility across all users and apps; one place for integrations with your identity, endpoint, SIEM, and other security systems; and one solution that easily scales as your access needs change?

Such a solution now exists. With Axis Security Application Access Cloud’s recent expansion of capabilities, organizations have a solution that scales with them as they grow, providing more agentless options, and supporting more apps and use cases than any other secure access solution. With Application Access Cloud, all of the secure access use cases that once required the complexity of multiple solutions, can all be handled one fast-to-deploy, easy-to-use, zero trust solution. For more information on what Application Access Cloud can now do for you, check out our December 8th announcement.

The post Secure Access Challenges for the Modern Enterprise appeared first on Axis Security.