DOCSLIB.ORG

Design and Management of Email Service

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design and Management of Email Service Design and Management of Email Service Source : homepage.ntu.edu.tw/~jsc/2005-mail.ppt Outline Introduction to the architecture and operation of SMTP Design of a suitable email system – Webmail solutions Postfix and simple configuration samples Spam and virus filtering Conclusion 2 Overview Electronic mail service has already evolved into one of the major Internet applications. It is not only fundamental, but also a must. Users may become impatient when mails were delayed, not to mention failed to access their emails. – Imagine we meet the situation of power failure or cut of water supply 3 Architecture of a Simple Mail System Consists of the following components – MTA - Mail transfer agent Sending and forwarding emails Server end – MDA - Mail delivery agent Delivering emails to recipients’ mailbox Server end – Pop3/Imap4 Daemons For users to download their mailboxs Server end – MUA - Mail user agent Reading and composing emails 4 Client end Architecture of a Simple Mail System Protocols Used for Mail System Protocols – For computer programs to communicate with each other – Similar to languages that human beings speak SMTP – Simple Mail Transfer Protocol – Too simple to provide any “advanced features” Authentication Authorization POP3 – Post Office Protocol version 3 – Simple IMAP4 – Internet Message Access Protocol version 4 – Fully compatible with internet message standards, e.g. MIME. – Allow messages to be accessed from more than one computer. – Provide support for online, offline, and disconnected modes. 6 – Multiple and share folders. Mail Forwarding Between Servers How to Find the Way to the Destination? How do we find the way to [email protected]? 8 DNS: The Key to All Internet Services Query DNS server by the address part of email address.([email protected]) 1. Query for MX records 2. Query for A records 3. Give up! Not required to exist a real machine hosting the address.(ntu.edu.tw) Adding MX records to improve query performance and to reduce unnecessary query overhead. 9 DNS: Query Results Precedence value of MX records – Lower values with higher priority 10 DNS: Query Results When MX record is absent, second query is required to issue. 11 Features Required By Modern Mail Systems This is what end users care. Ease of use interface – IMAP4 – Webmail Security – Authentication – Encrypted transmission Spam and virus filtering – The only effective way to prevent from virus infection is to remind and force your users to install antivirus softwares. 12 – Stop using M$ systems is alternative solution. Make the Right Decision For the Promise of Performance MTA – Postfix Our suggestion! – Sendmail Not scalable! Lack of new features. Not efficiency in resource management. Rich of documents and tutorials – Qmail Termination of development. – Exim Immature. – M$ Exchange Seeking trouble for yourself? POP3/IMAP4 – UW-IMAP – Courier-IMAP Supports Maildir format. – Dovecot Supports both mbox and Maildir format. Still under development. – Cyrus Proprietary spool format. 13 Not easy to convert between other formats. Webmail: The Trend of Browser Based Mail Reader Your determination depends on the system architecture. IMAP4 based – Access the mailbox via IMAP4 protocol locally or remotely. – Flexible, scalable – Speed may be limited by protocol overhead and network transmission. – Horde IMP project Locally direct access – Access the mailbox locally, proprietary protocol. – Could only run on local mail storage server. – NFS could be applied when deploying multiple servers – Extremely fast!! iff system not overloaded. – Not scale well when you want to expand. – Openwebmail Excellent project developed by NCKU, Taiwan Marvelous support to Chinese encodings Only support mbox format currently 14 Webmail Architecture – IMAP4 based Webmail Architecture – Locally Direct Access Postfix: The Modern and Advance MTA http://www.postfix.org Developed by Wietse Venema Features – Easy replacement of existing sendmail system by binaries with same file name and functionality . e.g. sendmail, newaliases – Human readable configuration file – Multiple small programs with limited execution privilege – Multiple queues to avoid block of normal mails – Backend database lookup table supported – Better support for virtual host – Virtual user system supported – Content filtering interface 17 – Simple spam check/block mechanism Postfix - the Big Picture http://www.postfix.org/big-picture.html – Yellow ellipsoids are mail programs. – Yellow boxes are mail queues or files. – Blue boxes are lookup tables. 18 Postfix Installation Debian Linux – apt-get install postfix-tls libsasl7 libsasl-modules-plain courier-imap Redhat/Fedora Linux – rpm -ivh postfix-2.2.x.i386.rpm – rpm -ivh cyrus-sasl-2.1.21.i386.rpm BSD – Use the ports system – /usr/ports/mail/postfix – /usr/ports/security/cyrus-sasl2 19 – /usr/ports/mail/courier-imap Post Installation Postfix Configuration – master.cf Similar to inetd.conf Control the behavior of small programs – In contrast against sendmail, with one binary and one config file – main.cf The main configuration of the mail system – In general cases, no modification is required for a simple setup. Commands to control the postfix program – postfix start – postfix stop 20 – postfix reload Test For Receiving Email Send an email to yourself. Check system logs – /var/log/maillog An simple test from [email protected] to [email protected] 21 Frequently Used Configuration Options In main.cf myhostname = mail.cc.ntu.edu.tw home_mailbox = Maildir/ mydomain = cc.ntu.edu.tw message_size_limit = 20971520 myorigin = $mydomain smtpd_recipient_limit = 1000 mydestination = $myhostname, localhost.$mydomain – On a mail domain gateway, you should also include $mydomain. mynetworks_style = host relay_domains = $mydestination 22 SMTP/Authentication Traditional mail servers could only determine their relay policy based on connected ip addresses. Insufficient in face of the modern network – DHCP, NAT – ADSL and dialup users – Roaming users Mobile, wireless SMTP Authentication – Username/password authentication for each mail delivery. – Reduce the chance to relay spam mails for anonymous. 23 Email Headers Envelope header – Negotiated between mail servers – Typical tricks that SPAM mail plays Why do I receive mails that are not destined to me? Content Text – Mail servers will not examine the content in general cases. 24 Real World Snail Mail Example Postman could only deliver the mail by envelope information. Sender address is not verified when email delivery. – Trick of SPAM mails. Content may be irrelevant or conflict with envelope. 25 Virus and Spam Mail Virus mail – Contain virus infected attachment – How do we determine if the mail is virus infected? Simple and easy. Base on the inspection and judgment of antivirus software. Spam mail – UCE/UBE Unsolicited Commercial Email Unsolicited Bulk Email – How do we determine if the mail is a Spam mail? Difficult. It’s not a yes/no problem. 26 One person’s meat may be another’s poison. Issues When Dealing With SPAM Do not block or discard users’ mail unless you have the authorization and delegation. The only safe and acceptable assistant you can provide is to score and tag each mail and let your users to do the rest themselves. To warn or not to warn the senders/recipients is a dilemma! – Virus and spam senders nowadays always fake the from address. – System notification mails may be another kind of SPAM. The result will be blamed by your users and blocked by 27 other mail servers. Greylisting Recently proposed (2003) method to block spam and virus mails. RFC requires MTA to be capable to support queue and retry of temporarily undeliverable mails. – Spam and virus always fire and forget. – For efficiency concern, usually they do not retry. How it works? – In brief, block every delivery at its first try. – For each mail delivery, check if the the triplet(source ip, sender, recipient) was seen recently. If yes, pass the mail. If not, reject the delivery with “450 Please retry later.” 28 Greylisting Drawback – Mail delivery will suffer a delay ranging from several minutes to hours. Depending on the remote MTA configuration. Risk – Sites that do not retry their mail delivery. Some bank notifications were observed to try only once. Mail sending programs that process the SMTP transaction themselves without calling the “sendmail” MTA interface. Suggestion – Whitelisted known hosts to prevent from delay and loss of mail. 29 Greylisting Benefit – Effectively reduce the volume of spam and virus. – Effectively reduce both cpu and disk load of servers. 30 Softwares To Block/Filter Spam and Virus Postfix – Content filter interface Postgrey – Greylisting policy server Amavisd-new – http://www.ijs.si/software/amavisd – http://www.ijs.si/software/amavisd/README.postfix Clam Antivirus – http://www.clamav.net – A GPL virus scanner SpamAssassin – http://spamassassin.apache.org 31 Software Architecture for Filtering 32 Amavisd-new A high performance interface between MTA and content checkers. – Calling external antivirus programs to do virus scanning. – Calling external spamassassin program to do spam level determination. – CPU intensive workloads. – Can be flexibly configured to pass, discard, or quarantine mails based on user defined policy. Pass spam mails with score > 10 with subject prepended the *** SPAM *** keyword. Quarantine spam mails with score > 20. Discard spam mails with score > 30. Quarantine
Load more

Recommended publications
  • Fighting Spam
    Fighting Spam 2017-10-18 Dianne Skoll Roaring Penguin Software Inc. [email protected] www.roaringpenguin.com Approaches to Fighting Spam ● Reputation-Based (IP, Domain) ● Authentication (SPF, DKIM, DMARC) ● Behavior-Based (greylisting, botnet detection) ● Content-Based ● Defense in Depth www.roaringpenguin.com IP Reputation ● Typically implemented by DNSBLs. ● Reactive – IPs are listed only after they spam. ● Some DNSBLs are high-quality. Most are not. ● Few are transparent as to listing and delisting criteria. ● Few have good IPv6 coverage. ● Useful as a first pass to cut down on spam passing to the rest of the filtering stages. www.roaringpenguin.com Domain Reputation ● Also typically implemented by DNSBLs. ● Reactive. ● Low to moderate hit rate. ● May be applied to sending domain and/or to domains of URLs in the message body. www.roaringpenguin.com Domain Reputation - 2 ● Spammers often register throwaway domains as sending domains. ● Idea: Penalize messages from “newly-seen” domains. ● CanIt 10.1.7 tracks domains seen across all CanIt installations and permits you to (mildly) penalize mail from only-recently-seen domains. www.roaringpenguin.com Authentication: SPF ● SPF (Sender Policy Framework) is a mechanism whereby domain owners can declare which machines may send email on their domains’ behalf. ● For arbitrary domains, an SPF “pass” is a mild spam indicator! ● Spammers are better at setting up SPF than many legitimate administrators. www.roaringpenguin.com Authentication: SPF - 2 ● SPF is useful for trusted domains (banks, PayPal, eBay, etc.) ● Adding points on SPF “fail” or “softfail” is useful. ● Subtracting points on SPF “pass” for arbitrary domains is dangerous. ● Subtracting points on SPF “pass” for trusted domains is useful.
    [Show full text]
  • Sicherer Betrieb Von E-Mail-Servern (Isi-S)
    Sicherer Betrieb von E-Mail-Servern (ISi-Mail-Server) BSI-Studie zur Internet-Sicherheit (ISi-S) Version 1.0 ISi-Reihe ISi-S Sicherer Betrieb von E-Mail-Servern Vervielfältigung und Verbreitung Bitte beachten Sie, dass das Werk einschließlich aller Teile urheberrechtlich geschützt ist. Erlaubt sind die Vervielfältigung und Verbreitung zu nicht-kommerziellen Zwecken, insbesondere zu Zwecken der Ausbildung, Schulung, Information oder hausinternen Bekanntmachung, sofern sie unter Hinweis auf die ISi-Reihe des BSI als Quelle erfolgen. Dies ist ein Werk der ISi-Reihe. Ein vollständiges Verzeichnis der erschienenen Bände findet man auf den Internet-Seiten des BSI. http://www.bsi.bund.de oder http://www.isi-reihe.de Bundesamt für Sicherheit in der Informationstechnik ISi-Projektgruppe Postfach 20 03 63 53133 Bonn Tel. +49 (0) 228 99 9582-0 E-Mail: [email protected] Internet: http://www.bsi.bund.de © Bundesamt für Sicherheit in der Informationstechnik 2009 2 Bundesamt für Sicherheit in der Informationstechnik ISi-Reihe ISi-S Sicherer Betrieb von E-Mail-Servern Vorwort Liebe Leserinnen und Leser, immer mehr Prozesse verlagern sich in die virtuelle Welt des Internets: Kommunikation und Daten- austausch erfolgen per E-Mail, Bankgeschäfte und Einkäufe werden zunehmend online getätigt. Dabei müssen häufig persönliche und vertrauliche Daten über das Internet versendet werden. Diese sind ein attraktives und lukratives Ziel für Online-Kriminelle, die heute international organisiert und professionell strukturiert zusammen arbeiten. IT-Kriminalität ist für die Angreifer ein lohnenswertes Geschäft bei vergleichsweise niedrigem Risiko. Identitätsdiebstahl und Angriffe mit Schadprogram- men unterschiedlichster Art gehören bei der Nutzung des Internets zu den ernstzunehmenden Bedrohungen für alle Anwender.
    [Show full text]
  • Toward an Automated Vulnerability Comparison of Open Source IMAP Servers Chaos Golubitsky – Carnegie Mellon University
    Toward an Automated Vulnerability Comparison of Open Source IMAP Servers Chaos Golubitsky – Carnegie Mellon University ABSTRACT The attack surface concept provides a means of discussing the susceptibility of software to as-yet-unknown attacks. A system’s attack surface encompasses the methods the system makes available to an attacker, and the system resources which can be used to further an attack. A measurement of the size of the attack surface could be used to compare the security of multiple systems which perform the same function. The Internet Message Access Protocol (IMAP) has been in existence for over a decade. Relative to HTTP or SMTP, IMAP is a niche protocol, but IMAP servers are widely deployed nonetheless. There are three popular open source UNIX IMAP servers – UW-IMAP, Cyrus, and Courier-IMAP – and there has not been a formal security comparison between them. In this paper, I use attack surfaces to compare the relative security risks posed by these three products. I undertake this evaluation in service of two complementary goals: to provide an honest examination of the security postures and risks of the three servers, and to advance the study of attack surfaces by performing an automated attack surface measurement using a methodology based on counting entry and exit points in the code. Introduction Contributions and Roadmap System administrators frequently confront the The paper makes two major contributions. First, problem of selecting a software package to perform a I undertake an in-depth discussion of the relative secu- desired function. Many considerations affect this deci- rity postures of the three major open source IMAP sion, including functionality, ease of installation, soft- servers in use today.
    [Show full text]
  • Set up Mail Server Documentation 1.0
    Set Up Mail Server Documentation 1.0 Nosy 2014 01 23 Contents 1 1 1.1......................................................1 1.2......................................................2 2 11 3 13 3.1...................................................... 13 3.2...................................................... 13 3.3...................................................... 13 4 15 5 17 5.1...................................................... 17 5.2...................................................... 17 5.3...................................................... 17 5.4...................................................... 18 6 19 6.1...................................................... 19 6.2...................................................... 28 6.3...................................................... 32 6.4 Webmail................................................. 36 6.5...................................................... 37 6.6...................................................... 38 7 39 7.1...................................................... 39 7.2 SQL.................................................... 41 8 43 8.1...................................................... 43 8.2 strategy.................................................. 43 8.3...................................................... 44 8.4...................................................... 45 8.5...................................................... 45 8.6 Telnet................................................... 46 8.7 Can postfix receive?..........................................
    [Show full text]
  • Server Administration
    Server administration Remo Suppi Boldrito PID_00148466 GNUFDL • PID_00148466 Server administration Copyright © 2009, FUOC. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License" GNUFDL • PID_00148466 Server administration Index Introduction............................................................................................... 5 1. Domain name system (DNS)............................................................ 7 1.1. Cache names server .................................................................... 7 1.2. Forwarders ................................................................................... 10 1.3. Configuration of an own domain .............................................. 11 2. NIS (YP)................................................................................................. 14 2.1. ¿How do we initiate a local NIS client in Debian? ..................... 14 2.2. What resources must be specified in order to use NIS? .............. 15 2.3. How should we execute a master NIS server? ............................ 16 2.4. How should we configure a server? ............................................ 17 3. Remote connection services: telnet and ssh............................... 19 3.1. Telnet and telnetd
    [Show full text]
  • The Qmail Handbook by Dave Sill ISBN:1893115402 Apress 2002 (492 Pages)
    < Free Open Study > The qmail Handbook by Dave Sill ISBN:1893115402 Apress 2002 (492 pages) This guide begins with a discussion of qmail s history, architecture and features, and then goes into a thorough investigation of the installation and configuration process. Table of Contents The qmail Handbook Introduction Ch apt - Introducing qmail er 1 Ch apt - Installing qmail er 2 Ch apt - Configuring qmail: The Basics er 3 Ch apt - Using qmail er 4 Ch apt - Managing qmail er 5 Ch apt - Troubleshooting qmail er 6 Ch apt - Configuring qmail: Advanced Options er 7 Ch apt - Controlling Junk Mail er 8 Ch apt - Managing Mailing Lists er 9 Ch apt - Serving Mailboxes er 10 Ch apt - Hosting Virtual Domain and Users er 11 Ch apt - Understanding Advanced Topics er 12 Ap pe ndi - How qmail Works x A Ap pe ndi - Related Packages x B Ap pe ndi - How Internet Mail Works x C Ap pe ndi - qmail Features x D Ap pe - Error Messages ndi x E Ap pe - Gotchas ndi x F Index List of Figures List of Tables List of Listings < Free Open Study > < Free Open Study > Back Cover • Provides thorough instruction for installing, configuring, and optimizing qmail • Includes coverage of secure networking, troubleshooting issues, and mailing list administration • Covers what system administrators want to know by concentrating on qmail issues relevant to daily operation • Includes instructions on how to filter spam before it reaches the client The qmail Handbook will guide system and mail administrators of all skill levels through installing, configuring, and maintaining the qmail server.
    [Show full text]
  • Esa Study Contract Report
    ESA STUDY CONTRACT REPORT ESA Contract No: Subject: Contractor: ESA ITT Number Current and Future Tech- Distributed Systems Group, AO/3-12280/07/NL/CB nologies for Collaborative Vienna University of Tech- Working Environments nology ESA CR() No: No of volumes: 1 Contractor’s Reference: This Volume No: 1 TEUN Abstract: This document reports the final, detailed result of the study on current and future technologies for collaborative working environments (CWEs). The goal of this study is to analyze current CWEs and whether they and their future trends are suitable for large- scale multinational organizations. To this end, we have analyzed the structure of large-scale organizations in general, and of ESA in particular, with respect to organization, geographical distribution, and IT environments. Requirements for CWEs used in collaborative work are presented. Based on an initial list of criteria given by ESA, we have revised and extended the list to introduce a comprehensive set of criteria for evaluating CWEs. The state-of-the- art CWEs are discussed and classified. We have selected 15 representative CWE products and evaluated and compared them in detail. From the evaluation and comparison of CWE products, we have presented our findings of current issues and future trends of CWEs. In particular, existing products provide many features required by large-scale and multinational organizations but those features are not well-integrated into a single system. Due to the complexity of collaborative work within those organizations, often many CWEs are used in parallel and it is not easy to integrate those CWEs together. The work described in this report was done under ESA Contract.
    [Show full text]
  • Social-Engineering Experiment
    Social-Engineering Experiment Master's Thesis Marco Studer [email protected] System Security Group Institute of Information Security ETH Zurich Supervisors: Dr. Raphael Reischuk Prof. Dr. Srdjan Capkun August 13, 2018 i The icons used to indicate quotes and mitigation strategies appear under the Creative Commons Attribution 4.0 International license at https://fontawesome.com/license. No changes were made to the icons. Full credit is given to FontAwesome. Acknowledgements I thank Raphael Reischuk for his tireless effort and for the immense amount of time he invested in me and the project. His enthusiasm motivated me throughout the project. He taught me countless things and was more friend than supervisor. I thank hYuuBluei for giving me the opportunity to write this thesis. I cost hYuuBluei and its employees a lot of time and nerves. I am thankful for their patience and for being so understanding. ii Abstract Social engineering, the act of manipulating people into committing actions ben- eficial to an attacker (and most likely detrimental to the manipulated target), is as old as time itself and is likely to remain a dangerous threat to organizations and individuals alike | especially today, in times where information is more valuable than ever before. In order to better understand the implications of social engineering, this thesis constitutes research on social engineering in the context of an internation- ally operating organization. More specifically, the thesis presents the planning and execution of various social-engineering attacks that were performed over the course of approximately two months. All attacks were conducted without any insider knowledge about the targeted organization.
    [Show full text]
  • Microsoft Office 365 for Enterprises Deployment Guide
    Deployment Guide for Enterprises Published: June 2011 Updated: September 2011 The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication and is subject to change at any time without notice to you. This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes. This document is confidential and proprietary to Microsoft. It is disclosed and can be used only pursuant to a non-disclosure agreement. The descriptions of other companies’ products in this document, if any, are provided only as a convenience to you. Any such references should not be considered an endorsement or support by Microsoft. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult their respective manufacturers. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.
    [Show full text]
  • ECE Mail System Overview
    ECE Mail System Overview Pablo J. Rebollo ECE Network Operations Center Agenda Overview of ECE mail system How mail system works SPAM!!! ECE mail system statistics and examples Problems References Mail system Previous server Sun UltraEnterprise 450 4 X UltraSparc 300 MHz 2 Gigabytes of RAM 10 x 9 Gigabytes hard drives (SCSI) Solaris Postfix (SMTP) Inboxes in MBOX format UW IMAP, and QPopper (POP3) Text file for user information (/etc/passwd) Mail System Current server Dell PowerEdge 1750 2 X Intel Xeon 3.2 GHz with HT 4 gigabytes of RAM 2 X 36 GB (SCSI), RAID 1 for OS 14 x 73 GB (SCSI), RAID 5 for users, web pages, etc Linux Postfix (SMTP, SMTPS, SASL, TLS) Cyrus (IMAP, POP3, TLS, maildir inboxes) LDAP for user information Mail System (cont.) Current system Over 1,400 inboxes Over 40,000 messages received per week Over 10,000 messages received are SPAM Over 10,000 messages sent per week Additional services Mail gateway (Spamassassin, ClamAV) Greylisting (OpenBSD spamd) Mail System (cont.) How mail system works User sends an email with a client The client sends the email to the designated SMTP server. The SMTP server look for the MX record for the recipient domain. The SMTP server sends the email to the MX. The recipient domain mail server receives the message and store it into the user INBOX. Finally, the user reads the new message with an email client using IMAP or POP3. How mail system works (cont.) dns.prt.net mail.prt.net 2 dns [email protected] 3 1 smtp smtp 4 IMAP/POP ` Internet ` PRT Client [email protected] mydomain Client [email protected] 1) Client sends the messages to mail.prt.net (SMTP) 2) mail.prt.net query the MX record for mydomain.com (DNS) 3) mail.prt.net send the message to mydomain.com (SMTP) 4) Recipient reads the message (IMAP/POP) SPAM!!! The biggest problem is SPAM.
    [Show full text]
  • Repairing Past Errors with System-Wide Undo
    A Recovery-Oriented Approach to Dependable Services: Repairing Past Errors with System-Wide Undo Aaron Brown EECS Computer Science Division University of California, Berkeley Report No. UCB//CSD-04-1304 December 2003 Computer Science Division (EECS) University of California Berkeley, California 94720 A Recovery-Oriented Approach to Dependable Services: Repairing Past Errors with System-wide Undo by Aaron Baeten Brown A.B. (Harvard University) 1997 M.S. (University of California, Berkeley) 2000 A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the GRADUATE DIVISION of the UNIVERSITY OF CALIFORNIA, BERKELEY Committee in charge: Professor David Patterson, Chair Professor John Chuang Professor Armando Fox Professor Katherine Yelick Fall 2003 A Recovery-Oriented Approach to Dependable Services: Repairing Past Errors with System-wide Undo Copyright 2003 by Aaron Baeten Brown Abstract Motivated by the pressing need for increased dependability in corporate and Internet services and by the perspective that effective recovery can improve dependability as much or more than avoid- ing failures, we introduce a novel recovery mechanism that gives human system operators the power of system-wide undo. System-wide undo allows operators to roll back erroneous changes to a service’s state without losing end-user data or updates, to make retroactive repairs in the historical timeline of the service system, and thereby to quickly recover from catastrophic state corruption, operator error, failed upgrades, and external attacks, even when the root cause of the catastrophe is unknown. We explore system-wide undo via a framework based on the novel concept of spheres of undo, bubbles of state and time that provide scope to the state recoverable by undo and serve as a structuring tool for implementing undo on standalone services, hierarchically-composed systems, and distributed interacting services.
    [Show full text]
  • Measuring Attack Surfaces of Open Source IMAP Servers
    Measuring Attack Surfaces of Open Source IMAP Servers E. Chaos Golubitsky May 2005 Abstract The attack surface metric provides a means of discussing the susceptibility of software to as-yet- unknown attacks. A system’s attack surface encompasses the methods the system makes available to an attacker, and the system resources which can be used to further an attack. The attack surface metric can be used to compare the security of multiple systems which provide the same function. The Internet Message Access Protocol (IMAP) is a protocol which has been in existence for over a decade. Relative to web (HTTP) and e-mail transfer (SMTP) servers, IMAP servers are a niche product, but they are widely deployed nonetheless. There are three popular Open Source Unix IMAP servers (UW-IMAP, Cyrus, and Courier-IMAP), and there has not been a formal security comparison between them. In this project, i use the attack surface metric to discuss the relative security risks posed by these three products. I undertake this evaluation in service of two complementary goals: to provide an honest examination of the security postures and risks of the three servers, and to advance the study of attack surfaces by performing an automated attack surface measurement using a methodology based on counting entry and exit points in the code. 1 Contents 1 Introduction 3 1.1 Contributions and Roadmap . 3 1.2 Attack Surfaces . 4 1.3 IMAP Servers . 5 2 Observation of IMAP Server Software 6 2.1 Observation Methodology . 6 2.2 High-Level Interactions of IMAP Servers . 7 2.3 UW-IMAP Server .
    [Show full text]