I was browsing the web using Firefox with my EC2 instance located in Ashburn, Virginia (IP Addr: 54.159.107.46) I visited www.supremenewyork.com and it did not load (other websites like Google did load.) I did some research and found the IP of Supreme's site: 52.6.25.180 . I found out that the location of that IP is ALSO IN ASHBURN, Virginia, which could only mean that supreme is using AWS to host their site. This is an issue for my instance because I want to connect to supreme using it, but because the IPs are in the same Server Building or in Amazon's IP range I can't. Is there a workaround to this issue? Please help.
By the way: I tried pinging Supreme's IP from my EC2 instance – 100% packet loss.
NOTE THAT I CAN ACCESS SUPREME FROM MY HOME COMPUTER: IT IS NOT DOWN
Is there a security problem because I am trying to connect to their site?
I ran some tests locally and on AWS machines. My conclusion: www.supremenewyork.com blocks traffic that originates from AWS. It is easy to block traffic from AWS using IP tables. AWS publishes IP Address Ranges and it is easy to write a simple script like AWS Blocker to block all traffic from AWS IPs.
Why do some vendors block traffic from AWS? Increasing DDoS traffic and bot attacks from AWS hosted machines. Many attackers exploit compromised machines running in AWS to launch their attack. I have seen too many such incidents. AWS does its best to thwart such attempts. But if you see most of the attacks from a set of IP ranges, naturally you will try to block traffic from those IPs. I suspect the same in this case.
The website is not pingable because ICMP traffic is blocked from all IPs. There is nothing you can do (unless you go through a VPN) to access the vendor website from your EC2 machine.
Related
I have my own servers and have hosted a few services (game servers, web servers, ...), and use to host these on a publicly accessible dynamic IP using DuckDNS.
I have recently moved to a rural area and use a satellite service for my internet that does not support publicly accessible IP address.
I would really like to host these things again, but the only way I can think of doing that, is to have an IP somewhere in the cloud and route that back into my network. I have been messing around in Azure but I can't seem to get what I want working. I am not stuck on Azure, just happens to be the one I am message about with.
I have pfSense as my router, so I can setup a VPN client on that and pretty much keep that alive indefinitely, so here is what I am thinking and I hope someone can point my in the right direction, or if you like, poke holes in the idea.
I configure a VPN client on pfSense to be an WAN interface
create a VPN gateway in the cloud
connect pfSense VPN client to the VPN gateway
create a static external IP in the cloud
route traffic from the external ip through the VPN back to my pfSense server and into my internal network
once I get the traffic coming into pfSense , I can route to computers / VMs on my internal network.
This way, I do not need a publicly accessible IP from my ISP, I can connect to the Azure and use its external IP and route back through the VPN to my internal network.
If this was real hardware, I would have had this built in 30 minutes, seems this virtual world is messing me up.
Any ideas on how to configure this or maybe another solution?
I am struggling with the whole Azure setup and have watch hours of videos about each of the bit in Azure, but I am lacking some key bits of knowledge to bring this together.
If you know what you are doing with pfSense...
cloudfanatic.net
$2.99 US a month for a VPS running pfSense. They will spin up a VPS with pfSense on it at no extra charge. Open an account, send support an email.
Gives you a static permanent IP. Shared 1GB Internet link. No data limits. I see between 150 and 500Mbps. Perfectly fine for what I use it for.
Wireguard on that pfSense, people connect in, etc...
I've been using it for about 6+ months. Been very impressed.
Chunky
I have a Rails 4 application running on Heroku with exception_notification. I was notified that an AWS server was fishing for a login page by trying to access /wp-login.php. Since that is not my app's login page, someone had to manually enter that URL. Tracking the IP shows an Amazon AWS server in Oregon.
There shouldn't be any reason why someone would ever access my app via an AWS server, so my initial thought is someone is trying to get into the application.
In order to avoid any potential attack, I'm thinking about blocking all Amazon AWS requests.
Is there any way to blacklist Amazon AWS servers specifically? The only thing I can think of is checking the IP address of every request and ignoring those coming from a list I keep of Amazon, but I'm not sure if there is an official listing of Amazon IP addresses.
But checking the IP of every request against a blacklist seems inefficient. I'm aware of the rack-attack gem, but that is still running Ruby code to do the check, which doesn't seem very fast...
Blocking all AWS IPs is not a good solution. Potentially, the traffic can come from any part of the world. How are you going to block the traffic? Instead you should make your application robust.
There is an official listing of AWS IP address: AWS IP Address Ranges
If you are 100% sure that traffic originating from AWS (remember there are many AWS regions), then you can block them using IP tabled. One such solution is: AWS Blocker
Blocking all AWS IPs is not a good solution.
I have just taken over as a developer for a company. They host their development site on Rackspace. When I arrived, this server was spun down. Upon bringing it back up, I discovered that the IP address of that server points to the live website. There must be some kind of forwarding in place (I assume that it is through Rackspace) that does this. How can I fix this? I searched for settings on Rackspace to no avail. I would like to be able to access this dev site at least through the direct IP address until the network admin reappoints the develoment domain name to proper IP.
I'm guessing that you mean the live website domain routes traffic through to this server? Off the top of my head, you either have DNS load balancing in place - so an A record on your domain matching the IP address of the powered down machine OR you have a load balancer within rackspace that is routing traffic to it.
I have created 2 VMs in the same Virtual Network within the same Cloud Service. They do not have public endpoints. I would like to have the VMs be able to recognize each other as if they are on a local network. For example, I'd like to be able to reference them by machine names using \\ syntax, e.g. on VM1, I'd like to be able to access \\VM2_host_name\shared_folder. Can someone please provide me the steps to configure my VMs to enable this scenario.
Notes: I tried referencing them by their internal IP addresses, and also enabled ICMP traffic in the Windows Firewall. I even entirely turned off the firewalls for both machines just to test. No luck. I can't ping these machines either by host name or IP address from the other machine even without firewall. I have also reviewed similar sounding questions such as (Azure VMs Virtual Network inter-communication) but to no avail.
More Information:
From VM_A (internal IP 10.0.0.5), I'm trying to communicate with VM_B (internal IP 10.0.0.4). Both VMs belong to the same cloud service "MyCloudServiceName". For this test, I also turned off their firewalls just reduce the variables at play.
C:\Users\Matt>NSLookup VM_B
Server: UnKnown
Address: 168.XX.XXX.XX
Non-authoritative answer:
Name: VM_B.MyCloudServiceName.hX.internal.cloudapp.net
Address: 10.0.0.4
C:\Users\Matt>ping VM_B
Pinging VM_B.MyCloudServiceName.hX.internal.cloudapp.net [10.0.0.4] with 32 bytes of data:
Reply from 10.0.0.5: Destination host unreachable.
Reply from 10.0.0.5: Destination host unreachable.
Reply from 10.0.0.5: Destination host unreachable.
Reply from 10.0.0.5: Destination host unreachable.
Ping statistics for 10.0.0.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
So what I can tell is that the DNS resolution is working. But the machines are still isolated from each other even within the same cloud service.
Note that my actual scenario is I have an ASP.NET Web API self hosted on a service running on one machine which I'd like to be able to access from the other in the same cloud service internally.
We had a similar issue and it was due to the Checksum Offload of the Network Adapters.
Thanks to Microsoft Azure Support for helping us diagnose the issue.
The simple fix is to run this on every machine then do a quick reboot:
Disable-NetAdapterChecksumOffload * -TcpIPv4
Here is an article describing the problem in more details:
http://systemscentre.blogspot.com.au/2013/05/problems-clustering-virtual-machines-on.html
PING may not work as its often disabled in network environments. So I would suggest an NSLookup to verify it is able to resolve the location of the other server.
If both VMs are already in the same cloud service, virtual network should not be necessary as Azure provides basic DNS resolution within that cloud service boundary. By doing a NSLookup -all on each server, you should be able to identify the names they are currently using.
Once you've verified that they can resolve each other, you shouldn't have any other issues getting them to address each other providing you're not using an unsupported protocol (such as UDP multi-cast).
I've Hadoop running on Amazon EC2 in 2 different sites, but when the components starts, they get the internal IP. I want to put the components in different sites communicating with each other using internal IP. I'm not discussing if it's safe. I've an idea to put a DNS server that translates the internal IPs to external IPs, without the components notice. So, when traffic goes with the internal IP, the DNS relays the traffic to the other site.
Is it possible? Any suggestion on how to put a DNS server in EC2?
Two options:
Use VPC, in which case you have control of what internal ips are assigned to your instances. Some limitations however.
Use elastic IPs. Connecting to the DNS name of the elastic ip will resolve to the internal IP within an aws region.