Any way to setup WebAdmin to be accessible from the WAN side, without a VPN, yet, without having to worry about brute force attacks?

After searching online awhile, I discovered no-ip still allows for a free version of their dynamic DNS, as long as a person renews their dynamic DNS registration every 30 days. In the event that I forget to reregister my username, it would mean only 1 external IP address and/or no-ip username could access the UTM remotely.

As long as the UTM automatically blocks the IP address of failed login attempts for a period of time, I think it would have to be an incredibly small and remote possibility that some would be able to hijack the DNS settings and remotely gain access to the UTM.

I love the idea of the 2-factor authentication, but I do not think I am ready to go there yet. Maybe when I have more free time to play with the system.

Thanks for your help everyone!

You will be pleasantly surprised by how easy OTP is to use.

My two cents on dynamic DNS

For my wife's business, we have a dynamic IP, but we don't use Dynamic DNS.   We just use HOSTS file entries on our home PCs to simplify use of the VPN client.   The IP address doesn't change very often, so it works pretty well.   If others need to find this IP, it should be a static IP registered with a respected DNS.   If only you or a small group of associates need to access this IP, then why add the risk of publicizing on a dynamic DNS service?  

I have seen the research which says that bad guys like Dynamic DNS, which is no surprise.   If it was possible, my primary business UTM would block any address associated with a dynamic DNS.   But right now, it is not feasible.

Have you got any instructions on how to set this up? I didn't know you could do it for the web admin login?

You missed the significance of some of my other comments.

I do NOT recommend putting OTP on the Admin account.   If you do, (a) you are the only one who can use the Admin account, and (b) if your cell phone gets damaged or replaced, you will quite possibly be locked out of the Admin account.

I do NOT recommend relying on lockout as an adequate defense against password guessing attacks.   I was in an IT Training course where an instructor told this story:   Another instructor had  bragged that he was not worried about password-guessing attacks.   So my instructor wrote a slow-rate password-guessing program that was configured to avoid the lockout defense.   It took about 6 months, but he had recently been able to tell his coworker his password.   This story is probably the best justification for policies that require regular password changes.

I have unhappy evidence, both from the media and from personal experience, that the bad guys are doing password-guessing on a widespread basis.  In priority order:   (a) if you have a Name Registration (who doesn't), make sure its password is VERY complex and uses 2-factor authentication if available.    If someone can take control of your name Registration, you have lost your organization's digital identity.   According to media reports, one bank had this happen to them, but was able to get it back after 6 painful hours.  (b) Have VERY complex password on any web hosting services.   If the password-guessers can get into your web presence, they can,. and will, add hidden malware links to your site.  (c) Verify that your web hosting service has security scanning configured on your website, or purchase a service to do so.  This is to ensure that if you do get hacked, you find out before the reputation services find out and blacklist you.  Finally (c) Protect your perimeter devices (including UTM or XG) from external compromise.

As a general principle, admin functions should be performed from an internal-network context, such as VPN or HTML5 VPRN RDP, as indicated in my previous note.

In UTM, you can create additional admin accounts, either locally or from a back-end authentication service, by putting the account or group into the local Admins group.   This is probably a good idea, so that if the Admin password is forgotten or even temporarily locked out, someone can still get into the admin role.

However, it seems that the better practice is to have one account configured for remote access, which is unprivileged.   Then after connecting with VPN or HTML5 VPN RDP, that session can be used to log into the UTM Admin portal with an admin-enabled account.   These need not be the same account, which means that to compromise your system, the bad guys must first hack your remote access login.  This is bad, but should not give them admin rights on your network.   Then as a separate hack, they have to guess a privileged password, either to UTM, Active Directory, or some other context.

Digression on cell-phone replacement:

1) It is possible to configure OTP on more than one device, such as both an IPad and a cell phone.   Then, one of them can break and the other can still get you in.

2) If your cell phone backup solution is able to preserve both application list and application settings, you may be able to restore your settings  to your new phone without needing synchronize the phone with UTM's QR code.   Obviously, this needs to be tested with your specific backup solution.

3) As long as someone can get into the Admin context, the administrator can clear the OTP information so that the user can log in without OTP for the purpose of re-establishing the OTP synchronization.

You missed the significance of some of my other comments.

I do NOT recommend putting OTP on the Admin account.   If you do, (a) you are the only one who can use the Admin account, and (b) if your cell phone gets damaged or replaced, you will quite possibly be locked out of the Admin account.

I do NOT recommend relying on lockout as an adequate defense against password guessing attacks.   I was in an IT Training course where an instructor told this story:   Another instructor had  bragged that he was not worried about password-guessing attacks.   So my instructor wrote a slow-rate password-guessing program that was configured to avoid the lockout defense.   It took about 6 months, but he had recently been able to tell his coworker his password.   This story is probably the best justification for policies that require regular password changes.

I have unhappy evidence, both from the media and from personal experience, that the bad guys are doing password-guessing on a widespread basis.  In priority order:   (a) if you have a Name Registration (who doesn't), make sure its password is VERY complex and uses 2-factor authentication if available.    If someone can take control of your name Registration, you have lost your organization's digital identity.   According to media reports, one bank had this happen to them, but was able to get it back after 6 painful hours.  (b) Have VERY complex password on any web hosting services.   If the password-guessers can get into your web presence, they can,. and will, add hidden malware links to your site.  (c) Verify that your web hosting service has security scanning configured on your website, or purchase a service to do so.  This is to ensure that if you do get hacked, you find out before the reputation services find out and blacklist you.  Finally (c) Protect your perimeter devices (including UTM or XG) from external compromise.

As a general principle, admin functions should be performed from an internal-network context, such as VPN or HTML5 VPRN RDP, as indicated in my previous note.

In UTM, you can create additional admin accounts, either locally or from a back-end authentication service, by putting the account or group into the local Admins group.   This is probably a good idea, so that if the Admin password is forgotten or even temporarily locked out, someone can still get into the admin role.

However, it seems that the better practice is to have one account configured for remote access, which is unprivileged.   Then after connecting with VPN or HTML5 VPN RDP, that session can be used to log into the UTM Admin portal with an admin-enabled account.   These need not be the same account, which means that to compromise your system, the bad guys must first hack your remote access login.  This is bad, but should not give them admin rights on your network.   Then as a separate hack, they have to guess a privileged password, either to UTM, Active Directory, or some other context.

Digression on cell-phone replacement:

1) It is possible to configure OTP on more than one device, such as both an IPad and a cell phone.   Then, one of them can break and the other can still get you in.

2) If your cell phone backup solution is able to preserve both application list and application settings, you may be able to restore your settings  to your new phone without needing synchronize the phone with UTM's QR code.   Obviously, this needs to be tested with your specific backup solution.

3) As long as someone can get into the Admin context, the administrator can clear the OTP information so that the user can log in without OTP for the purpose of re-establishing the OTP synchronization.

Sorry, I may not have done a good job of explaining this before. In my setup, I have my UTM setup in Bridge Interface + Full Transparent Mode. This means the UTM does not give out IP addresses, as it does not function as a DHCP server. I was under the impression that I could not setup a VPN on the UTM in Bridge Interface + Full Transparent Mode. Maybe this is possible, but I will need to research that further, as Bridge Interface + Full Transparent Mode is atypical of the majority of UTM setups.

I agree that 2-factor authorization is a good idea. Who knows, if John Podesta had used 2-factor authentication, we might have a different president right now. Not trying to get into politics, but I agree, that it is a good idea in general.

Lastly, and this is the most important factor for me currently is finding the time to properly become familiarize myself with 2-factor authentication on the Sophos UTM. I am familiar with Dynamic IP address and have no issue with setting that up. I have used DynDNS in the past and was extremely disappoint when they shut down the free version, due to abuse by malware distributors and spammers. I am hesitant to use No-IP as they also have been known for being abused for malware distribution. That is why I am so glad Balfson mentioned FreeDNS. It seems much more reputable and less likely to have free DNS registration expire, which is my biggest concern.

Believe it or not, I am in the actually in the midst of my last law school finals, in the US. I am taking the Bar Exam, in July. Once the exam is over, I will look into adding 2-factor authentication, but for the time being, if I can restrict it to one external IP with Admin rights, that I can control with a dynamic DNS service, like FreeDNS and lock every other external IP in the world out, I feel comfortable with the setup, until I can eventually add 2 factor authentication + Dynamic DNS limiting remote access to one IP, for remote access. If possible, I will also restrict it to a VPN also.

In other words, once the bar exams ends in July, I will be able to live like a normal human being again!

Quick note, according to a post from Etienne Liebetrau over at Fastvue, it appears it is likely possible to setup a VPN on a UTM in Bridge Interface + Full Transparent Mode, behind a router.

This is the stripped down post from over at Fastvue:

"In other words, once the bar exams ends in July, I will be able to live like a normal human being again!" - I have a lot of lawyer friends.  Sorry, Scott, you'll never be a normal human being again! [:D][:D][:D]

Although you cannot configure an L2TP/IPsec VPN behind a NAT, you can configure SSL VPN Remote Access.  You just need to forward the port to the UTM.  I like to configure that to use UDP port 1443 for SSL VPN.

Cheers - Bob

Bob, you are right on that one. Law school messes a person up in all sorts of ways, some for the better, some not so much.

Thank you for the info about the SSL VPN. As I mentioned earlier, I will look to implement this after the bar exam, this summer.  I want to thank you for the help that you have given me and others on this forum. When searching for information about how to get my UTM up and running, I routinely find that have you given others on here answers which I would otherwise be asking myself. You have probably unintentionally answered questions of my at least 20x, without ever replying directly before this thread, so thank for all your advice!

Scott