How to protect a Docker host before deploying applications Solution Engineer

Transcript

[00:03,11]
I love making pour over coffee, but it can be a time intensive process, so I’d like to get better at multitasking too. With that in mind while I make the coffee up there, let’s see what we can accomplish with Trend Micro Cloud one in protecting this stalker host before we deploy an application our co-worker wants us to check out.

[00:23,23]
Starting with workloads security, we can generate a deployment script with the root policy we’ve built for Linux servers, we can copy the script from workload security directly into an empty file we create on the Docker host. After making the script, we’ll give it execution permissions and then begin installing the workload security agent. We can monitor the status of the installation in the workload security manager here in the computers tab. As an aside, using the in-product cloud connector integrations, we see that our computer environment in workloads security can mirror our instant deployment with a similar level of visibility to the native console in a cloud provider like AWS. Within workload security, we have options not only for AWS, but also Azure, GCP and vCloud accounts as well.

[01:22,19]
Now that the installation has finished on our Docker host, we can verify the installation in workload security. Note that only modules enabled within the policy have installed, and modules running recommendation scans to provide precise protection are implementing their rule sets as well. While that agent manager communication finishes up, let’s take a look at the application we’ve been recommended. Now our coworker usually means well, but sometimes things shoot past his watchful eye. So we’ll have to be careful while exploring this application. However, I’m optimistic everything will be OK. So let’s clone this repo onto our docker host. And now that it’s finished cloning, let’s take a look inside. I’m noticing there’s some zipped up test malware in this folder and that the workload security agent has also caught two more pieces of malware that were inside this repo. So we’ll have to talk to Chuck about this later. For now, let’s set up application security before we go live. Creating a new group allows us to generate the credentials we’ll need to activate the application security library, which Chuck has thankfully left for us. So opening the stalker file and finishing the relevant three to four line code block with our key and secret key information allows us to effectively install and activate the application security library.

[02:51,30]
With Docker Compose, all that’s left to do is build out the application. While that builds, we can finish configuring our policy for the app and as an example, we can turn on all the different detection types that aren’t on by default. While we wait, I’ll also copy the IP address for our Docker host, so that way we can check out the app as soon as it’s finished building. I know from our Docker file that this app will be hosted on 80 80, so I can append that to the IP address as well.

[03:43,13]
And now that our Docker host says it’s done, we can give it a minute to finish loading and admire our handiwork up there in the corner, as they say, patience is a virtue in poor overs and cloud protection alike. Now that the landing page has loaded, we can guess the log in using Chuck’s favorite administrator account credentials. Try these out and now let’s take a look around. Seeing this app built on Apache Struts 2 makes me think we can test the Struts 2 vulnerability, digging into the exploits folder and running the aptly named Struts Exploit script, we’ve successfully pulled our container’s environment variables, proving our assumptions correct. And we can see the detection event come in on application security.

[04:36,81]
Reviewing the event details of the malicious payload attack, we can see that application security has identified our exploitation of Struts 2. So going into policies and flipping the switch from report to mitigate, we’ll give this a moment to propagate, and after the policy update is successful, we can switch back to our Docker host and attempt to run the exploit script again. This time, note that our request was unsuccessful, being denied by application security, which has served up the blog page template, we can customize in the console itself. And time, four minutes, 49 seconds. Not too bad as we let the poor overtrain down its last drops, we have now protected our Docker host at both the operating system and application level. And the coffee’s not too shabby either. Looks like a nice full extraction. So while I enjoy this, hopefully you’ve enjoyed this sample of what’s possible today with Trend Micro Cloud one.

Read More HERE