I am operating in US-West Availability Zone.
I was trying to solve the problem for ELB and I courageously or stupidly changed the Source IP of my default VPC security group to fix it. It did not fix the original issue but now I am in to another issue.
Now I am trying to restore the default VPC security Group setting in my Amazon Web Service account.
As per my knowledge the default VPC is very restrictive.
I don't quite remember what was the value for inbound source IPs.
The issue is that I have changed the Inbound rule's Source IP (from its original value which I do not remember) to Anywhere (0.0.0.0/0) in the default VPC Security group on AWS Console.
So how do I bring back the original default VPC security rule inbound IP setting that is applicable to my availability zone?
What is the implication of this? As a precaution I am not using default VPC Security Group on any of the EC2 instance or ELB.
Default VPC security group can not be deleted
You can make changes though
The default VPC security group simply points to its own Group-ID.
So you know how to restore the default VPC rule if you mess up with it.
You can search the informations inside AWS Forum https://forums.aws.amazon.com/forum.jspa?forumID=58
Many people open tickets similar to your problem.
Related
I've deployed a new AADDS in Azure. and ever since Im getting a warning on this domain service that it requires:
"Required network security group update
We have detected that your Network Security Group for Azure AD Domain Services does not include the Service Tag ‘AzureActiveDirectoryDomainServices’. We are in the process of making service-side changes which will result in a service disruption for you unless this Service Tag is present. To avoid this service disruption, the Service Tag needs to be added by January 18th, 2021. To make this change, follow the steps in this document: Network security groups and required ports. If you do not make the change, we will make the change for you starting January 22nd, 2021 so that your service will not be impacted.
More about service tags."
Now.. I have already added the required port the way they have explained in their article, but im still getting this warning everytime I check the "view health" in my AADDS.
Can anyone suggest a way forward to resolve this issue?
They said that they would automatically resolve the issue for me on the 22nd but nothing has happened
You may double-check if you have these NSG rules in the NSG associated with the virtual network subnet that your managed domain is deployed into.
Furthermore, you can verify if your configuration or function is working well excluding it's just a warning. Also, verify if there is any Azure policy in your subscription trigger that warning.
So the solution was,
I had deployed the domain in a Resource Group called AADDSRG and the domain controller had its own NSG.
The server was in a separate Resource group and had its own NSG but it is part of the same V-Net as AADDS.
I had a chance to Microsoft representatives and they got me to add the Port to the second NSG.
I still do not understand why I had to do that, since they should only have access to the domain controller, and not the server that is connected to it.
But regardless, this fixed the issue.
Hope this information helps someone in future.
Here's my situation...
I'm trying to deploy an application to several customers. Each customer will have their own VPC (for security and isolation purposes). The IP addresses for the application cannot be changed. I want to use VPC Peering in order to manage all customers.
So.. On one hand I need a subnet that's identical across all VPCs. I also need a subnet in the VPC that's unique (otherwise peering falls apart).
In the AWS Console I'm able to build this scenario and it works.
Looking at a describe_vpc call there appears to be a CidrBlockAssociationSet which is a list of CIDR blocks.
Does Terraform support this? Workarounds?
Thx
I have been trying to setup a Private Hosted Zone in route53 with current associated VPCs in eu-west-1 and will soon add more. I have conformed that my VPC has DNS resolution option set to yes and necessary DHCP option sets are also created. I have added a DNS record under the domain.local domain and it works fine. However, the issue comes when I tried to created a sub-damain dev.domain.local and tried to associate with the same VPC. I see the following error
"A conflicting domain is already associated with the given VPC or Delegation Set."
My intention is to have one parent private zone as zorotools.local and several subdomain such as dev.domain.local, staging.domain.local, prod.domain.local etc.
I would then associate ec2 instances with these DNS names.
So, please let me know what mistake I am making and how should I proceed.
Just create records with the remainder of the FQDN filled out. So in this case create "server1.dev" and it will resolve to "server1.dev.domain.local".
I have 2 AWS EC2 instances living inside 2 different subnets of my vpc.
I would like to allow the ruby app running on the first instance (say App#1) to call the endpoints of the app (say App#2) running on the 2nd instance.
I would also like my users to directly call the endpoints of App#2 from their browser.
Here is what I have tried (and mostly failed):
[Sucess!] I added the known IP addresses of my users to the inbound rules of Load Balancer Security Group of App#2 and have confirmed that they can access App#2 endpoints from their browsers.
[Fail!] I added the Load Balancer Security Group ID of App#1 to the inbound rules to the Load Balancer Security Group of App#2. But my logs tell me App#1 cannot access the endpoints of App#2.
[Fail!] I added the VPC Security Group ID of App#1 to the inbound rules of the Load Balancer Security Group of App#2 - nope, still doesn't work.
(Somehow, when I launched the instance for App#1, aws automatically created 2 security groups for this instance - one for VPC and one for load balancer... I have no idea why/how this happened...)
[Fail!] I added the CIDR for the subnet App#1 was in to the inbound rules of the Load Balancer Security Group of App#2. Still no joy.
[Success...Sort Of] I assigned an elastic IP for the instance running App#1 and added that to the inbound rules of the Load Balancer Security Group of App#2. This works but I would rather not use this method since I would like to elastically scale my App#1 in the future and I do not know how to automatically assign more elastic IPs for the new instances when they spin up, add them to the inbound rules, and then somehow remove them when they shut down.
I feel like there has got to be a really clean solution to this problem and I am probably missing something painfully obvious. Can someone please give me a hint?
Any help would be appreciated!
It sounds like you might be using the public IP address of your load balancer, so it looks like the traffic is coming from the outside. Try using the private IP/DNS if there is one, or setting up a second, internally-facing load balancer.
So App#2 is in public subnet, App#1 is in private subnet. For example, the diagram will be something like:
Internet => LB#2 => App#2:80 (in public subnet) => LB#1 => App#1:4567 (in private subnet)
Let's open all inbound rules in all instances and loadbalancers, check if you can access it via internet,
then apply security groups on each layer each time, don't change all of them at same time.
Let me know which layer has issue.
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.