1. Instructor: Michael Teske BI222

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

3.  Questions/comments from lab

4.  Discussion

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

6.  Open source  Which applications are available?  Vendor commitment  Support?

7.  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

8.  Administration ◦ User accounts ◦ Network configuration ◦ Change management ◦ Backups  FUD (fear, uncertainty, and doubt) ◦ Skills ◦ Lawsuits

9.  Skills availability  Uniqueness/risk  Fear/emotion  Is it? ◦ Secure ◦ Stable ◦ Profitable  Biggest issue: “culture clash” between departments

10.  Mission-critical vendor applications may not be supported  Consider alternatives ◦ Many exist ◦ Cost savings may justify change

11.  Standard procedures  Proven techniques  What is the goal? ◦ Reliability ◦ Availability ◦ Supportable ◦ Performance ◦ Security  Measurable results

12.  Services  Security  Up to date

13.  Configuration

14.  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…

17.  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 }

18.  Physical security  Operating System  Application(s)

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

20.  Installation  Configuration  Maintenance

21.  Where  What  How

22.  Where to start? ◦ Sudo!  Where do we go from there? ◦ Applications? ◦ Basic configuration?

23.  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…

24.  Protect startup?  Uncontrolled system shutdown never causes problems (true?)  Possible data loss after uncontrolled shutdown even after fsck

25.  What  Where  Checking

26.  logins.def  limits.conf  rc.local

27.  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

28.  Network configuration ◦ TCP/IP configuration different  Like any system, housekeeping and maintenance require effort, new tools

29.  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

30.  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

31.  Monitor  Firewall  Intrusion Detection

32.  Calculate real storage needs

33.  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

34.  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

35.  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

36.  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

37.  Numerous types  Source RPMs are generally architecture- independent  Can aid in porting to new architectures ◦ Just try to build it, see if it compiles

38.  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

39.  What  How

40.  Infrastructure ◦ Apache ◦ DNS ◦ Samba ◦ MySQL ◦ Email ◦ Etc…  Applications of all types

42.  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

43. Network Applications © Paul Massey, 2008