1

System & Network Administration

•Chapter 0 – Introduction•Chapter 1 – Desktops

By Chang-Sheng Chen (20080218)

2

The Practice of System and Network Administration

• Components of the book– Part 1: The Principles– Part 2: The Processes– Part 3: The Practices– Part 4: Management

• The Editing Style of each chapter– The Basics – The Icing

3

System Administration Tasks

• A Typical Life Cycle of SA Tasks– Identification/Definition Phase

• Collecting information• Analysis

– Design Phase– Deployment Phase

• Installation, Configuration

– Maintenance Phase• Update• Debug/Troubleshooting• Reconfiguration, Rebuild

4

Contents of Chapter 0 - Introduction

I.1 Do These Now !– Use a Trouble-Tick System – Manage Quick Requests Right – Start Every New Host in a Known State

I.2 Conclusion

5

Contents of Chapter 1

1.1 The Basics1.1.1 Loading the System Software and Applications ini

tially1.1.2 Updating the System Software and Applications 1.1.3 Network Configuration1.1.4 Dynamic DNS with DHCP

1.2 The Icing1.2.1 High Confidence in Completion1.2.2 Involve customers in the Standarization Process1.2.3 A Variety of Standard Configurations

1.3 Conclusion

6

Desktops

• Desktops are usually deployed in large quantities and in long life cycles.

• The Big Three Tasks of managing operations systems on Desktops– Loading the system software and applications initially– Updating the system and applications – Configuring network parameters

• Automating these tasks makes a world of difference

7

Desktops - The Basics

• Managing operations systems on Desktops– Loading the system software and applications initially– Updating the system and applications – Configuring network parameters

• Evard’s life cycle of a machine (Evard 1997)• Automating Installation Reduces Frustration• First-class Citizens (i.e., Fully-support)

– A variety of platforms

8

Evard’s life cycle of a machine( LISA XI, Evard 1997)

9

What can we learn from the diagram in previous page ?

1. Various states and transitions exists.– Plan for installation, things will break

and require repair, etc.

2. The computer is usable only in the configured state.

– We want to maximize the amount of time spent in that state.• The setup and recovery process should

be fast, efficient, and automated.• Ensure that the OS degrades as slowly

as possible.– Design decisions by the vendor have the

biggest impacts– Architecture decisions by the SA can

weaken the protection

10

What can we learn from the diagram in previous page ? (Cont.)

3. When mistakes are made during installation, the host will start into a decay cycle.

4. Reinstallation (rebuild) is similar to installation, except one may potentially have to carry forward old data and applications.

5. Finally, machines are eventually retired.– Some data and applications must be carried to

the replacement machine or stored on the tape for future reference.

11

Updating the system software and Applications

• Updates are different from the Initial Load– The host is in usable state (vs. disabled state)– The host is in an office– No physical access– The host is already in use

• Cannot be messed up after the update/patches– The host may not in “known state”– The host may have “live” users (e.g., log in and still

running active programs)– The host may be gone (e.g., not booted temporarily).– The host may be dual-boot (e.g., Windows + Linux, or

even multi-boot,)

12

Updating the system software and Applications

• Characteristic:– An automated update system has potential to cause massive

damage.– Use the One-Some-Many technique to reduce the risk of a

failed patch.• One -> Some -> Many

• Tips for guiding the update process– Create a well-defined update that will be distributed to all hosts.– Establish a communication plan so that those affected do not

feel surprised by updates.– Checkpoints and restart

• If there is a single failure, the group size returns to a single host and starting growing again.

– Needing a way for customers to stop the deployment process if things go disastrously wrong.

13

DHCP

• Dynamic DNS with DHCP– Adds unnecessary complexity and security risks– Letting a host determine its own hostname is a security risk (e.g.,

conflicting names)– Workaround: Dynamic DNS should be limited to specific DNS zo

nes (i.e., building a “jail” for dynamic DNS configuration)• Advantages of Using DHCP

– Avoiding situations in which the customers are put into a position that allow their simple mistakes to disrupt others.

• E.g., The same IP address as a router (default gateway)– Managing DHCP Lease Time

• Lease time can be managed to aid in propagating updates. (e.g., Change subnet netmask)

– DHCP Also assists in Moving Clients away from Resources (e.g., Changing IP address of a DNS server)

14

Network Configuration

• DHCP (Dynamic Host Configuration Protocol)– The most common system to automating ways to update

network parameters for a large desktop environment

• Use Template Rather Than Per-Host Configuration • When to Use Dynamic Lease

– When you have many hosts chasing a small number of IP address

• Cf. Office LANs statically assigned• Servers -> static assignment (permanent lease)

• DHCP and Public Network– LANs in university labs or dorms, hotel rooms, wireless LANs,

etc.

15

1.2 The Icing

• High confidence in Completion – automation

• Involve Customers in the Standardization Process– Platform controlled by management (i.e., specific AP

sites, telesales offices, etc.)– Platforms controlled by SA Team (more common)

• Base system, most commonly required applications, utilities that can be licensed economy in bulk

• A Variety of Standard Configurations– Beauty or nightmare ?

• Simple (all the same) and scalability (multiple configuration schemes)

16

Appendix

• Background - Internet Applications

• Networking Troubleshooting Process

• 5 Phases of Software Life Cycle

• DNS security and DHCP

• Case Study: E-mail delivery errors of NCTU-course portal

17

Background - Internet Applications

18

Networking Troubleshooting Process

DNS_b

DNS_a

SMTP_a

SMTP_b

DNSFiltering

DNSFiltering

Router/SwitchFiltering

Router/SwitchFiltering

SMTP Filtering

SMTP Filtering

ClientRouter_a

Router_b

19

5 Phases of Software Life Cycle

Waterfall Model

20

5 Phases of Software Life Cycle

Realistic Waterfall Model

21

Local Attacks (1)DNS spoofing

HOST DNSserverX.localdomain.it

10.1.1.50

MITM

10.1.1.1

If the attacker is able to sniff the ID of the DNS request,he/she can reply before the real DNS server

22

Local Attacks (2)DNS spoofing - tools

• Ettercap (http://ettercap.sf.net)

– Phantom plugin

• Dsniff (http://www.monkey.org/~dugsong/dsniff)

– Dnsspoof

• Zodiac (http://www.packetfactory.com/Projects/zodiac)

23

Local to remote attacks (1)DHCP/DNS spoofing

• The DHCP request are made in broadcast.

• If the attacker replies before the real DHCP server it can manipulate:

– IP address of the victim– GW address assigned to the victim– DNS address

24

Local to remote attacks (2)DHCP spoofing - countermeasures

• YES - detection of multiple DHCP replies

• Yes – restrict the DHCP replies to a range of IP – e.g., discard the DHCP replies from remote sit

es across edge routers since they can be spoofed

25

26

27

Viewing Header Source of a Mail Messages

28

Excerption of The SMTP System Log • Sep 13 12:43:31 mail sm-mta[1868]: k8D4hUEP001868: from=<cs

chen@mail.nctu.edu.tw>, size=4154, class=0, nrcpts=3, msgid=<45078D1E.9060906@mail.nctu.edu.tw>, proto=ESMTP, daemon=MTA, relay=C200-152.cc.NCTU.edu.tw [140.113.200.152]

• Sep 13 12:43:31 mail sm-mta[1870]: k8D4hUEP001868: to=<cschen@mail.nctu.edu.tw>, ctladdr=<cschen@mail.nctu.edu.tw> (1002/20), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=94461, relay=local, dsn=2.0.0, stat=Sent

• Sep 13 12:43:33 mail sm-mta[1870]: k8D4hUEP001868: to=<n0170@infor.org>, ctladdr=<cschen@mail.nctu.edu.tw> (1002/20), delay=00:00:02, xdelay=00:00:02, mailer=esmtp, pri=94461, relay=athena.infor.org. [203.64.26.200], dsn=2.0.0, stat=Sent (Ok: queued as A6EA617029)

• Sep 13 12:43:34 mail sm-mta[1870]: k8D4hUEP001868: to=<leafmab.csie93@nctu.edu.tw>, ctladdr=<cschen@mail.nctu.edu.tw> (1002/20), delay=00:00:03, xdelay=00:00:01, mailer=esmtp, pri=94461, relay=d2-spool.ntcu.net. [211.76.241.2], dsn=2.0.0, stat=Sent (Ok: queued as EC8D419EF4)