By Sridhar Nanjesudwaran, Windows Azure lead at 10gen I have used the MongoDB Installer for Windows Azure to deploy my MongoDB instance on a Windows Virtual Machine on Windows Azure. It is not my production environment but I would still li

By Sridhar Nanjesudwaran, Windows Azure lead at 10gen

I have used the MongoDB Installer for Windows Azure to deploy my MongoDB instance on a Windows Virtual Machine on Windows Azure. It is not my production environment but I would still like to secure it. What do I need to do to secure this standalone instance?

Let us take a look at the possible issues and how you would resolve each of them.

Password

We are assuming you have created a strong password for the Administrator user. If not make sure to set a strong password for the Administrator user.

Administrator Username

The user name cannot be specified using the installer. It is always “Administrator”. The background here is that when Azure Virtual Machines were preview, “Administrator” was the only username allowed when creating Windows Virtual Machines. This was recently fixed but the installer has not been modified to allow it. To secure the instance it would be a good idea to change the username. You can change the username by logging onto the instance.

Once you remote desktop to the instance, you can change the username from PowerShell. To change:

$user = Get-WMIObject Win32_UserAccount -Filter "Name='Administrator'"
$username = “”
$user.Rename($username)

You can verify the username changed by logging out of the instance and retrying with Administrator – this should fail. Now retry with the username you just created which should succeed.

Endpoints

By default the installer creates 3 endpoints on the instance. The endpoints are for

We are going to secure the endpoints by

1. Removing the ports when not required
2. Choosing non-standard ports
3. Securing them to your location

Removing endpoints

Remove the endpoints if they are not necessary. The PowerShell remoting endpoint is only required for the initial setup. It is not necessary unless you explicitly want to continue to use PowerShell remoting to manage the instance. Hence you should remove the endpoint. Also if you want to use PowerShell remoting to manage the instance, it is more secure to add it via an Azure interface such as (CLI, PowerShell or Management portal) when needed.?

To remove the PowerShell remoting endpoint, from a Windows Azure PowerShell console:

# Remove PowerShell remoting endpoints
Get-AzureVM -ServiceName | Remove-AzureEndpoint -Name endpname-5985-5985 | Update-AzureVM

The default remoting endpoint name is “endpname-5985-5985”. The service name is the same as the dns prefix you specified in the installer to create the instance. Similarly remove the RDP endpoint. Add it when needed as opposed to keeping it open all the time.

Choosing non-standard ports

Only add the RDP endpoint when necessary. When adding ensure you do not use the default port of 3389 for the external load balancer. To create the endpoint for RDP, from a Windows Azure PowerShell console:

# Add RDP endpoints to the single VM
Get-AzureVM -ServiceName “myservice” | Add-AzureEndpoint -Name rdp -LocalPort 3389 -Protocol tcp | Update-AzureVM

The above sets the load balancer port to an arbitrary one from the ephemeral range.

If an RDPendpoint already exists (like the default one created by the installer), you can change the load balancer port to a non standard port from a?Windows Azure PowerShell console by:

# Update RDP endpoint external port
Get-AzureVM -ServiceName “myservice” | Set-AzureEndpoint -Name rdp -LocalPort 3389 -Protocol tcp | Update-AzureVM

To check the external port you can get it from the management portal or use Windows Azure PowerShell:

# Get RDP endpoint external port
Get-AzureVM -ServiceName “myservice” | Get-AzureEndpoint

Securing the endpoint to your location:

Prior to the recent updates to Windows Azure and Windows Azure PowerShell, the only method of securing endpoints are using firewall rules on the actual instance. While this does help secure the instance, it still allows for malicious DoS attacks. With the recent updates, in addition to firewall rules you can secure your endpoints by specifying a set of addresses that can access it (white list). You want to secure the MongoDB endpoints to only allow your MongoDB client/app machines (maybe in addition to administrator machines) to access the machines.

Also if you are enabling the RDPendpoint, secure it by only allowing access by the specified administrator machines. Using a Windows Azure PowerShell:

# Setup the ACL
$acl = New-AzureAclConfig
Set-AzureAclConfig -AddRule Permit -RemoteSubnet “mysubnet” -Order 1 –ACL $acl -Description “Lockdown MongoDB port”
# Update the endpoint with the ACL
Get-AzureVM -ServiceName “myservice” | Set-AzureEndpoint -Name endpname-27017-27017 -PublicPort 27017 -LocalPort 27017 -Protocol tcp –ACL $acl | Update-AzureVM

Mysubnet – is your subnet that you want to allow access specified in the CIDR format.

原文地址：Securing MongoDB on Windows Azure, 感謝原作者分享。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com