5 Ways to Secure Your Small Business Website

Your small business website is likely an essential part of your marketing strategy. It may also be your e-commerce sales channel or the platform you deliver your software on. In short, you need to keep your small business website safe. However, you likely can’t afford the same cybersecurity services as the big guys. Fortunately, there is a lot you can do yourself. This quick guide from nexxai.dev can help you figure out what you need to do.

Set Strong Login Credentials

The various login credentials you use for your website are one of your most important lines of defense. Make sure you are using long, strong passwords for any accounts. Additionally, at a minimum, all accounts with administrator access should be using either two-factor authentication or SSH keys. This may seem like a lot of trouble, but it is worth it.

Additionally, you should be very cautious about who has access to your website. If you need to give access to employees or freelancers, only give them the permissions they need. For example, if someone is just posting blogs, he or she doesn’t need administrator access.

Implement SSL

Secure socket layer or SSL is a technology used to encrypt data between computer browsers and website servers. It is a must-have technology for any small business website.

First, it will ensure that no one can snoop on the traffic between your visitors and your website. This includes if you are trying to log into your website back end from your own computer.

Second, many browsers are all but requiring HTTPS connections (achieved using SSL). It makes your website more secure, more professional-looking, and in compliance with the latest best practices. In short, you need to use this technology. According to the University of Michigan, around 80 percent of websites use HTTPS. If you aren’t, you are falling behind.

Back Up Your Website Often

You are hopefully already backing up your business data regularly. You should be doing the same with your website content. Anything that you have on your website should be backed up fairly regularly. If you post a lot of new content or capture customer data through your site, consider daily or even hourly backups. If not, you may be able to do weekly backups.

Get Help Configuring It

There are a lot of options when setting up a website, especially if you manage your own server or content management system. It is a good idea to get someone to help you set it up. This will help you to ensure that your website complies with all the latest security best practices. Even seemingly unrelated errors can cause significant vulnerabilities. Don’t risk your website or your business’s financial well-being. Consider hiring a freelancer. When you are considering an individual, look at his or her reviews from other customers. Also, make sure you have clear expectations about cost and delivery time.

Use Malware Protection

Finally, remember to use malware protection with your website hosting service. If you are renting or setting up a server on your own, you should install the appropriate anti-malware software – and keep it updated. Additionally, you will want a firewall (ideally a stand-alone network firewall). If you are using a shared hosting service, learn about your host’s security practices. Never use a host that doesn’t have a well-defined security plan.

Get Started Today

Discover more today about keeping your small business website safe. With a few best practices and the right help, you can ensure that your website is safe from cyberattacks.

About the Author

Cody McBride’s love for computers stems from high school when he built his own computer. Today he is a trained IT technician and knows how the inner workings of computers can be confusing to most. He is the creator of TechDeck.info where he offers easy-to-understand tech related advice and troubleshooting tips.

Public key authentication for non-techies

Over the last couple weeks, I’ve had a number of conversations with people on our product and delivery teams about public key authentication due to conversations they’ve had to have with some of our vendors. After having to explain public key authentication to non-techies several times, I figured it might be useful to post something public in case it helps anyone else.

So what is public key authentication and how does it work?

At it’s base, public key authentication is a secure way for a user or client to connect to a service via SSH, without having to send a password across the wire. Passwords can be intercepted and so the fewer times we have to send a password across an untrusted network, the better. Before the first connection is ever established, the client generates a public/private key pair and then sends their public key to the server they wish to connect to, while keeping their private key private.

Now the math that goes into why sharing this public key in the open isn’t a problem is a bit complicated (but hardly goes beyond grade 12 math), but it’s a lot easier to understand when you compare it to a real world scenario.

Let’s say you have a friend (vendor) and they have a shed (server) that you want to access and leave a batch of freshly baked cookies (files) for on a regular basis when they’re not home. You think about it for a while and come up with a solution: “Friend, please install a separate door (username) on your shed that only provides access to a small section of it (your home folder)”. Next, you go to the hardware store and buy a deadbolt lock (public key) that comes with a metal key (private key) that you keep on your keychain. Finally, you send this deadbolt lock to your friend to install on the door, while never showing them the key that opens the lock.

You can now come and go as you please, leaving your friend freshly baked cookies every few days, and since your key never left your possession, you can be sure that one else is sneaking inside the shed to steal the cookies. Additionally, your friend never needs to see the key because they have access to the whole shed, and you can be certain that no one else will ever be able to open up the lock because they don’t have your key.

This is public key authentication in a nutshell.

One added benefit that I haven’t really touched on here is that public key authentication – when properly created and protected – is the securest way to offer access to a system. Due to the math involved, it would take an adversary many times longer than the entire universe’s existence (that is not an exaggeration) to break your private key. Basically you can assume that if you do it right, it’s going to be secure.

I hope this made public key authentication a little less confusing and daunting for the non-techies who read this site, but if not, Khan Academy has a great video that goes into more depth using paint and color mixing. And if that still doesn’t answer your question, please leave a comment and I’d be happy to go into more detail.

Cloudflare – Error 520: What is wrong and how to fix it?

We recently ran into an issue setting up a new DNS entry on Cloudflare, using the orange-cloud (reverse proxying) feature, but we were receiving Error 520 and were curious what was wrong and how to fix it.  The error page itself doesn’t give a lot of information and since it’s a custom error they’ve created, it wasn’t easy to find out or even intuit much information about what it might mean.

To give some backstory, we are using a SaaS provider of a service for our employees that we want to protect behind our own domain. For example, instead of using ourcompany.saascompany.com, we wanted to use something like saasservicename.ourcompany.com. The provider supported this and so we set up the record within Cloudflare but as soon as we tried to visit the page, we received Cloudflare’s infamous 520 error: “Web server is returning an unknown error”.

After trying to troubleshoot the problem through Cloudflare, we turned off the orange-cloud and figured out that the SaaS provider hadn’t installed our TLS certificate correctly and so when Cloudflare was attempting to retrieve our instance from their server, they were receiving the NET::ERR_CERT_COMMON_NAME_INVALID. In response to that, they were throwing their own custom error 520 (it is not an official error code).

As soon as the vendor fixed the certificate issue, the 520 went away and we were able to re-enable orange-cloud, confirm that the site was up and working, and continue on with life confident that an attacker would not be able to determine who is providing the SaaS service for us.

Posts navigation