Sonicwall NSA 250m - how to block attempts to connect to L2TP VPN from intruders

The Sonicwall OS is 5.x. This is just the base router, no extra licenses for IPS, malware etc... I recently setup L2TP VPN for a couple users - using long and complex Pre-shared secret and each have a very long and complex password... I have been blocking obvious attempts from just IP addresses trying to access a webcam port using the info I found on how to do that - but blocking an IP address from WAN  - doesn't seem to affect efforts of a couple outsiders trying to access via L2TP - I see the failed messages from the different stages... but they keep trying - and added their IPs to my 'Blocked IPs' address object group has no effect.
I want to be able to deny them access to even try to authenticate and get them out of the logs - like blocking IP addresses.
Anyone savvy on the SonicWALL as to how to prevent attempted L2TP connections from undesired sources? Is there a way to create access rules to block from L2TP to ANY or LAN, we have the network on the X0 interface.
My understanding is there is a VPN access list on the SonicWALL - but it does not apply to L2TP.
Thank you!
LVL 1
Mark Lytleowner operatorAsked:
Who is Participating?
 
Blue Street TechConnect With a Mentor Last KnightCommented:
Hi alpenit,

You are going about it the wrong way. Allow secure functions to do there job - blocking IP addresses will never prevent this attack from occurring because an attacker could infiltrate from a multitude of real and fake IP addresses in which case you will always be behind the game trying to catch up, meanwhile, they are hitting it in real-time and possible already gotten in while you are sleeping (you can't monitor it forever!). You should scrap L2TP VPN as it in itself is insecure & vulnerable to attack - password length/complexity has nothing to do with its insecurity. Instead for better security and results, use GVC (Global VPN Client) or SSL-VPN and both come auto-licensed in your device (System > Licenses).

Is there a way to create access rules to block from L2TP to ANY or LAN, we have the network on the X0 interface.
The only way to create an Access Rule like that is if your users have Static Public IPs and they only login from those IPs. Again, not a good model for remote access. You would be better served to install GVC to everyone and then lock down access (since the security mechanism is stable and secure) to your users pre-defined in the SonicWALL Users dB.

My understanding is there is a VPN access list on the SonicWALL - but it does not apply to L2TP.
Again, L2TP is worthless and should be abandoned. The authenticated Users are in SonicWALL under the Users > Local Users section in your SonicWALL

Let me know if you need help in setting up either.
0
 
arnoldConnect With a Mentor Commented:
Echo Blue street tech,

How do you define the "intruders"?

You could make the VPN more secure by requiring user login credential to complete the setup

Presumably it is an L2TP over IPSec.
L2tp is unencrypted and needs an IPSec tunnel which is encrypted.
0
 
Mark Lytleowner operatorAuthor Commented:
Blue Street Tech,
Thank you for the input. I have been using the L2TP solution - yes over IPsec... some years ago it was an obvious move - to have a more secure VPN then the old PPTP... I have this setup on other SonicWALL routers where they have the added software layers of protection - the subscribed Intrusion protection etc...  and I understand the wackamole syndrome with IP addresses... I get it. I don't seem to have that problem - just occasionally on this base router.... Anyway,  out of interest I will research the L2TP faults... and I think I will take your suggestion and go with the SSL variety... I have wanted to do that anyway.
Arnold, for lack of better term at the moment - intruders means those making efforts to connect that are foreign. We have the preshared key, we use a username and password - which in the past I have also made complex for both, so as Blue Street Tech has advised - I will look at the security issues with the L2TP, I know there are choices to be made in securing it.  
Thank you both!
 I will let you know how it goes - going for the SSL.... and maybe the GVC, but I had a lot of trouble over ten years ago with GVC - and that sticks with me - I am sure improvements have been made... we'll see.
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
arnoldConnect With a Mentor Commented:
you could secure your existing setup by looking into whether a certificate based ipsec tunnel setup this will provide you with a more granular control, i/e. you expire the certificate and that client stops being able to connect.

The issue is that you have to look at the available options on the devices you have.

do not know whether certificate based authentication for ipsec is an option for the sonicwall that you have.
0
 
Mark Lytleowner operatorAuthor Commented:
Thanks for advice - yes I believe I could setup certificate based IPsec tunnel in L2TP but I have SSL VPN working now using NetExtender, NO Radius or Virtual whatever...   It seems to me the setup of the SSL Server and the certificate choice which there is only one 'self signed certificate' as a choice, which I believe is by default available on the NSA, is also not so secure in that anybody using any username and password will get prompted to accept or trust that cert.

So shouldn't that be a concern?

Then its just a matter of them finding a username and password that matches one of the local users configured on the NSA... so its back to just cracking username and password. Am I wrong? Would it make a difference to import a purchased SSL cert and select that in SSL VPN server settings? Or would it too just be offered for trust. I am going to change port 4433 to an unused port and if the only barrier I have against entry to the network is username and password - I will as I did with L2TP use some pretty hard to crack usernames and passwords, then I trust the client when going to access resources on the remote network will be prompted for their Windows credentials... I am wide open to any clarification, suggestions or slaps upside the head...

Thanks Again!
0
 
arnoldConnect With a Mentor Commented:
The certificate I mention deals with a client side certificate that will authenticate the remote client.
I.e. with a pre-share key, the connection will setup for purposes to exchange a pre-shared key. in normal mode, this is encrypted, in aggressive mode, less secure.
The preshare an be shared. the client certificate might be more secure, with you issuing the client side certificate and thus can revoke/cancel the certificate without having to go through a config change of the pre-shared key ......
Self-signed, will generate errors on the client unless and until they add your self certificate as trusted.
There is a free issuer, seen letsencrypt.org mentioned in several comments dealing with certificates, have not used, so can not provide insight from a personal experience.

Changing ports, could run into issues where more and software vendors and potentially isp/companies in an effort to shield their network, limit internal systems to access to "known" ports.
i.e. browsers have the same situation where they alert the user that the destination they are going to is being blocked by the application as the destination port ... the user then has to add an exception to the application.
one would not be able to add an exception to the ISP's firewall ......if a similar block is setup by them.

If you are logging the events of remote access attempts, you could use the log in conjunction with rwhois (linux application) or www.arin.net to track down to whom the IP is allocated and then report the multiple attempts to the abuse contact to whom the IP is allocated. You may have to track down that entity. arin is for North America, APNIC.net for Asia Pacific, RIPE for Europe, LACNIC for Latin America and the Caribbean, etc.  
whois -h whois.arin.net IP_address
then look through the results .....

notifying the Abuse contact with the log entries , not just one, could lead to them suspending that user ......feed ...
0
 
Mark Lytleowner operatorAuthor Commented:
All good info Arnold... I will keep and check it out. I think I will be ok with the NetExtender as I also enabled the OTP - one time password in the local user profiles - where it sends a random password to their email address each time they go to connect. That should discourage anyone that isn't desired.

I hear you on the ports and how ISPs and apps are watching closer activity on uncommon ports... in my case, luckily, I am setting up access for just a couple people, owner and manager... versus a large group.

So I am trusting I will be ok with the built in self-signed cert, and uncommon port and OTP...  all tested.

Thanks to you both for the help!
0
 
arnoldCommented:
oh, two-factor authentication.. like  mechanism. in this case, you may see remote requests make sure the response is the same whether the local user exists or not.
i.e. send me my code, prompt for username: someuser, the response should always be the key has been sent to your email.
If you have, no such user here, this will expose your side to be tested to discover the listed users..........
i.e. send to someuser, no such user,
send to anotheruser, your password has been emailed.....
0
 
Mark Lytleowner operatorAuthor Commented:
I'll watch for that. Each local user has their email address added to their user setup....   Is this something that is true with the SonicWALL? Or are you theorizing this might be a possibility?  I'll have to test that. Thanks!
0
 
arnoldCommented:
Theorizing

If the option exists to generate the same response without regard whether an email was actually sent,
Some similar implementations have, the message an email was sent to your ab.....@.......org email address to assist the user to identify where the code should be looked for,

it seems you found a better alternative than trying to block intruders on an individual case by case basis.
0
 
Mark Lytleowner operatorAuthor Commented:
There is no notification of email sent etc.... user simply goes to connect - gets a very simple box to enter password... nothing else... I will test what happens when wrong or no password is entered and then to proceed with connect.
0
 
Mark Lytleowner operatorAuthor Commented:
And if password is wrong.... it will just state that the password is no good.... nothing else - no matter how many times tried, there should be a way to lock out the one attempting after so many failures....  I think I'm good here...
0
 
arnoldCommented:
What happens if a wrong username provided?
0
 
Mark Lytleowner operatorAuthor Commented:
Again - there are no opportunities to go any further than 'wrong'...  See attached file for pics of the OTP dialog and response to wrong info as well as initial connection via NetExtender if wrong user/pw entered.

What I want to find on this unit is a limit as to attempts like '5' before a lock in enforced - that applies to SSL VPN user login.
Logins-Failed.pdf
0
 
arnoldCommented:
0
 
Blue Street TechLast KnightCommented:
It seems to me the setup of the SSL Server and the certificate choice which there is only one 'self signed certificate' as a choice, which I believe is by default available on the NSA, is also not so secure in that anybody using any username and password will get prompted to accept or trust that cert.

So shouldn't that be a concern?

I missed all the conversation somehow..maybe due to the holiday bustle...IDK. Anyway, I'd like to add that with SSL-VPN it is, always, recommended to use a proper SSL Certificate opposed to self-signed cert. Buy it at GoDaddy or the like and install it on the SonicWALL then select it to be used in the SSL config section.

Then its just a matter of them finding a username and password that matches one of the local users configured on the NSA... so its back to just cracking username and password. Am I wrong? Would it make a difference to import a purchased SSL cert and select that in SSL VPN server settings? Or would it too just be offered for trust. I am going to change port 4433 to an unused port and if the only barrier I have against entry to the network is username and password - I will as I did with L2TP use some pretty hard to crack usernames and passwords, then I trust the client when going to access resources on the remote network will be prompted for their Windows credentials... I am wide open to any clarification, suggestions or slaps upside the head...
Obfuscation is never security so changing ports will do nothing. An adversary will simply scan your network for open/listening ports and discover them all then attempt to exploit vulnerabilities therein. I'd leave it at 4433; it is the default and recommended port to use. With SSL-VPN an adversary would have to known the port and domain name on top of the username/password. If you want to thwart that you can setup RADIUS and tie in authorization and authentication policies so now, as an example, a user would have to belong to a security group within the domain and additionally meet some security requirements before being allowed to authenticate. This could include blocking the user access as in Windows lockout or blocking the connecting IP address, etc. Certification would be on the NPS server so that clients could gain access from their smartphones and laptops (form-factor agnostic)! Cert-based authentication on the client side increases management significantly since smartphone OS's vary and are inconstantly increasing based on mfg; at least from what we have seen in the field.

2FA and UFA are always Best Security Practices!

@arnold has guided you well (as always :) )!
0
 
Mark Lytleowner operatorAuthor Commented:
Thanks BST, you got me started on the SSL VPN, so I went that route... and it does seem to me I would feel more 'secure' is I had a true SSL cert.... so I will look into that. There will be those scanning for a way in - and if setting the port to an uncommon port (and hope the ISP allows uncommon port traffic) makes these people take another step - as little as it is - then so be it. Its not going to be just sitting there on the common port.  This really helps me with the whole SSL VPN idea and I appreciate you both for really guiding me here. This particular setup will not require any mobile device access...  its pretty simple - a nice first time SSL VPN setup to get acquainted. Instead of going the Radius route, I used the OTP choice for users...one time password. And in talking with Arnold - want to see if I can setup a max # of login attempts before logout. It looks pretty unbeatable as each time the user connects the password changes...
I have this working as it is now with OTP option. I will be busy for a few days and then will post the findings as to max # user login attempts lockout...
0
 
Blue Street TechLast KnightCommented:
OK, terrific! Post another question if you need help configuring the cert or with the lockout timers...I'm hear and ready! DM me when you post your question so I'll be sure to see it.

Just to clarify,
...if setting the port to an uncommon port (and hope the ISP allows uncommon port traffic) makes these people take another step - as little as it is - then so be it.
I understand that you want to change the default port but please understand there are no "extra" step, but literally one and only one step...command: scan for ALL open ports.

I'm glad we could help. Thanks for the points and see you next time!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.