Linux Security

Brought to you by the good folks at:

Michael J. Clarkson, Jr.Red Hat Certified Architect Level II

Instructor for Red Hat and Cloudera

O’Reilly Media Content Creator

Really smart guy

Good looking, too

Presented By

I thought Linux was secure?

You don’t just become secure magically by

installing Linux. Security requires vigilance no

matter which OS you choose. Linux is still the

right choice of course...

Reasons to secure Linux

● Recent security exploits:o Heartbleed

o Shellshock

o Daily discoveries of new holes in software

● Regulationso DoD STIG (Security Technical Implementation Guide)

o Financial CIA (Confidentiality, Integrity, Availability)

regulations

o HIPAA

● Because you have important data

Bona fides - Why should you listen to me?

(If you read the second slide, you’d know this.)

● Red Hat Certified Architect Level IIo Actually it’s Red Hat Certified {E,I,X,VA,SA-

OSP,DS,A}

● Cloudera Certified Administrator Apache

Hadoop

● Really smart guy

“If you entrench yourself behind strong

fortifications, you compel the enemy seek a

solution elsewhere.”

- Carl von ClausewitzPrussian general and military strategist

Author of Vom Kriege (On War)

The key to Linux security comes in layers.Key components we cover today:

● Planning and testing : If you fail to plan, you plan to

fail.

● Network Security o Host based firewalls

● Local Securityo Security Patching

o Password aging and hardening

o Beating your users regularly (Preventing social engineering)

o SELinux (or AppArmor, not covered today)

● Security Analysiso Tools you can use to check your security and monitor changes

Key components we don’t cover today,

but you totally should learn to use:

● Securing data at rest with encryption: LUKS

encryption with cryptsetup

● Network encryption: Using TLS to encrypt

normally insecure traffic such as syslog,

Hadoop Mapreduce, etc.

● iSCSI over TLS or IPSec

● Central authentication with LDAP/Kerberos

using FreeIPA Server

Planning and testing

“If you fail to plan, you plan to fail.”

- Ben Franklin

● Set up a test environment that replicates

your physical.

● Test, break, fix, repeat.

Network Security

● Cover your bases with all of the security

approaches for your network hardware.

● Even with all of those in place, enable host

based firewalls on your individual servers.

This isn’t hard, just tedious. We’ll show you

how next.

● Monitor your network. We’ll cover this more

later.

Host based firewalls

Two native options for production servers:

● iptables

● firewalld

iptables (simple web server example)

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

iptables -A INPUT -p tcp --dport 443 -j ACCEPT

iptables -A INPUT -j DROP

service iptables save

The above accepts all connections from localhost, SSH, and connections on http and

https. Anything not matching one of those gets dropped.

firewalld (simple web server example)

firewall-cmd --permanent --zone=trusted --add-interface=lo

firewall-cmd --permanent --add-service=http

firewall-cmd --permanent --add-service=https

firewall-cmd --permanent --add-service=ssh

firewall-cmd --reload

The above accepts all connections from localhost, SSH, and connections on http and

https. Anything not matching one of those gets dropped.

Local Security - Patching

No software is perfect. If it were, we’d be

unemployed because it would just work all by

itself.

Normal patching cycles don’t work

Normal patching cycles vary wildly per

company and range from monthly to annually.

Fine for bugfixes, bad for security.

Security specific patching (YUM)

For yum based systems (RHEL, CentOS, and derivatives)

● Install yum-plugin-security

● When a new CVE or Red Hat Advisory drops:o yum update --cve CVE-NUMBER

o yum update --advisory RHSA-NUMBER

● To update all security patcheso yum update --security

Security specific patching (APT)

For apt based systems (Ubuntu, Debian, and derivatives) it

isn’t quite as straightforward but here is one solution:apt-get update

grep security /etc/apt/sources.list > /tmp/security.list

apt-get upgrade -oDir::Etc::Sourcelist=/tmp/security.list

NOTE: There are many other, probably more elegant

solutions out there, but I’m a Red Hat guy so not really my

wheelhouse.

Security updates - bottom lineUpdate your security any time an advisory

drops. How will you know? Join the mailing list

for your distro.

Red Hat:http://www.redhat.com/mailman/listinfo

Ubuntu:https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce

Local Security - Password Security

Default aging rules:

● 99999 days till passwords expire

● Not a dictionary word

● 6 character length

● Really, really bad

Fixing password security● Set better defaults for age and length in

/etc/login.defs

● Set better complexity requirements with

pam.cracklib

● Beat your users. Okay, train them not to use

kids names, pets, or anything guessable.

Also, no taping passwords to things. I have a

better answer to keep them from hating you

later.

/etc/login.defs

Set reasonable defaults like these

PASS_MAX_DAYS 30 #30 days till change

PASS_MIN_DAYS 0 #No min age

PASS_MIN_LEN 10 #10 char minimum

PASS_WARN_AGE7 #Warn 7 days before expire

pam.cracklib - Before you begin

WARNING: Typos in PAM will break your

system. BE CAREFUL.

Open a second terminal with a root shell. This

will save your bacon if you typo something.

pam.cracklib

In /etc/pam.d/system-auth (and sometimes

/etc/pam.d/password-auth) you can configure

more complex password requirements. What

follow are my favorites.

pam.cracklib

Find the line beginning with:password requisite pam_cracklib.so

Add from these optionsminlen - set minimum password length

minclass - minimum number of classes, lowercase, uppercase, digit, and

other

lcredit, ucredit, dcredit, ocredit - extra credit for using another class

(lowercase, uppercase, digit, and other respectively)

pam.cracklib examples

Require all four classes, min length of 10, max at 3 retries

to reset password:password requisite pam_cracklib.so try_first_pass retry=3 minlen=10

lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1

Require at least 3 classes, extra credit for special

characters and numbers, 15 char minimum:password requisite pam_cracklib.so try_first_pass minlen=15

minclass=3 ocredit=2 dcredit=2

Extra tidbit

To help with brute force attacks, set a lockout

thus:Also in /etc/pam.d/system-auth (and password-auth where it exists) in

the auth section:

auth required pam_tally2.so deny=2 unlock_time=180

pam_tally2 -u user #check user's failed login tally

pam_tally2 --reset -u user #reset count for user

Beat your users regularly

Okay, HR might not like that. Educate your

users regularly. An educated user is more likely

to follow protocols if they know why.

Tips for educating users● Encourage passphrases.

o The most secure password is one you can

remember. ‘Eb7#$()!_T’ is less secure than ‘Tree

hats bear 23!’ because it is less likely to be written

down and still meets complexity and length.

● Train them to recognize phishing and social

engineering.

● Train them to hide the keyboard when typing

passwords in front of others.

SELinux - NEVER TURN IT OFF

I don’t care what your vendor says. Turning off

SELinux is a horrible idea. After this lecture,

you will never disable it ever again. (Trying my

Jedi mind trick)

SELinux - How it works

Controls Subject → Object interaction

● Subject - The thing performing the action,

usually a running application.

● Object - The thing being acted upon, usually

files or network ports.

● Access Vector - The action requested like

read, write, port bind, etc.

SELinux Example - Apache httpd allowed

SELinux uses types to allow actions

Apache being well behaved and reading its own website to

serve:httpd (type httpd_t) → read → index.html (type httpd_sys_content_t)

Request goes to Access Vector Cache in the kernel. Allow

rule exists, so action is allowed.

SELinux Example - Apache httpd Blocked

Apache trying to be bad and read your password hash file:httpd (type httpd_t) → read → /etc/shadow (type shadow_t)

Request goes to Access Vector Cache in the kernel. No

allow rule exists, so action is denied and logged in

/var/log/audit/audit.log.

Controlling SELinux

In enforcing rules fully enforced. In permissive it logs what

would have violated but never blocks anything.

To see current mode: getenforce

To set to permissive: setenforce 0

To set to enforcing: setenforce 1

To set persistently edit: /etc/selinux/config

Controlling SELinux - cont.

The targeted policy has sensible values set for

most applications. To view them:ls -Z /default/application/dir

ps -Z PID

ps auxZ | grep application

Setting contexts for new directories

Example - you want to use Apache name virtual hosting in

the directory /www.semanage fcontext -a -t httpd_sys_content_t ‘/www(/.*)?’

restorecon -vFR /www

The above sets the new default context for /www, its

children, and everything in them to the correct context for

web content which we can get from:ls -Zd /var/www

Setting contexts for nonstandard ports

Example - you want to use Apache on tcp port 777.

First, find the port type for httpd with:man httpd_selinux

Then use semanage to add 777 to that type:semanage port -a -t http_port_t -p tcp 777

SELinux important commands

getenforce

setenforce [0|1]

semanage fcontext -a -t some_type ‘/some/dir(/.*)?’

restorecon [-v verbose, -F force, -R recursive]

semanage port -a -t some_port_t -p [tcp|udp] portnumber

semanage boolean -l

setsebool -P some_boolean [0|1]

audit2allow -alrM name

semodule -i name.pp

Security Analysis Tools

You can’t secure your weaknesses when you

don’t know where you have them. Remember,

the greatest flaw is cognisance of none.

NMAP - http://insecure.org

WARNING: Tests for open ports. Do not use on

a network you do not personally own without

direct written consent.

● Used to test for open ports that should not

be.

● Often referred to as the hacker’s Swiss Army

Knife.

OpenVAS - http://www.openvas.org/

Per its own website: “The world's most

advanced Open Source vulnerability scanner

and manager.”

● Has fancy WebUI

● Has a daily updated feed of potential

vulnerabilities to scan for.

● Great when preparing for a security audit.

Nessus - http://www.tenable.com/products/nessus

No longer open source but still the most

commonly used vulnerability scanner.

● Offers support contracts.

● Constantly updated vulnerability scanner.

● Used by many security auditors to ensure

compliance with STIG or similar regulations.

Kali Linux - https://www.kali.org/The WARNING from NMAP goes triple here.

Do not use without the direct written consent of

the network owner.

● Full Linux distribution with a plethora of

penetration testing tools.

● If your network has a weakness, Kali will find

it.

● Descended from Backtrack Linux.

Summary

● Use local firewalls

● Keep your systems updated

● Keep your password rules sensible

● Keep your users educated

● NEVER DISABLE SELINUX

● Check your work with the tools we covered

Contact info

michael@flakjacketinc.com

http://flakjacketinc.com

Twitter: @m_clarkson78

Brought to you by: