I have 2 VM instances under 2 separate projects. When I go into the firewall page, all rules are tied to the first instance. Is there a way to specify which instance the rule applies to? Another issue may be that one was built on us-central and the other on us-east1.
Related
I'm trying to get the company to use Azure Firewall as we start to move production workloads to Azure, however the network team have stated there are limitations when using Azure firewall. For example they have saod the Firewall reboots or drops all connections when you update a rule on it?
Is this true? Would anyone know of any limitations of using Azure Firewall. The network team prefer to use Checkpoint firewalls in Azure which are fine, but I would rather use Azure firewall, if its not going to fall down eveytime we do an update to teh rules.
That just doesn't sound like its right, as Azure Firewall is prouction ready resource.
• Please find the link below for detailed known documented limitations of Azure Firewall: -
https://learn.microsoft.com/en-us/azure/firewall/overview#known-issues
It clearly states all the issues regarding configuration of rules, NAT of UDR and other features of Azure that are used in integration with it. There, it clearly states that for configuration updates regarding the Azure Firewall, it takes three (3) to five (5) minutes on average to take effect independently, i.e., if multiple configuration updates are done to the Azure Firewall, each configuration update takes separate time to take effect and reciprocate it in its functioning. Thus, please check this, and as for updating of rules is concerned, I don’t think the existing rules defined on Azure Firewall are dysfunctional or the Azure Firewall as an appliance goes down for few periods of time when the rules are getting updated.
How can we change the IP Restriction Rules while the Cloud Service is running. (A reboot is acceptable).
For example, add / remove an IPAddress.
We don't really want to redeploy and we definitely don't want to repackage.
https://learn.microsoft.com/en-us/azure/cloud-services/schema-cscfg-networkconfiguration
Using Network Security Groups. This can be done at any time.
https://learn.microsoft.com/en-us/azure/virtual-network/security-overview
In NSG overview add either the tag or IP range and the desired restriction or allow.
I created two VMs. I did not created Availability Set for them because I did not know I will need it. I do not want to re-create those VMs, since I needed one month to configure and install everything on them.
Now I created LB but I can see that I can associate it only to one VM or to Availability Set which will contain multiple VMs (which is as I stated not possible because it can be configured only during the creation of VM).
I try to associate LB to VM but I can see that I can select only one VM.
I cannot believe that I cannot select at least two VMs for LB??? Is this really working in this way?? This is really surprising for me and very disappointing.
Please suggest me if there is some quick work around how to associate Load Balancer with same resource group and virtual network to multiple VMs.
Please!
Is there really not any kind of work around for this? I checked this and it was not mentioned how to associate multiple VMs.
Azure load balancer with single VM
You can use a standard load balancer (you would need to attach standard public ips to the vms). The only way to make it work without Availability Set. Thats how it is in Azure, sadly.
https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-standard-overview
Does any one know why on rebooting web/worker instance from the Azure portal the fire wall rules set in that machine instance gets removed.
I know that the best practice is to use VNET and NSG and there is no logic from adding the rules to one instance while these rules are not being applied to the other instances but it would be nice if I know what is happening on Rebooting Instance (Not the Service) from the portal.
I'm puzzled by the role played by several groups that seem to have been added automatically to my list of AWS security groups, connected in what I gather is the default configuration, and wonder how they work (and what about them it is safe to change). Specifically there are three that are mysterious:
launch-wizard-1 which has an inbound rule SSH, TCP, 22, 0.0.0.0/0.
default described as "default VPC security group" which has an inbound rule for all traffic and all ports that uses itself as a source.
default_elb_... described as "ELB created security group used when no security group is specified during ELB creation - modifications could impact traffic to future ELBs" which has an inbound rule allowing HTTP from all IP addresses
The first two do not appear to be connected to any other security groups, while the latter is the source for a for an inbound HTTP rule in each of the security groups for my Elastic Beanstalk environments.
What do these do three groups do? Can I change them? Or change connections to them?
For example, the latter rule seems to have the effect of allowing HTTP traffic from anywhere to all of my EB environments. Can I change this rule to limit IPs (to to all environments)? Can I "un hook" the rule as a source from a given EB environment (e.g. replacing it as a source with a range of IPs)?
Looks like you've got a handle on what a security group is: a stateful firewall that is applied to EC2 instances.
When you manually launch an EC2 VM from the web console, AWS will provide you with the option of reusing an existing security group or creating a new one. When you create a new one, the default rule is SSH (port 22) and a default security group name of "launch-wizard-#".
Unfortunately, since a security group can be used by multiple EC2 instances, they are not cleaned up when you delete a VM. So if you deleted the VM that launch-wizard-1 was created with, it does not delete the security group.
Onto the "default security group for VPC". When you create your VPC, a default security group is created alongside with it. When EC2 instances are launched into a VPC subnet, they will have the default security group assigned to them if another is not specified. (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#DefaultSecurityGroup).
So what does that rule mean that allows it to talk to itself? By default, all inbound traffic is denied by a security group. This 'talk to itself' inbound rule indicates that if two VMs both have this rule assigned to them, they will be allowed to communicate with one another on all ports. Should you use this default group? No. Create unique security groups that exercise the rule of least privilege (only open the ports you need to the instances that need them).
Unfortunately, I do not have much elastic beanstalk experience, so this is where my answer turns to assumptions. In the little that I have played with beanstalk, I recall that it created auxiliary resources in your account. This appears to the be the case with your Elastic Load Balancer (ELB). As the description indicates, when Elastic Beanstalk needs to launch a new load balancer, the load balancer will use this default group unless you specify another. I believe that this link documents how you would do this (http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.elb.html).
In all cases, I would recommend against using the default security groups in favor of individual firewall rules unique to that instance's security needs.
Can you change or delete these?
launch-wizard-1: Yes, you can delete or modify this group. Since you mentioned he is unused, go ahead and nuke him.
default: VPC is finicky about some of the default resources that it creates. I tested it on my account and I cannot delete it. You can of course modify it, but I'd recommend instead just not using it.
default_elb: If I remember properly, elastic beanstalk uses cloudformation to create additional resources, such as an ELB security group. You can modify this security group, but it will create inconsistencies between the cloudformation definition and reality. For your specific question, you can change the range of allowable IPs, but if you're writing rules on a private IP you won't be able to cross environments if the environments are deployed to separate VPCs.