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.

Convert a CRT SSL certificate chain to PFX format

Many SSL certificate authorities (CAs) do not natively support .PFX format certificates which means that if you plan on installing them on something like an Azure App Service, you may encounter issues. Today, let’s figure out how to convert a CRT SSL certificate chain to PFX format.

First, let’s generate a private key and certificate signing request. Run the following command, and answer the questions as accurately as possible. The private key file (domain.key) should be kept secret and protected.

openssl req \
        -newkey rsa:2048 -nodes -keyout domain.key \
        -out domain.csr

Next, take the contents of domain.csr (it is just a plaintext file with your answers and some other non-secret information base64-encoded; it can be opened in any text editor) and request your certificate through your CA. This process varies per certificate authority, and so is out of scope for this article.

[Time passes]

Now, your CA provides you with a .ZIP file with the following files.

your_domain_com.crt
AAACertificateServices.crt
DomainValidationSecureServerCA.crt
USERTrustRSAAAACA.crt

(where your_domain_com.crt is the actual certificate file and the other .CRT files represent the various certificates that will allow a browser to chain up to the root; while the filenames and number of files will almost certainly be different for each certificate authority, the point here is to illustrate that there will be some number of .CRT files and that they are all important)

Extract those files into the same folder that you have the domain.key file from earlier in.

Finally, let’s take our certificate and combine them with the rest of the chain to create a single .PFX file by running the following command. Your site’s certificate should be specified in the -in parameter, and for each of the chain certificates, adding another -certfile entry.

openssl pkcs12 -export -out certificate.pfx \
        -inkey domain.key \
        -in your_domain_com.crt \
        -certfile AAACertificateServices.crt \
        -certfile DomainValidationSecureServerCA.crt \
        -certfile USERTrustRSAAAACA.crt

NOTE: Azure App Services and Azure Key Vaults require a password-protected .PFX file, so ensure that you enter one when prompted. When you go to upload the certificate and you are required to select the .PFX file and a password, the password you created here is the one it’s referring to.

And you’re done! You now have a file in that folder (certificate.pfx) that you can upload/install and ensure your site is protected against MITM attacks.

Cannot use the SKU Basic with File Change Audit for site

The problem

We’ve recently begun attempting to scale our Azure App Services up and down for our test environments; scaling them up to match production performance levels (SKU: PremiumV2) during the day and then back down to minimal (SKU: Basic) at the end of the working day to save on costs. Just in the last month or two however, we’ve started to get the error “Cannot use the SKU Basic with File Change Audit for site XXX-XXX-XXX-XXX”.

Initially, we thought it had to do with the fact that we had a Diagnostic setting that was tracking AppServiceFileAuditLogs, but even after removing that Diagnostic setting before attempting the scale down, the issue persisted.

After banging our head against the walls with no progress being made, we opened a low-severity ticket with Azure Support to understand what was going on. They suggested we remove the following App Configuration settings:

  • DIAGNOSTICS_AZUREBLOBCONTAINERSASURL
  • DIAGNOSTICS_AZUREBLOBRETENTIONINDAYS
  • DiagnosticServices_EXTENSION_VERSION
  • WEBSITE_HTTPLOGGING_CONTAINER_URL
  • WEBSITE_HTTPLOGGING_RETENTION_DAYS

Again, these did not have any effect.

It was at this time that I was in the portal browsing around for something else and happened to notice the “JSON View” option at the top right of the App Service so I checked it out and grep’d for audit just to see what I’d find.

Bingo: fileChangeAuditEnabled

Not so bingo: fileChangeAuditEnabled: null

But seeing that setting got me to thinking. What if there’s a bug in what JSON View is showing. The error we’re receiving is clearly saying it’s enabled, but the website is showing null; what if there’s some kind of type-mismatch going on behind the portal that is showing null but actually has a setting? What if we could use a different mechanism to test that theory?

Well, it just so happens that Azure PowerShell has a Get-AzResource function that can do just that and this blog post shows us how to do that.

The solution

First, let’s get the resource:

$appServiceRG = "example-resource-group"
$appServiceName = "example-app-service-name"
$config = Get-AzResource -ResourceGroupName $appServiceRG `
    -ResourceType "Microsoft.Web/sites/config" `
    -ResourceName "$($appServiceName)/web" `
    -apiVersion 2016-08-01

We now have an object in $config that we can now check the properties of by doing:

$config.Properties

And there it is:

fileChangeAuditEnabled                 : True

Now all we need to do is configure it to false (and also unset a property called ReservedInstanceCount which is a duplicate of preWarmedInstanceCount but cannot be included when we try and reset the other setting due to what I assume is Azure just keeping it around for legacy reasons):

$config.Properties.fileChangeAuditEnabled = "false"
$config.Properties.PSObject.Properties.Remove('ReservedInstanceCount')

Next, as per the suggestion from Parameswaran in the comments (thank you!), create a new Array (since existing arrays are of fixed size and cannot be modified) while removing AppServiceFileAuditLogs from the list of azureMonitorLogCategories

$newCategories = @()

ForEach ($entry in $config.Properties.azureMonitorLogCategories) {
    If ($entry -ne "AppServiceFileAuditLogs") {
        $newCategories += $entry
    }
}

$config.Properties.azureMonitorLogCategories = $newCategories

And finally, let’s set the setting:

$config | Set-AzResource -Force

Next, for any Deployment Slots you have on this resource, repeat these steps again, but using the following resource retrieval code:

$config = Get-AzResource -ResourceGroupName $appServiceRG `
    -ResourceType "Microsoft.Web/sites/slots" `
    -ResourceName "$($appServiceName)" `
    -apiVersion 2016-08-01

Now, when you try to scale down from a PremiumV2 SKU to a Basic SKU, you will no longer receive the error of “Cannot use the SKU Basic with File Change Audit for site XXX-XXX-XXX-XXX”.

Posts navigation