Gain insights into effective security techniques including patching, cryptography, and phishing prevention. Explore practices to make systems resistant and vulnerabilities more detectable, enhancing defense against attacks.

docker.tar.gz

network-commands

node

It seems like hardly a week goes by without a high-profile computer breach. Why do these happen? How can you prevent them? This course doesn’t have all the answers, but it does outline practices that make life harder for attackers and that will help tide you over until you get a full-time security team in place.

In this course, you will learn 5 simple, yet effective, techniques for preventing attackers from getting into your system. These techniques are related to: patching, software vulnerabilities, cryptography, windows security, and phishing. Within each chapter you will learn the best practices for preventing vulnerabilities and how to make them more detectable. 

This course is based on the Pragmatic Programmers’ book, Practical Security, and is aimed at developers, admins, team leads, architects, technology generalists, and all others who stand guard against the things that disrupt the network.

Practical Security: Simple Practices for Defending Your Systems

# Jenkins
If we use [Jenkins](https://jenkins.io), we need to keep it patched, as we discussed back in [Chapter 1: Patching](https://www.educative.io/courses/practical-security-defending-your-systems/introduction-3jA4yM9Y8AA).

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](http://groovy-lang.org/). 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?](https://www.educative.io/courses/practical-security-defending-your-systems/a-closer-look-at-patching/#joe-asks-what-is-a-cve).

Two tools that are great for this are [Shodan](https://shodan.io) and [Censys](https://censys.io/). 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.

In this lesson we will explore how misconfigured Jenkins instances and forgotten about public-facing servers can lead to vulnerabilities. 

Introduction

Patching

Vulnerabilities

Cryptography

Windows

Phishing

Jenkins & Public-Facing Servers

Jenkins