Because xdcr is used over the internet, it is totally possible to perform ddos attacks on those xdcr ports?
Should I do something about it? What should I do?
XDCR ports only need to be open to the other cluster nodes; so if you did use XDCR over the open internet you would typically firewall those ports to only be accessible to the remote cluster.
(Note: You would likely want to use encryption of your data if you are doing XDCR over the internet, either using XDCR-with-SSL in Couchbase 2.5 or otherwise with a VPN tunnel / private WAN.
Related
I want to configure Google Identity Aware Proxy for an application running on Google Kubernetes Engine. To do that i added an Ingress to my Kubernetes Configuration so i get a Load-Balancer to configure as an identity-aware-proxy.
Now GCP shows me a few warnings that are about problematic firewall rules. As all of these rules were configured by GKE i'm not quite sure if they are a problem.
As far as i understand it 10.128.0.0/9 is the default VPC for projects and 10.56.0.0/14 is the ip range for all containers in my kubernetes cluster.
To me this means that "only" internal traffic inside my project/kubernetes-cluster can bypass the IAP. Is that correct?
You’re correct. However, keep in mind that if you have set up an internal load balancer the traffic will bypass the IAP.
Note, you can natively integrate with IAP through Ingress
https://cloud.google.com/iap/docs/enabling-kubernetes-howto
I've setup my ssl cert in AWS through EC2 using the Elastic IP Address and Elastic Load Balancing. It costs me about 20$ per month to run this.
Does anyone have cheaper suggestions?
Depends on what you are using your EC2 instance for... If for a web service, look at API Gateway in front of a Lambda function for a serverless architecture. If for a website and it is static, consider hosting in a S3 bucket.
Let'sencrypt would be the ideal solution for your case. https://letsencrypt.org/ offers free ssl certificates that you can generate and import into your ACM and attach them from ELB
OR
If you prefer it directly to your EC2 instance then you can install them in your apache (httpd) web server.
Refer: https://www.godaddy.com/help/apache-install-a-certificate-centos-5238
https://www.youtube.com/watch?v=_a4wRsT6LaI
Use certificates from the AWS certificate manager and you won't pay anything. They are free. https://aws.amazon.com/certificate-manager/pricing/
You can use AWS CloudFront as the gateway to your application which can use AWS Certificate Manager issued SSL certificates for free. There are no upfront commitments and you will pay only for the usage (More details refer CloudFront Pricing). You can connect your EC2 instance to CloudFront to receive traffic.
This will provide you a higher performance by caching the static content while reducing the load for your backend further reducing costs at scale.
I'm new to the whole cloud concept.
I have set up a Windows VM with GCE, remote desktopped into it, installed Apache HTTPD and set the firewall rules, turning this Google GCE into a web server. I intend to install Perl, which is my primary programming language and isn't supported in App Engine.
I am looking for an alternative to my current hosting solution for better uptime and availability, or at least a fall-back service.
Is it recommended to use GCE in this way or am I barking up the wrong tree?
GCE is a very general solution, you can use your VM for whatever purpose you want. In particular GCE is recommended for all workloads that do not fit in the rather strict limitations of App Engine.
Having said that, web hosting was probably the first and main use case for GCE when it was being implemented. On top of having a single VM serving your traffic you can trivially scale your solution up by using load balancers and/or autoscaling. On top of that you can use a managed DB if your web server needs storage, etc. So the answer is, yes, GCE is definitely designed to be used as a web server.
By default, when you open the bind-address to listen to the outside, the default communication between the MySQL client & server is not secured, that means anyone that can do a MitM attack can view every transactions made.
There is options out there to protect against this type of attack (SSH Tunneling or enabling SSL in MySQL) but from what I understand, Amazon RDS doesn't implement, by default, any SSL security.
So I'm wondering, when you create an RDS instance, is it like installing MySQL on a server and opening the 3306 port or am I missing something?
A few points. Firstly AWS RDS for mysql does support ssl. This is discussed here
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.SSLSupport
Second, the usual way to arrange servers in a AWS VPC is to have "private" and "public" subnets. The private subnets route to other private hosts and perhaps to other hosts in the same VPC. But they have no Elastic IPs and no direct access to the Internet Gateway. It is usual to put databases on private subnets so that their ports are not exposed
There is a nice diagram on this page showing this concept
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html
Lastly, AWS RDS exists within the philosphy of the shared responsiblity model
This tries to make it clear what security AWS services provide and what is supposed to be the responsibility of the customer
If you're creating an instance you've to also allow port 3306 to be open at your endpoints. This means you've to also configure your security settings as to which IP you've to allow for this connection. Regarding SSL security or SSH, as a good practice you should rely on ssh keys with Pass phrase.
I have one server veeam 8 backup & replication and some hosts with virtual machines. Also I installed veeam proxies (one proxy for each host) and added its into the veeam main server. How should i specify, which veeam proxy backup each job must use?
Thanks.
You can specify proxies on the "storage" page of the backup job configuration wizard. By default, "automatic selection" mode is used.
Yes, you can manually select which proxy servers to use, but I would suggest sticking to automatic selection. This will be beneficial when one proxy goes down for some reason. Thanks!