We've been working on a collaborative project using AWS and in particular SimpleDB. Lately, our SDB cost have been going through the roof and we're trying to figure out what's going on. Is there any way to find out which IP addresses connect to it?
EDIT: If we can't find out which IPs are accessing SDB to get data from it, is it at least possible to determine how much each of our SDB domains get queried in terms of number of queries to a domain and/or the total amount of data getting pulled from a domain?
AWS IAM allows you to put condition on user's IP address using AWS IAM AWS-Wide Policy Keys. Here is the link - For Managing Users for Amazon SimpleDB using AWS IAM.
Here is the example to allow requests only if they come from certain IP address or range. source
Allow requests only if they come from a certain IP address or range
This policy is for an IAM group that all users in a company belong to. The policy denies access to all actions in the account unless the request comes from the IP range 192.0.2.0 to 192.0.2.255 or 203.0.113.0 to 203.0.113.255. (The policy assumes the IP addresses for the company are within the specified ranges.) A typical use is for Amazon VPC, where you might expect all your users' requests to originate from a particular IP address, and so you want to deny requests from any other address.
{
"Version": "2012-10-17",
"Statement":[{
"Effect":"Deny",
"Action":"*",
"Resource":"*",
"Condition":{
"NotIpAddress":{
"aws:SourceIp":["192.0.2.0/24", "203.0.113.0/24"]
}
}
}
]
}
Related
Firebase Hosting did not provide enough security, but I love the features of Firebase. So I wrote a firebase function that renders dynamic content. I put it behind a google load balancer to be able to block all traffic except whitelisted IPs.
I hope to write a function that will whitelist the IP into cloud armor after a successful sign in. I hope to whitelist as many IPs as possible (1000+) and I will add a TTL to each IP as each session expires.
My goal is to strictly limit access and prevent a DDoS attack that could potentially bring the function down and accrue charges. A bearer token is not enough for my use case.
So this is a two part question, is it possible to whitelist IPs programmatically? Is there a limit to how many IPs I can whitelist?
Update:
According to https://cloud.google.com/armor/quotas, I can have 200 rules each rule containing 10 IPs, meaning 2000 IPs. So my new question, is this an standard use case for Cloud Armor?
I understand I can get a quota increase, but there are other load balancer services such as Cloudflare with much larger IP whitelist. Although, I would like to stay within Google services.
According to the official documentation and #John Hanley recommendation you should not use IP whitelists filtering for your security model:
Note that using static IP address filtering is not considered a safe
and effective means of protection. Instead, we suggest that you take a defense
in depth approach using OAuth and Certs.
I am trying to find the security group of my Elasticsearch domain in AWS but from the Elasticsearch console, I can't find it. My ES domain is not inside a VPC but is exposed to the Web with some authentication.
What I want to do is to whitelist some IP addresses and block the rest and I wanted to implement it using the security group.
There is no security group but an access policy where you can whitelist IP addresses or ARNs. This can be done from the ElasticSearch console.
I have a Cosmos DB locked down to a vnet (and its subnets) and am looking to have this Cosmos DB be a data source for Azure Search.
When I attempt to configure it, it complains about being blocked by the firewall.
If I enabled "Accept connections from within public Azure datacenters" it still complains about being blocked by a firewall.
If I remove the "Accept connections from within public Azure datacenters
" setting and grant access to the following IP 13.76.208.129 it works.
Is it only 13.76.208.129 that is actually required for integration or is there a larger range I need to add into the firewall?
As mentioned in this documentation page:
If your search service has only one search unit (that is, one replica
and one partition), the IP address will change during routine service
restarts, invalidating an existing ACL with your search service's IP
address.
One way to avoid the subsequent connectivity error is to use more than
one replica and one partition in Azure Search. Doing so increases the
cost, but it also solves the IP address problem. In Azure Search, IP
addresses don't change when you have more than one search unit.
Usually we set AWS security group outbound as ALL since we may need to download/upgrade sth. from internet. using any port, from any IPs.
One concern is what if sb. who login EC2 tries to upload company's important data to his personal cloud storage?
If we can restrict AWS security group outbound, then this can be avoided.
I see some similar post about the concern on security group outbound setting. such as:
AWS Security Group for RDS - Outbound rules, but all the response said it is fine to set outbound as ALL, or just restrict to a few ports.
I still want to raise the question again. for example, how to resolve the above concern I have? and if we do not have solution, then is restricting port to 80/443 enough if we just want to upgrade/update OS and app, not anything else?
I have a MySQL database instance on Google Cloud SQL. Currently it has over 10 authorized ip addresses since multiple teams are accessing it from various locations. I would like to know if I can setup a VPN to this database instance and authorize just this ip address, instead of 10 addresses.
If that's possible, I would also like to know how many user accounts I can create for one VPN. I could not understand the Google Cloud documentation about setting up VPN. Please provide links to websites/tutorials/documentation that can help me with setting up a VPN in Google Cloud Platform.
Thanks.
Using cloud VPN and authorize only its external IP will not work for two reasons:
1) You can not specify in cloud SQL a private network (for example, 10.x.x.x) as an authorized network. as documented here.
2) Packets will arrive to cloud SQL after decapsulation which means that Cloud SQL get them as they come from different source IPs.
If you want more secure connection without IP white-listing, maybe using cloud SQL proxy.