Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. System & Network Administration <ul><li>Chapter 3 – Service </li></ul><ul><li>By Chang-Sheng Chen (200803011) </li></ul>
  2. 2. Contents of Chapter 3 <ul><li>3.1 The Basics </li></ul><ul><ul><li>3.1.1 Customer Requirements </li></ul></ul><ul><ul><li>3.1.2 Operational Requirements </li></ul></ul><ul><ul><li>3.1.3 Open Architecture </li></ul></ul><ul><ul><li>3.1.4 Simplicity </li></ul></ul><ul><ul><li>3.1.5 Vendor Relation </li></ul></ul><ul><ul><li>3.1.6 Machine Independence </li></ul></ul><ul><ul><li>3.1.7 Environment </li></ul></ul><ul><ul><li>3.1.8 Restricted Access </li></ul></ul><ul><ul><li>3.1.9 Reliability </li></ul></ul><ul><ul><li>3.1.10 Single or Multiple Servers </li></ul></ul><ul><ul><li>3.1.11 Centralization and Standards </li></ul></ul><ul><ul><li>3.1.12 Performance </li></ul></ul><ul><ul><li>3.1.13 Monitoring </li></ul></ul><ul><ul><li>3.1.14 Service Rollout </li></ul></ul><ul><li>3.2 The Icing </li></ul><ul><ul><li>3.2.1 Dedicated Machine </li></ul></ul><ul><ul><li>3.2.2 Full Redundancy </li></ul></ul><ul><li>3.3 Conclusion </li></ul>
  3. 3. The Basics <ul><li>The most important thing to consider at all stages of design and deployment is the customers’ requirements . </li></ul><ul><ul><li>Talk to the customers and find out what their needs and expectations are for the services. </li></ul></ul><ul><li>Then, build a list of other requirements that are only visible to the SA team . </li></ul><ul><ul><li>Focus on what , rather than how . </li></ul></ul><ul><li>Service should be built on server-class machines that are kept in a suitable environment. </li></ul>
  4. 4. The Basics (cont.) <ul><li>Access to server machines should be restricted to SAs for reasons of reliability and security. </li></ul><ul><li>An SA has several decisions to make when building a service. </li></ul><ul><ul><li>Choosing vendors and products ( software, hardware) </li></ul></ul><ul><ul><li>Reliability, performance, etc. </li></ul></ul>
  5. 5. The Basics (cont.) <ul><li>Most services rely on other services . </li></ul><ul><ul><li>Understanding in detail how a service works will give you insight into the service on which it relies. </li></ul></ul><ul><ul><ul><li>For example, almost every service relies on name service (DNS). DNS relies on network , and therefore, anything that relies on DNS also relies on network. </li></ul></ul></ul><ul><li>A service should be built as simple as possible , with as few dependencies as possible , to increase reliability and make it easier to support and maintain. </li></ul>
  6. 6. The Basics (cont.) <ul><li>Another method of easing support and maintenance is to use standard hardware/software , standard configurations and have documentation in a standard location . </li></ul><ul><li>A key part of implementing any new service is to make it independent of the particular machine </li></ul>
  7. 7. 3.1.1 Customer Requirements <ul><li>When building a new service, you should always start with the customer requirements. </li></ul><ul><li>Gathering the customer requirements </li></ul><ul><ul><li>There are very few services that do not have customer requirements. </li></ul></ul><ul><ul><ul><li>DNS, authentication services , etc. </li></ul></ul></ul><ul><li>A Service Level Agreement (SLA) </li></ul><ul><ul><li>An SLA enumerate the services that will be provided and the level of support they receive . </li></ul></ul>
  8. 8. Service Level Agreement (cont.) <ul><li>A Service Level Agreement (SLA) </li></ul><ul><ul><li>An SLA enumerate the services that will be provided and the level of support they receive . </li></ul></ul><ul><ul><li>It typically categories problems by severity and commits to response times for each category. </li></ul></ul><ul><ul><li>The SLA usually defines an escalation process that increases the severity of a problem if it has not been resolved after a specified time and calls for managers to get involved if problems are getting out of hand. </li></ul></ul>
  9. 9. Service Level Agreement (SLA) <ul><li>The SLA process is a forum for the SAs to understand the customers’ expectations and to set them appropriately, so that the customers can understand what is and is NOT possible and why . </li></ul><ul><ul><li>It is a tool to plan what resources will be required. </li></ul></ul><ul><ul><li>The SLA should document the customers’ requirements and set realistic goals for the SA teams in terms of features , availability, performance, and support. </li></ul></ul><ul><ul><li>It should document future needs and capacity so that all parties will understand the growth plans. </li></ul></ul>
  10. 10. 3.1.2 Operation Requirements <ul><li>The SA team may have other requirements for the new service that are not immediately visible to the customers. </li></ul><ul><ul><li>The administrative interface , whether it interoperates with other existing services and can be integrated with central service such as authentication or directory services. </li></ul></ul><ul><ul><li>SAs also need to consider how the service scales. </li></ul></ul><ul><ul><li>A related consideration is the upgrade path for the service </li></ul></ul><ul><ul><li>The level of reliability </li></ul></ul><ul><ul><li>Network performance issues </li></ul></ul><ul><ul><li>Monitoring issues ( availability, performance, etc.) </li></ul></ul><ul><ul><li>Budget issues </li></ul></ul>
  11. 11. Operation Requirements (cont.) <ul><li>Questions about an upgrade process: </li></ul><ul><ul><li>Does it involve an interruption of service ? </li></ul></ul><ul><ul><li>Does it involve touching every desktop ? </li></ul></ul><ul><ul><li>Is it possible to rollout the upgrade slowly, to test it on a few willing people before inflicting it on whole organization ? </li></ul></ul><ul><li>Try to design the service, so that upgrades are easy, can be performed without service interruption, don’t require touching the desktops, and can be rolled out slowly. </li></ul>
  12. 12. 3.1.3 Open architecture <ul><li>Whenever possible , a new service should be built around open protocols and file formats. </li></ul><ul><ul><li>Any service with an open architecture can be more easily integrated with other services that follow the same standards. </li></ul></ul><ul><li>The business case for using open protocols is simple: </li></ul><ul><ul><li>it lets you build better services because you can select from the best server and client , rather than being forced to pick, for example, the best client and then getting stuck with a less than optimal server. </li></ul></ul>
  13. 13. Open architecture (cont.) - The ability to decouple the client and server selections <ul><li>A better way to select protocols based on open standards ad permit each side (i.e., client and server) to select their own software. </li></ul><ul><ul><li>Customers are free to choose the software that best fits their own needs, biases, and even platforms. </li></ul></ul><ul><ul><li>SAs can independently choose a server solution based on their needs for reliability, scalability, and manageability. </li></ul></ul><ul><ul><ul><li>The SAs can now choose between competing server products, rather than being locked into the (potential difficult to manage) server software and platform required for a particular client application. </li></ul></ul></ul><ul><ul><li>Open protocols provide a level playing field that inspire competition between vendors, which benefits you. </li></ul></ul>
  14. 14. Open architecture (cont.) <ul><li>Open protocols and file formats are typical quite static (or only change in upward compatible ways) and widely support, </li></ul><ul><ul><li>giving you the maximum product choice and maximum chance of reliable, interoperable products. </li></ul></ul><ul><li>The other benefit of using open systems is that you don’t require a gateway to the rest of world. </li></ul><ul><ul><li>Gateways are additional services that require capacity planning, engineering, monitoring, and everything else mentioned in this chapter </li></ul></ul><ul><li>Case Study </li></ul><ul><ul><li>Hazards of Proprietary Email Software </li></ul></ul><ul><ul><ul><li>Primarily based on client user interface and features (e.g., Graphic User Interface, etc.) and no concerns for server management, reliability and scalability </li></ul></ul></ul><ul><ul><ul><ul><li>All messages from all users in a single large file </li></ul></ul></ul></ul><ul><ul><li>Protocol Gateway Reduce Reliability </li></ul></ul><ul><ul><ul><li>Microsoft Exchange Server </li></ul></ul></ul>
  15. 15. 3.1.4 Simplicity <ul><li>When architecting a new service, simplicity should be your foremost consideration. </li></ul><ul><ul><li>The simplest solution that satisfying all the requirements will be the most reliable , easiest to maintain , easiest to expand , and easiest to integrate with other systems . </li></ul></ul><ul><ul><li>As the system grows, it will become complex. Therefore, starting out as simple as possible delays the day when a system has become too complex. </li></ul></ul><ul><li>Sometimes, one or two requirements from the customer or SAs may add considerably to the complexity of the system. </li></ul><ul><ul><li>Reevaluate the importance of these requirements </li></ul></ul><ul><ul><ul><li>These requirements could be met, but at a cost to reliability, support levels, and on-going maintenance. </li></ul></ul></ul>
  16. 16. 3.1.5 Vendor Relations <ul><li>When choosing hardware and software for a service, you should be able to talk to sale engineers from your vendors to get advices on the best configuration from your application . </li></ul><ul><ul><li>Hardware vendors sometimes have product configurations that are tuned for particular applications, such as database or web server. </li></ul></ul><ul><li>If there is more than one server vendor in your environment, and it seems that more than one of your vendors has an appropriate product , You should use the situation to your advantage . </li></ul><ul><ul><li>Get those vendors biding against each other </li></ul></ul><ul><ul><ul><li>the same price for more performance, reliability, or scalability </li></ul></ul></ul><ul><ul><ul><li>Get a better price and be able to invest the surplus </li></ul></ul></ul><ul><ul><li>Even if you know which vendor you will choose, don’t let them know that you have decided until you are convinced that you have the best deal possible . </li></ul></ul>
  17. 17. 3.1.5 Vendor Relations (cont.) <ul><li>When choosing a vendor, particularly for software product , it is important for you to understand the direction in which the vendor is taking the product. </li></ul><ul><ul><li>For key, central service , such as authentication or directory services, it is essential to stay in touch with the product direction , or you may suddenly discover that the vendor no longer supports your platform. </li></ul></ul><ul><li>If possible, try to stick to vendors who develop the product primarily on the platform you use , rather than port it to other platform. </li></ul><ul><ul><li>Having fewer bugs, receiving new features first, and better support, etc. </li></ul></ul>
  18. 18. 3.1.6 Machine Independence <ul><li>For Name-based Service (Ch.6 Name Service) </li></ul><ul><li>Clients should always access a service using a generic name that is based on the function of the service. </li></ul><ul><ul><li>E.g.,, </li></ul></ul><ul><li>The machine should never have a primary machine name that is functional-based, </li></ul><ul><ul><li>because ultimately the function may need to move to another machine. For example, </li></ul></ul><ul><ul><ul><li>Primary name : </li></ul></ul></ul><ul><ul><ul><li>Alias (service) name : </li></ul></ul></ul>
  19. 19. 3.1.6 Machine Independence (cont) <ul><li>For IP address based services , </li></ul><ul><li>we could also use some techniques (such as layer 4 switching) to give the machine that the service runs on multiple virtual IP addresses in addition to the primary real IP address. </li></ul><ul><ul><li>Then the virtual address and the service can be moved to another machine relatively easily. </li></ul></ul>
  20. 20. 3.1.7 Environment <ul><li>A fundamental piece of building a service is providing a reasonable high level of availability , which means placing all the equipments associated with that service into a data center (cf. Ch.17). </li></ul><ul><ul><li>A data center provides protected power, plenty of cooling, controlled humidity (vital in dry or damp climates), fire suppression, and a secure location where the machine should be free from accidental damage or disconnection. </li></ul></ul><ul><ul><li>In addition, a server often needs much high speed network connections (e.g., high-speed links, more interfaces) than its clients because it needs to be able to communicate at reasonable speeds with many clients simultaneously. </li></ul></ul><ul><ul><ul><li>High-speed network cabling and hardware typically are expensive to deploy </li></ul></ul></ul>
  21. 21. Environment (cont.) <ul><li>None of the components of the service should rely on anything than runs on a machine that is not located in the data center. </li></ul><ul><ul><li>The service is only as reliable as the weakest link in the chain of the components that need to be working for the service to be available. </li></ul></ul><ul><ul><li>If that is the case, find a way to change the situation: </li></ul></ul><ul><ul><ul><li>Move the machine into a data center </li></ul></ul></ul><ul><ul><ul><li>Replicate that service onto a data center machine </li></ul></ul></ul><ul><ul><ul><li>Remove the dependency on the less reliable machine </li></ul></ul></ul><ul><li>Case Study </li></ul><ul><ul><li>Hazards of servers relying on Non-servers </li></ul></ul><ul><ul><ul><li>NFS automount </li></ul></ul></ul>
  22. 22. 3.1.8 Restricted Access <ul><li>Restricting server access to the SA team from the beginning is the best approach to ensure reliability and expected performance levels . </li></ul><ul><ul><li>There should be no reason for anyone to log in to a server other than an SA performing administrative work on the server. </li></ul></ul><ul><ul><ul><li>The fewer people who log in to a machine, the more stable it is. </li></ul></ul></ul><ul><ul><li>If a customer can and becomes accustomed to logging in to a particular server, he probably will start running other jobs on it that take CPU and I/O cycles away from the services , without realizing that he is adversely affecting the service . </li></ul></ul><ul><ul><ul><li>E.g., NFS server </li></ul></ul></ul>
  23. 23. 3.1.9 Reliability <ul><li>If you have redundant hardware available, use it as effectively as you can. </li></ul><ul><li>The single most effective way to make a service as reliable as possible is to make it as simple as possible. </li></ul><ul><ul><li>Find the simplest solution that meets all the requirements. </li></ul></ul><ul><li>When you are building a service at a central location that will be accessed from remote sites, it is particularly important to take network topology into account. </li></ul><ul><ul><li>If connectivity to the main site is down, can the service still be available to remote sites ? </li></ul></ul><ul><ul><ul><li>Some, Yes  stale name service, authentication service </li></ul></ul></ul><ul><ul><ul><li>Others, No,  database or file service </li></ul></ul></ul>
  24. 24. 3.1.10 Single or Multiple Servers <ul><li>Independent services (or daemons) should always be on separate machines , if cost and staffing-levels permitting . </li></ul><ul><ul><li>However, if the service that you are building is actually composed of more than one new application or daemon and the communication between those components is over a network, you need to consider whether to put all of the components on one machine or to split them across many machines . </li></ul></ul><ul><ul><ul><li>E.g., a website with a database , a mail system with many filtering mechanisms (e.g., anti-spam, anti-virus, etc.) </li></ul></ul></ul><ul><ul><li>The choice may be determined by security, performance, or scaling concerns . </li></ul></ul>
  25. 25. Single or Multiple Servers (cont.) <ul><li>In other cases, one of the components will initially only be used for this one application , but may later be used by other applications. E.g., </li></ul><ul><ul><li>calendar service + LDAP server (Initially) </li></ul></ul><ul><ul><li>Mail service + LDAP server (later) </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><li>If a service, such as LDAP, may be used by other services in the future , it should be placed on dedicated machines, </li></ul><ul><ul><li>so that the calendar service can be upgraded and patched independently of the (ultimately more critical) LDAP servers. </li></ul></ul>
  26. 26. Single or Multiple Servers (cont.) <ul><li>Sometimes, two applications or daemons may be completely tied together and will never be used apart from each other. </li></ul><ul><ul><li>In this situation, it makes sense to put them both on the same machine. </li></ul></ul><ul><ul><li>E.g., mail server + DNS caching server </li></ul></ul><ul><li>Video Streaming Server </li></ul><ul><ul><li>Encoding, Streaming Server </li></ul></ul>
  27. 27. 3.1.11 Centralization and Standards <ul><li>An element of building a service is centralizing the tools, applications, and services that your customers’ need. </li></ul><ul><ul><li>Centralization ( 集中化 / 單一窗口 ) means that the tools, applications, and services are primarily managed by one central group of SAs on a single central set of servers . </li></ul></ul><ul><ul><li>Support for these services is provided by a central helpdesk . </li></ul></ul><ul><li>Centralizing services and building them in standard ways make them easier to support and lower training costs . </li></ul><ul><ul><li>The service should be designed and documented in some consistent way , so that the SA answering the support call knows where to find everything and thus can respond more quickly . </li></ul></ul>
  28. 28. Centralization and Standards (cont.) <ul><li>Centralization does not preclude centralizing on regional or organization boundaries , particularly if each region or organization has its own support staff. </li></ul><ul><ul><li>Some services , such as e-mail, authentication services and networks, are part of the infrastructure and need to be centralized . </li></ul></ul><ul><ul><ul><li>For large sites, these services can be built with a central core that feeds information to and from distributed regional and organizational systems. </li></ul></ul></ul><ul><ul><li>Other services , such as file services and CPU farms, are more naturally centralized around departmental boundaries . </li></ul></ul>
  29. 29. 3.1.12 Performance <ul><li>From a customer’s view , two things are important in any service: </li></ul><ul><ul><li>“ Does it work ?” and “ Is it fast ?” </li></ul></ul><ul><li>When designing a service , you need to pay attention to its performance characteristics , </li></ul><ul><ul><li>even though there may be many other difficult technical challenges to overcome. </li></ul></ul><ul><li>Performance expectations increase constantly as networks, graphics, and processors get faster. </li></ul><ul><ul><li>To build a service that performs well , you need to understand how it works and perhaps look at ways of splitting it effectively across multiple machines . </li></ul></ul>
  30. 30. 3.1.12 Performance (cont.) <ul><li>Performance expectations increase constantly as networks, graphics, and processors get faster. </li></ul><ul><ul><li>Performance that is acceptable now , may not be six months or a year from now. </li></ul></ul><ul><li>To build a service that performs well , you need to understand how it works and perhaps look at ways of splitting it effectively across multiple machines. </li></ul><ul><ul><li>You also needs to consider how to scale the performance of the system as usage and expectation rise above what the initial system can do. </li></ul></ul>
  31. 31. 3.1.12 Performance (cont.) <ul><li>When choosing the servers that run the service, consider how the service works . </li></ul><ul><ul><li>A lot of disk I/O ? </li></ul></ul><ul><ul><ul><li>More disk read than write (or vice versa) </li></ul></ul></ul><ul><ul><li>Keeping large tables of data in main memory ? </li></ul></ul><ul><ul><ul><li>Lots of fast memory and larger memory caches </li></ul></ul></ul><ul><ul><li>A network-based service that sends large amount of data to clients or between servers ? </li></ul></ul><ul><ul><ul><li>Multiple dedicated servers with high-speed interfaces, clusters of servers, etc. </li></ul></ul></ul>
  32. 32. Performance (cont.) <ul><li>Case Study </li></ul><ul><ul><li>Bad capacity planning makes a bad first impression </li></ul></ul><ul><ul><li>Performance at remote sites (i.e., over wide area links ) </li></ul></ul><ul><ul><ul><li>Web site (e.g., different content for Modem, T1, High speed links, etc.) </li></ul></ul></ul><ul><ul><ul><ul><li>Solution: Proxy server (HTTP accelerator ) </li></ul></ul></ul></ul><ul><ul><ul><li>Handset windows vs. computer windows </li></ul></ul></ul>
  33. 33. Performance at remote sites <ul><li>Performance of the service for remote sites may also be an issue. </li></ul><ul><ul><li>In some cases , quality of service or intelligent queuing mechanisms can be sufficient to make performance acceptable. </li></ul></ul><ul><ul><ul><li>E.g., mail relays/forwarders, web proxies, etc. </li></ul></ul></ul><ul><ul><li>In others , you may need to look at ways for reducing the network traffic . </li></ul></ul><ul><ul><ul><li>Different content on a web system for different speed of links (e.g., text-only versions for low-speed links (modem, T1) and graphical versions for high-speed links, etc.) </li></ul></ul></ul>
  34. 34. 3.1.13 Monitoring (Ch.24) <ul><li>A service is not complete and cannot be called a service unless it is being monitored for availability, problems, and performance and there are capacity planning mechanisms in place. </li></ul><ul><ul><li>The helpdesk , or front-line support group, must be automatically alerted to problems with the service so that they can start fixing them before too many people are affected by these problems. </li></ul></ul><ul><ul><li>Likewise, the SA group should monitor the service on an ongoing basis from a capacity planning standpoint. </li></ul></ul><ul><ul><ul><li>E.g., network bandwidth, server performance, transaction rates, license and physical device availability, etc. </li></ul></ul></ul>
  35. 35. Monitoring Example - Statistics for
  36. 36. Monitoring Example (cont.)
  37. 37. Monitoring Example (cont.)
  38. 38. Monitoring Example (cont.)
  39. 39. 3.1.14 Service Rollout ( 首次推出 ) <ul><li>Make sure the customers’ first impression are positive. </li></ul><ul><ul><li>The rollou t and the customers’ first experiences with the service will color the way that they view the service in the future. </li></ul></ul><ul><li>One of the key pieces of making a good impression is having all of the documentation available , the helpdesk familiar with and trained on the new service , and all the support procedures in place. </li></ul><ul><ul><li>There is nothing worse than having a problem with a new application and finding out that no one seems to know anything about it when you look for help. </li></ul></ul>
  40. 40. 3.1.14 Service Rollout (cont.) <ul><li>The rollout also includes building and testing a mechanism to install new software and configuration settings that are needed on each desktop. </li></ul><ul><ul><li>One-some-many technique </li></ul></ul><ul><ul><ul><li>One  Some  Many </li></ul></ul></ul><ul><li>Ideally, no new desktop software or configuration should be required for the service , because that is less disruptive for your customers and reduce maintenance, </li></ul><ul><ul><li>but installing new client software on the desktops is frequently. </li></ul></ul><ul><ul><li>E.g., enabling IEEE 802.1x authentication scheme, web browser (IE vs. Firefox) </li></ul></ul><ul><li>New Trend </li></ul><ul><ul><li>Example: SSL VPN vs. PPTP VPN </li></ul></ul>
  41. 41. 3.2 The Icing <ul><li>3.2.1 Dedicated Machine </li></ul><ul><li>3.2.2 Full Redundancy </li></ul><ul><ul><li>E.g., Name Service & Authentication Services </li></ul></ul><ul><ul><li>Primary vs. Secondary (duplicate) set of servers </li></ul></ul><ul><ul><ul><li>Failed-over, backup </li></ul></ul></ul><ul><ul><li>Tightly coupled vs. loosely-coupled servers </li></ul></ul><ul><ul><ul><li>Load-sharing, performance-increasing </li></ul></ul></ul>
  42. 42. 3.2.1 Dedicated Machine <ul><li>Having dedicated machines for each service </li></ul><ul><ul><li>More reliable </li></ul></ul><ul><ul><li>Debugging easier when there are reliability problem </li></ul></ul><ul><ul><li>Outage ( 暫時中斷服務 ) more limited in scope, </li></ul></ul><ul><ul><li>And upgrades and capacity planning much easier </li></ul></ul>
  43. 43. Dedicated Machine (cont.) <ul><li>Sites that grow from a small company to a larger one generally end up with one central administrative machine . </li></ul><ul><ul><li>Eventually, this machine will have to be split up and the services spread across many servers because of increased load . </li></ul></ul><ul><ul><li>IP address dependencies are the most difficult to deal with when splitting services from one machine to many. </li></ul></ul><ul><ul><ul><li>Name service (e.g., DNS, NIS), Security service (e.g., router of firewall rules ), etc . </li></ul></ul></ul>
  44. 44. 3.2.3 Full Redundancy <ul><li>Consider which services will benefit your customers most to have completely redundant and start there. </li></ul><ul><ul><li>Name service and authentication services are typically the first services to have full redundancy. </li></ul></ul><ul><ul><ul><li>They are designed for secondary servers </li></ul></ul></ul><ul><ul><ul><li>they are so critical </li></ul></ul></ul><ul><ul><li>Other critical services, such as e-mail, printing, and networks , tend to be considered much later because they are more complicated or more expensive to make completely redundant. </li></ul></ul>
  45. 45. Full Redundancy <ul><li>Another benefit of full redundancy </li></ul><ul><ul><li>It makes upgrade procedure easier. </li></ul></ul><ul><ul><ul><li>A “ rolling update” can be performed </li></ul></ul></ul><ul><li>Case Study: Design Email services for Reliability </li></ul><ul><ul><li>Incoming mail path vs. Outgoing mail path </li></ul></ul><ul><ul><ul><li>Mail relays vs. mail routing hosts </li></ul></ul></ul><ul><ul><ul><li>Mail delivery hosts </li></ul></ul></ul><ul><ul><li>Firewall </li></ul></ul>
  46. 46. Appendix <ul><li>Background - Internet Applications </li></ul><ul><li>Networking Troubleshooting Process </li></ul><ul><li>Case Study: </li></ul><ul><ul><li>E-mail system operations and design considerations </li></ul></ul><ul><ul><li>Security events </li></ul></ul>
  47. 47. Background - Internet Applications
  48. 48. Truth Depends on Interpretation (e.g., Anti-spam or anti-virus mail filtering ) Filtering with H 1 (msg) Filtering With H 2 (msg) Mail Spool Discard <ul><li>MTA 1 (or MUA 1 ) </li></ul>Accep t <ul><li>MTA 0 </li></ul><ul><li>MTA = Mail Transfer Agent </li></ul><ul><li>MUA = Mail User Agent </li></ul><ul><li>MTA 2 (or MUA 1 ) </li></ul>
  49. 49. Internet <ul><li>Bouncing server </li></ul><ul><li>Incoming SMTP Gateway Farm </li></ul><ul><li>Mail Spool </li></ul><ul><li>server </li></ul><ul><li>Outgoing SMTP Gateway Farm </li></ul><ul><li>Firewall </li></ul>典型 E-mail 系統運作圖 <ul><li>SMTPauth </li></ul><ul><li>Mail Filtering </li></ul><ul><li>BL/GL/WL </li></ul><ul><li>Auto-learn </li></ul>
  50. 50. MTA LDA Mail spool Internet POP3/IMAP server MUA user Mail storage Anti-virus programs Incoming Flow of a Typical Mail System <ul><li>User PC </li></ul><ul><li>procmail </li></ul><ul><li>sendmail </li></ul><ul><li>Netscape, </li></ul><ul><li>MS-outlook, etc. </li></ul><ul><li>A Typical Mail System </li></ul>
  51. 51. <ul><li>Incoming </li></ul><ul><li>SMTP Gateway </li></ul><ul><li>SMTP </li></ul><ul><li>POP3/IMAP </li></ul>SMTP <ul><li>Outgoing </li></ul><ul><li>SMTP Gateway </li></ul><ul><li>source </li></ul><ul><li>destination </li></ul>Firewall, filtering Firewall, filtering Generic E-mail Transmission Path 1 2 3 4 5 6
  52. 52. A Hybrid Model for Anti-spam -- Generic Mail Filtering Generic Mail Filtering White List Black List Automatic SPAM Learning Reject Mail Spool <ul><li>Accept </li></ul>Grey List (1) (2) (3) (4) Pass Pass Fail Fail Fail temporarily Client Update <ul><li>Discard </li></ul><ul><li>Bounce </li></ul>
  53. 53. Sample Statistics anti-spam in ( ) All Msg. 73% Rejected 27% Greylist 25% ClamAV SpamAssassin 2% Virus 3% 17% 5% Passed Blocked SpamLevel > 16 Passed SpamLevel (6-15)
  54. 54. Networking Troubleshooting Process DNS_b DNS_a SMTP_a SMTP_b DNS Filtering DNS Filtering Router/Switch Filtering Router/Switch Filtering SMTP Filtering SMTP Filtering Client Router_a Router_b
  55. 55. Port-scanning summary on DNS servers of neighbor sites
  56. 56. 竹苗區網 DNS server 入侵事件 - Sample scenario <ul><li>2000 年 , 某校在區網的網域 , 登錄有兩個 DNS servers </li></ul><ul><ul><li>不過 , 從一開始 , 就只有建立一個 server </li></ul></ul><ul><li>該 server-A 有 security hole, 被外來者闖入 </li></ul><ul><ul><li>入侵者 , 持續透過該 server-A, 嘗試入侵國外網站 </li></ul></ul><ul><ul><li>由於該單位未設立 abuse, postmaster 等標準聯絡信箱 , 且該機器的 root mail 根本無人處理 </li></ul></ul><ul><ul><li>網域上層 , 持續收到國外不同地方轉來的抱怨與求助 e-mail </li></ul></ul><ul><li>從區網的 router 統計數字 , 發現該校有大量異常的 DNS 流量 </li></ul><ul><ul><li>往國外地區 ( 東歐 ) </li></ul></ul>
  57. 57. <ul><li>DNS </li></ul><ul><li>Server </li></ul><ul><li>farm </li></ul>.com .arpa Others <ul><li>DNS </li></ul><ul><li>server </li></ul><ul><li>Caching-only </li></ul>www, proxy SMTP Layer-1 Layer-2 <ul><li>Ordinary </li></ul><ul><li>client </li></ul>Multiple outgoing paths and distributed DNS Internet ISP-2 ISP-1
  58. 58. Traffic Amplifying Attacks via DNS Zone Transfer A: Attacker V: attacked site ( Victum) D1 D2 Dn Q: zone transfer Dn: n - >some large number Q(n) R(n) R(1) R(2) Q(1)
  59. 59. Common Terms <ul><li>Reliability ( 可信度 , 可靠性 ) -- From Wikipedia, </li></ul><ul><ul><li>In general, reliability (systemic def.) is the ability of of a person or a system to perform and maintain its functions in routine circumstances , as well as hostile or unexpected circumstances . </li></ul></ul><ul><ul><li>The IEEE defines it as &quot;. . . the ability of a system or component to perform its required functions under stated conditions for a specified period of time .&quot; </li></ul></ul>
  60. 60. Common Terms <ul><li>In telecommunications and reliability theory , the term availability has the following meanings: </li></ul><ul><ul><li>1. Simply put, availability is the proportion of time a system is in a functioning condition . </li></ul></ul><ul><ul><ul><li>Note 1: The conditions determining operability and committability must be specified. </li></ul></ul></ul><ul><ul><ul><li>Note 2: Expressed mathematically, availability is 1 minus the unavailability . </li></ul></ul></ul>
  61. 61. Common Terms <ul><li>In telecommunications and reliability theory , the term availability has the following meanings: </li></ul><ul><ul><li>2. The ratio of (a) the total time a functional unit is capable of being used during a given interval to (b) the length of the interval. </li></ul></ul><ul><ul><li>Note 1: An example of availability is 100/168 if the unit is capable of being used for 100 hours in a week. </li></ul></ul><ul><ul><li>Note 2: Typical availability objectives are specified either in decimal fractions , such as 0.9998, or sometimes in a logarithmic unit called nines , which corresponds roughly to a number of nines following the decimal point, such as &quot; five nines&quot; for 0.99999 reliability. </li></ul></ul>
  62. 62. Definition of availability <ul><li>Barlow and Proschan [1975] define availability of a repairable system as &quot;the probability that the system is operating at a specified time t .&quot; </li></ul><ul><li>Representation </li></ul><ul><ul><li>The most simple representation for availability is as a ratio of the expected value of the uptime of a system to the aggregate of the expected values of up and down time , or </li></ul></ul>