Prevent spam on your entry level Blog

The settings for controlling comments in WordPress is available under Settings > Discussion. Please note that this is the manual method of preventing/combating spam and is usually the most effective when you have a few comments every day. However, if you have over 1000 daily comments, it is more feasible to use an antispam plugin.

Let’s discuss certain ways to use these default WordPress settings to prevent spam. We will discuss one section at a time.

Default Article Settings

Simply disable trackbacks and pingbacks to save yourself from half the spam traffic. Only allow people to post comments on new articles.

Other Comment Settings

It is almost always necessary for the comment author to enter his name/email before commenting. WordPress enables this by default. If you require users to log in before leaving comments then this will cut down on a significant amount of spam This step might be a turn off for few legit readers who want to leave a comment but don’t want to sign in. Therefore you must carefully analyze before enabling this feature.

You should disable comments on posts older than 90 days in a fairly active blog. However, if you keep updating articles, make sure to change the published date so that the 90 days boundary doesn’t overlap. Keep Threaded comments to the default or increase it if required.

E-mail Me Whenever

You can use this feature if you don’t get thousands of comments on your posts. You will get email notifications for every comment that pops up and you can mark it spam right away cutting down on a section of spam comments.

Before a Comment Appears

Allowing readers who have previously left a comment, to leave a comment again without requiring any approval, will help you cut down the legit comments in the moderation queue. You’ll only have to focus on the remainder of users, mostly of which will be spam.

Comment Moderation

I suggest you use a value of 2. This ideally allows guest bloggers to leave at most one outgoing link (link bait) in their comment. Building an effective comment moderation blacklist is a very time-consuming process, with equally beneficial payoffs. However, you can leverage this setting as an effective profanity filter. Simply add the profane words to the list and all such comments will be added to the moderation queue.

Comment Blacklist

Comment Blacklist is stricter version of the Comment Moderation Blacklist, where if a comment contains a blacklisted word, it is sent to the spam queue, instead of the moderation queue. The benefit – saves your time.

Adding a separate email account as an owner subscription

My friend has created the Azure subscription using this email address, foo.inc@outlook.com. Azure has created a domain fooincoutlook.onmicrosoft.com in Azure Active Directory.

Me and my friend share same subscription with same foo.inc@outlook.com email address to provision services Azure. There are occasional disruptions in my sign-in and I see a login pop up window. It asks me to type-in our shared email address to get a code and authenticate in Azure. I contact my friend and solve login issue. This is a waste of time.

To solve this issue, navigate to Active Directory -> Manage -> User and create a new user;

adam@fooincoutlook.onmicrosoft.com

Navigate to Azure subscription -> Access control (IAM) -> Add -> Add role assignment;

By using adam@fooincoutlook.onmicrosoft.com, We can share a single subscription but can use our own email accounts to provision resources.

There are other ways to manage identities but I have found this an easier and quicker fix.

enabling / disabling xp_cmdshell

I am not getting into the discussion of pros and cons of xp_cmdshell. This command helps you to run broad level features inside your SQL server. You can run OS level commands, SSIS packages etc.

Here is how you can enable, disable and use.

To check, if xp_cmdshell is enabled and available to use;

SELECT CONVERT(INT, ISNULL(value, value_in_use)) AS config_value
FROM sys.configurations
WHERE name = 'xp_cmdshell';

Turn on xp_cmdshell

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE

Turn off xp_cmdshell

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE

Here is a simple use case;

EXEC xp_cmdshell 'dir c:\'

Here is how you can enable it, use it and disable;

DECLARE @originalSetting INTEGER = 0;
SELECT @originalSetting = CONVERT(INT, ISNULL(value, value_in_use))
FROM  sys.configurations
WHERE  name = 'xp_cmdshell' ;
 
IF @originalSetting = 0
BEGIN
    EXEC sp_configure 'show advanced options', 1;
    RECONFIGURE;
    EXEC sp_configure 'xp_cmdshell', 1;
    RECONFIGURE;
END
 
EXEC xp_cmdshell 'dir c:\';
 
IF @originalSetting = 0
BEGIN
    EXEC sp_configure 'show advanced options', 1;
    RECONFIGURE;
    EXEC sp_configure 'xp_cmdshell', 0;
    RECONFIGURE;
END

You can create a stored procedure and use;

CREATE PROCEDURE sp_SuperCmdShell
(
    @commandToRun VARCHAR(1000)
)
AS
BEGIN
    -- check to see if xp_cmdshell is enabled, if its not
    --   then enable it and run the command then set it back
    --   to not enabled.
    DECLARE @originalSetting INTEGER = 0;
    SELECT @originalSetting = CONVERT(INT, ISNULL(value, value_in_use))
    FROM  sys.configurations
    WHERE  name = 'xp_cmdshell' ;
 
    IF @originalSetting = 0
    BEGIN
        EXEC sp_configure 'show advanced options', 1;
        RECONFIGURE;
        EXEC sp_configure 'xp_cmdshell', 1;
        RECONFIGURE;
    END
 
    EXEC xp_cmdshell @commandToRun;
 
    IF @originalSetting = 0
    BEGIN
        EXEC sp_configure 'show advanced options', 1;
        RECONFIGURE;
        EXEC sp_configure 'xp_cmdshell', 0;
        RECONFIGURE;
    END
 
END
GO
exec #sp_SuperCmdShell 'dir c:\';

This is not a new feature. It came out with early release of SQL server. If you see the usage command, they are OS level command. With the super privileged access any body can run a “format c:\” OS command and leave your database server in unrecoverable state. My suggestion would be to use it with least privileged proxy account.

Restrict Web App Access to selected IPV4 addresses

To secure your web app make sure you have setup HTTPS only and client certificate required.

To further restrict access, you can setup IP address-based rule.

To add an access restriction rule to your app, select Networking under settings and click on Configure Access Restrictions. On the Access Restrictions pane, select Add rule. After you add a rule, it becomes effective immediately.

Rules are enforced in priority order, starting from the lowest number in the Priority column. An implicit deny all is in effect after you add even a single rule.

On the Add Access Restriction pane, when you create a rule, do the following:

  1. Under Action, select either Allow or Deny.
  • Optionally, enter a name and description of the rule.
  • In the Priority box, enter a priority value.
  • In the Type drop-down list, select the type of rule.

The different types of rules are described in the following sections.

 Note

  • There is a limit of 512 access restriction rules. If you require more than 512 access restriction rules, we suggest that you consider installing a standalone security product, such as Azure Front Door, Azure App Gateway, or an alternative WAF.

Set an IP address-based rule

Follow the procedure as outlined in the preceding section, but with the following addition:

  • For step 4, in the Type drop-down list, select IPv4 or IPv6.

Specify the IP Address Block in Classless Inter-Domain Routing (CIDR) notation for both the IPv4 and IPv6 addresses. To specify an address, you can use something like 1.2.3.4/32, where the first four octets represent your IP address and /32 is the mask. The IPv4 CIDR notation for all addresses is 0.0.0.0/0. To learn more about CIDR notation, see Classless Inter-Domain Routing.

Azure DevOps required to deploy build to App Services and we need to allow these services for this use case. Microsoft has introduced an AzureDevOps service tag for it but as of this writing the tag is not working. The work around is to open app to selected geography where Azure DevOps is running. In my case, they are running in EASTUS. I am going to add this rule to allow Azure DevOps to works with Azure App Service;

This will open up App to the whole EastUS region but still is better than opening it up to the whole world.

As of this writing Azure DevOps Service tag is not supported for hosted agents. AzureDevOps tag does not cover Microsoft Hosted Agents IP range, which makes the use case for using it in Azure App Service limited. The only relevant use case is, if a custom web hook is hosted on App Services.

Azure DevOps IP address and domain URLs can be used and Azure Virtual machine scale set agents to shrink the possible IP range. Refer to following links for further info;

DevOps Inbound connections: Allowed address lists and network connections – Azure DevOps | Microsoft Docs

Scale set agents: Azure virtual machine scale set agents – Azure Pipelines | Microsoft Docs

SET AN IP ADDRESS-BASED RULE USING POWERSHELL

Add-AzWebAppAccessRestrictionRule -ResourceGroupName “appservice-rg” -WebAppName “simse” -Name IpRule -Priority 200 -Action Allow -IpAddress 100.15.181.143/32

Resource

https://docs.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions

https://docs.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions

Azure Key Vault Delete and Purge

I couldn’t find any option in Azure portal for this. Open Azure CLI and run this command;

Remove-AzureRmKeyVault -VaultName “qsa-keyvault” -PassThru

This key vault has been soft deleted. If you want to recover this deleted key vault, follow this;

Search for Key vaults in Azure search bar; click on Manage deleted vaults. You will see your deleted key vault;

From here you can recover or purge your key vault;

Resources;

https://docs.microsoft.com/en-us/powershell/module/azurerm.keyvault/remove-azurermkeyvault?view=azurermps-6.13.0

https://docs.microsoft.com/en-us/azure/key-vault/general/key-vault-recovery?tabs=azure-portal