Have you checked the update management system for your Azure and On-Premises server that supports both Windows and Linux operating systems? And it is completely free! Please find the full list of supported operating systems and prerequisites here: https://docs.microsoft.com/en-us/azure/operations-management-suite/oms-solution-update-management#prerequisites.
Lets get started. The easiest way is to start from an Azure VM. Go to the VMs blade and find “Update management”. You will see a notification that the solution is not enabled.
Click the notification and the “Update Management” blade will open. The “Update Management” is an OMS solution, so you will need to create a “Log analytics” workspace, you can use the Free tier. If you don’t have a Log analytics workspace the wizard will create a default for you. Also it will create an automation account. Pressing enable will enable the “Update Management” solution.
After about 15 minutes, at the “Update Management” section of the VM you will see the report of the VM’s updates.
After that process the Automation Account is created and we can browse to the “Automation Accounts” service at the Azure Portal. There click the newly created Automation Account and scroll to the “Update Management” section. There we can see a full report of all VMs that we will add to the Update Management solution. To add more Azure VMs simply click the “Add Azure VM” button.
The Virtual Machines blade will open and will list all Virtual Machines at the tenant. Select each VM and press Enable.
After all required VMs are added to the Update Management solution click the “Schedule update deployment” button. There we will select the OS type of the deployment, the list of computers to update, what type of updates will deploy and the scheduler. More or less this is something familiar for anyone that has worked with WSUS.
Press the “Computers to Update” to select the Azure VMs for this deployment from the list of all VMs enabled.
Then select what types of updates will deploy.
If you want to exclude any specific update you can add the KB number at the “Excluded updated” blade.
And finally select the schedule that the update deployment will run.
Back to the “Update Management” blade, as we already said, we have a complete update monitoring of all Virtual Machines that are part of the “Update Management” solution.
You can also go to the “Log Analytics” workspase and open the “OMS Portal”
There, among other, you will see the newly added “System Update Assessment” solution.
and have a full monitoring and reporting of the updates of your whole environment.
A complete guide on how to create a pfSense VM on a local Hyper-V server, prepare it for Microsoft Azure, upload the disk to Azure and create a multi-NIC VM.
Download the latest image from https://www.pfsense.org/download/
Open Hyper-V Manager create a Generation 1 VM. I added 4096 ram, 2 cores, use VHD, add an extra NIC (for second interface) and select the downloaded ISO. (create a fixed VHD as Azure supports only fixed VHDs for custom VMs)
Start the VM and at the first screen press enter.
At all screens I accepted the default settings. Finally at the reboot prompt remove the installation ISO.
There is no need to setup VLANs, select the second interface for WAN and the first for LAN.
Once the pfSense is ready press 2 and change the LAN (hn0) interface IP to one at your network. Then select the option 14 to enable SSH.
Now we can login with putty, with username admin password pfsense and press 8 for Shell access.
The first thing is to update the packages running:
Then install Python, as it is requirement for the Azure Linux Agent.
Search for Python packages running:
pkg search python
Install the latest Python package, setup tools and bash:
pkg install –y python27–2.7.14
pkg search setuptools
pkg install py27-setuptools-36.2.2
ln -s /usr/local/bin/python /usr/local/bin/python2.7
pkg install -y bash
Azure Linux Agent
pkg install git
git clone https://github.com/Azure/WALinuxAgent.gi
git checkout WALinuxAgent–2.1.1
git checkout WALinuxAgent–2.0.16
python setup.py install
ln –sf /usr/local/sbin/waagent /usr/sbin/waagent
check the agent is running:
One final step before uploading the VHD to Azure is to set the LAN interface as dhcp.
This can be done by the web interface, go to https://lanaddress, login using admin / pfsense, and go to interfaces / LAN and select DHCPas ipv4 configuration.
Now, shutdown the pfSense and upload it to Azure Storage.
I use the Storage Explorer, https://azure.microsoft.com/en-us/features/storage-explorer/ a free and powerful tool to manage Azure Storage. Login to your Azure Account and press Upload. Select as Blob type: “Page blob”
After the upload is completed we can create a multiple NIC VM. This cannot be accomplished from GUI. We will create this using PowerShell.
$ResourceGroupName = “******”
$pfresourcegroup = “*******”
$StorageAccountName = “******”
$vnetname = “*****”
$NSGname = “******”
$location = “West Europe”
$vnet = Get-AzureRmVirtualNetwork -Name $vnetname -ResourceGroupName $ResourceGroupName
$backendSubnet = Get-AzureRMVirtualNetworkSubnetConfig -Name default -VirtualNetwork $vnet
$vnet = Get-AzureRmVirtualNetwork -Name $vnetname -ResourceGroupName $ResourceGroupName
$pubip = New-AzureRmPublicIpAddress -Name “PFPubIP” -ResourceGroupName $pfresourcegroup -Location $location -AllocationMethod Dynamic
$nic1 = New-AzureRmNetworkInterface -Name “EXPFN1NIC1” -ResourceGroupName $pfresourcegroup -Location $location -SubnetId $vnet.Subnets.Id -PublicIpAddressId $pubip.Id
$nic2 = New-AzureRmNetworkInterface -Name “EXPFN1NIC2” -ResourceGroupName $pfresourcegroup -Location $location -SubnetId $vnet.Subnets.Id
$VM = New-AzureRmVMConfig -VMName $vmName -VMSize $vmSize
$VM | Set-AzureRmVMOSDisk
-Name pfsenseos -CreateOption attach -Linux -Caching ReadWrite
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic1.Id
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic2.Id
$vm.NetworkProfile.NetworkInterfaces.Item(0).Primary = $true
New-AzureRMVM -ResourceGroupName $pfresourcegroup -Location $locationName -VM $vm -Verbose
Once the VM is created, go to the VM’s blade and scroll down to “Boot diagnostics”. There you can see a screenshot of the VM’s monitor.
Then go to the Networking section and SSH to the Public IP.
and also we can login to the Web Interface of the pfSense
In my case I have added both NICs at the same Subnet, but at a production environment add the LAN interface to the backend subnet and the WAN interface to the DMZ (public) subnet.
Of course more NICs can be added to the VM, one for each Subnet at our environment.
Route external traffic through the pfSense
We cannot change the gateway at an Azure VM, but we can use routing tables to route the traffic through the pfSense.
From the Azure Portal, select New and search for Route table.
We need to configure two things. One is to associate the Route table to a Subnet and the second is to create a Route.
Open the “Route table” and click the “Routes”. Press “Add route” and in order to route all outbound traffic through the pfSense then add for Address prefix “0.0.0.0”, next hop type Virtual appliance” and Net hop address the ip address of the pfSense’s LAN interface IP.
Then go to the “Subnets” and associate the required subnets.
Continuing the Azure Security Center posts, today we will see a new feature of the Security Center, called Just in Time VM Access.
As best security practice, all the management ports of a Virtual Machine should be closed using Network Security Groups. Only the ports required for any published services should be opened, if any.
However there are many occasions that we are requested to open a management port for administration or a service port for some tests for short time. This action has two major problems, first it requires a lot of administration time, because the administrator must go to the Azure Portal and add a rule at the VM’s NSG. The second problem is that many time the port is forgotten open and this is a major vulnerability since the majority of the Brute Force attacks are performed to the management ports, 22 and 3389.
Here comes the Azure Security Center, with the Just in Time VM Access feature. With this feature we can use the RBAC of the azure Portal and allow specific users to Request a predefined port to be opened for a short time frame.
Lets see how we configure the JIT. First we need to go to the Azure Security Center. Scroll down to the ADVANCED CLOUD DEFENSE and click the “Just in time VM Access”. Since it is at a Preview you need to press the “Try Just in time VM access”
After we enable JIT, the window displays tree tabs, the Configured, the Recommended and the No recommendation. The Configured tab displays the Virtual Machines that we have already enabled JIT. The recommended are VMs that have NSGs and are recommended to be enabled for JIT. The No recommendation are Classic VMs or VMs that don’t have attached NSG.
To enable JIT for a VM, go to the Recommended tab, select one or more VMs and press “Enable JIT on x VMs”
At the “JIT VM access configuration” the Security Center proposes rule with the default management ports. We can add other ports that we need and also remove any of them that are unnecessary.
At each rule we can configure the Port, the Protocol, the Source IP and the Maximum request time.
If we leave the “Allowed source IPs” to “Per request” then we allow the requester to decide. One very interesting setting here is that when a user requests access it has the option to allow only the Public IP that he is using at that time automatically.
With the last option, the “Max request time” we narrow down the maximum time that we will allow a port to be opened.
After we configure all the parameters we click Save and the VM moves to the Configured tab. At any time we can change the configuration by selecting the VM, press the three dots at the end of the line (…) and click Edit.
The Propertied button opens the VM’s blade, the Activity log shows all the users that requested access and the Remove of course disabled the JIT.
Behind the scene
What really happens to the VM? if you browse to the NSG that is attached to the VM you will see that all the port rules configured at the JIT are added as NSG Rules with lower priority than all the other rules. All other rules automatically changed priority to higher.
Lets see how we request access and what happens in the background. To request access go to the Security Center / JIT , select the VM and press “Request Access”
At the “Request access” blade switch on the desired port, select “My IP” or “IP Range” and the Timerange, all according to the JIT configuration of the VM. Finally press “Open Ports”
At the above example I select “My IP” so if you go to the VM’s NSG you will see that the 3389 port rule changed to “Allow” and for Source has my current Public IP. Also it moved at first priority.
After the expiration of the time rage the port will change to “Deny” and move back to its prior priority.