I used the AWS Ethereum Template to deploy an Ethereum stack. The stats page works, and is showing the workers and mining stats, however, the explorer page is showing
'Allow Access to Geth and Refresh the Page'
I have recreated my stacks, and went over each step twice to make sure I wasn't missing something. I also followed some of the posts on fixing this issue (setting the IP manually in my app.js), but that didn't seem to work either.
I am not sure what code to provide, but will do so if anyone asks.
Template tutorial - https://docs.aws.amazon.com/blockchain-templates/latest/developerguide/blockchain-templates-getting-started.html
I had to put my Bastion host in the ec2 security group, instead of just the alb security group. the documentation does not say this, so I am wondering if I have something else not setup correctly. I am going to close this for now, but if I find the root cause, I will update.
The step is at the very bottom of this doc: https://docs.aws.amazon.com/blockchain-templates/latest/developerguide/blockchain-template-getting-started-prerequisites.html
edit: I opened up a pull request. Hopefully AWS can tell me what I did wrong, or if the documentation is actually wrong.
https://github.com/awsdocs/aws-blockchain-templates-developer-guide/pull/2
Putting your Bastion in the EC2 Security Group (private) defeats the purpose of having a Bastion. I'm a user too, and have managed to get past this step. You should notice that these instructions require the creation of 3 subnets: 1 private, and 2 public subnets in different zones of the same region. Your EC2 instances reside in the private subnet, your ALB in both public subnets, and your Bastion in one of the public subnets.
Once you setup the security groups, the public group (such as the Bastion instance) can be reached from the Internet, and the members of the public and private group have access to each other. So you can SSH into the Bastion, and from there either hop via another SSH or a FoxyProxy setup to the private EC2s.
I assume you're looking at the stats page while SSH-ing into the Bastion and using FoxyProxy to make your local machine a Bastion proxy with access to the "internal*" DNS addresses. The page itself is being serviced by the ALB machine. So if it's missing any access, it suggests to me that the private / public security groups may be missing inbound / outbound rules to each other, so I would double check that.
Hope this was helpful.
Related
I have set up a VPC with two public and private subnets, I've got an ALB in the public subnet and a service running in the private and being routed to from the ALB.
For production my service should be accessible by everyone, which it is, however for development or staging environments I'd like it only to be accessible to users who are connected to a VPN Endpoint.
At first I thought this would be a breeze seeing as this is covered in their documentation, https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/scenario-restrict.html, but there has to be something I'm not getting right. From what I've understood the VPN Endpoint will be related to one or more security groups upon creation, and here's what I must be confused about.. should I then be able to use said security group(s) as source for my inbound rules?
Tried that and didn't get it to work, I'm not sure if the security group actually resolves to the public IP address a user is assigned when connected through the client or if it's one out of the provided Client CIDR. If it's the latter then that would make more sense but how would one go about achieving what I've tried using AWS VPN Client?
Thanks a ton in advance
I have a application on EC2 Instance which connects to a website (github.com) to download application repository (say thrice a week or bit more frequently).
I like to block the access to my VPC using NACL; So no traffic other than from this website github.com (keeping in view that NACL are stateless) can go through.
The issue i am facing is that i cannot whitelist a website using NACL; since the IP based approach is not workable (the IP's are always changing).
Can someone suggest a better solution or a fix that we can apply here.
NACL cannot resolve DNS as this requires further OSI layer that has information about the HTTP protocol details.
One option you can do here is to place your EC2 instance behind a NAT gateway, thus effectively placing it in a private subnet and it would translate to an IP that will not change when facing the public internet such as an Elastic IP. In this way, you will be able to protect your EC2 instances while referencing a consistent IP address.
Another option is to use ssh-keygen to generate a public and private key pair which you will then copy over to the respective git repo (SSH key), then block any other protocols and traffic after establishing that one-to-one trust. A more secured version of this is tackled nicely in this post: EC2 can't SSH into github
Is there an alternative to AWS's security groups in the Google Cloud Platform?
Following is the situation which I have:
A Basic Node.js server running in Cloud Run as a docker image.
A Postgres SQL database at GCP.
A Redis instance at GCP.
What I want to do is make a 'security group' sort of so that my Postgres SQL DB and Redis instance can only be accessed from my Node.js server and nowhere else. I don't want them to be publically accessible via an IP.
What we do in AWS is, that only services part of a security group can access each other.
I'm not very sure but I guess in GCP I need to make use of Firewall rules (not sure at all).
If I'm correct could someone please guide me as to how to go about this? And if I'm wrong could someone suggest the correct method?
GCP has firewall rules for its VPC that work similar to AWS Security Groups. More details can be found here. You can place your PostgreSQL database, Redis instance and Node.js server inside GCP VPC.
Make Node.js server available to the public via DNS.
Set default-allow-internal rule, so that only the services present in VPC can access each other (halting public access of DB and Redis)
As an alternative approach, you may also keep all three servers public and only allow Node.js IP address to access DB and Redis servers, but the above solution is recommended.
Security groups inside AWS are instance-attached firewall-like components. So for example, you can have a SG on an instance level, similar to configuring IP-tables on regular Linux.
On the other hand, Google Firewall rules are more on a Network level. I guess, for the level of "granularity", I'd say that Security Groups can be replaced to instance-level granularity, so then your alternatives are to use one of the following:
firewalld
nftables
iptables
The thing is that in AWS you can also attach security groups to subnets. So SG's when attached to subnets, are also kind of similar to google firewalls, still, security groups provide a bit more granularity since you can have different security groups per subnet, while in GCP you need to have a firewall per Network. At this level, protection should come from firewalls in subnets.
Thanks #amsh for the solution to the problem. But there were a few more things that were required to be done so I guess it'll be better if I list them out here if anyone needs in the future:
Create a VPC network and add a subnet for a particular region (Eg: us-central1).
Create a VPC connector from the Serverless VPC Access section for the created VPC network in the same region.
In Cloud Run add the created VPC connector in the Connection section.
Create the PostgreSQL and Redis instance in the same region as that of the created VPC network.
In the Private IP section of these instances, select the created VPC network. This will create a Private IP for the respective instances in the region of the created VPC network.
Use this Private IP in the Node.js server to connect to the instance and it'll be good to go.
Common Problems you might face:
Error while creating the VPC Connector: Ensure the IP range of the VPC connector and the VPC network do not overlap.
Different regions: Ensure all instances are in the same region of the VPC network, else they won't connect via the Private IP.
Avoid changing the firewall rules: The firewall rules must not be changed unless you need them to perform differently than they normally do.
Instances in different regions: If the instances are spread across different regions, use VPC network peering to establish a connection between them.
I have four EC2 instances, three of them running api services and another running user interface (UI). The UI instance obtains the data over api calls to another instances. Right now everthing works fine becouse im using the public IP provided for eeach EC2 service for api calling. But, mi cocern is about what happend if the public ip of service change (for any reason)? then miy application go down becouse UI cannot get the data from services. After a little researching i have found that appers to be a solution: use a vpc for connect EC2 instances over private ip (because is static) and associed the UI instance to an Elastic IP (no problem here). Sow, i have some issues:
1) I make a test putting all instances in the same vpc (and sub net) but when I do ping from one to another the pings faild. Its my approach right? or i missing some thing?
2) I read a couple of another options but im not sure what is best: Maybe i have to use an Api Gateway?. Or a NAT Gateway?
3) What is the standar practice to communicate EC2 instances in private way?
1) I make a test putting all instances in the same vpc (and sub net) but when I do ping from one to another the pings faild. Its my approach right? or i missing some thing?
For security reasons, AWS block the ICMP traffic using security group. Please enable Ping traffic (ICMP) in security group from the Ip's you are trying to connect, it's better to allow the entire CIDR block for the VPC for all traffic, will make your life a lot easy. Please make sure you do this in a test Environment only.
2) I read a couple of another options but im not sure what is best: Maybe i have to use an Api Gateway?. Or a NAT Gateway?
Also, as you mentioned that your concern is that the public IP of the Instance will change, (definitely if your Instance stop/starts for any reason), but why don't you use Elastic IP for all of your Instances, that could be on of the solution, but using this approach all of your instances will be exposed to internet, so going with private IP is the best option.
3) What is the standard practice to communicate EC2 instances in private way?
It depends on the use case, if your Instances are in the same vpc no extra configuration is required, you only need to make sure the security groups, Network Access Control List and firewall configuration are correct.
In case if your instances are in different VPC, then you can use VPC Peering/Transit gateway.
1.) You need to update security groups with the permission to ICMP traffic.
Go to your VPC -> Select Security Groups -> Select the relevant security group -> Add Inbound/Outbound rule for all traffic with CIDR of the instance subnet.
2.) Internal network is the better way as long as all your traffic gonna be internal.
Thanks
I am new to AWS and launched my first EC2 instance (Amazon Linux), got a public IPv4 address for it.
The SSH port is closed and the instance does not respond to ping. It looks as if it was totally disconnected from the internet.
All the help I found online was related to security groups and opening the proper ports (or ICMP) but I already did this, in fact I even set the corresponding security group to allow all inbound traffic.
The instance shows Online and reachabiliy check shows ok. The route table of the subnet directs 0.0.0.0/0 to the igw.
What else could this be??? There must be something else that I am forgetting.
Thanks!
EDIT: (this is still not resolved, the suggestions below, although good, did not help)
Screenshots of everything: https://florianbador.com/pub/aws-issue-screenshots/
EDIT 2:
I found what the problem is (or at last the real symptoms). The machine is available through the network for about 1 minute after its creation then it is like offline (although still on).
I tested twice with 2 other machines and the same thing happened: for 1 minute I could log via ssh, then the terminal froze as if someone put an iptables DROP rule there, and I could never reach the server again.
I tried from different IP addresses, it doesn't seem to be that something blacklists my IP, it's the whole server that becomes unreachable, from anywhere.
Any idea what this could be?
EDIT 3:
As a confirmation of Amit's answer below, here's a screenshot showing that indeed Amazon blocks accounts even when they have been reactivated, and there is no way to tell that an account is somehow blocked on their network because everything shows as normal in the portal.
I decided not to use AWS because I cannot risk to put 20 businesses in jeopardy, risking to see them all down one day for some administrative reasons that take days to debug/understand.
I faced a very similar issue and I finally figure it out.
Security Groups for Your VPC :
A security group acts as a virtual firewall for your instance to
control inbound and outbound traffic.
therefore, even though the security group allowed inbound and outbound traffic, you need to make sure the VPC is public or VPC private that use NAT gateway.
VPC with Public and Private Subnets :
The instances in the public subnet can send outbound traffic directly
to the Internet, whereas the instances in the private subnet can't.
Instead, the instances in the private subnet can access the Internet
by using a network address translation (NAT) gateway that resides in
the public subnet. The database servers can connect to the Internet
for software updates using the NAT gateway, but the Internet cannot
establish connections to the database servers.
Update:
As mentioned in the comments, looks like the problem is with the aws account. after the account is closed\suspended the account being blocked to connect any resource. even after reactivated the account, the account still doesn't have access to new instances and you need to connect with aws.
This information based on this thread and #FlorianB experience.