Instructor: Michael Teske BI222

 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 , 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 ◦ ◦ 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