Forum for HA and Autoscaling UTM deployments @ AWS?

hi, any update on this ? im interested in this feature on AWS.

thanks

P.

I've been trying this for few weeks as well.  

Apparently, the firmware upgrade within UTM does not do anything for HA/Autoscaling.  It's basically UTM software patch(eg. Windows security patch vs Windows Service Pack).  What has to happen is that you have to download entirely new AMI version(9.4x) from AWS marketplace and reconfigure the new instance from scratch.  or use backup to reload your configurations.  Which it kind of sucks because, it requires more work than just simple upgrade.  

Sophos is really behind on their contents on this matter.  Their template is pointing to the wrong AMI version(9.3x) so you have to manually change that first and their instructions is wrong as well.  

AWS stack error

My username and access key policy for AWS sophos is below it has SNS in it why is it failing

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloudformation:CreateStack"
            ],
            "Resource": "*",
            "Condition": {
                "ForAllValues:StringLike": {
                    "cloudformation:TemplateUrl": [
                        "https://s3.amazonaws.com/sophos-nsg-cf/*"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:Create*",
                "ec2:Describe*",
                "ec2:AuthorizeSecurityGroup*",
                "ec2:AllocateAddress",
                "ec2:AssociateRouteTable",
                "ec2:ReplaceNetworkAclAssociation",
                "ec2:RevokeSecurityGroupEgress",
                "ec2:TerminateInstances",
                "cloudformation:Describe*",
                "cloudwatch:PutMetricAlarm",
                "autoscaling:Create*",
                "autoscaling:Describe*",
                "autoscaling:PutScalingPolicy",
                "autoscaling:PutNotificationConfiguration",
                "autoscaling:UpdateAutoScalingGroup",
                "elasticloadbalancing:CreateLoadBalancer",
                "elasticloadbalancing:ModifyLoadBalancerAttributes",
                "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
                "elasticloadbalancing:ConfigureHealthCheck",
                "iam:CreateRole",
                "iam:PutRolePolicy",
                "iam:CreateInstanceProfile",
                "iam:AddRoleToInstanceProfile",
                "iam:PassRole",
                "sns:CreateTopic",
                "sns:ListTopics",
                "sns:Subscribe",
                "s3:CreateBucket",
                "s3:Get*",
                "s3:Delete*",
                "s3:List*",
                "s3:PutObject"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:Delete*",
                "ec2:DisassociateRouteTable",
                "ec2:releaseAddress",
                "autoscaling:Delete*",
                "elasticloadbalancing:DeleteLoadBalancer",
                "iam:RemoveRoleFromInstanceProfile",
                "iam:Delete*"
            ],
            "Resource": "*"
        }
    ]
}

I added some more SNS actions.

                "sns:CreateTopic",
                "sns:Publish",
                "sns:ListTopics",
                "sns:Subscribe",
                "sns:CreateTopic",
                "sns:GetTopicAttributes",
                "sns:ListSubscriptionsByTopic",

The auto scaling is not working I'm stuck at this point

Issue was caused by not having an AWS market place license for the secondary HA unit, went to the market place and added a secondary subscription.

After deploying in HA what is the default user name and password because the conversion dosnt carry over the username and password I cant log into the Firewall after the conversion.

Hi Vitale,

Thanks for the feedback and update. Someone from our Solutions Architect team will reach out to touch base with you. Ping us at aws.marketplace@sophos.com if you need anything else.

Guys @ Sophos I dont mind being the beta tester But I have a live AWS production environment and need stable HA firewall implementation ASAP I have benn patient

1) Waited for multiple sophos  releases

2)Deployed and talked to product engineering about set backs of HA deployment

3) Got on a phone call with video recording to Show current Sophos UTM 9 HA pair cloudformation issues and adjustments that Sophos needs to take,

4) Unable to pick my own production DMZ or Public subnets when running a HA conversion ? This needs to be fixed asap Sophos by default takes existing Subnet and as an example changes the Third octet for a New public subnet  in my case sophos created 10.74.1.0 public subnet One and Public subnet two 10.74.2.0  in my prod environment My subnets are 10.74.3.0 and 10.74.4.0 Sophos needs to adjust and let the customer choose where the HA conversion AMI are deployed.

With the Above point NO one can use the HA cut over in a production environment without making live route table change or adjustments.

5) When deploying the HA conversion Unable to login to the New HA pair firewalls this is an issue No default user name or password work including the one from the Source conversion firewall where the HA conversion was started.

6) The assumption that two new HA AWS AMIs are created during the conversion is ridiculous, If I already have a single production Sophos firewall running , All I want is to Hit the HA conversion wizard and have one warm firewall spin up and attach itself to my current production firewall.  This is clearly not the behavior in the cloud formation template.

The behavior when doing a new Warm HA conversion creates two new Sophos AMI's firewalls in their own public subnet inside my VPC. This dosnt make life easier it creates more complexity with end customer having to make route table and ACL changes on their production environment.

What was expected with this release.

1) To run HA conversion wizard "Warm"

2)two have a single AMI spin up

3)That new AMI is synces with S#, SNS,

4)The current production source firewall that is working and where the conversion for HA has been initiated from stays in place and works to sync with S3, SNS, auto-scaling etc.... to create HA fail-over.

This has not been done

Instead sophos took the HA conversion utility within the production firewall AMI that a comapny might have and created a path for a brand new (Subnet, HA Firewall Pair AMI, and isolated the deployment within your production VPC) 

How is this useful at all?

The consideration is the customer and company, again I wrote above what is expected and required for this to be successful, Again I'm willing to work with Sophos engineering team to test live in my prod environment.

Byron J. Watson  you are the Security Solution Architect , I did speak with you and let you video record all the issues above.  What is the update ?

Hi Vitale,

I sent you an email asking for a time to coordinate a phone call, but let me answer your questions here for other readers.

1. Two AMIs vs. spinning up a new AMI as a cold/warm spare: there are a couple of reasons why we chose the option of spinning up two new AMIs. First, in the event that a customer may want to revert back to the original AMI for whatever reason, we wanted to provide a way to access the original image and still play with the HA scenario. Second, many of our customers are using Stand Alone UTM running on PV instead of HVM. PVs are not supported by AWS in the newer regions or on newer EC2 instance types; however, there were scenarios where customers wanted to keep using PV because of pricing, compatibility, etc. for older EC2 instances types. Third, we are not planning on releasing a conversion path for customers who want to convert from HA to Auto Scaling. As such, the preserved image provides a way to test the HA on the new AMIs but also convert to Auto Scaling from the previous image to compare the two deployment scenarios. At any rate, based on your feedback we're evaluating if we can support both methods going forward, i.e., convert by spinning up two AMIs or just add a cold/warm standby. We're hoping to have this evaluation complete here shortly and will let you know.
2. We're also looking at how we can support customers using pre-existing subnets and VPCs based on your feedback. For the Auto Scaling release this may not work as the UTM Workers and OGW instances typically require new, separate subnets, but we may be able to get this to work for the HA scenario. We'll keep you posted.
3. Unable to login to the HA spare. This is by design. The account credentials and policy settings are not transferred over to the HA spare until a failover has been initiated. The reason we chose this was to reduce locations where important information like user credentials was stored. If an attacker were to compromise user credentials on an inactive system, there were limited ways on alerting customers to the attempts. However, we're always curious to understand what customers are tying to do with UTM. Can you provide details on why you need access to the secondary system?
4. Byron did provide me with the recorded video. Thanks again for taking the time to give us your feedback.

I hope this answers your questions. If not, please reach out at aws.marketplace@sophos.com. Thanks again.

Hi Vitale,

I sent you an email asking for a time to coordinate a phone call, but let me answer your questions here for other readers.

1. Two AMIs vs. spinning up a new AMI as a cold/warm spare: there are a couple of reasons why we chose the option of spinning up two new AMIs. First, in the event that a customer may want to revert back to the original AMI for whatever reason, we wanted to provide a way to access the original image and still play with the HA scenario. Second, many of our customers are using Stand Alone UTM running on PV instead of HVM. PVs are not supported by AWS in the newer regions or on newer EC2 instance types; however, there were scenarios where customers wanted to keep using PV because of pricing, compatibility, etc. for older EC2 instances types. Third, we are not planning on releasing a conversion path for customers who want to convert from HA to Auto Scaling. As such, the preserved image provides a way to test the HA on the new AMIs but also convert to Auto Scaling from the previous image to compare the two deployment scenarios. At any rate, based on your feedback we're evaluating if we can support both methods going forward, i.e., convert by spinning up two AMIs or just add a cold/warm standby. We're hoping to have this evaluation complete here shortly and will let you know.
2. We're also looking at how we can support customers using pre-existing subnets and VPCs based on your feedback. For the Auto Scaling release this may not work as the UTM Workers and OGW instances typically require new, separate subnets, but we may be able to get this to work for the HA scenario. We'll keep you posted.
3. Unable to login to the HA spare. This is by design. The account credentials and policy settings are not transferred over to the HA spare until a failover has been initiated. The reason we chose this was to reduce locations where important information like user credentials was stored. If an attacker were to compromise user credentials on an inactive system, there were limited ways on alerting customers to the attempts. However, we're always curious to understand what customers are tying to do with UTM. Can you provide details on why you need access to the secondary system?
4. Byron did provide me with the recorded video. Thanks again for taking the time to give us your feedback.

I hope this answers your questions. If not, please reach out at aws.marketplace@sophos.com. Thanks again.