We have a system running on Amazon's Beanstalk.
We would like to limit access to the server to HTTPS only.
When blocking HTTP on the environment settings - it prevents accessing through the beanstalk DNS.
However, if someone knows the public IP (or name) of any of the servers - he can access them directly through HTTP. It seems that the LB forwards the requests to port 80, so we can not change the security group and remove port 80.
Is there a simple way, to limit HTTP access to be only from the LB?
Thanks
You should be able to do this through EC2 Security Groups, which is an Elastic Beanstalk environment property.
By default this allows connections to port 80 from any IP address, but you could remove that rule or replace it with your own IP address (for testing purposes).
Failing that, you could reroute all HTTP traffic to HTTPS at the application level or simply test the CGI property *server_port_secure* and refuse to answer.
Yes, you need http/80 to be open for health-check to work. The option for you is to redirect all the other requests (except the health check URL) to use https - This way though the port is open, you "dont serve any data in an insecure way".
You have at least two options:
1 - set the Security Group Policy that allows access on port 80 from the Load Balancer only. IMPORTANT!!! Do not use the Load balancer IP in the instances' security group. Use the Load balancer security group ID instead.
2 - remove the public IPs from the instances. You should be good if all your EC2 instances have a private IPs and the ELB has a public IP.
Related
I have an autoscaling istance group, i need to setup a Proxy/Load balancer that take request and send it to the istance group.
I thinked to use a Load balancer, but I need to grab both HTTP(S) and TCP requests.
There is some way (or some workaround) to solve this?
EDIT: The problem is that from TCP LB settings i can set the backend service (the managed group that i need to set) only for one port.
For your use case, a single load balancing configuration available on Google Cloud Platform will not be able to serve the purpose. On the other hand, since you are using managed instance groups (Autoscaling), it can not be used as backend for 2 different load balancers.
As per my understanding, the closest you can go is by using Network load balancing (TCP) and install SSL certificate to handle HTTPS requests
on the instance level.
So for a project that I am working on at my office, I have a .NET application that will be storing and retrieving data to/from an AWS RDS MySQL Server that I have setup. The problem that I have run into is that port 3306 is not open on the work network.
I have reached out to my networking department to see what they can do about opening this port. They asked me if there was a way to set a static IP to this AWS RDS Instance. They only want to open the port based on the server's IP address rather than open the port 3306 completely for security reasons they say. After some research, I have seen that it is possible to set an elastic IP (similar to static IP?) on an AWS EC2 instance but I am curious about setting a static IP on an AWS RDS Instance. I did not see anywhere on the AWS Dashboard about setting a static IP for my RDS Instance. The reason behind the static IP is so that when the IP that is associated with the endpoint DNS that they provide changes, they wont need to adjust the firewall settings to accommodate this change.
Is it possible to have the port open for only this specific DNS
endpoint that AWS provides? If not, is it possible to set an IP
to static on the RDS instance?
What sort of security concerns are there if they were to completely open port 3306?
Thank you!
You don't need a fixed IP for RDS Instance. When you create a RDS instance AWS service defines a URL for your instance. This URL is fixed. Even in case of IP change the URL will still route to the correct instance.
You can tell your IT team to create a firewall rule in port 3306 for the RDS instance URL and it will work fine.
About the security, the idea is to close the inbound connections on port 3306 to your site. This will restrict anyone trying to connect to your internal instances at the same time that you can connect to all hosts in the internet using this port. There is no need to close all the outbound connections. But...
Is a information security best practice to apply the least privileged access principle. This means: only allow what is specificaly needed. If they open the port for all hosts, maybe in the future, someone can discover a new vulnerability and exploit it, because no one in your IT team will remember why was needed to open the port for all hosts. So.. they keep open only what is needed.
I have set up an Google Cloud Compute Instance:
Machine type
n1-standard-1 (1 vCPU, 3.75 GB memory)
CPU platform
Intel Haswell
Zone
us-east1-c
I can ssh in using the external address.
I have installed the vncserver and can access it on port 5901 from localhost as well as the internal IP.
I am trying to access it from the static, external IP address but it is not working.
I have configured the firewall to open to port to 0.0.0.0/0, but it is not reachable.
Can anyone help?
------after further investigation from the tips from the two answers (thanks, both!), I have a partial answer:
The Google Cloud Compute instance was set, by default, to not allow
HTTP traffic. I reset the configuration to allow HTTP traffic. I
then tried the troubleshooting tip to run a small HTTP service in
python. I was able to get a ressponse from the service over the
internet.
The summary of the current situation is as follows:
The external IP address can be reached
It is enabled and working for SSH
It is enabled and working for HTTP
It does not seem to allow traffic from vncserver
Any idea how to configure the compute instance to allow for vncserver traffic?
If you already verified that Google Firewall or your VM are not blocking packets, you must make sure that VNC service is configured to listen on the external IP address.
You can always use a utility like nmap outside Google project to reveal information on the port status.
enable http/https traffic form the firewall as per the need. it will work!!
The Google Cloud Compute instance was set, by default, to not allow HTTP traffic. I reset the configuration to allow HTTP traffic. I then tried the troubleshooting tip to run a small HTTP service in python. I was able to get a response from the service over the internet.
As such, the original question is answered, I can access Google Cloud Compute Instance External IP. My wider issue is still not solved, but I will post a new, more specific question about this issue
TLDR: make sure you are requesting http not https
In my case i was following the link from my CE instance's External Ip property which takes you directly to the https version and i didn't set up https, so that was causing the 'site not found' error.
Create an entry in your local ssh config file as below with mentioned local forward port. In my case its an example of yarn's IP, which I want to access in browser.
Host hadoop
HostName <External-IP>
User <Local-machine-username>
IdentityFile ~/.ssh/<private-key-for-above-user>
LocalForward 8089 <Internal-IP>:8088
In addition to having the firewall rules to allow HTTP traffic in both Google Cloud Platform and within the OS of the instance, make sure you install a web server such as Apache or Nginx.
After installing the web server, you connect to the instance using SSH and verify you do not get a failed connection with the following command:
$ sudo wget http://localhost
If the connection is positive, it means that you can access your external URL:
http://<IP-EXTERNAL-VM>
Usually there are two main things to check.
1. Port
By default, only port 80, 443 and ICMP are exposed. If your server is running on a different port, create a record for the same.
2. Firewall
Make sure you are allowing http and https traffic based on your need.
oua re
For me the problem was that I set up the traffic for the firewall rule to be 'Egress' instead of 'Ingress'.
If anyone already initiated 'https'
just disable it and check again.
I have created a HTTP load balancer to basically redirect from port 80 to port 8080. The server on my instance is running on port 8080.
I can connect to the server directly but the LB is not able to connect to the instance, both accessing the LB's IP directly and also the health check always fails. The instance group the LB is using consist of just that single instance.
I read Google Compute Engine health checks failing
and the google-address-manager is running. However, when running ip route table list local there is no routing for my LB. The user in the above question is using Network load balancing and not HTTP load balancing (as I am) so I don't know if that is related?
Or perhaps it's related to a firewall? I have added my LB's ip address to a firewall rule that allows tcp:8080
Does anybode have any idea how can I fix this? I am not experienced with debian nor gcp.
Show I just try and run the route add command referenced in the above question? If so, how come the google-address-manager is not adding the route?
Thank you in advance!
You need to make sure that your port mapping on instance group is set to correct port, the 8080 in your case.
First, edit your instance group and change the port name and port to 8080:
Then, navigate to your http backend's settings and change the default port to the port name you've configured in your instance group.
Finally, make sure that your firewall rules allow access on port 8080 from 0.0.0.0/0 or at least from the IP address of HTTP load balancer (130.211.0.0/22)
I had the same issue and fixed it by adding a firewall rule for the health checker (which is not the same IP as your LB!). See https://cloud.google.com/compute/docs/load-balancing/health-checks?hl=en_US#http_and_https_load_balancing for instructions.
In my case, I did not configure the HTTP health check correctly.
I used "/" as path, but on my backend, "/" redirects to a login-page (HTTP 301), which responds with a HTTP 200.
The health check does not follow a redirect, every HTTP response code != 200 is assumed unhealthy (from Debugging Health Checks in Load Balancing on Google Compute Engine).
So, I changed my path to "/login", this fixed my issue.
I'm planning to create a web site that runs on several different machines in Google Cloud Compute, and I'm serious thinking to use the Network Load Balancing of Google. But I have some questions regards security and usability.
My machines can have a private ip address with the http port opened ?( we don't when some hacker is trying to get in ours servers)
My http response will have the machine own ip address or the ip in the Network Load Balance ?
Does Google protect the opened port in Google Cloud Compute machine against SYN,Pack flow attacks( like a router)?
You could use the HTTP/S load balancing to do what you want. https://cloud.google.com/compute/docs/load-balancing/http/
See https://cloud.google.com/compute/docs/load-balancing/http/cross-region-example#optional_remove_external_ips_except_for_a_bastion_host for removing external IPs.
Responses will come from the load balanced IP, not your VMs' IPs.
Yes for some types of malicious traffic, because the load balancing layer is doing full proxying. This means TCP and SSL termination both happen before your VMs.
if your machines have only private IP (RFC 1918 space) and no external IP, then configuring NLB doesn't make them externally accessible directly on port 80 (if thats what you configure for your service).
google does handle some level of attacks, but if you are like for a full-fledged ddos, then implementing additional layer on your end helps.
No. Is only possible to have the port 80(http) open if and only if the instance has a public ip address; however, it is possible to limit the machine instances affected with a bastion host.
No. Using the Network Load Balance will protect the ip address of you machine, but is possible (in theory) to gather the machine external ip address with random ip address scans or some flaw in the application.
GCE machine instances have some sort of protection, but they are susceptible to TCP or UDP flood according to securityfocus.