Does google compute engine offer ddos protection for any virtual machines created within a project, I have read that it does can anyone confirm?
There are different types of DDOS and Google would guard VM from some of them (SYN flood, ICMP flood, etc.) simply because it's on shared network infrastructure but as far as I know/understand it would not be able to protected from fake HTTP requests.
Related
I have a simple app connected to a server via some sockets and the traffic is not yet encrypted users must log in or create accounts before using the app and afterwards traffic is shared between users and server. i want to know if i must encrypt all traffic or just the authentication and account creation?
Use https for all traffic (or an equivalent TLS-based protocol for non-HTTP traffic). Yes, encrypt and certificate-authenticate everything. For modern systems, there are vanishingly few cases where TLS is not the correct answer for network traffic. It is ubiquitously available across platforms, languages, and protocols.
On any modern network system you need an argument for why you wouldn't encrypt and authenticate the connection. It's not a matter of "must" you. It's a matter of "why wouldn't you?"
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.
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).
I have a situation where messages are being generated by an internal application but the consumers for the messages are outside our enterprise network. Will either of http(s) transport or REST connectivity work in this scenario, with HTTP reverse proxy on DMZ? If not, is it safe to have a broker on the DMZ which can act as gateway to outside consumers?
Well, the rest/http approach to connect to ActiveMQ is very limited as it does not support true messaging semantics.
Exposing an ActiveMQ broker is no less secure than any other communication software if precautions are taken (TLS, default passwords changed, high entropy passwords are used and/or mutual authentication, recent patches applied, web console/jolokia not exposed externally without precautions etc etc).
In fact - you can buy online ActiveMQ instances from Amazon - which indicates that at least they think it's not such a bad idea to put them on the Internet.
I'm trying to solve an architecture design puzzle, it's about designing an infra for keeping data and servers as much secured/hidden as possible, here are requirements:
I want to hide the internal design of my infra (several data servers with public and private hosts)
I want to access to each service using same IP address, and the query is forwarded to right server based on something (cookie, uri, port or whatever)
access to data service must be enforced with ssl/tls encryption
After studying carefully these requirements I was thinking about using a reverse proxy and grant access to all data services only across the reverse proxy server, an other pro of a reverse proxy is that access authentication is enforced at once with sll/tls encryption and no need to configure each endpoint separately.
my real issue is that I didn't find any reverse proxy that supports tcp queries, and same for static load balancing algorithms that are supported only for HTTP requests, (haproxy for instance)
Any idea how to solve this issue ?
Thanks to all