Use best practices to avoid the total fiasco that just hit managed.com. Step one is understanding what's happening, and never placing web files on Drive C. 

Ransomware has been a critical security issue since 2018 and is constantly evolving, making it increasingly difficult to detect as malware. We have taken this opportunity to share our experience and help you protect your DNN websites from ransomware attacks in the future.

We all know it: If we have problems accessing a database, we can assign the db_owner role to the account that accesses the database - or even worse, we assign the sysadmin role for the whole server to this account.
And we have that presentiment that we could open some security holes by doing so. So what is reasonable?

Sometimes it’s easy to forget some of the simple things when you've been working with something over a long period of time. When this happens, it's easy to overlook how technical, difficult, hidden, or simply not obvious things. You end up in something of an auto-pilot mode. This article helps to outline some of the quick-and-easy things that we often do after first installing DNN. 

There are a lot of blog entries and articles in the Web about that topic, and it has been discussed a million times in the last years - esp. since Let's Encrypt entered the market and Google announced that using (or not using) HTTPS will affect site ranking. But still I find sites in the community that don't use it, so here I want to work out reasons for doing a change.

If you’re in the developer community, and especially if you’re using or near any Azure conversations, you’ll continuously hear someone suggest Let’s Encrypt when it comes to securing your domain name.  You know, that thing you do to allow your website to use the HTTPS protocol to get that lock in front of it in the web browser.  I’ve tended to use NameCheap.com these days.  They’re cheap like their name suggests, and they’re super easier to use.  However, things just got even easier.