Monitoring Hosts and Domains for RBL Listing Using Azure - Part 3: Management
Following my last post about monitoring your domains and hosts for RBL listing, we are going to continue with the PowerShell module to manage the solution and a script to query the status of hosts and domains.
Since the solution is accessible via HTTP, it couldn't be simpler to manage using PowerShell. But first, let's take a look at the files in the module.
The module is comprised of three files, the module manifest (.psd1), the script file (.psm1), and a configuration file (.json). The manifest contains the module parameters and configuration, the script file the code of the functions, and the configuration file a couple of settings such as the URL of the function app and the key to use. We'll talk about key management later in this article.
The module contains the following functions:
To enhance the security of your functions you can restrict the IPs that can access them and allow access only, from let's say, your office and monitoring server. I believe that it would be a great idea to also issue different keys for the different user types. This way, an administrator's key would be able to call all functions and update hosts, domains, and lists while a monitoring user's key would only be able to call the function to check the status of domains or hosts.
The solution code is available on GitHub over here, deploy it and start monitoring your resources!
Since the solution is accessible via HTTP, it couldn't be simpler to manage using PowerShell. But first, let's take a look at the files in the module.
The module is comprised of three files, the module manifest (.psd1), the script file (.psm1), and a configuration file (.json). The manifest contains the module parameters and configuration, the script file the code of the functions, and the configuration file a couple of settings such as the URL of the function app and the key to use. We'll talk about key management later in this article.
The module contains the following functions:
List related
Host related
Domain related
After you deploy the function app project to Azure, you have to update the configuration file of the module with the function app URL and key.
- Get-AzureRBLList
- Add-AzureRBLList
- Remove-AzureRBLList
- Get-AzureRBLHost
- Add-AzureRBLHost
- Remove-AzureRBLHost
- Check-AzureRBLHost
- Get-AzureRBLDomain
- Add-AzureRBLDomain
- Remove-AzureRBLDomain
- Check-AzureRBLDomain
The configuration file is a simple JSON file with only two objects:
{
"APIBaseUri": "https://<yourfunctionapp>.azurewebsites.net/api/",
"APIKey": "<yourfunctionkey"
}
You can get the value for the APIBaseUri from the Overview pane of your function app:
and you just need to append the "/api" part.
To create a new key, you have to open the App Keys pane and create a new host key as shown below:
Creating a host type key will allow our module to call all the functions deployed on Azure.
Now that the configuration file has been properly configured, you can import the module and start adding your hosts and domains along with the lists to check them against using the Add functions.
If you managed to successfully import the module, getting the available commands from it should look similar to the below:
To demonstrate the functionality of the solution, I've added some hosts, domains, and lists to my environment:
You will have to add your own domains and hosts. A starting point for lists is available in my Github repository with the rest of the code, you can import this list and then adjust it according to your needs.
Performing the checks for our host with IP 54.39.224.173 shows that it is listed at at least one list:
To get only the lists that have the host, we can pipe the output to Where-Object:
Now you know who you have to contact in order to remedy the issue. The same approach can be followed with domains as well.
Apart from the module to manage the solution, I've also added a sample script to check the status of a domain or host. This script (available here) takes a host or domain as a parameter and returns a status number based on whether the domain or host is listed on any lists. You can then have your monitoring system execute the script at set intervals and create events and alerts.
A sample execution would be similar to the one below:
The return number is the number of lists that have marked the host/domain. A negative value indicates an error.
To enhance the security of your functions you can restrict the IPs that can access them and allow access only, from let's say, your office and monitoring server. I believe that it would be a great idea to also issue different keys for the different user types. This way, an administrator's key would be able to call all functions and update hosts, domains, and lists while a monitoring user's key would only be able to call the function to check the status of domains or hosts.
In my environment, I've configured a dedicated key for the Check-Domain and Check-Host functions named Monitoring so that the administrator of the monitoring solution can only perform those two operations:
The solution code is available on GitHub over here, deploy it and start monitoring your resources!
Previous Articles
Part 3 - Management
