I noticed that my VM in the google cloud platform is generating DOS and wondering where that may be coming from. On further search, I noticed a file that wasn't created by me and deleted the file.
So far, I have changed the ssh port but I'm still getting This project appears to be committing denial of service attacks
I would like suggestions on what else I can do to prevent this in the future.
I'm leaving here some interesting resources you can check to secure your Google Compute Engine instance:
Ubuntu SSH Guard manpage
ArchLinux SSH guard guide (guides you through installation and setup)
Apache hardening guide from geekflare
PHP security cheatsheet from OWASP
MySQL security guidelines
General security advice for Google Cloud Platform instances:
Set user permissions at project level.
Connect securely to your instance.
Ensure the project firewall is not open to everyone on the internet.
Use a strong password and store passwords securely.
Ensure that all software is up to date.
Monitor project usage closely via the monitoring API to identify abnormal project usage.
To diagnose trouble with GCE instances, serial port output from the instance can be useful.
You can check the serial port output by clicking on the instance name
and then on "Serial port 1 (console)". Note that this logs are wipped
when instances are shutdown & rebooted, and the log is not visible
when the instance is not started.
Stackdriver monitoring is also helpful to provide an audit trail to
diagnose problems.
Here are some hints you can check on keeping GCP projects secure.
Related
On Google Cloud we are using the following:
A Cloud Function that connects to
A service running on a GCE VM
via a VPC Access Connector
Its been running fine for months then all of a sudden it stopped working and all attempts to connect to the service cause the following error in our Cloud Function logs:
Connection to 10.X.X.X timed out. (connect timeout=10)
That IP address is the IP address of the VM.
At this point I'm not sure how to go about diagnosing the problem as GCE networking is unfamiliar to me. What should I be searching for in Cloud Logging to try and determine the root cause of the problem?
You can use Cloud Logging to check the logs of your GCE Networking. You check it on:
Navigation Menu > Logging > Log Explorer
On the right upper part of your GCP console, click Resource.
Scroll down and choose GCE Network.
Once you click GCE Network, it will show you the Network ID of your VPC network
Then choose where your VM instance is located then click “apply”.
For more information about Cloud Logging you can explore this link.
I've discovered that much more detailed logs are available by filtering on
resource.type="gce_subnetwork"
These logs provide much more detailed information about the network traffic.
I have a VM running on Debian. Considering security, does it make sense to install antivirus/security software on it?
I know Google recommends ClamAV for the scanning of files uploaded to Google Cloud Storage. But I don't find anywhere about malware scans or antivirus on virtual machines.
This is the same for SQL instances in Cloud SQL. Is it recommended and/or possible to add additional security to detect malware?
It depends on what that VM is going to do. Does this machine really receive external files that are going to be kept in the VM?. if so you may need an antivirus installed in the VM.
If this VM has your own software, your security could be the firewalls, Security Command Center, and Shielded VMs.
If your VM is serving web apps, you could look for other Googles security tools like Cloud Armor.
For Cloud SQL instances, as they are a managed service, Google is responsible for security at OS and DB software levels. Although data access security is the customer's responsibility.
I have made a web application (Play Framework, Cassandra) which I'll not put in production on GCP . However, I am not well versed with networking and systems administration. The application would be containerised and I'll use K8s to create a cluster containing 2 pods for Play web application and 3 pods for Cassandra (for replication). There also be a load balancer service in front of the play application.
I suppose the above configuration is still vulnerable to DDOS attack. How can I prevent it on GCP?
The communication between the browser and server is not encrypted (eg. the passwords is being sent in plain text. Could could I enable encryption on GCP?
Any other tips on creating a reliable production system would be much appreciated. So far I have only worked on my laptop
Please find the below responses
I suppose the above configuration is still vulnerable to DDOS
attack. How can I prevent it on GCP?
https://cloud.google.com/files/GCPDDoSprotection-04122016.pdf, this can help you with DDOS protection. If you are using APIGEE, then APIGEE edge can also help you
The communication between the browser and server is not encrypted
(eg. the passwords is being sent in plain text. Could could I enable
encryption on GCP?
you will have to install certificated in general and ensure that the data is sent over a https network. You can also try sslforfree
Any other tips on creating a reliable production system would be
much appreciated. So far I have only worked on my laptop
since you are using K8s to run cassandra please ensure you are using some sort of volumes to store the data.
I'm using Cloud Run containers to run untrusted (user-supplied) code. The container receives a POST request, runs the code, and responds with the result. For security reasons, it's deployed on a locked down service account, but I also want to block all other network activity. How can this be accomplished?
Cloud Run (managed) currently doesn't offer firewall restrictions to selectively block inbound or outbound traffic by IP/host. I'm assuming you're trying to block connections initiated from container to outside. In the future, Cloud Run has plans to add support for Google Cloud VPC Service Controls feature, so that might help.
However, if you have a chance to use Cloud Run for Anthos (on GKE) which has a similar developer experience but runs on Kubernetes clusters, you can actually easily write Kubernetes NetworkPolicy policies (which I have some recipes here) to control which sort of traffic can come/go from the containers running. You can also use GCE firewall rules and VPC service controls when using a Kubernetes cluster.
Other than that, your only option on a Cloud Run (fully managed) environment is to use Linux iptables command while starting your container to block certain network patterns. Importantly, note that Cloud Run (fully managed) runs on a gVisor sandbox which emulates system calls. And many of the features in iptables are currently not implemented/supported in gVisor. By looking at issue tracker and patches , I can tell that it's on the roadmap and some may even be working today.
You could couple the Cloud Run (managed) deployment to a VPC Network that doesn't have any internet access.
I figured this out for my usecase (blocking all egress).
In the first generation of cloud run atlease, there's 2 eth interfaces - eth0 and eth2. Blocking traffic on eth2 solves egress traffic.
iptables -I OUTPUT -o eth2 -j DROP
Run this on startup of the container/app and then ensure the running application is not run (and hence cannot undo this).
I recently start using GCP but i have one thing i can't solve.
I have: 1 VM + 1 DB Instance + 1 LB. DB instance allow only conections from the VM IP. bUT THE VM IP allow traffic from all ip (if i configure the firewall to only allow CloudFlare and LB IP's the website crash and refuse conections).
Recently i was under attack, i activate the Cloudflare ddos mode, restart all and in like 6 h the attack come back with the Cloudflare activate. Wen i see mysql conections bump from 20-30 to 254 and all conections are from the IP of the VM so i think the problem are the public accesibility of the VM but i don't know how to solved it...
If i activate my firewall rules to only allow traffic from LB and Cloudflare the web refuses all conections..
Any idea what i can do?
Thanks.
Cloud Support here, unfortunately, we do not have visibility into what is installed on your instance or what software caused the issue.
Generally speaking you're responsible for investigating the source of the vulnerability and taking steps to mitigate it.
I'm writing here some hints that will help you:
Make sure you keep your firewall rules in a sensible manner, e.g. is not a good practice to have a firewall rule to allow all ingress connections on port 22 from all source IPs for obvious reasons.
Since you've already been rooted, change all your passwords: within the Cloud SQL instance, within the GCE instance, even within the GCP project.
It's also a good idea to check who has access to your service accounts, just in case people that aren't currently working for you or your company still have access to them.
If you're using certificates revoke them, generate new ones and share them in a secure way and with the minimum required number of users.
Securing GCE instances is a shared responsability, in general, OWASP hardening guides are really good.
I'm quoting some info here from another StackOverflow thread that might be useful in your case:
General security advice for Google Cloud Platform instances:
Set user permissions at project level.
Connect securely to your instance.
Ensure the project firewall is not open to everyone on the internet.
Use a strong password and store passwords securely.
Ensure that all software is up to date.
Monitor project usage closely via the monitoring API to identify abnormal project usage.
To diagnose trouble with GCE instances, serial port output from the instance can be useful.
You can check the serial port output by clicking on the instance name
and then on "Serial port 1 (console)". Note that this logs are wipped
when instances are shutdown & rebooted, and the log is not visible
when the instance is not started.
Stackdriver monitoring is also helpful to provide an audit trail to
diagnose problems.
You can use the Stackdriver Monitoring Console to set up alerting policies matching given conditions (under which a service is considered unhealthy) that can be set up to trigger email/SMS notifications.
This quickstart for Google Compute Engine instances can be completed in ~10 minutes and shows the convenience of monitoring instances.
Here are some hints you can check on keeping GCP projects secure.