Google cloud Compute Engine refuse outer access through apache2 - google-cloud-platform

Today, I tried to make a blog with Google Cloud Platform.
So, I made a Computer Engine Instance and install Apache2 on Ubuntu 16.
And then, clicked the Outer IP address, but it show me "connection denied.."
Why this happen?
I allowed HTTPS % HTTP Traffic also.
And I can't find a menu like AWS's Security Group...
So, this problem irritate me...
(I'm not a English native, so documentation is so hard read.. please, give me a tip for this matter)

TL;DR - You need to open up ports using firewall rules to allow ingress traffic into your VMs.
Google Compute Engine (GCE) blocks all traffic to your VMs by default for the purpose of keeping your infrastructure secure. You can open up ports as needed and manage the security yourself. The default created network has few exceptions in terms of allowing traffic from other VMs in the network, but still does not allow traffic from outside the network.
Firewalls
Each VPC network has its own firewall controlling access to the
instances.
All traffic to instances, even from other instances, is blocked by the
firewall unless firewall rules are created to allow it. The exception
is the default VPC network that is created automatically with each
project. This network has certain automatically created default
firewall rules.
For all VPC networks except the automatically created default VPC
network, you must create any firewall rules you need. To allow
incoming network connections on a manually created VPC network, you
need to set up firewall rules to permit these connections. Each
firewall rule represents a single rule that determines what
connections are permitted to enter or leave instances. It is possible
to have many rules and to be as general or specific with these rules
as you need. For example, you can create a firewall rule that allows
all traffic through port 80 to all instances, or you can create a rule
that only allows traffic from one specific IP or IP range to one
specific instance.
Firewall rules are connection tracking, and therefore only regulate
the initial connection. Once a connection has been established with an
instance, traffic is permitted in both directions over that
connection.
Since you say apache2 package on Ubuntu, the instructions I share here will guide you on how to open up port 80 on your VM and make it accessible through the VM's public IP. You can do the same for any additional ports as needed.
Using gcloud to allow ingress traffic for tcp:80 into your VM
# Create a new firewall rule that allows INGRESS tcp:80 with VMs containing tag 'allow-tcp-80'
gcloud compute firewall-rules create rule-allow-tcp-80 --source-ranges 0.0.0.0/0 --target-tags allow-tcp-80 --allow tcp:80
# Add the 'allow-tcp-80' tag to a VM named VM_NAME
gcloud compute instances add-tags VM_NAME --tags allow-tcp-80
# If you want to list all the GCE firewall rules
gcloud compute firewall-rules list
Using Cloud Console to allow ingress traffic for tcp:80 into your VM
Menu -> Networking -> Firewall Rules
Create Firewall Rule
Choose the following settings for the firewall rule:
Name for the rule - rule-allow-tcp-80 or any other name you prefer for this firewall rule.
Direction is ingress
Action on match is Allow
Targets is Specified target tags
Target tags is allow-tcp-80
Source IP ranges is 0.0.0.0/0 (or if you have a set of IP ranges you know will be the only ones accessing this, use them instead for stronger restriction)
Protocols and ports is tcp:80
Select Create button to create this firewall rule.
Once you've created the above firewall rule you will need to add the tag allow-tcp-80 to all the instances where this rule needs to be applied. In your case:
Open up the GCE VM Instances page
Select the instance where Jenkins is running
In the VM instance details page, select the Edit link on the very top.
In the Network Tags box, enter allow-tcp-80 to apply the tag to this instance.
Select Save to save the changes.
Now give it a few seconds to a few minutes for the changes to take effect and you will be able to access the jenkins web URL.
You can also go through the documentation for Firewall rules to get a better understanding of how they work and how to configure them.
WARNING: By using a source range of 0.0.0.0/0, you're opening up the port on the VM to the entire internet. This lets clients anywhere in the world to connect to the application running on this port. Be fully aware of the security implications of doing this.

Related

Inter-subnet communication within the same VPC - GCP

I am fairly new to GCP networking and I could use some guidance. I'm sure there is a simple explanation for what I'd like to accomplish.  I believe its just a simple firewall rule but I'm not sure how to configure the rule.
I current have 3 subnets in the same VPC network. I'd like subnet-a to be a "jump-network" for admins doing work on compute instances in subnet-b and subnet-c over various ports. i.e. 22, 3389, 80, 443 etc etc. Admins will work on a jump VM (windows) in subnet-a and access compute instances (both windows/linux) in subnet-b and subnet-c. (using private IP addresses)
I'm sure there are simple firewall rules to allow connectivity between subnets inside the same VPC. Can someone help me? What are the firewall rules? 
Thanks. Any and all input from the community is greatly appreciated.  
Ive tried several firewall rules from various google searches, but I don't want to leave my network open to the malicious threat actors by incorrectly configuring the firewall.
As answered by #JohnHanley in another post
VPC subnets within the same VPC can communicate with each other. The VPC Firewall rule default-allow-internal allows all TCP, UDP, and ICMP traffic between resources within the same VPC. The key is to use the internal (private) IP address.
When creating VPC Networks, you have the option to automatically create default firewall rules such as default-allow-internal which allows connectivity between instances on any port. As mentioned, you'll just have to use the Internal IP address of the instance(s) that you are trying to connect to
You may refer to this documentation as a helpful guide for creating simple Firewall rules for your use case.

Google Cloud firewall

I have this doubt about GCP firewall rules in the default network.
I create two VMs in two different regions inside the same network and so they can ping via internal ip each other. Why if I delete the firewall rule default-allow-internal they are still able to ping them each other via internal ip?
Instead, if I also remove the default-allow-icmp rule they are not able to ping each other via internal ip.
As per the GCP documentation default-allow-internal allows ingress connections for all protocols and ports among instances in the network. If you delete this FW rule instance can be pinged using the FW rule default-allow-icmp and it's intended behavior.
FW rule default-allow-icmp Allows ingress ICMP traffic from any source to any instance in the network.

2 ec2 instance interacting with each other

I am new to aws and ec2 interaction with traffic flow.
I have one ec2 instance which I am using as a web server and other as an application server.
how can my two ec2 interact with each other maintaining all the security required?
Both the ec2 machines are on the ubuntu image.
I tried adding All ICMP - IPv4 with source 0.0.0.0/0. I feel it's not the correct way I want only my other instance to access it.
I also tried adding source as other instance security group but didn't work. I was not able to ping from one machine to other
The recommended security configuration would be:
Create a Security Group for the web server (Web-SG) that permits Inbound traffic for HTTP and HTTPS (ports 80, 443). Leave the Outbound configuration as the default "Allow All".
Create a Security Group for the app server (App-SG) that permits Inbound traffic from Web-SG on the desired ports. Leave the Outbound configuration as the default "Allow All".
That is, App-SG should specifically refer to Web-SG in the Inbound rules. This will permit traffic from Web-SG to enter App-SG.
You might want to add additional access so that you can manage the instances (eg SSH), or you can use AWS Systems Manager Session Manager to connect.
Do not use Ping to test access since that requires additional settings and only proves that Ping works. Instead, test the actual access on the desired ports (eg port 80).

Cannot access EC2 via HTTP/HTTPS

I recently had to completely rebuild my AWS EC2 environment, because I accidentally deleted the SSH key, thinking it was something else. Unfortunately, I cannot access my Tomcat instance which I have confirmed is running on that EC2 instance.
I have added the following security groups for inbound HTTP traffic:
Type. Protocol Port Range Source
HTTP TCP 80 0.0.0.0/0
HTTP TCP 80 ::/0
Custom TCP Rule TCP 8080 0.0.0.0/0
Custom TCP Rule TCP 8080 ::/0
SSH TCP 22 (my IP address)
I have three security groups, and the above rules were added to the group named default:
rds-launch-wizard
launch-wizard-1
**default
I purchased a domain via AWS which I have pointed to this EC2 instance using Route 53. Previously, the DNS was available, but now it is not. However, there is a bigger fundamental problem here because I can't even ping the public IP of my EC2 instance.
I am in fact able to access my EC2 instance via SSH on port 22, which is why I was able to setup Java and Tomcat (both of which I have confirmed are running).
I suspect that some state from my previous configuration is responsible for this problem, but I don't even know where to begin looking for something.
Any help would be appreciated.
To have inbound/outbound internet access to your EC2, you need to look for three things:
Are you able to SSH from outside or inside AWS via an internet gateway (IGW)? If you can SSH from outside then you already have IGW setup properly. Otherwise, make sure your subnet's route table points to IGW by having a route like below:
0.0.0.0/0 igw-efxxxxxxx Active No
Network ACL: Go to your EC2's subnet and find its associated NACL
Create both inbound and outbound rules to ALLOW traffic to the above NACL by adding a rule like below:
100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW
Security Groups: Your security groups look good. No changes required there. However, based on the comments you made below it appears that, while you did define a security group with the proper inbound rules, for whatever reason you did not associate that security group with your EC2 instance. As a result, the inbound rules you defined were not being applied. To fix this, from the EC2 instance tag access the following:
Actions -> Networking -> Change Security Groups
Then, associate your security group with your instance by checking the appropriate box. After making these changes, your inbound rules should take effect, and you should be able to hit your Tomcat instance running on EC2.

Amazon EC2 Security Group with Host / Dynamic IP / DNS

I am seeking some guidance on the best approach to take with EC2 security groups and services with dynamic IP's. I want to make use of services such as SendGrid, Elastic Cloud etc which all use dyanmic IP's over port 80/443. However access to Port 80/443 is closed with the exception of whitelisted IPs. So far the solutions I have found are:
CRON Job to ping the service, take IP's and update EC2 Security Group via EC2 API.
Create a new EC2 to act as a proxy with port 80/443 open. New server communicates with Sendgrid/ElasticCloud, inspects responses and returns parts to main server.
Are there any other better solutions?
Firstly, please bear in mind that security groups in AWS are stateful, meaning that, for example, if you open ports 80 and 443 to all destinations (0.0.0.0/0) in your outbound rules, your EC2 machines will be able to connect to remote hosts and get the response back even if there are no inbound rules for a given IP.
However, this approach works only if the connection is always initiated by your EC2 instance and remote services are just responding. If you require the connections to your EC2 instances to be initiated from the outside, you do need to specify inbound rules in security group(s). If you know a CIDR block of their public IP addresses, that can solve the problem as you can specify it as a destination in security group rule. If you don't know IP range of the hosts that are going to reach your machines, then access restriction at network level is not feasible and you need to implement some form of authorisation of the requester.
P.S. Please also bear in mind that there is a soft default limit of 50 inbound or outbound rules per security group.