DOCSLIB.ORG

Discovering Path MTU Black Holes Using RIPE Atlas

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Discovering Path MTU Black Holes Using RIPE Atlas MSC.SYSTEMS &NETWORK ENGINEERING Discovering Path MTU black holes on the Internet using RIPE Atlas Commissioned by: Authors: Supervisors: Maikel DE BOER Benno OVEREINDER [email protected] [email protected] Jeffrey BOSMA Willem TOOROP [email protected] [email protected] July 23, 2012 This page is intentionally left blank. Abstract The Internet as we know it today is a complex system that works because of the many different protocols standardized by the Internet Engineering Task Force (IETF) defined in Request for Comments (RFC). If people intentionally or unintentionally do not comply with these standards problems are inevitable. Due to some network administrators that have configured their firewalls to filter Internet Control Message Protocol (ICMP) Packet Too Big (PTB) packets and Internet Protocol (IP) fragments and some Customer- premises equipment (CPE) devices which does this by default, several of the protocols on the Internet do not work as they are supposed to do. By filteringICMPPTB packets andIP fragments, Path MTU (PMTU) black holes can occur. The effect of these particular black holes in a networked path is that packets, that are larger than the smallest link can assimilate, are forever lost because of the Maximum Transmission Unit (MTU) of this link. Such an event results in a situation where a typical end user thinks is caused by outage of their application, the remote service, or the connection in between. To determine the scale of the problem and where it occurs we have build an experimental setup and in our experiments use RIPE Atlas as a worldwide measurement. We have conducted several different experiments for nine periods of four hours using an average of between 1134 and 1365 Internet Protocol version 4 (IPV4) vantage points and an average of between 397 and 502 Internet Protocol version 6 (IPV6) vantage points. We observed that forIP V4 between 4% and 6% of the paths between the vantage points and our experimental setup filter ICMP PTB packets. ForIP V6 this was between 0.77% and 1.07%. Furthermore, we found that whenIP V4 Domain Name System (DNS) servers do not act on the receipt of ICMP PTB packets, between 11% and 14% of the answers from these DNS servers are lost. ForIP V6 DNS servers this was between 40% and 42%. Lastly, we found that forIP V4 approximately 6% of the paths between the vantage points and our experimental setup filterIP fragments. ForIP V6 this was approximately 10%. Both ICMP PTB packet and IP fragment filtering seems to be happening close to the end users and not in or near the core of the Internet. The amount of ICMP PTB packet filtering is larger inIP V4 than inIP V6, although it is not likely many users will notice any problems because of this. The results forIP fragment filtering inIP V6 are more troublesome since it is likely that protocols like Domain Name System Security Extensions (DNSSEC) are not going to work as smoothly on the Internet as it exists today. Luckily it looks like the problems do not occur in or near the core of the Internet. This means that there is a high probability that everyone would be able to fix their own networks if these are not configured correctly. ii Acknowledgements We, Maikel de Boer and Jeffrey Bosma, enjoyed working together with several people that helped us to achieve the results that are described in this thesis. We are grateful to Benno Overeinder and Willem Toorop from NLnet Labs for their their insight, sugges- tions, feedback and (technical) support. We would also like to thank Olaf Kolkman, the director of NLnet Labs, for providing us with the opportunity to work on this project. Furthermore, we thank Vesna Manojlovic, Philip Homburg, Andreas Strikos and Emile Aben from RIPE NCC for their helpful and much appreciated work. Without them the project would not have been possible. Contents Abstract ii 1 Introduction 1 1.1 Path MTU black holes..........................................1 1.2 Research objective.............................................2 1.3 Research questions............................................2 1.4 Thesis outline...............................................2 2 Related work 3 3 Background and concepts 4 3.1 Terminology................................................4 3.2 MTU and MSS..............................................4 3.3 PMTUD..................................................5 3.4 PMTU black holes............................................7 4 Experiments 10 4.1 RIPE Atlas................................................. 10 4.2 Experimental setup............................................ 11 4.3 Measurement periods........................................... 14 5 Results 15 5.1 Number of probes............................................. 15 5.2 ICMP PTB filtering............................................ 15 5.3 IP fragment filtering........................................... 18 5.4 Location determination.......................................... 21 5.5 PMTU determination........................................... 24 6 Discussion 25 7 Conclusion 27 8 Future work 28 9 Recommendations 29 Bibliography 31 Glossary 32 Appendices A RIPE Atlas probes per country 33 B PMTU determination 34 List of Figures 1 PMTUD: successful HTTP POST - MTU: 1280.............................6 2 PMTU black hole: ICMP PTB filtering.................................7 3 PMTU: successful DNS query - MTU: 1280..............................8 4 PMTU black hole: IP fragment filtering................................9 5 RIPE Atlas number of active probes.................................. 10 6 RIPE Atlas active probes map...................................... 11 7 ICMP PTB filtering setup......................................... 12 8 IP fragment filtering setup........................................ 13 9 PMTU determination setup....................................... 14 10 ICMPv4 PTB filtering - MTU: 1500................................... 15 11 ICMPv6 PTB filtering - MTU: 1500................................... 16 12 ICMP PTB filtering percentages - MTU: 1500............................. 16 13 ICMPv4 PTB filtering - MTU: 1280................................... 17 14 ICMPv6 PTB filtering - MTU: 1280................................... 17 15 ICMP PTB filtering percentages - MTU: 1280............................. 18 16 IPv4 fragment filtering - MTU: 1500.................................. 18 17 IPv6 fragment filtering - MTU: 1500.................................. 19 18 IP fragment filtering percentages - MTU: 1500............................. 19 19 IPv4 fragment filtering - MTU: 576................................... 20 20 IPv6 fragment filtering - MTU: 1280.................................. 20 21 IP fragment filtering percentages - MTU: IP minimum........................ 21 22 Hop counting algorithm......................................... 22 23 IPv4 common Path MTUs........................................ 24 24 IPv6 common Path MTUs........................................ 24 25 RIPE Atlas probes per country (high).................................. 33 26 RIPE Atlas probes per country (low).................................. 33 27 IP Path MTUs (complete)......................................... 34 Listings 1 Location of ICMPv4 PTB packets filtering............................... 22 2 Location of ICMPv6 PTB packets filtering............................... 23 3 Location of IPv4 fragment filtering................................... 23 4 Location of IPv6 fragment filtering................................... 23 List of Tables 1 Experiment measurement periods................................... 14 2 Average number of probes per experiment.............................. 15 Introduction Chapter 1 1 Introduction With the ever increasing number of nodes on the Internet, the Internet Protocol version 4 (IPV4) is pushed more and more towards its addressing capability limits. This limit restricts the number of on-line users that can be connected without the use of translation mechanisms such as Network Address Translation (NAT). The use of such translation mechanisms in, e.g. the core of the Internet, adversely affects the growth of the Internet as a whole. The Internet Protocol version 6 (IPV6) is intended to be the next generation Internet protocol, succeeding the more than 30 years old IPV4 because of its deficiencies. The main limitation is the number of addressable nodes. WithIP V4, a 32-bit addressing space is available which allows for the addressing of 4.294.967.296 individual nodes. Certain parts of this address space cannot be used because of predefined purposes ranging from local private networks to completeIP-blocks reserved for experimental or future usage. In theIP V6 address space several parts are also marked as unusable. However,IP V6 defines a 128-bit address space and therefore it is possible to address 2128 nodes, leaving an immense amount of usable addresses. Now that the pool of unallocatedIP V4 addresses is exhausting, or is even already entirely depleted for vari- ous regions, an increasing number of organizations are pushed towards the use ofIP V6. Unfortunately, the transition fromIP V4 toIP V6 is not at all considered a smooth deployment and has given rise to anomalies inIP V6-enabled services in the Internet. Some of these anomalies are unique toIP V6 regardless of its im- plementation, however, others occur due to a specific implementation ofIP V6 and may as well occur with IPV4. The focus of this research is on Path MTU (PMTU) black holes, a type of anomalies that occur in both theIP V4 andIP V6-driven Internet. 1.1 Path MTU black holes The Internet
Load more

Recommended publications
  • Network Layer 2
    Network Layer Topics • Network service models • Datagrams (packets), virtual circuits • IP (Internet Protocol) • Internetworking • Forwarding (Longest Matching Prefix) • Helpers: ARP and DHCP • Fragmentation and MTU discovery • Errors: ICMP (traceroute!) • IPv6, scaling IP to the world • NAT, and “middleboxs” • Routing Algorithms CSE 461 University of Washington 2 Dynamic Host Configuration Protocol (DHCP) Bootstrapping •Problem: • A node wakes up for the first time … • What is its IP address? What’s the IP address of its router? • At least Ethernet address is on NIC What’s my IP? CSE 461 University of Washington 4 Bootstrapping 1. Manual configuration (old days) • Can’t be factory set, depends on use 2. DHCP: Automatically configure addresses • Shifts burden from users to IT folk What’s my IP? Use A.B.C.D CSE 461 University of Washington 5 DHCP •DHCP (Dynamic Host Configuration Protocol), from 1993, widely used •It leases IP address to nodes •Provides other parameters too • Network prefix • Address of local router • DNS server, time server, etc. CSE 461 University of Washington 6 DHCP Protocol Stack •DHCP is a client-server application • Uses UDP ports 67, 68 DHCP UDP IP Ethernet CSE 461 University of Washington 7 DHCP Addressing •Bootstrap issue: • How does node send a message to DHCP server before it is configured? •Answer: • Node sends broadcast messages that delivered to all nodes on the network • Broadcast address is all 1s • IP (32 bit): 255.255.255.255 • Ethernet/MAC (48 bit): ff:ff:ff:ff:ff:ff CSE 461 University of Washington
    [Show full text]
  • A Black Hole Attack Model for Reactive Ad-Hoc Protocols Christopher W
    Air Force Institute of Technology AFIT Scholar Theses and Dissertations Student Graduate Works 3-22-2012 A Black Hole Attack Model for Reactive Ad-Hoc Protocols Christopher W. Badenhop Follow this and additional works at: https://scholar.afit.edu/etd Part of the Computer Sciences Commons Recommended Citation Badenhop, Christopher W., "A Black Hole Attack Model for Reactive Ad-Hoc Protocols" (2012). Theses and Dissertations. 1077. https://scholar.afit.edu/etd/1077 This Thesis is brought to you for free and open access by the Student Graduate Works at AFIT Scholar. It has been accepted for inclusion in Theses and Dissertations by an authorized administrator of AFIT Scholar. For more information, please contact [email protected]. A BLACK HOLE ATTACK MODEL FOR REACTIVE AD-HOC PROTOCOLS THESIS Christopher W. Badenhop AFIT/GCO/ENG/12-01 DEPARTMENT OF THE AIR FORCE AIR UNIVERSITY AIR FORCE INSTITUTE OF TECHNOLOGY Wright-Patterson Air Force Base, Ohio APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED The views expressed in this Thesis are those of the author and do not reflect the official policy or position of the United States Air Force, Department of Defense, or the United States Government. This material is declared a work of the U.S. Government and is not subject to copyright protection in the United States. AFIT/GCO/ENG/12-01 A BLACK HOLE ATTACK MODEL FOR REACTIVE AD-HOC PROTOCOLS THESIS Presented to the Faculty Department of Electrical & Computer Engineering Graduate School of Engineering and Management Air Force Institute of Technology Air University Air Education and Training Command In Partial Fulfillment of the Requirements for the Degree of Master of Science Christopher W.
    [Show full text]
  • The GINI Router
    The GINI Router: A Routing Element for User-level Micro Internet by Weiling Xu DEPARTMENT OF COMPUTER SCIENCE MCGILL UNIVERSITY, MONTREAL JUNE,2004 A THESIS SUBMITTED TO MCGILL UNIVERSITY IN PARTIAL FULFILMENT OF THE REQUlREMENTS OF THE DEGREE OF MASTER OF SCIENCE © Weiling Xu 2004 Library and Bibliothèque et 1+1 Archives Canada Archives Canada Published Heritage Direction du Branch Patrimoine de l'édition 395 Wellington Street 395, rue Wellington Ottawa ON K1A ON4 Ottawa ON K1A ON4 Canada Canada Your file Votre référence ISBN: 0-494-06476-5 Our file Notre référence ISBN: 0-494-06476-5 NOTICE: AVIS: The author has granted a non­ L'auteur a accordé une licence non exclusive exclusive license allowing Library permettant à la Bibliothèque et Archives and Archives Canada to reproduce, Canada de reproduire, publier, archiver, publish, archive, preserve, conserve, sauvegarder, conserver, transmettre au public communicate to the public by par télécommunication ou par l'Internet, prêter, telecommunication or on the Internet, distribuer et vendre des thèses partout dans loan, distribute and sell th es es le monde, à des fins commerciales ou autres, worldwide, for commercial or non­ sur support microforme, papier, électronique commercial purposes, in microform, et/ou autres formats. paper, electronic and/or any other formats. The author retains copyright L'auteur conserve la propriété du droit d'auteur ownership and moral rights in et des droits moraux qui protège cette thèse. this thesis. Neither the thesis Ni la thèse ni des extraits substantiels de nor substantial extracts from it celle-ci ne doivent être imprimés ou autrement may be printed or otherwise reproduits sans son autorisation.
    [Show full text]
  • Guidelines for the Secure Deployment of Ipv6
    Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
    [Show full text]
  • RFC 6349 Testing with Truespeed™ from JDSU—Experience Your
    RFC 6349 Testing with TrueSpeed™ from JDSU— Experience Your Network as Your Customers Do RFC 6349 is the new transmission control protocol (TCP) throughput test methodology that JDSU co-authored along with representatives from Bell Canada and Deutsche Telecom. Recently issued by the Internet Engineering Task Force (IETF) organization, RFC 6349 provides a repeatable test method for TCP throughput analysis with systematic processes, metrics, and guidelines to optimize the network and server performance. This application note summarizes RFC 6349, “Framework for TCP Throughput Testing,” and highlights the automated and fully compliant JDSU RFC 6349 implementation, TrueSpeed, now available on the JDSU T-BERD®/MTS-6000A Multi-Services Application Module (MSAM) and T-BERD/MTS-5800 Handheld Network Tester. This application note also discusses the integration of TrueSpeed RFC 6349 with the ITU Y.1564 Ethernet service activation standard. This powerful testing combination provides a comprehensive means to ensure an optimized end-customer experience in multi-service (such as triple play) environments. RFC 6349 TCP Test Methodology RFC 6349 specifies a practical methodology for measuring end-to-end TCP throughput in a managed IP network with a goal of providing a better indication of the user experience. In the RFC 6349 framework, TCP and IP parameters are also specified to optimize TCP throughput. RFC 6349 recommends always conducting a Layer 2/3 turn-up test before TCP testing. After verifying the network at Layer 2/3, RFC 6349 specifies conducting
    [Show full text]
  • Solution for TCP/IP Flooding
    1 Solution for TCP/IP Flooding (Data Communication and Networking Report ) +Dr. Kiramat Ullah, -Minhaj Ansari, -Yahya Bakhtiar, -Talha Bilal and Zeeshan* *Arid Agriculture University, Rawalpindi, Pakistan - , PIEAS, University Pakistan + Derby University, UK Abstract: TCP stands for transmission control protocol. It was defined by Internet Engineering Task Force (IETF). It is used in establishing and maintaining communication between applications on different computers and provide full duplex acknowledgement and flow control service to upper layer protocol and application. [2][3][4][5] In this report proposes solution for TCP SYN flood. Key Words— TCP (Transmission Control Protocol). SYN (Synchronous), DoS (Denial of Service), DDos (Distributed DoS) I. INTRODUCTION The entire internet protocol suite -- a set of rules and procedures -- is commonly referred to as TCP/IP, though others are included in the suite. TCP/IP specifies how data is exchanged over the internet by providing end-to-end communications that identify how it should be broken into packets, addressed, transmitted, routed and received at the destination. TCP/IP requires little central management, and it is designed to make networks reliable, with the ability to recover automatically from the failure of any device on the network. The two main protocols in the internet protocol suite serve specific functions. TCP defines how applications can create channels of communication across a network. It also manages how a message is assembled into smaller packets before they are then transmitted over the internet and reassembled in the right order at the destination address. IP defines how to address and route each packet to make sure it reaches the right destination.
    [Show full text]
  • The PTB-PTS ICMP-Based Attack Against Ipsec Gateways Vincent Roca, Saikou Fall
    Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways Vincent Roca, Saikou Fall To cite this version: Vincent Roca, Saikou Fall. Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways. 2016, pp.16. hal-01178390 HAL Id: hal-01178390 https://hal.inria.fr/hal-01178390 Submitted on 19 Jul 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. IPsec Maintenance and Evolution (IPSECME) V. Roca Internet-Draft S. Fall Intended status: Informational INRIA Expires: January 7, 2016 July 6, 2015 Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways draft-roca-ipsecme-ptb-pts-attack-00 Abstract This document introduces the "Packet Too Big"-"Packet Too Small" Internet Control Message Protocol (ICMP) based attack against IPsec gateways. We explain how an attacker having eavesdropping and packet injection capabilities, from the unsecure network where he only sees encrypted packets, can force a gateway to reduce the Path Maximum Transmission Unit (PMTU) of an IPsec tunnel to the minimum, which can trigger severe issues for the hosts behind this gateway: with a Linux host, depending on the PMTU discovery algorithm in use (i.e., PMTUd versus PLPMTUd) and protocol (TCP versus UDP), the attack either creates a Denial of Service or major performance penalties.
    [Show full text]
  • Exploring Usable Path MTU in the Internet
    Exploring usable Path MTU in the Internet Ana Custura Gorry Fairhurst Iain Learmonth University of Aberdeen University of Aberdeen University of Aberdeen Abstract—To optimise their transmission, Internet endpoints methodologies and tools [7] [8], providing an up-to-date need to know the largest size of packet they can send across PMTUD behaviour report for both IPv4 and IPv6. a specific Internet path, the Path Maximum Transmission Unit We include an in-depth exploration of server and client (PMTU). This paper explores the PMTU size experienced across the Internet core, wired and mobile edge networks. advertised Maximum Segment Size (MSS), taking advantage Our results show that MSS Clamping has been widely deployed of existing measurement platforms, MONROE [9] and RIPE in edge networks, and some webservers artificially reduce their Atlas [10], and using or extending existing tools Netalyzr [11] advertised MSS, both of which we expect help avoid PMTUD and PATHspider [12]. failure for TCP. The maximum packet size used by a TCP We also look at ICMP quotation health and analyze a connection is also constrained by the acMSS. MSS Clamping was observed in over 20% of edge networks tested. We find a large number of ICMP quotations from a previous large- significant proportion of webservers that advertise a low MSS scale measurement campaign. These results provide important can still be reached with a 1500 byte packet. We also find more insight to inform the design of new methods that can robustly than half of IPv6 webservers do not attempt PMTUD and clamp discover the PMTU for UDP traffic where there are currently the MSS to 1280 bytes.
    [Show full text]
  • ICMP Attacks Against TCP
    ICMP attacks against TCP Author: Fernando Gont Email: [email protected] http:/ /www.gont.com.ar Universidad Tecnológica Nacional February 200 6 Internet -Draft / ICMP attacks against TCP OWASP Papers Program February , 2006 Table of Contents Abstract .............................................................................................................................................. 3 A1 Introduction........................................................................................................................... 4 A2 Background ............................................................................................................................ 5 A2.1 The Internet Control Message Protocol (ICMP) .................. 5 2.1.1 ICMP for IP version 4 (ICMP) ................................ ...... 5 2.1.2 ICMP for IP version 6 (ICMPv6) ................................ .... 5 A2.2 Handli ng of ICMP error messages ............................... 6 A3 Constraints in the possible solutions ................................................................................... 7 A4 General counter -measures against ICMP attacks ............................................................. 8 A4.1 TCP sequence number checking ................................ .. 8 A4.2 Port randomization ................................ ............ 8 A4.3 Fil tering ICMP error messages based on the ICMP payload ....... 9 A5 Blind connection-reset attack ............................................................................................
    [Show full text]
  • On Improved Generalization of 5-State Hidden Markov Model-Based Internet Traffic
    On Improved Generalization of 5-State Hidden Markov Model-based Internet Traffic Classifiers by Grant H. R. Bartnik A Thesis presented to The University of Guelph In partial fulfilment of requirements for the degree of Master of Science in Computer Science Guelph, Ontario, Canada c Grant H. R. Bartnik, May, 2013 ABSTRACT On Improved Generalization of 5-State Hidden Markov Model-based Internet Traffic Classifiers Grant H. R. Bartnik Advisors: University of Guelph, 2013 Dr. Stefan C. Kremer The multitude of services delivered over the Internet would have been diffi- cult to fathom 40 years ago when much of the initial design was being undertaken. As a consequence, the resulting architecture did not make provisions for differentiating between, and managing the potentially conflicting requirements of different types of services such as real-time voice communication and peer-to-peer file sharing. This shortcoming has resulted in a situation whereby services with conflicting require- ments often interfere with each other and ultimately decrease the effectiveness of the Internet as an enabler of new and transformative services. The ability to passively identify different types of Internet traffic then would address this shortcoming and enable effective management of conflicting types of services, in addition to facilitating a better understanding of how the Internet is used in general. Recent attempts at developing such techniques have shown promising results in simulation environments but perform considerably worse when deployed into real-world scenarios. One possi- ble reason for this descrepancy can be attributed to the implicit assumption shared by recent approaches regarding the degree of similarity between the many networks which comprise the Internet.
    [Show full text]
  • NIST Firewall Guide and Policy Recommendations
    Special Publication 800-41 Guidelines on Firewalls and Firewall Policy Recommendations of the National Institute of Standards and Technology John Wack, Ken Cutler, Jamie Pole NIST Special Publication 800-41 Guidelines on Firewalls and Firewall Policy Recommendations of the National Institute of Standards and Technology John Wack, Ken Cutler*, Jamie Pole* C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 *MIS Training Institute January 2002 U.S. Department of Commerce Donald L. Evans, Secretary Technology Administration Phillip J. Bond, Under Secretary for Technology National Institute of Standards and Technology Arden L. Bement, Jr., Director ii Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing tech- nical leadership for the Nation’s measurement and standards infrastructure. ITL de- velops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, ad- ministrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach ef- forts in computer security, and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technolog y Special Publication 800-41 Natl. Inst. Stand. Technol. Spec. Publ. 800-41, 75 pages (Jan.
    [Show full text]
  • Chapter 5: Blocking Spammers with DNS Blacklists 63
    Color profile: Generic CMYK printer profile Hacking / Anti-Spam Tool Kit / Wolfe, Scott, Erwin / 3167-x / Chapter 5 Composite Default screen 5 Blocking Spammers with DNS Blacklists 61 P:\010Comp\Hacking\167-x\ch05.vp Monday, February 23, 2004 9:44:07 AM Color profile: Generic CMYK printer profile Hacking / Anti-Spam Tool Kit / Wolfe, Scott, Erwin / 3167-x / Chapter 5 Composite Default screen 62 Anti-Spam Tool Kit n Chapter 4 we introduced you to DNS Blacklists as one of several means for fighting spam. In this chapter, we will look at popular individual DNS Blacklists, explain how Ito implement them on a mail server, and help you decide which list is the best one to use. When referring to DNS Blacklists, the shorthand DNSBL is often used, and that’s how we’ll refer to them throughout this chapter. Before we talk about specific blacklists and how to implement them, we’ll delve into what DNSBLs are and how they work. UNDERSTANDING DNS BLACKLISTS DNSBLs are an integral part of any spam-fighting toolkit. The fact that many, many users on the Internet are updating them means you get the benefit of block- ing a spammer before the first piece of spam even hits you. To understand how DNSBLs help, you need to know the types of DNSBLs available and how they work. Types of DNSBLs Currently, two different types of DNS Blacklists are used: ■ IP-based blacklists ■ Domain-based blacklists The majority of DNSBLs are IP-based, which look at the Internet Protocol (IP) ad- dress of the server sending the mail.
    [Show full text]