Instructor: Michael Teske BI222. Lab follow up Current events Linux/Unix best practices Project...

43
Instructor: Michael Teske BI222

Transcript of Instructor: Michael Teske BI222. Lab follow up Current events Linux/Unix best practices Project...

Instructor: Michael TeskeBI222

Lab follow up Current events Linux/Unix best practices Project Management

Questions/comments from lab

Discussion

Open source Excellent business case with good ROI Low acquisition/growth costs Lower facilities costs

Open source Which applications are available? Vendor commitment Support?

Free?◦ Just download it◦ Pay for support?

How much will it save you?◦ Difficult to generate firm cost savings projections◦ “Too good to be true” numbers easy to produce

Administration◦ User accounts◦ Network configuration◦ Change management◦ Backups

FUD (fear, uncertainty, and doubt)◦ Skills◦ Lawsuits

Skills availability Uniqueness/risk Fear/emotion Is it?

◦ Secure◦ Stable◦ Profitable

Biggest issue: “culture clash” between departments

Mission-critical vendor applications may not be supported

Consider alternatives◦ Many exist◦ Cost savings may justify change

Standard procedures Proven techniques What is the goal?

◦ Reliability ◦ Availability◦ Supportable◦ Performance◦ Security

Measurable results

Services Security Up to date

Configuration

Services commonly installed on systems are inherently dangerous

Server should not be running services not required◦ R* services ◦ Printer services ◦ Mail Server ◦ Telnet◦ FTP◦ And more…

Manual

# default: off# description: The rsync server is a good addition to an ftp

server, as it \# allows crc checksumming etc.service rsync{ disable = yes socket_type = stream wait = no user = root server = /usr/bin/rsync server_args = --daemon log_on_failure += USERID}

Physical security Operating System Application(s)

Who has access? How do they have access? Can you “secure” it? Do you have any control over this?

Installation Configuration Maintenance

Where What How

Where to start?◦ Sudo!

Where do we go from there?◦ Applications?◦ Basic configuration?

One concern with multiple Linux machines is maintaining root passwords

Same password on all machines? Having to remember multiple passwords? When performing tasks across multiple

machines◦ Consider sftp a file to 75 machines…

Protect startup? Uncontrolled system shutdown never

causes problems (true?) Possible data loss after uncontrolled

shutdown even after fsck

What Where Checking

logins.def limits.conf rc.local

Accounts without passwords Accounts whose passwords are identical to

the account name Accounts with overly simplistic passwords

◦ (ex. 12345678, ABCDEFGH, password, qwerty, etc)

Enforce aging of passwords when possible Use strong passwords

Network configuration ◦ TCP/IP configuration different

Like any system, housekeeping and maintenance require effort, new tools

Determine a user’s identity and permission Managing authentication for many

instances may become difficult Typical result

◦ Resistance to updates◦ Multiple instances not kept in sync

Secure Shell (SSH) uses PKI to enable secure connections

Very useful for maintaining root access on many instances◦ Using ssh-agent on original client, can set up

environment such that password needs to be entered only once

Monitor Firewall Intrusion Detection

Calculate real storage needs

YUM◦ Open Source program to manage package

(product) installation◦ Used to install add-ons ◦ Used to update packages◦ Think “InstallShield for Linux”

Most packages available as RPMs◦ RPMs not just used by Red Hat◦ Alternatives: tarball or custom executable◦ Other less elegant solutions

You need to verify that downloaded packages are what you think they are◦ Could have viruses/Trojan horses in them

RPMs are digitally signed, avoid “man-in-the-middle” alteration

Also include package metainfo ◦ Where and when created, by whom◦ Level, support, description, license, etc

Dependency information included (other required libraries, products)◦ No DLL issues◦ Tools exist to help find dependent RPMs on the

Internet Disk space requirement aggregation

◦ Precalculates space required including RPMs and by dependencies

◦ No surprises 98% through an install

RPM-installed packages can be deleted very cleanly

Enable system recoverability◦ What if accidental edit breaks critical file?

rpm –V lets you know if RPM-installed files have been altered since installation

Numerous types Source RPMs are generally architecture-

independent Can aid in porting to new architectures

◦ Just try to build it, see if it compiles

Some applications actually just use RPM as wrapper, non-RPM installer

RPMs can be poorly built◦ Bad dependencies◦ Files might be installed in inappropriate locations◦ Might not work with some distributions

General learning curve◦ Building RPMs is non-trivial

What How

Infrastructure◦ Apache◦ DNS◦ Samba◦ MySQL◦ Email◦ Etc…

Applications of all types

You want to build a house Where do you start? There are many tasks to be completed A task like the “basement” has sub-tasks

◦ Dig hole◦ Pour footings

This is referred to as work breakdown structure

Network Applications © Paul Massey, 2008