By Hervé Arsène Bineli Manga.
Continuous integration (CI) is completely disrupting the way software is delivered in companies today. To use it in your company, use the world-renowned solution Jenkins.
This article is aimed at helping you get to know about the security risks a jenkins server may face, and show you how you can mitigate these problems.
Jenkins is the de facto tool to implement continuous integration and continous deployment (CI/CD) pipelines in the industry. Since its launch in 2010, Jenkins has been very appreciated as an Open source automation server. It has been used for automating building, deploying and automating software. As of today, Jenkins has a huge database of more than 1600 plugins and a growing number of users, with more than 200.000 installations.
However, its popularity has resulted in many security issues, new vulnerabilities and attacks executed against Jenkins servers. This is the reason why it is necessary for anyone administering a Jenkins installation to know what are the threats A Jenkins installation can be exposed to, how to mitigate these risks, and where they can seek help if there is an issue with the software.
My article is aimed at showing how to set up a jenkins server, how to secure it from internal and external attackers, and how to evaluate the effectiveness of the security configurations we made. This piece is based on recommendations made by SANS on how to harden a Jenkins installation.
Jenkins is an open-source continuous integration server capable of orchestrating a chain of actions that help to achieve continuous integration in an automated fashion.
Jenkins is free and is entirely written in Java. Jenkins is a widely used application around the world that has around 300k installations, and this number is growing day by day.
It is a server-based application and requires a web server like Apache Tomcat. The reason Jenkins became so popular is because it can monitor repeated tasks, which arise during the development of a project. For example, if your team is developing a project, Jenkins can help you to continuously test your project build and show you the errors in early stages of your development.
By using Jenkins, software companies can accelerate their software development process, as Jenkins can automate building and testing at a rapid rate. Jenkins supports the complete development lifecycle of software from the building and testing stages, to documenting the software and deploying stages, and really all the other stages in a software development lifecycle.
Jenkins was developped by Kosuke Kawagushi, an employee of SUN Microsystems. When SUN was acquired by Oracle in 2011, the Hudson project (the original name of Jenkins) went open source with the name Jenkins.
Below are some of the major security vulnerabilities discovered.
Serialization and de-serialization are methods to send application's data through a network by converting them to the binary format. The vulnerability occurs on the de-serialization phase, when allowing untrusted code to be executed on remote hosts. This vulnerability can be used by an attacker to remotely execute arbitrary code on Jenkin's server. To prove this vulnerability, Stephen Blewit in 2015 crafted a proof of concept, creating a payload using the Java de-serialization vulnerability.
Cross-site scripting is an attack to access the users of a website through the dynamic injection of malicious code into the webpage's Javascript code. CVE-2015-7536 allows a lower privilege user to create code that could result in cross-site scripting when other users visit this page. The vulnerability fix prevents script execution from the workspace as well as archived artifacts.
Jenkins security has a built-in cross-site request forgery protection that's disabled by default. When enabled, this can cause difficulty when using Jenkins features such as remote API and some plugin functionality. With this protection enabled, Jenkins' CSRF protection still has bugs that allowed attackers to circumvent it with crafted POST requests.
Jenkins uses a matrix-based security system that can grant access from a very granular level. Any user with job creation and configuration privileges has shell access to the nodes because job configuration allows an arbitrary command to run on the nodes. A compromised Jenkins administrator or privileged account is a recipe for disaster because the attacker could have control over all nodes attached to the master.
Now that we have presented the different vulnerabilities a Jenkins server may face, let's see how you can secure your server.
Jenkins global security is the first line of defense in protecting the asset it controls. Core Jenkins supports four security realms: delegate to servlet container, Jenkins's own user database, LDAP, and Unix user/group database. The "Unix user/group database" option uses Unix's PAM database to authenticate Jenkins users. This is useful for extending Jenkins users with Unix servers preconfigured with LDAP (see Nemeth, Hein, & Snyder, 2006). The best authentication method is LDAP because most organizations that use it enforces a 90-day password change. If the LDAP account gets compromised, an account lockout or password reset also protects the Jenkins system that benefits from it.
The second part of selecting a security realm is the authorization method. Matrixbased security allows user permissions configuration at a global level. Project-based matrix authorization strategy extends matrix-based security by allowing security on a perjob basis. This option is beneficial for restricting access to jobs on a per group or user basis.
Enable the slave to master access control prevents the node from asking the master to do harmful things. For example, if the master needs to temporarily take control of a user's machine to do a specific job, turn off this option if all nodes are under full control of the Jenkins master.
No matter how secure Jenkins security is, passwords get passed around as clear text without the Secure Sockets Layer (SSL). The remedy for passing around password in clear text is to use an SSL certificate. It is easy to generate a self-signed SSL key with Java's keytool with the following command:
$ Keytool -genkey -alias jenkins -keyalg RSA -keystore jenkins.key -keysize 2048If the "slave to master access control" is not enabled, the attacker can now send requests for the master to do and cause harm.
You can start a Jenkins server with the following command:
$ java -jar jenkins.jar --httpPort=8080This command can be harmful for your system because any user which has access to the list of processes can see the command line options used to launch the Jenkins server. Winstone servlet container offers configuration file in place of the complicated command line parameters. For security purposes, storing KeyStore password in a configuration file means not exposing passwords on the command line. Remove all permissions to the configuration file for group members' permission and other users' permission so that only the user who runs Jenkins master has access. This is a non-issue for web servers because they already utilize configuration files.
By default in when mitigating security risk for any computer system, you have to disable all the functionalities that are not essential for your systems to work. So, as we found that the Jenkins' Groovy CLI is a security risk for Jenkins' servers, and since one can manage his Jenkins' server without using the Groovy CLI, you have to disable it by default.
Since Jenkins' CLI is a core functionality of Jenkins, you have to write some code to disable it. Here is the Groovy source code used to disable the Groovy CLI :
import jenkins.*; import jenkins.model.*; import hudson.model.*;
// disabled CLI access over TCP listener (separate port)
def p = AgentProtocol.all()
p.each {
x -> if (x.name.contains("CLI")) p.remove(x)
}
// disable CLI access over /cli URL
def removal = {
lst -> lst.each {
x -> if (x.getClass().name.contains("CLIAction")) lst.remove(x)
}
}
def j = Jenkins.instance; removal(j.getExtensionList(RootAction.class)) removal(j.actions)Next, disable Jenkins's SSHD daemon because every Jenkins has this feature on by default. If there is a need for these features, the recommendation is to configure the SSHD daemon to a known port so that firewall rules can whitelist Jenkins administrator's IP.
To better secure a server installation, it is always recommended to follow the best practices to secure the OS on which the application is running. So, here is the part OS hardening, where you will see how to secure a your OS to minimize attacks to your Jenkins' server.
One should never run with administrator or root privileges regardless of the operating system platform. In addition to not running with administrator or root privileges, implement least privileges by removing sudoer access to the account that Jenkins uses. Implementing the principle of least privileges can reduce the damage caused by a compromised account by as much as 86% according to research data from Dr. Eric Cole.
Regularly applying system patches and OS updates are crucial to security because OS vendors routinely fix vulnerabilities and bugs. Both Windows and Mac OS X recommend enabling the automatic patching policy. In addition to OS updates, updating Java is equally important because vulnerabilities in Java will put Jenkins at risk.
Look for all running processes with ps -ax on Linux and Mac OS X or Task Manager on Windows. If the service is not essential to Jenkins or the OS, disable it because Jenkins master and its nodes do not need a file sharing service to function properly.
There are a few files on Jenkins master that should only be accessible by the account running Jenkins. Make sure the configuration files are properly locked down by granting access only to the owner if running under web servers such as Tomcat or JBoss. The other file that requires the same permission lockdown is the SSL certificate file.
Due to the nature of Jenkins master and their nodes, the application that runs on them are finite. This makes application whitelisting an excellent tool for protecting Jenkins.
Turning on the host-based firewall on Jenkins servers and nodes is another layer of protection against attacks. The only system that nodes should talk to are Jenkins master, source code servers, operating system's patch update servers, antivirus update server, and the IP addresses of administrators who does system maintenance.
After completing this article, you have seen how much security risks a mal-configured Jenkins server is going through. Then, we showed you how you can perform security configurations to protect your confidential data. Now you are able to protect the data inside your organization and promote the best practices for securing Jenkins' servers.
A Silver Lining to Your Cloud Application Architecture Design
Jack Ma Foundation Equips Africa in Fight against Coronavirus
2,605 posts | 747 followers
FollowAlibaba Cloud Community - March 31, 2022
Alibaba Cloud MVP - March 27, 2020
Alibaba Clouder - May 29, 2018
Alibaba Clouder - July 3, 2019
Alibaba Clouder - May 30, 2018
Alibaba Clouder - February 27, 2019
2,605 posts | 747 followers
Follow
Simple Application Server
Cloud-based and lightweight servers that are easy to set up and manage
Learn More
Web Hosting Solution
Explore Web Hosting solutions that can power your personal website or empower your online business.
Learn More
DevOps Solution
Accelerate software development and delivery by integrating DevOps with the cloud
Learn More
Alibaba Cloud Flow
An enterprise-level continuous delivery tool.
Learn MoreMore Posts by Alibaba Clouder