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.
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.
I've got an azure sftp container instance properly set up finally but I ran into a wall while configuring security for it (much like the person here).
My basic flow is this:
PIP on Azure ->
-> Load balancer using PIP to be reached by the wider web ->
-> Load balancing rule to backend subnet ->
-> SFTP container group living on that subnet ->
-> SFTP container in that group
Nothing special and I verified before associating the NSG that the network is operating as intended. Connection to the SFTP server is functioning properly. The problem is, after associating the NSG with the container group's subnet, I was still able to connect to it without any configured rules. Even after applying a rule # priority 100 to deny all traffic, to rule out something I may miss from the default rules, I can still get in.
After reading how NSG flow logs don't include container instances, I'm torn between believing users have NSGs working with container groups but are missing logs, and the possibility that NSGs don't work with container groups at all. If anyone has any guidance on properly using NSGs here, please let me know. Otherwise, if there's another tool I should be using, please recommend it (Azure Firewall is included in the container group tutorial, but I believe completely overkill for what I need and also prohibitively expensive).
EDIT: Adding picture of NSG rules -
After my validation, currently, the NSG associated with the ACI subnet does not work in this scenario for the SFTP container service behind an Azure load balancer. This NSG rule does not block the client's public IP address and it works like without it.
As a workaround, you could restrict the SFTP access with NGINX reverse proxy like this blog or add a service like Azure Application gateway reverse proxy to direct your public-facing traffic to your backend instance.
I want to enable traffic from my webapp (that sits inside the VNET and has its private IP) to Application Gateway (that is deployed to the same VNET and has NSG attached to its subnet).
How can I do it?
If I add webapp outbound ip to NSG as allowed - traffic works fine, but I do not want to hardcode this ip.
If I add "Internet" service tag it works as well, but it is too broad for my taste.
I could not find any other relevant service tags for me (tried "AppServiceManager", "AppService" and "AppService.AustraliaEast").
Also checked this document (and had to update the filename to last Monday! :) ) but could not find the IP that worked for me (52.187.231.76).
Ideal solution would be to allow only VNET traffic, but this did not do the trick as well... All ServiceEndpoints are there.
Checked with Azure support. Unfortunately there is no service tags available to do this yet.
Workaround - to manually add security rules for each application that supposed to access Application Gateway to allow Outbound IPs.
To do so - go to azure portal, to the application that needs to be able to access App GW. Go to properties blade and copy Outbound IP addresses. Then go to NSG and create a new inbound security rule to allow access from all of those IPs (at least it can be 1 rule).
According to Azure support those IPs should not change unless you recreate the whole webapp and the app can only cycle through those IPs.
I'm getting started using docker-machine on my Windows 2016 box. I'm trying to create some VMs in Azure but I have a particular network security group that I want for it to use and which already exists in Azure. I ran docker-machine create --driver azure and looked over the small help text which tells me how to set the resource group, subnet, etc but I don't see an option for network security group. Is there a way to specify an existing network security group for docker-machine to use when creating VMs in Azure?
Ok, so according to the documentation, you should use Subnet\VNet or Availability Set. The reason you are asking this is because you don't understand how NSG's work in Azure. NSG's are attached to a VNet or Subnet, so deploying a VM\Container into that Subnet\VNet will effectively attach that NSG to the entity you are deploying. But as the documentation states - "Once the machine is created, you can modify Network Security Group rules and open ports of the machine from the Azure Portal.".
So I suppose it creates a new NSG each time you deploy something, so there's no way to achieve that what you are trying (at least for now).
What you could try is deploy to an existing VNet and check if no new NSG are being created specifically for that container host which you are deploying. If that holds and you have an NSG in place, you've achieved what you want exactly.
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.