How to restrict AWS security group outbound rules - aws-security-group

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?

Related

Can I use Google Cloud Armor to programmatically whitelist many IPs?

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.

HTTP or HTTPS on virtual private cloud (VPC)?

Should I use HTTP or HTTPS to communicate between services on my virtual private network (VPC)? What are the risks (if any) of using HTTP in such scenario?
My naive reasoning is that given the inherent privacy of the network, HTTP should be suffice for internal communication between servers inside of said network. Am I wrong to make such assumption?
I've searched through GCloud VPC documentation, yet can't find anything regarding this question. I've also found this article on AWS HTTPS, yet again no indication as to whether one or other should be preferred.
I'd link up more sources, but I can not find any articles arguing for either.
As per my understanding, a VPC network isolates the traffic and puts some security measures in place that prevent your traffic from being seen from a different VPC. That being said, the security of the resources is a shared responsibility in cloud environments. In case there is a security breach inside GCP that allows someone to gain access to my VPC and sniff the traffic, if I'm using HTTPS, the communication is encrypted and I am adding another layer of security. Therefore, I would always go with the safest option (HTTPS).

Are the Google Cloud Endpoints only for REST?

Are the Google Cloud Endpoints only for REST?
I have a virtual machine with cassandra, and now I need (temporarly) to expose this machine for the world (the idea is to run a cassandra client in some computers in my home/office/...). Is Google Cloud Endpoints the best way to expose this machine to world?
I am assuming that you are running Cassandra on a Google Compute Engine (CE). When one runs a compute engine, one can specify that one wants a public internet address to be associated with it. This will allow an Internet connected client application to connect with it at that address. The IP address can be declared as ephemeral (it can be changed by GCP over time) or it can be fixed (I believe there will be a modest charge for its allocation). When one attempts to connect to the software running on the Compute Engine, a firewall rule (by default) will block the vast majority of incoming connections. Fortunately, since you own the CE you also own the firewall configuration. If we look here:
https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureFireWall.html
we see the set of ports needed for different purposes. This gives us a hint as to what firewall rule changes to make.
Cloud Endpoints is for exposing APIs that YOU develop in your own applications and doesn't feel an appropriate component for accessing Cassandra.

Setup VPN for database instance on Google Cloud SQL

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.

How to safegaurd AWS EC2 node based website from Spam and DDOS?

We have a website deployed on AWS EC2 running on ubuntu,Apache, MYSQL. We have been getting continous requestes from below IP
"195.154.105.219"
"88.150.242.243". Requesting for xmlrpc.php file using POST method. As a result our website has become really slow and our clients work has been effected. As of now we have blocked these IP values by dropping them from iptables. We would like to know how to safegaurd our site from any future attacks like this.
The question is very general, and depending to your application's requirements, your budget and other factors, there are several techniques you can use, separately or together to mitigate DDOS and SPAM attacks.
Use Auto Scaling and an Elastic Load Balancer, to let AWS scale your infrastructure depending on traffic : http://aws.amazon.com/autoscaling/
Use S3 to serve static content. S3 is designed is scaling automatically for incoming traffic. All content served by S3 directly allows to offload your EC2 based web server : http://aws.amazon.com/s3/
Use CloudFront to distribute and server your content from AWS' edge location. This mitigates DDOS by distributing attackers' request to the network of edge locations instead of sending the traffic to your web server : http://aws.amazon.com/cloudfront/
All these three options have a cost associated, be sure to understand the pricing structure before deciding to implement any of these.
If you have a relatively short and stable list of IP addresses you want to block, you can customise either your EC2 instance's Security Group (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html) either your VPC Subnet ACL (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html) to deny traffic from these IP addresses. This approach is not very scalable and, most of the time, you will play a mouse / cat game trying to catchup with whatever new addresses are used by your attackers
Last but not least, using plain old Apache configuration to block certain URL or restrict access to these by IP Addresses is very effective too (http://httpd.apache.org/docs/current/en/mod/mod_authz_core.html#require and File Directive)
Last but not least, I would encourage everyone to watch this re:invent talk about DDOS resiliency for AWS : https://www.youtube.com/watch?v=V7vTPlV8P3U)
Seb
xmlrpc.php is from wordpress. install the Disable xmlrpc pingback plugin, or better yet , in the wordpress site. .htaccess , deny xmlrpc.php file ;). that will fix it. Also checkup the wp-admin/scripts for any wierd script or just . find /var/www/ -type f -mtime -10 , to find the latest modified files.. check for any wierd php script..

Resources