I can't seem to be able to whitelist the correct IP ranges for use with Sagepay direct payment module.
I keep getting invalid response 4020 : Information received from an Invalid IP address.
The instance is a non VPC instance and it is able to talk outbound on the correct port (hence getting any response at all). It has a public IP address attached to it and I have whitelisted that in the sagepay backend.
The entry looks something like this
054.217.010.211 - 255.255.255.000
Any help with this would be greatly appreciated
4020 error - happens with a Server or Direct integration. Fixed IP recommended. If you've added the IP address and subnet mask to cover the range to MySagePay (Sage Pays admin portal) and still getting error, means we're not recognising the IP your posting from as the IP you have given.
Invalid Transactions within MySagePay, you should be able to see the IP we're recognising that you're posting from. Then add that IP to MySagePay.
Sage Pay may need to check that our internal IPs are registered against your account.
Sage Pay can add the IP ranges for you to your Sage Pay account if needed so you can check it resolves.
Related
I am relatively new to Metabase. I want to set up an EC2 instance to have my custom website www.*.com display the Metabase homepage so I can follow the corresponding setup. Please can you advise on how this can be done? I have tried and researched but not gotten what I actually want.
Please ask questions if you do not understand any part of the question.
Thanks for the help!
You need to point the domain name to the IP Address of the EC2 machine, using the Domain Name System (DNS), most likely with an "A record"
By default, your EC2 instance, will have a different IP address if you stop/start it, so you should use an Elastic IP Address to give you a static IP
You will need to read your DNS host's documentation to figure out exactly how to do that. If you happen to use AWS's Route 53 DNS service, here is the appropriate link
We are trying to configure a VPC, which has a private subnet and a public subnet. In the private subnet there is an RDS which is not publicly accessible. We have test it and seems that works fine! The issue though its that when I ping the RDS endpoint from my computer it returns the Private IP of the RDS (its not returns any packets though).
We do not want to shows the Private IP.
Any help would be appreciated!
I went ahead and popped open a chat with our AWS support team to pick their brain. Basically, this boils down to how they host their DNS mappings for RDS endpoints; they're created in a public hosted zone by default (not modifiable). Hence, you can resolve your RDS endpoint over the internet (because the mapping is hosted publicly), but can't actually route any data to it.
If this is an issue, to get around it you can ... jump through some hoops:
An alternative will be to create a private hosted zone with a record
that points to the rds endpoint. (for example a private hosted zone
"xxxx.com" that has an alias record pointing to rds endpoint), in which case you will reach out to your rds instance
using xxxxx.com
However, this doesn't actually disable the original AWS created endpoint from returning the private IP, it just allows you to configure an endpoint that doesn't.
For what it's worth, revealing your private IP is pretty harmless; several thousand devices likely share your exact private IP. The only way this information would be concerning for you is if an attacker was actually in your network - and at that point... they could just do a lookup on the DNS from there to get the IP.
First question: why do you want to do this? Your 10.1.2.3 or 172.31.2.3 or whatever is a non-routable address. It really doesn't matter whether people know it if they can't get into your VPC.
As for actually preventing it, you can't: Amazon makes the endpoint available via DNS (you can use nslookup to find it). You could always try filing a support ticket, but I wouldn't expect any results.
Also, FYI the second component of the endpoint is related to your account. So in your image you redacted non-important information but left the (potentially) important information present.
In case it's not clear, the problem is in how Amazon resolves DNS requests, not in how the networks are connected. Here's an example of an nslookup call for one of our database instances that's running on a private subnet. This is from my PC, not connected to the VPC via VPN or any other means:
> nslookup REDACTED.REDACTED.us-east-1.rds.amazonaws.com
Server: 127.0.1.1
Address: 127.0.1.1#53
Non-authoritative answer:
Name: REDACTED.REDACTED.us-east-1.rds.amazonaws.com
Address: 10.1.56.119
I am deploying a laravel installation in AWS, everything runs perfectly when I allow it to recieve all inbound traffic (EC2>Network&Security>Security Groups>Edit inbound rules.), if I turn off inbound traffic and limit it to an IP it doesnt load the webpage it gives me this error:
PDO Exception SQLSTATE[HY000] [2002] Connection timed out
However for security reasons I dont want this setup like this, I dont want anyone being able to even try to reach my webapp. Everything is being hosted in AWS, I dont have any external entities, its running in RDS and EC2. I added en elastic IP address and whitelisted it, but that didnt work either. I followed every step in this tutorial : http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/php-laravel-tutorial.html#php-laravel-tutorial-generate
Environmental variables are working as well as dependencies, well.. pretty much everything unless I restrict inbound traffic as I mentioned.
How do I whitelist AWS own instance then to make this work with better security?
Thank you!
I think part of this answer is what you may be looking for.
You should enable inbound access from the EC2 security group associated with your EC2 instance, instead of the EC2 IP address.
More than just adding an elastic IP address to your AWS instance you need to do two more things.
Assign the elastic IP to your AWS instance ( yes is not the same as just adding it to the instance, you must specify )
White list the internal IP that it generates once you link it to your app.
?????
Profit
I have a domain that I own. I will say is example.com. I added SSO.example.com as a Type A record on GoDaddy with a value of 37.89.245.2(example).
The IP address is a elastic IP on a Windows AWS server.
I can ping the IP address but I can't ping the URL. Do I need to do something with the IP address on the AWS Windows server to be able to ping the URL?
This is pretty much one of my first web based projects so any help would be appreciated!
Ping is not a reliable test method in AWS because most security groups do not permit inbound ICMP protocol, which is used by Ping. So, if you really want to test connectivity, do it on a port that you actually need your application to support, such as HTTP (80) or trying an SSH/RDP connection.
Another common use for a Ping is to resolve the domain name to an IP address, since it displays the result on-screen. This can be a good way to check that your Amazon Route 53 configuration is correct. (Same as a dnslookup.)
I was jumping the gun a bit and the new NameServers I was using had not replicated completely yet. After replication completed everything was able to be pinged successfully.
Scenario:
I have an EC2 server which houses the api currently setup to accept connections from several iPads. I do not wish for network sniffers to see the JSON requests that are being exchanged between the servers and the devices. The idea is to have a secure protocol in place so that communication will be secured.
I have been told purchasing a SSL certificate is the way forward. The Amazon server instance I have running has an address in this format:
ec2-xx-xxx-xx-xxx.ap-southeast-1.compute.amazonaws.com/
this is where my web root is with all the appropriate web service files. My webservice urls look something similar to this:
ec2-xx-xxx-xx-xxx.ap-southeast-1.compute.amazonaws.com/Agent/Create
so on so forth. There is no hosting plan whatsoever (in the case that information is necessary).
I have been recommended to buy an SSL Cert from http://www.Godaddy.com and have thought about getting the up to 5 multiple domains SSL certificate package.
Question: 1
What things do I need to be made aware of in order to make sure nothing fails?
I have recently read that I may need to associate an elastic IP address to my instance, otherwise the IP of my instance will change on reboots? And if that is the case, that means that the SSL certificate that was used for this: ec2-xx-xxx-xx-xxx.ap-southeast-1.compute.amazonaws.com domain would no longer work since the ip address would have changed upon reboot and therefor me losing my secure domain?
Question: 2
If my thoughts in question 1 stands true, then my question would then be what is the most user friendly way or lets say, the way for beginners to create a dedicated url for my server instance (so that 1) the domain name doesnt randomly change upon server reboot (not sure when i would reboot anyway) and 2) does this mean I can have easier webservice urls that one can remember? such as.... www.pk.com/Agent/Create instead of the long ec2 ugly url?!
Any easy to follow tutorials would be very helpful. I have looked at a few articles that spoke about elastic ip address, SSL certificates, and other articles about renaming ec2 url, but I'm in a position where I dont actually know which one applies to me. lol
Hope someone can help. thanks
What you want to do is to get an elastic IP address. This lets you bind your instance to a particular IP address when you start it up. You can then register a hostname in DNS (Amazon don't help you with this part) and state that that hostname has the IP address that is the elastic IP address that you have registered.
The final piece is to get a server certificate (strictly, a keypair where the public part is the server certificate) that has the hostname in the CN field of its Distinguished Name, and to install that server keypair on the instance. (This is another part that Amazon don't help you with, and is in fact the same process as if you were hosting the hardware yourself.) Like that, the client
looks up the hostname and gets the elastic IP address,
connects and gets the server certificate, and
checks the server certificate and sees that the hostname it is for is the hostname that they expected. (There's a few other checks as well, such as whether the certificate was signed by a trusted certificate authority and whether the certificate is within its validity period.)
That allows the client to trust that who they have securely connected to is who they expected to securely connect to, which is a key part of establishing trust.
What you do not do is use the AWS machine names (internal or external) in the certificate you apply for. Those change and you really do not want to trust other people's VMs.
Donal's answer is the way to go. You need to explicitly register a domain and generate the SSL certificate containing the CN as that domain. Elastic IP addresses definitely are your friends in this issue. You will need them.
I added another answer in order to give another point of view: if you ever want to scale your backend solution, going that way will be more difficult. If you ever thought about adding more servers to host your web service, you should definitely set up an Elastic Load Balancer, add your instances to it, and point the domain you just registered to your Elastic Load Balancer. Then, you can purchase the SSL certificate and install it directly on your ELB, configuring SSL termination on the ELB. You will also configure the ELB so that connections arriving at port 443 will map to port 80 (or whatever port) on your servers. Don't worry, this is plain easy to set up.
Whenever you want to add more servers to your web service, it will just be a matter of setting up another EC2 instance (this process can - and should - be automated) and adding it to the ELB.
With this setup, you get rid of the need for Elastic IP addresses. All the connections go through the ELB.