In my Amazon EC2 instance I am configuring the firewall to allow access from an IP address 1.2.3.4. The autocomplete feature is completing the addresses to 1.2.3.4/32. I'm not sure why, and I don't see any mention of this in the AWS documentation.
I think that this might make sense if I were configuring an address of the type 1.2.3.0 to allow connections from the entire C block, but I am configuring a specific address. It this some usage of the CIDR notation that I am unfamiliar with? What is the autocomplete trying to suggest with this notation?
The /32 specifies a single address. A c block's CIDR would be 1.2.3.0/24, which would include 254 usable addresses.
Here's a nice little "cheat sheet" for CIDR stuff: http://www.oav.net/mirrors/cidr.html
Related
I have successfully assigned an IPv6 block to my VCN. When I try to assign a block to my subnet within the same VCN, it asks me to choose an IPV6 CIDR block.
The IPv6 assigned to my VCN: 2603:c020:4002:6c00::/56
I am trying to assign the following to my subnet:
2603:c020:4002:6c91::/64
The GUI lets me edit only the '91' part in there, as demonstrated above.
When I confirm the change, it fails with an error (image attached). I have tried destroying the resources and recreating the VCN, subnet, etc., for troubleshooting. IPv4 works fine, and I can create resources without any hiccups.
Is that a bug in OCI? I have been assigned 2603:c020:4002:6c00::/56 to my VCN. I cannot use 2603:c020:4002:6c91::/64 in my subnet because it belongs to 2603:c020:4002:6c91::/56. I can use 2603:c020:4002:6c00:91::/64 in my subnet. But then, Oracle is not letting me do this and giving me the error "NotAuthorizedOrNotFound". The error is inevitable as 2603:c020:4002:6c91::/64 does not belong to my VCN.
I may be wrong here; my IPv6 skills are not top-notch.
In any case, please help. I am a free tier subscriber and cannot raise a ticket directly.
I used a wizard to create the VCN. The wizard is not IPv6 aware, and I assigned an IPv6 manually to it later via the web GUI. The same wizard creates two subnets - one public and one private. I was trying to attach an IPv6 range to those subnets. But it was giving me an error. I created a new subnet in the VCN and was able to assign IPv6 to that subnet.
The solution was - manually create a new subnet in the VCN and add IPv6 to it.
I am unable to connect to amazon ec2 instance (public domain) form office network. It works fine outside the office network.
Looks like something is getting blocked in the network. Not sure how to figure out or which logs need to be checked to find out what exactly is getting blocked.
Error Message:
ec2-54-218-186-23.us-west-2.compute.amazonaws.com took too long to respond.
Typically, if the connection takes too long to respond, the problem is due to the Security Group assigned to the instance. Check that it is allowing Inbound access from the entire Internet (0.0.0.0/0) on your desired port (Windows RDP port 3389, SSH port 80).
Of course, opening up access to the entire Internet is not good for security, so it is better to limit it to a smaller range of IP addresses, such as your corporate network and your home IP address.
Reason
Security groups enable you to control traffic to your instance, including the kind of traffic that can reach your instance. For example, you can allow computers from only your home network to access your instance using SSH. If your instance is a web server, you can allow all IP addresses to access your instance using HTTP or HTTPS, so that external users can browse the content on your web server.
Before You Start
Decide who requires access to your instance; for example, a single host or a specific network that you trust such as your local computer's public IPv4 address. The security group editor in the Amazon EC2 console can automatically detect the public IPv4 address of your local computer for you. Alternatively, you can use the search phrase "what is my IP address" in an internet browser, or use the following service: Check IP. If you are connecting through an ISP or from behind your firewall without a static IP address, you need to find out the range of IP addresses used by client computers.
Warning
If you use 0.0.0.0/0, you enable all IPv4 addresses to access your instance using SSH. If you use ::/0, you enable all IPv6 address to access your instance. This is acceptable for a short time in a test environment, but it's unsafe for production environments. In production, you authorize only a specific IP address or range of addresses to access your instance.
THE SOLUTION BEGINS HERE
Your default security groups and newly created security groups include default rules that do not enable you to access your instance from the Internet. To enable network access to your instance, you must allow inbound traffic to your instance. To open a port for inbound traffic, add a rule to a security group that you associated with your instance when you launched it.
Adding a Rule for Inbound SSH Traffic to a Linux Instance
In the navigation pane of the Amazon EC2 console, choose Instances. Select your instance and look at the Description tab; Security groups lists the security groups that are associated with the instance. Choose view rules to display a list of the rules that are in effect for the instance.
In the navigation pane, choose Security Groups. Select one of the security groups associated with your instance.
In the details pane, on the Inbound tab, choose Edit. In the dialog, choose Add Rule, and then choose SSH from the Type list.
In the Source field, choose My IP to automatically populate the field with the public IPv4 address of your local computer. Alternatively, choose Custom and specify the public IPv4 address of your computer or network in CIDR notation. For example, if your IPv4 address is 203.0.113.25, specify 203.0.113.25/32 to list this single IPv4 address in CIDR notation. If your company allocates addresses from a range, specify the entire range, such as 203.0.113.0/24.
Choose Save.
You can find detailed solution here
I have an Amazon EC2 instance that hosts different services (cassandra db, elasticsearch, rabbitmq, mysql...) used by several developers at different locations. Since these developers have dynamic IP addresses, and this EC2 instance is used only for development, I left inbound access to required ports opened to 0.0.0.0. I'm aware that this is absolutely not recommended, and I should limit access, but I don't want to change the rules every day as someone's IP address change.
However, I just got report from Amazon that my instance is used for DoS attack, so I would like to fix this.
My question is if it is possible to make a rule that will limit access to several ranges such as:
94.187.128.0 - 94.187.255.255
147.91.0.0 - 147.91.255.255
Definitely yes, because the ranges you meant aren't just ranges but match CIDR.
The range which cannot be expressed as CIDR won't be accepted:
You can use IPcalc or similar site to make it easier.
If it fits you, you can use port range like 2000-3000, or, better, use custom ports for the services. Then the range will be e.g. 2000-2001, and using port ranges you can fit one user into one rule.
Alternative, more secure but more difficult way: a web page, user connects there with proper security key. If the key is recognized then a script on the server adds rule to a group using the client's IP. Another script by cron deletes the rules older than X hours. To check it deeper you may want to look e.g. here: On apache side check Two-way SSL authentication, on AWS side check API and Command Overview
I'm trying to add a IPv6 address to the security group of an EC2 instance, but I need to specify it as a CIDR block. It's a full IPv6 address, like this fake address: 2600:1003:c10c:b42c:1956:fed1:db13:ff42. How can I convert this to a CIDR block/range?
As vcsjones said, AWS security groups do not support IPv6 - primarily because EC2-VPC does not support IPv6.
See this thread on the AWS forums for some relevant info.
This thread has more info on Amazon's lack of support for IPv6 on EC2.
Okay, so we implement Recaptcha in production. We get errors because it can't reach the IP address it needs to use the service. We open a port for the IP address to reach Google. No problem. We do that and configure that IP address explicitly to work. It works great. Then, the next day, we start getting errors again because Recaptcha is using a different IP address. I can allow requests from that IP address, too, but now I'm unsettled. Where are these addresses coming from? How do I configure this to work reliably?
Recatpcha from Google can use any Google IP address and there are lots of them.
Ran this from Windows:
_netblocks.google.com text =
nslookup -type=TXT _netblocks.google.com
"v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all"
That's all the network Google uses currently. These can change so check them often.
Google suggest allowing port 80 to all IPs outbound, this highly insecure. They recommend going through a proxy server but again that is highly insecure if your web server is an DMZ. Proxy aware trojans do exist. All that need to be done is exploit a vulnerability to execute arbitrary code and you can create reverse connection on port 80 through a proxy server to download the payload. Then it is trivial to escalate privileges and own the box. I don't mean just Windows servers but Linux as well. I've done it in lab environment on security was on. It's really easy to do.
This is the Google website I got this from:
http://code.google.com/p/recaptcha/wiki/FirewallsAndRecaptcha
I wanted to append to this answer with more recent information. The documentation that Chris is pointing to does not include all of the TXT records necessary to dig (thanks Google):
_netblocks2.google.com (IPv6 subnets)
_netblocks3.google.com (Additional IPv4 subnets)
In my particular case, the _netblocks3 entry contained 2 large /19's that made my initial rule ineffective
(I found additional references here: https://support.google.com/a/answer/60764?hl=en)
Perhaps you should be using a hostname rather than IP