1. Azure Sophos Vpn
2. Sophos Firewall Price
3. Azure Sophos Xg Firewall

Find Server Protection on Microsoft Azure. Click Get your VM extension script. Then click Download Script. You’ll need an API token so that the script can find and access the installer. Sophos Cetral & Azure Sentinel Intergration I would love Sophos to create a 'Connector' for Azure Sentinel. The combined infromation from O365 and Azure would be amazing!

Sophos Cloud Security Posture Management Easily identify cloud resource vulnerabilities, ensure compliance, and respond to threats faster. Asset and network traffic visibility for AWS, Azure, and Google Cloud Risk-based prioritization of security issues with guided remediation. Sophos offers two pricing options for XG Firewall on Azure: pay-as-you-go and bring-your-own-license. PAYG allows you to pay only what you use, with no minimum commitment and stop at any time. BYOL allows you to use your existing investment in XG Firewall. If the on-premises Sophos XG Firewall appliance is behind a NAT device, The recommendation is to use a Sophos XG Firewall in Azure to deploy the VPN connection. Please refer to Sophos XG Firewall: Quick Start Guide on Microsoft Azure to deploy the XG Firewall on Azure.

Businesses move to the Public Cloud for a variety of reasons, whether it’s flexibility, the ability to customize, or lower costs. That’s why Sophos XG Firewall has been available through the Microsoft Azure Marketplace for some time, offering pay-as-you-go (PAYG) and bring-your-own-license (BYOL) options, providing industry leading price-performance, and the ultimate in flexibility.

Best value in price-performance on Azure

XG Firewall for PAYG delivers all features and functionality of XG Firewall on Azure (FullGuard License), including Network Protection, Web Protection, Email, and Web Server Protection modules ­– already installed and ready to go. And we’re pleased to announce we recently updated the template package for our Azure Marketplace offer of XG Firewall.

New PAYG pricing and recommended VM performance tiers

You now have complete flexibility to select any virtual machine series* for your XG Firewall, allowing you to fine-tune your virtual machine selection and compute costs to meet your exact requirements. Plus, our recommended Fsv2-series has been chosen to provide the best value in price-performance in the Azure portfolio based on the Azure Compute Unit (ACU) per vCPU.

*Virtual machine series exceptions A0, A1, B1 and B1ms
** Prices listed are in U.S. dollars. You can find pricing in your local currency by using the Azure Pricing Calculator

In the same update, your current PAYG pricing for new and existing XG Firewall Azure VMs may change dependent on the country where you purchase Azure services. From March 10, 2020 Sophos will use standardized currency exchange rates to localize your pricing based on the U.S. dollar pricing in the table above. This will not affect services currently payed for in US Dollars. Microsoft will notify you of any changes to pricing affecting your bill prior to the correction.

Now sell XG Firewall in more regions than ever

Providing our partners with greater flexibility will also extend to licensing in this update, with two major improvements to PAYG and BYOL options.

PAYG is now available in 12 additional regions:

BYOL availability grows from 90, to all 141 Azure enabled countries – a huge expansion to help you become more competitive than ever selling Sophos XG Firewall on Azure. See all 51 new countries below:

We hope this important update enables you to be more competitive as a Sophos Partner, and provide a service that meets the exact requirements of your customers’ who have already moved or are planning to move to Microsoft Azure.

Sophos made a great article regaring running Sophos XG with Azure AD authentication, here are the steps:

This document is applicable to all the XG Firewalls running all versions. To integrate the XG firewall with Azure AD, we need to create a new service called “Azure AD Domain services”.

With this integration, administrators can use Azure AD for the following:

1. Captive portal authentication of internal firewall users.
2. Authentication agent for windows, mac, linux.
3. SSL VPN authentication.
4. Sophos Connect client.
5. Use the SSO using the Synchronized security UserID*.

Note: SSO with synchronized security and Azure AD needs to meet some specific requirements which are outside the scope of this document.

Azure AD DS replicates identity information from Azure AD to a Microsoft-operated set of domain controllers, so it works with Azure AD tenants that are cloud-only, or synchronized with an on-premises AD DS environment. The same set of Azure AD DS features exists for both environments.

Azure Sophos Vpn

Azure AD domain services offer an LDAP interface to XG that can replicate the working of an on-premise Active Directory. This article assumes there is an existing Azure AD environment in place.

Table of Contents

Sophos Firewall Price

1. Login in to the Azure portal and create Azure AD domain services, this step will take 60-90 minutes to deploy. Please see the documentation from Microsoft on how to deploy Azure AD domain services.
2. Once the AD domain services are deployed, you should see the health status as “Running”.
3. Click on Synchronize, you can either select scoped or chose to synchronize all the Azure AD.

   Note: The following step is required for cloud-only user accounts in Azure AD, as the Azure AD account is not synchronized with AD domain services until the user has changed the password by logging in to their office365 login. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD.

4. Each user needs to login to the Office 365 portal and change the password. If it’s a new user logging into office 365 for the first time, they will be prompted for the password change.
5. Once the AD domain services are deployed, it’s recommended to enable LDAPs if the firewall is sending LDAP bind request over the internet. For additional security, Sophos recommends creating an IPsec tunnel to Azure over which to bind the LDAP.

   Note: Azure accepts self-signed certificates for this purpose. In this example, we use OpenSSL to generate a self-signed chain of certificates. Azure only accepts certs with “extendedkeyusage for server authentication”.

   Below is the process to generate self-signed Certs with EKU:serverauth:

   • In order to create the Certificate Authority Private Key and Certificate, you first need to create a private key for the CA with the name azureADca.key.

     $ openssl genrsa -out azureADca.key 4096
     Generating RSA private key, 4096 bit long modulus
     ……………………………………………………………………………………………………………………………………….++
     …………….++
     e is 65537 (0x10001)

   • Create the CA certificate to be used to validate signed certificates, called azureADca.pem.

     $ openssl req -x509 -new -nodes -key azureADca.key -days 3650 -out azureADca.pem
     You are about to be asked to enter information that will be incorporated
     into your certificate request.
     What you are about to enter is what is called a Distinguished Name or a DN.
     There are quite a few fields but you can leave some blank
     For some fields there will be a default value,
     If you enter ‘.’, the field will be left blank.
     —–
     Country Name (2 letter code) []:CA
     State or Province Name (full name) []:ON
     Locality Name (eg, city) []:Burlington
     Organization Name (eg, company) []:<Your org>
     Organizational Unit Name (eg, section) []:Salesengineering
     Common Name (eg, fully qualified host name) []:<Commaon name>
     Email Address []:email@email.com

   • Create a text file and copy/paste the below text. Save the file as “azureAD-eku.conf” or any name of your choice.

     [client_server_ssl]
     extendedKeyUsage = serverAuth

   • Now that this file exists, you need to generate a private key for the LDAP cert with the name “ldapssl_private.key”.

     $ openssl genrsa -out ldapssl_private.key 4096
     Generating RSA private key, 4096 bit long modulus
     …………………………….++
     ……….++
     e is 65537 (0x10001)

   • Next, create a certificate signing request to sign with the CA you previously created with the name “azureADldapssl.csr” and fill in the following values in yellow.
     $ openssl req -new -key ldapssl_private.key -out azureADldapssl.csr
     You are about to be asked to enter information that will be incorporated
     into your certificate request.
     What you are about to enter is what is called a Distinguished Name or a DN.
     There are quite a few fields but you can leave some blank
     For some fields there will be a default value,
     If you enter ‘.’, the field will be left blank.
     —–
     Country Name (2 letter code) []:CA
     State or Province Name (full name) []:ON
     Locality Name (eg, city) []:Burlington
     Organization Name (eg, company) []:firewallinabox
     Organizational Unit Name (eg, section) []:Sales Engineering
     Common Name (eg, fully qualified host name) []:<yourdomainname>
     Email Address []:<email@email.com>

     Please enter the following ‘extra’ attributes
     to be sent with your certificate request
     A challenge password []:<Password>

   • You now need to sign the request, while including the signing extensions created earlier. The following command will create the signed cert with the name “azureADcert.crt”.

     $ openssl x509 -req -extensions client_server_ssl -extfile azureAD-eku.conf -in azureADldapssl.csr -CA azureADca.pem -CAkey azureADca.key -CAcreateserial -out azureADcert.crt -days 365
     Signature ok
     subject=/C=CA/ST=ON/L=Burlington/O=firewallinabox/OU=Sales Engineering/CN=firewallinabox.tk/emailAddress=email@email.com
     Getting CA Private Key
     $ Apple macbook white.

   • Convert the certificate into PFX format, as Azure accepts the certs in the PFX format.

     $ openssl pkcs12 -export -out XGazureADcert.pfx -inkey ldapssl_private.key -in azureADcert.crt -certfile azureADca.crt
     Enter Export Password:
     Verifying – Enter Export Password:

   • Next, upload the XGazureADcert.pfx file into Azure AD.
6. Under Azure AD domain service, navigate to properties and make a note of the following, Secure LDAP external IP address. If you are connecting through an IPsec tunnel, you can use the internal addresses which are 10.201.1.4 and 10.201.1.5 in this example.
7. Make sure the admin group is selected with the correct administrator group used on the XG to send LDAP bind requests to AD domain services.
8. In the Azure portal, navigate to Azure AD > Users and make sure the user is part of the AAD DC Administrators group inside Azure AD.
9. In the Azure portal, navigate to the Network security groups > Inbound security rules, then add a new inbound security rule allowing the LDAPs traffic from your firewalls public IP. (This is optional and only required if you are using an IPsec tunnel for additional security).
10. The administrator account you will be using on the XG Firewall must be first logged in to Office365, and the password needs to be changed upfront.

1. Login to the XG Firewall web UI and navigate to Configure > Authentication > Servers > Add and use the following settings we have from the Azure AD domain services.
2. Import the groups from Azure AD as shown below.
3. Select the server from the list of authenticated servers from Configure > Authentication > Services.
4. Test the authentication with the user portal and the login should be successful.

Source: Sophos XG Firewall: Integrate XG Firewall with Azure AD – Recommended Reads – Sophos (XG) Firewall – Sophos Community

Azure Sophos Xg Firewall

Related Posts