Probably stupid question about VPN

[Velvis]

How do you determine what software or hardware is providing the VPN server?

New client with very little documentation.

 

[Slaters Kustum Machines]

How do the users connect to VPN? Do they have a specific software? Do they use the builtin options in Windows? Do they have a business grade router/firewall that you could login to and see what services are provided? You could do the same for the server.

 

[Velvis]

They use the built in options in windows. There is just one login user account but then it goes to each persons Remote Desktop based on ip in their settings.

Remote access and routing is on in the server roles but I don't see any user setup info.

There is a juniper srx 100

 

[Markverhyden]

There are no stupid questions. Only stupid answers.

Adding to what @Slaters Kustum Machines said, you need to do an onsite. One quick thing though is to see what a client is using. Many business grade VPN appliances use their own VPN clients.

 

[Slaters Kustum Machines]

My guess would be the Juniper is doing VPN. But like Mark said you need to go onsite and look through everything to get a handle on what is going on.

 

[Velvis]

What are the pros/cons of using something like the juniper over Server 2016 Remote Desktop?

 

[freedomit]

Check the VPN type, if it’s SSTP it has to be a Microsoft product managing.

 

[Slaters Kustum Machines]

What are the pros/cons of using something like the juniper over Server 2016 Remote Desktop?

I like to have VPN handled at the edge of the network rather than internally. Preference I reckon. There maybe security reasons that someone could better explain.

 

[putz]

How do you determine what software or hardware is providing the VPN server?

New client with very little documentation.

Usually if the edge firewall is terminating the VPN, they would be using a specific client software from the firewall vendor, like Cisco Anyconnect, or Sonicwall NetExtender, Watchguard, etc. If they are using the built in Windows VPN client, then it may be be using a Windows machine.

If the termination is directly on the firewall you would see that setup in the firewall config somewhere... Typically under a VPN section. If the termination is done on a machine behind the firewall you should see some port forwards or NAT polices on the firewall directing traffic on those specific ports to the machine on the local network.

 

[SAFCasper]

Most likely the Juniper. Easiest option is log in and have a look.

If it's not the Juniper then look for any of these port forwards.

TCP 1723
UDP 500
UDP 4500

If they exist the destination IP is likely your VPN server.

 

[YeOldeStonecat]

What are the pros/cons of using something like the juniper over Server 2016 Remote Desktop?

Technically a VPN is something totally different than RDP.
A VPN connects you (or your network) to another network securely from across the internet. So you can access resources on that network...be it RDP to your desktop, or RDP to a terminal server, or...bring up file shares from the server or some lightweight application. Kinda like you're sitting on the local network...just...slower.

Remote Desktop...you connect to a terminal server or a desktop...either directly via port 3389 through the firewall, or...through a more secure method such as TSGateway...or...even more secure..via VPN. Many people are shying away from exposing that port 3389 on the firewall now, gets hacked fairly easily now.

 

[fencepost]

Is it that RDP gets hacked, or is it just that places that leave RDP open are in many cases the same ones that have crappy username and password policies? I'm not aware of any actual cracks against RDP even on older versions, but brute forcing attempts and distributed brute forcing? Yeah, that can easily happen.

Back when we'd allow RDP to be open for customers to remote in I'd check for failed logins and see attempts for a wide range of first names (which didn't match any naming pattern we used). For a while we just set up something to block remote IPs after a certain number of failed connection attempts, but as the frequency of distributed "grinding" went up we moved completely away from that - for a brief time to having it on unusual ports, but ever since Comcast basically abandoned changing IP addresses we generally whitelist home user IPs as appropriate. We also have some folks set up with "port knocking" to open up connections for a limited time (4-12 hours) when there's someone who needs access from an actually dynamic IP.

Edit: clarifying some second paragraph word salad.

 

[YeOldeStonecat]

Is it that RDP gets hacked, or is it just that places that leave RDP open are in many cases the same ones that have crappy username and password policies? I'm not aware of any actual cracks against RDP even on older versions, but brute forcing attempts and distributed brute forcing? Yeah, that can easily happen.

I believe it's a tool that fingerprints RDP listen (thus trying to cloak the port via some obscure port doesn't really work anymore)...and exploits it, I've only seen it happen on older servers....03 and I think 08 non-r2. The server gets ransomed.
One of the other users here, SkyNight, studied it a bit and may chime in.

 

[Markverhyden]

Port scanning, with finger printing, is a mature business so switching to non-standard ports is not a jump in security. The last RDP CVE I heard of was an NSA exploit released by the ShadowBrokers. And that was only for XP and Server 03 and did allow access. I think earlier ones generally focused around DoS. But I agree about the link between leaving 3389 open and weak security in general going hand in hand.

 

[fencepost]

When we did it for a while moving to a non-standard port did cut down hugely on the number of attempts based on what I saw in logs, but it was still too high and didn't last forever. With a high number of attempts what you get is low-speed password guessing, along with a shift from probing from single IPs to probing being done by distributed botnets to avoid being blocked.

"Low and slow" distributed brute-force attacks have been around for a long time.... https://www.immutablesecurity.com/index.php/2009/10/06/low-and-slow-ssh-brute-force-attacks/