I have a database server configured on AWS and I want to restrict access to it only from my computer's IP.
The problem is as IP addresses get assigned dynamically by the ISPs, I manually need to whitelist my IP address before accessing the server from my computer, everytime I switch from my home network to some other network.
I have been able to set a static IP address for my machine, but when I try to change my ISP from local broadband to mobile internet's hot-spot or to another network different from my broadband, the connection seems to fail. Is there any way to make my machine use the same static IP while using different ISPs ?
Here's a script I use:
IP=`curl -s http://whatismyip.akamai.com/`
aws ec2 authorize-security-group-ingress --group-name GROUP-NAME --protocol tcp --port 22 --cidr $IP/32 --output text
In this example, it is adding my current IP address to the security group for use with SSH (port 22). You can modify it for your needs.
Please note that there is a maximum number of security group rules, so you will need to "empty it out" after you've hit the limit.
Related
One of the options to ssh into the instance is in-browser ssh. It only works if I allow SSH from 0.0.0.0/0 IP range.
Is there a way to get the range of specific IP address range(s) from where GCP will establish in-browser SSH?
P.S.: I am not talking about SSH from my laptop. I am talking about in-browser SSH.
The Handling "Unable to connect on port 22" error message documentation states that you can get Google's IP address range using the public SPF records.
Per the documentation, you'll need to run the three commands below from a linux VM instance:
nslookup -q=TXT _netblocks.google.com 8.8.8.8
nslookup -q=TXT _netblocks2.google.com 8.8.8.8
nslookup -q=TXT _netblocks3.google.com 8.8.8.8
You may need to install dnsutils on the vm instance to be able to use dnslookup.
I just tested it and got various ranges for IPv6 and IPv4. I believe this are the ranges you are searching for.
I also wanted to restrict SSH access to in-browser only and found this
The client IP address in the SSH connection will be part of the range 35.235.240.0/20. This range is the pool of IP addresses used by IAP to proxy the connection from your browser to your instance. So, you can create a more restrictive VPC firewall rule allowing SSH connections only from this IP address range. As a result, only users allowed by IAP will be able to connect to VM using SSH.
(from https://cloud.google.com/community/tutorials/ssh-via-iap)
In order to allow SSH access from your laptop GCP console browser, you need to find your public IP address or external IP address of your LAN. You can check it in this link.Once you have your external IP address you need to create a FW to allow SSH access just from that external IP address.
Example:
gcloud compute firewall-rules create test-ssh-example \
--action allow \
--direction ingress \
--target-tags=[TAG] \ [You can specify a tag to apply this FW rule just to the VMs with the same tag. (optional)]
--rules tcp:22\
--source-ranges \
--priority 1000
With this option, only from that IP address you will be able to have SSH access to a VM instance.
Why don't you run the command who on your ssh session, to see where the connection is originating from?
The search the excellent Cloud Platform documentation to see if an automation to allow this already exists. Otherwise write one.
This is not the best place to do your firewalling from, as its one more configuration to keep up to date. I would recommend an application firewall, or just adding a rate limit to your existing firewall. The chances of someone logging into your servers if you use keys, is virtually 0, even with a 14 character random password, and rate limited new connections. If you use keys or a password manager (as you should), use fail2ban.
When I spin up an Amazon EC2 CentOS 7 server in, say, availability zone us-east-1a, the server is automatically assigned a primary private IP address on eth0, such as 172.31.8.244/20 and a gateway of 172.31.0.1. If I then attach a second interface on eth1, I can specify the address, which needs to be within the 172.31.0.0/20 subnet (or one will be assigned to me automatically within that subnet). Eth1 will have the same gateway as eth0. Let's say I am assigned 172.31.12.121/20. I use the same security group on both eth0 and eth1, which allows SSH only in and everything out.
The problem is that when I try to SSH to eth0 from a different server, it works fine. But when I try to SSH to eth1 I get a timeout. ip addr and ip route show that both interfaces are up and have the correct routes. I can even SSH locally to eth1 and the /var/log/secure log shows the correct entries as when I SSH to eth0 bound to eth1. What do I need to do to be able to SSH to either interface from a different server?
The problem is asymmetric routing. A request to eth1 comes in eth1 and goes out eth0. The reply coming out on eth0 has a different IP address than in the request, and so it is dropped on the client side. The solution is to set up rules that allow responses to route through eth1.
First, make sure you have created an AMI of your server, because if you enter the wrong thing in following steps, you may lose all connectivity to the server and be unable to do anything but reboot it from the Amazon console web page.
Start off by setting the default route for each interface in separate tables:
ip route add default via 172.31.0.1 dev eth0 tab 1
ip route add default via 172.31.0.1 dev eth1 tab 2
To check those were properly added use:
ip route show table 1
ip route show table 2
Now you need to add rules that say to use the different tables depending on the source IP address:
ip rule add from 172.31.8.244/32 tab 1
ip rule add from 172.31.12.121/32 tab 2
You can check all of the rules with:
ip rule
You should now be able to connect to either IP address from a client machine. You can also use the bind option of SSH to connect from either interface on this server to a client machine:
ssh centos#client_ip_address -i mykey.pem (uses the default, eth0)
ssh -b 172.31.12.121 centos#client_ip_address -i mykey.pem (uses eth1)
ssh -b 172.31.8.244 centos#client_ip_address -i mykey.pem (uses eth0)
You can use both interfaces to connect to other EC2 servers in the same availability zone and for any interface that has a Public IP assigned to it, you can connect to the outside world or to other EC2 servers in the same VPC, even if they are in different availability zones.
But what if you want to connect to other EC2 servers that are in the same VPC but different availability zones? In other words, servers in the same data center. The problem is that the Private IP address is masked at 20 bits, which confines you to one availability zone. So for datacenter us-east-1 you have:
us-east-1a: 172.31.0.0/20
us-east-1b: 172.31.16.0/20
us-east-1d: 172.31.48.0/20
us-east-1e: 172.31.32.0/20
To connect across availability zones in one VPC and in one datacenter you need a 16-bit mask. ip addr will show:
inet 172.31.12.121/20 brd 172.31.31.255 scope dynamic eth1
If losf -n | egrep 172.31.12.121 shows you that this address is not in use you can add the new mask and delete the old. Note that the broadcast address has to change at the same time the mask changes:
ip addr add 172.31.12.121/16 dev eth1 brd 172.31.255.255
ip addr del 172.31.12.121/20 dev eth1
Now you should be able to connect from an EC2 server in availability zone A to another host in availability zone B, so long as they are in the same VPC, even if they do not have Public IP addresses.
Troubleshooting:
If you are having problems, try resetting both interfaces, which will remove any manual twiddling you have done. First copy /etc/sysconfig/network-scripts/ifcfg-eth0 to /etc/sysconfig/network-scripts/ifcfg-eth1, editing the second file to change the DEVICE from eth0 to eth1. Then add a line to /etc/sysconfig/network which says GATEWAYDEV=eth0. Finally, run /etc/init.d/network restart (no, it should not disconnect you). Then start over with the above commands.
I am attempting to connect to my instance via PuTTY but when I attempt to connect with the inbound rule set to my private range (i.e 192.168.2.0/24) it just won't work. When I set it to the insecure 0.0.0.0/24 all is fine. Can anyone explain, or solve this issue. I am running Windows 7 with all current updates. My IP address is not static.
The 192.168.0.0/16 CIDR range is considered a private network, which means it is not routable. This also means that AWS, when receiving the connection from the PuTTY client on your machine (which might have an IP address of 192.168.2.1, for example), does not see the remote address of that connection as the IP address of your server. Instead, AWS probably sees the remote address of that incoming connection as being an IP address from your ISP. That's why allowing "0.0.0.0" as the inbound rule works; it allows incoming addresses from everywhere.
To find out what CIDR range to use as a more restrictive inbound range for your AWS security groups, you might connect in to your instance, then do:
$ env | grep SSH_CONNECTION
SSH_CONNECTION=1.2.3.4 54068 5.6.7.8 22
In particular, you are looking for the SSH_CONNECTION environment variable. Per the ssh man page, the SSH_CONNECTION environment variable
Identifies the client and server ends of the connection.
The variable contains four space-separated values: client IP address,
client port number, server IP address, and server port number.
Thus the first part of the value, the "1.2.3.4" in my contrived example, would show you the IP address that AWS sees your PuTTY connection as coming from; you can then use that IP address as the basis for a CIDR range.
Hope this helps!
I'm trying to host a website on AWS and I came across this:
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. If you don't know this address
range, you can use 0.0.0.0/0 for this tutorial. However, this is
unsafe for production environments because it allows everyone to
access your instance using RDP.
My intention was to host my personal website. I connect through an ISP and do not have a static IP address and I'm not sure about the range of IP addresses.
Is there another way to solve this or would I be best to use a different web host such as godaddy, name.com, etc..?
The recommendation is that you don't allow RDP (or ssh if you go with a linux-based server) from the internet in general (i.e. 0.0.0.0/0).
Instead, you should restrict access to your ip (1.2.3.4/32). The problem with this is that when your ISP-provided IP address changes, you will be locked out until you adjust your security rules.
Now, for a personal web site, if you're not accessing it a lot, that's probably not a big deal. Chances are that your ip address doesn't actually change that often, and when it does you can remember to update the security group.
If you want to automate it, you can do this from a script that would query one of the many services that provide this, and then update the security group via the aws cli.
Finally, another option is to set up a VPN between your AWS VPC and your local network. This is probably overkill for your problem, but is something to consider when you want to extend your local network into AWS.
Here is a script that can automate the additional of an IP address to Inbound Security Group rules:
IP=`curl -s icanhazip.com`
aws ec2 authorize-security-group-ingress --group-name "RDS-SG" --protocol tcp --port 22 --cidr $IP/32
I recently changed port field with custom port sshd_config file on amazon ec2.
However, it doesn't respond to ssh -p1234 user#domain.com because of security groups.
I have my ssh port (22) open on security group but I need to make it 1234 but on aws console, when I changed ssh source to 0.0.0.0/1234 it says unable to find group.
So, how do I set security group right ?
You appear to have confused the port with the CIDR address.
The CIDR annotation describes the range of addresses which are permitted to establish connections on a port - if you want anyone to be able to access the port from any address, use 0.0.0.0/0.
You then specify the port separately, which in your case is 1234.
Please note that changing your ssh port is not considered as a best practice. Network scanners will find your 'hidden' ssh port in no time. It is actually worse than having ssh on 22 since it provides you with false sense of security.
Consider restricting the actual scope of this service to your home / office IP addresses (as instructed by AWS Trusted Advisor)
You can even utilize Dome9 to have this port normally closed and only opened on demand.
(disclaimer: I'm a proud Dome9'er)