There are a number of safety issues when using containers. For example, many Docker images ship outdated libraries. And sometimes security vulnerabilities in these outdated libraries can lead to privilege escalation.
This is why StackRox, a security startup, has applied advanced machine learning to this issue. After three years of development, they recently emerged from stealth, announcing a product that analyzes system calls, network traffic, Docker container commands. It then correlates attack indicators and presents this via a sophisticated UI.
StackRox built their product on top of CrateDB, because CrateDB can handle the complexity of this type of analysis in real time.
Since Crate.io runs customer-facing instances of CrateDB on Docker, we decided to double down on security and deploy StackRox to harden our public cluster. In this blog post, I’ll discuss why security is important for a database like CrateDB, and how to use StackRox to protect your data.
Database Security: Beyond the Basics
StackRox complements the authentication, access controls, and encryption added in Crate 2.0 Enterprise Edition with comprehensive threat coverage for well-known attack vectors on containerized database applications.
Some of those threats include:
- SQL injection is one of the most common attack vectors for database applications. An injection attack can allow an attacker to manipulate the database, or tamper with, steal, or destroy data.
- Misconfiguration. For example, if a database is supposed to be read-only, but someone has write access by mistake.
- Privilege escalation is another attack vector or policy violation that allows a user to operate with a broader, unauthorized scope than they would otherwise be able to.
- Many other threats which could lead to someone moving data out, or exfiltrating data, from the database.
StackRox monitors and tracks access to CrateDB containers and highlights potentially malicious activity.
Deploying StackRox and CrateDB on Docker
CrateDB runs seamlessly in a Docker swarm (or any orchestrator of your choice!) and can be deployed using our guide.
Within the same swarm, a StackRox deployment is required to monitor and control what's going on in the swarm. The people over at StackRox guided us through the deployment. They have an awesome on-boarding process to help get customers set up.
Once deployed, StackRox immediately detects containers running on each worker node, and begins monitoring activity. StackRox has several hundred pre-defined filters, which flag potential threats. Machine learning helps analyze threat indicators and adapt to your situation based on the activity it sees over time.
For CrateDB, this traffic would be calls to the
_sql endpoint CrateDB Admin UI. Unusual behavior would include calls to an outside URL or things that happen within the container, like binaries being deleted or replaced, and so on.
Another great StackRox feature is image scanning.
Image scanning alerts you when a vulnerable image is pulled into your Docker swarm. This is a useful feature for flagging vulnerabilities in a mixed stack of CrateDB, reverse proxies, web applications, and other web service applications.
Monitoring CrateDB Database Security With StackRox
In detect mode, StackRox shows unusual activities as events.
In the screenshot below, the attack was a simple
docker exec -it 6a0bb0a39e20 sh, which mimics an attack with a reverse shell or other remote code execution.
In this screenshot we can see the map dot for CrateDB turned orange, which means that something has happened to this application. On the left side, there’s a list of incidents that detail what has been done.
A click on the alert reveals even more information like what model detected the event, how severe it is, and details on the attack phases and context.
Here's what a simple
apk update looks like:
Many attacks focus on data. Therefore it’s important to take extra care of databases.
Crate.io works hard to provide a secure, robust, yet easy-to-manage distributed database. StackRox is one way to further enhance this!
Other good security practices include network isolation and regular audits.