Jenkins & Public-Facing Servers

Jenkins

If we use Jenkins, we need to keep it patched, as we discussed back in Chapter 1: Patching.

But Jenkins has a common misconfiguration that merits special mention. Jenkins instances are often started with insecure settings that allow for unauthenticated execution of commands in a scripting language called Groovy. Groovy scripts can execute arbitrary shell commands. So a common attack is to scan the network for misconfigured Jenkins servers, use the Groovy Scripting Console to dump passwords from the Jenkins server, then use those passwords to compromise other servers on the network.

So make sure to lock down Jenkins so that it requires a login before allowing any of its functionality, especially the Groovy Scripting Console.

Public-facing servers

We’re going to look at one last source of vulnerabilities in this chapter—long-forgotten public-facing servers. It’s easy to forget to shut down public-facing servers that aren’t used anymore. This mistake is even easier to make if you use a cloud hosting service. We’ll address the problem of forgotten or unpatched servers exposed to the internet similar to the way we’ve addressed other vulnerabilities in this chapter.

First, we’ll do a one-time cleanup effort. Once we’ve addressed the problems of today, we’ll add automation to make sure we don’t reintroduce this problem again in the future.

Ideally, before you kick off a one-time cleanup effort, you already know exactly what servers you have exposed to the internet. Whether that’s the case or not, it’s worthwhile to examine your organization using a public tool. This can either serve as a first census or a double-check on your existing practices around maintaining an up-to-date inventory of your public-facing servers.

The first time you do a check like this can be pretty eye-opening. You may be surprised to see how many public servers you actually maintain. You may also be surprised about how up-to-date the software running on those servers is. If these scans reveal version numbers of server-side software, be sure to google for CVEs for that software. We covered CVEs in What Is a CVE?.

Two tools that are great for this are Shodan and Censys. Both Shodan and Censys continually scan the full IPv4 address space and provide queryable access to data about the servers they discover on the internet.

See what your organization has exposed to the internet. Hopefully, there are no surprises there. Clean things up if there are. Then decide on a way to check automatically going forward. The amount of automation you will want to build out will be highly specific to your organization.

If you only have a couple of servers, maybe you can just manually look at your hosting service’s dashboard and eyeball it periodically. If you have a larger footprint or a larger organization with lots of people who can provision new servers, you’ll probably want to put more effort into automating scans.

---

In the next lesson, we’ll conclude this chapter with a quick further reading list and an overview of what’s to come.