Review Please turn in any homework/practicals you

may have Jobs

Job IDs Backgrounding

Runlevels HDDs Partitions

Today

My favorite topic Security

Corporate vs ‘actual’ Hardening IPTables SELinux

Corporate vs Practical Security

• Practical security looks at ports, process that opened that port, and known vulnerabilities

• Port 80 – Internet – well-known, usually masked by network, required for http, etc…

• This on a web server is not a big deal

• Port 23 – Telnet – also well known, required for telnet, HUGE DEAL

• Telnet offers no security, is easily sniffed, has many exploits, offers MITM chances, etc…

Corporate Security• Corporate security is bureaucracy

• Found open telnet port, report goes into writeup

• Writeup goes to boss

• Goes to boss’ boss

• Goes to boss’ boss’ boss

• Boss’ boss’ boss wants details

• Comes back to you to say ‘it’s in an audit’ or not

• VP or Senior Manager will then ‘signoff’ or not

• ALWAYS KEEP THIS EMAIL OR DOCUMENT

Security

ALWAYS KEEP THAT EMAIL OR DOCUMENT

We will not be talking about intrusions today

That is it’s own beast

Those interested should look at NIST

http://csrc.nist.gov/

Audit

• Different types of companies have different audits

• SAS70 – successor to SoX (ish)

• HIPAA – anything relating to healthcare

• PCI (not the hardware spec) – Credit card processing systems

• And more…

Scope

• Know what is in your environment

• Keep an inventory of both hardware systems and applications running on those systems

• Versions are important (Heartbleed)

• Know how a ‘normal’ system behaves

• This is a system profile (active processes, logfiles, common errors and system behavior)

• Actively monitor your logs

System Baseline

• Don’t install things you don’t need to

• Our installs contain quite a bit – a ‘best practice’ installation would not include many of these modules (GUI)

• Set the system to log at an appropriate level (ex. high level is not necessary when application doesn’t log to that level)

• Send logs to a “SEIM” if appropriate

• Backup – set the schedule and ensure failed backup attempts run at some point that day

Device ‘Hardening’ Process of making a device more secure

ie, those things we just mentioned Best Practice all over the place Reducing ‘attack surface’ and making it less of

a target Hackers go after ‘low hanging fruit’ first Script kiddies will give up if they don’t find it If they’re not script kiddies, you’re being

targeted and they’re going to get in anyway

IPTables Who liked Vista’s pop-up security notifications? Who likes Windows firewall? Linux has one too – iptables Again, just an application/program running on

the system It is a simple software based firewall

Firewall Network security system that controls incoming

and outgoing traffic through ‘rules’ Allow web traffic incoming and outgoing Deny telnet either incoming or outgoing Allow outbound SSH connections

Can be a program Can be a physical device Best practice is to have your ruleset and then

the last one is ‘deny all’ Block all traffic that you aren’t sure of

Firewall – Network vs Personal Network firewall usually sits in between our line

in and our gateway out to the internet Literally – there will be a single cable (network

cable, coax, fibre) that your ISP will run into the building – this is your ‘line in’ into your company

Usually, this plugs into the ISP’s router, but may go directly out to the internet

From there, it goes into your network, so frequently it goes into a firewall owned by you

That firewall then routes known good traffic to the router

IPTables OSI Model, firewalls are layer 2/3 devices So conceptually think of them as sitting in

between the plug on the cord and the computer, but really they’re just in another part of memory

Input streams come in/out – a request for a web page, SSH connection, etc…

IPTables looks at the connection, checks its rules for this connection type, and acts accordingly

Accepts or rejects

Rules IPTables comes with a ‘default’ ruleset Mantra seems to be “we’re better than

CentOS5!” Accept or reject – Accept means it allows the

connection in and continues with it’s ruleset (may forward as well – you can ‘chain’ iptables rules just like commands)

Reject means it drops it, done, no connection allowed

We can add rules through the command line

Accessing It Access it through iptables command Show current ruleset

Adding Rules Simple rules – Accept or Reject We want to accept SSH, accept HTTP (so we

can SSH, so we can run a web server) We want to reject Telnet and FTP iptables -A INPUT -p tcp --dport 22 -j ACCEPT -A flag = ‘add’ (we can –D to drop rules we want

to get rid of) -p flag = protocol (SSH uses TCP protocol) --dport = destination port -j flag = do we accept or drop?

Accept HTTP (port 80, tcp)

iptables -A INPUT -p tcp --dport 80 -j ACCEPT So what is the command to deny telnet to port

23 over the tcp protocol?

Best Practice

Best practice with firewalls in general is to have the last rule as the ‘paranoid’ rule

Theory: don’t let anything in that you haven’t explicitly ok’d

iptables -A INPUT -j DROP This at the end of your ruleset means anything

that doesn’t match your rules, gets dropped (and rules with OUTPUT and FORWARD)

Questions on iptables?

iptables -A INPUT -p tcp --dport 80 -j ACCEPT Find a command similar to your own Validate port, protocol, direction, and what do to

with it Is on all Linux systems Best practice is to deny anything unexpected

SELinux Security Enhanced Linux is installed by default Uses mandatory access controls Principle of least privilege

Principle of minimal privilege, principle of least authority

Breaks down users, policies, and security contexts SELinux users do not always match up 1-to-1 with

real users A policy is an explicit list of permissions Context is the ‘labeling’ of what processes can and

cannot access

Three Modes

Disabled, Permissive, Enforcing Disabled = off Permissive = off, but logs all messages

Used with ‘audit2allow’ to build a policy Enforcing = implementing all rules and contexts /etc/selinux/config sestatus command returns current state (no

argument)

Implementing SELinux -Z flag shows ‘context’ of running processes ls -Z or ps -Zef

USE IT! 75% of all businesses will use Dev/Test/Prod

environments The other 25% use small-scale replications of

“production” and then test on a live subset Run ‘permissive’ mode in test, enforcing in

production

If You’re Interested In Security

Corporate security is “white hat” Except for pen-testers, most of whom are GSEC’s

Look at Kali Linux & “Metasploitable” Think about CCDC

http://www.prccdc.org/ I want to put together a team PS – Byte Club!

NIST, SANS GSEC, one specific subject You have to know what you’re breaking into

BTW – ‘Standard Process’

A “req” is needed A good boss shows their resources are over utilized

Ideal description is created HR adds description into their “standard” stuff HR filters all applicants

This is why certs matter “Finalists” are forwarded on to actual manager Then interviews occur

Own Study Security

Corporate vs ‘actual’ Hardening

http://en.wikipedia.org/wiki/Hardening_%28computing%29

http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf

IPTables http://wiki.centos.org/HowTos/Network/IPTables

SELinux http://wiki.centos.org/HowTos/SELinux