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 OR DOCUMENT

Security ALWAYS KEEP THAT OR DOCUMENT We will not be talking about intrusions today That is it’s own beast Those interested should look at NIST

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 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 ng%29 ng%29 pamphlet-i731.pdf pamphlet-i731.pdf IPTables SELinux