Container Security: Anchore Engine

Nowadays, containers are taking over the world. We still have big systems, legacy system and, obviously, not every company out there has enough speed to migrate to containerized solutions but, wherever you look, people are talking about containers.

And, if you look in the opposite direction, people are talking about security. Breaches, vulnerabilities, systems not properly patched, all kind of problems that put at risk enterprise security and users data.

With all of this, and it is not new, projects involving both topics have been growing and growing. The ecosystem is huge, and the amount of options is starting to be overwhelming.

We have projects like:

  • Docker Bench for Security: The Docker Bench for Security is a script that checks for dozens of common best-practices around deploying Docker containers in production. The tests are all automated and are inspired by the CIS Docker Benchmark v1.2.0.
  • Clair: Clair is an open-source project for the static analysis of vulnerabilities in application containers (currently including apps and docker).
  • Cilium: Cilium is open source software for providing and transparently securing network connectivity and load-balancing between application workloads such as application containers or processes. Cilium operates at Layer 3/4 to provide traditional networking and security services as well as Layer 7 to protect and secure use of modern application protocols such as HTTP, gRPC and Kafka. Cilium is integrated into common orchestration frameworks such as Kubernetes and Mesos.
  • Anchore Engine: The Anchore Engine is an open-source project that provides a centralized service for inspection, analysis and certification of container images. The Anchore Engine is provided as a Docker container image that can be run standalone or within an orchestration platform such as Kubernetes, Docker Swarm, Rancher, Amazon ECS, and other container orchestration platforms.
  • OpenSCAP: The OpenSCAP ecosystem provides multiple tools to assist administrators and auditors with assessment, measurement, and enforcement of security baselines. We maintain great flexibility and interoperability, reducing the costs of performing security audits.
  • Dagda: Dagda is a tool to perform static analysis of known vulnerabilities, trojans, viruses, malware & other malicious threats in docker images/containers and to monitor the docker daemon and running docker containers for detecting anomalous activities.
  • Notary: The Notary project comprises a server and a client for running and interacting with trusted collections. See the service architecture documentation for more information.
  • Grafaes: An open artefact metadata API to audit and govern your software supply chain.
  • Sysdig Falco: Falco is a behavioural activity monitor designed to detect anomalous activity in your applications. Powered by sysdig’s system call capture infrastructure, Falco lets you continuously monitor and detect container, application, host, and network activity – all in one place – from one source of data, with one set of rules.
  • Banyan Collector: Banyan Collector is a light-weight, easy to use, and modular system that allows you to launch containers from a registry, run arbitrary scripts inside them, and gather useful information.

As we can see, there are multiple tools within this container security scope. These are just some example.

In this article, we are going to explore a bit more Archore Engine. We are going to create a basic Jenkins pipeline to scan one container. Fro this, we are going to need:

  • A repository in GitHub with a simple dockerized project. In my case, I will be using this one. It’s a simple Spring Boot app with a hello endpoint and a very simple ‘Dockerfile’.
  • We are going to need a Docker Hub repository to store our image. I will be using this one.
  • Docker and docker-compose.

And, that’s all. Let’s go.

We can see in the next image the pipeline we are going to implement:

Install Anchore Engine

We just need to execute a few commands to have Anchore Engine up and running.

mkdir -p ~/aevolume/config 
mkdir -p ~/aevolume/db/
cd ~/aevolume/config && curl -O && cd - 
cd ~/aevolume
curl -O

After that, we should see a folder ‘aevolume’ with a content similar to:

Running Anchore Engine

As we can see, the previous step has provided us with a docker-compose file to run in an easy way Anchore Engine. We just need to execute the command:

docker-compose up -d

When docker-compose finishes, we should be able to see the two containers for Anchore Engine executing. One for the application itself and one for the database.

Install the Anchore CLI

It is not necessary but, it is going to be very useful to debug integration problem if we have (I had a few the first time). For this, we just need to execute a simple command that it will make the executable ‘anchore-cli’ available in our system.

pip install anchorecli

Install the Jenkins plugin

Now, we start working on the integration with Jenkins. The first step is to install the Anchore integration on Jenkins. We just need to go to the Jenkins management plugin area and install one called ‘Anchore Container Image Scanner Plugin’.

Configure Anchore in Jenkins

There is one more step we need to take to configure the Anchore plugin in Jenkins. We need to provide the engine URL and the access credentials. This credentials can be found in the file ‘~/aevolume/config/config.yaml’.

Configure Docker Hub repository

The last configuration we need to do, it is to add our access credential for our Docker Hub repository. I recommend here to generate an access token and not to use our real credentials. Once we have the access credential, we just need to add them to Jenkins.

Create a Jenkins pipeline

To be able to run our builds and to analyze our containers, we need to create a Jenkins pipeline. We are going to use the script feature for this. The script will look like this:

pipeline {
    environment {
        registry = "fjavierm/anchore_demo"
        registryCredential = 'DOCKER_HUB'
        dockerImage = ''
    agent any
        stages {
            stage('Cloning Git') {
                steps {
                    git ''

            stage('Building image') {
                steps {
                    script {
                        dockerImage = registry + ":$BUILD_NUMBER"

            stage('Container Security Scan') {
                steps {
                    sh 'echo " `pwd`/Dockerfile" > anchore_images'
                    anchore name: 'anchore_images'
            stage('Deploy Image') {
                    script {
                        docker.withRegistry( '', registryCredential ) {
            stage('Cleanup') {
                steps {
                    for i in `cat anchore_images | awk '{print $1}'`;do docker rmi $i; done

This will create a pipeline like:

Execute the build

Now, we just need to execute the build and see the results:


With this, we finish the demo. We have installed Anchore Engine, integrate it with Jenkins, run a build and check the analysis results.

I hope it is useful.

Container Security: Anchore Engine

THC Hydra: Auditing passwords

As we have said previously, the Cyber Security world is full of useful tools to perform different task. At the end of the day, pentesters are usually very proficient with some of them, the ones they use in daily day basis but, at least, they know or they have tried some of the others. Even similar tools or tools that apparently do the same task, sometimes have slightly different behaviors that can be the difference between success or fail in a pentest.

The tool we are going to see today is called THC Hydra. THC Hydra is a tool that will help us to test the strength of our passwords auditing remote authentication services.

As an example, I am going to use the same set up I used in the Ncrack article before. If you do not know what I am talking about, you can follow this link to my previous article.

After we have our service running in our virtual machine, and we have checked the machine and the service are available, we can execute the “hydra” command.

Just a few notes before test our service.

You can execute the command to obtain information about how to execute the tool:


You will see that multiple flags are listed, and the most interesting part is the list of services that are supported by the tool. As an important note, I must say that the number of services supported by the tool depends on the kind of compilation and installation we have done. There are a few libraries or dependencies we need to install before THC Hydra to have support for all types of services.

To follow this example, it is enough if you have install the tool with the “libssh” support.

Now, let’s continue. As you have seen in the help description for the tool, there are multiple flags we can use, but for this test, we are going to focus in the next flags:

  • -l LOGIN or -L FILE: It allows us to give to the tool a user or a list of users.
  • -p PASS or -P FILE: It allows us to give to the tool a password or a list of passwords.
  • service: The service we want to test. In our case “ssh”

Now, following the appropriate syntax, we can execute the next command:

hydra -l fjavierm -P password.txt ssh://

This is going to show us the result:

Hydra v8.4 (c) 2017 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra ( starting at 2017-04-02 08:26:38
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 3 tasks per 1 server, overall 3 tasks, 3 login tries (l:1/p:3), ~1 try per task
[DATA] attacking service ssh on port 22
[22][ssh] host: login: fjavierm password: pa$w0rd
1 of 1 target successfully completed, 1 valid password found
Hydra ( finished at 2017-04-02 08:26:41

As we can see, we have been able to find the weak password.

THC Hydra: Auditing passwords

SSH access with Ncrack

The cybersecurity field has thousands of tools we can use to check the security of our systems. One category of tools we can find is the password crackers. In this group, we can find Ncrack. Ncrack defines itself as a high-speed network authentication cracker.

Ncrack is a high-speed network authentication cracking tool. It was built to help companies secure their networks by proactively testing all their hosts and networking devices for poor passwords. Security professionals also rely on Ncrack when auditing their clients. Ncrack was designed using a modular approach, a command-line syntax similar to Nmap and a dynamic engine that can adapt its behaviour based on network feedback. It allows for rapid, yet reliable large-scale auditing of multiple hosts.

Ncrack’s features include a very flexible interface granting the user full control of network operations, allowing for very sophisticated bruteforcing attacks, timing templates for ease of use, runtime interaction similar to Nmap’s and many more. Protocols supported include RDP, SSH, HTTP(S), SMB, POP3(S), VNC, FTP, SIP, Redis, PostgreSQL, MySQL, and Telnet.

Let´s try to do a little demo. Previously, we need a few things:

  • A remote system to audit. It can be a real system or a virtual machine. In my case, I am going to use a Debian VM with a SSH server installed.
  • Ncrack installed in our machine. There are versions available for different systems like Windows, Linux and Mac OS.
  • We need two dictionaries. One with a list of users we want to use and, the second one with a list of passwords to use to audit the system.

Firsts thing, let´s try the connectivity with the system we want to audit:

~# ping -c 1 PING
( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=0.382 ms

--- ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.382/0.382/0.382/0.000 ms

The next step should be to check if the SSH port is available in the remote system. For this purpose, we can use a tool like Nmap.

~# nmap -sV
Starting Nmap 7.40 ( ) at 2017-03-25 10:09 GMT
Nmap scan report for
Host is up (0.00094s latency).
Not shown: 992 closed ports
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
80/tcp open tcpwrapped
110/tcp open tcpwrapped
111/tcp open rpcbind 2-4 (RPC #100000)
143/tcp open tcpwrapped
443/tcp open tcpwrapped
993/tcp open imaps?
995/tcp open pop3s?
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 6.45 seconds

And, finally, let´s audit our external system using Ncrack. We are going to use a few flags to execute the Ncrack tool:

  • -p: Allows us to specify the port we want to audit.
  • -U: Allows us to specify a file with the list of users.
  • -P: Allows us to specify a file with the list of passwords.
~# ncrack -p 22 -U users.txt -P passwords.txt

Starting Ncrack 0.5 ( ) at 2017-03-25 10:11 GMT

Discovered credentials for ssh on 22/tcp: 22/tcp ssh: 'fjavierm' 'pa$w0rd'

Ncrack done: 1 service scanned in 18.02 seconds.
Ncrack finished.

And, let´s double check the credentials are working properly:

~# ssh
fjavierm@'s password:

The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.
Last login: Sat Mar 25 10:07:52 2017 from

As we can see, now, we have access to the remote system exploiting a weak password.

There are some countermeasures that we can implement to fix this problem, one of them is to establish a strong password policy.

SSH access with Ncrack