Internet Integration: the DNS Security Mess D. J. Bernstein University of Illinois at Chicago 2 the Domain Name System Uic.Edu Wants to See
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Självständigt Arbete På Grundnivå
Självständigt arbete på grundnivå Independent degree project - first cycle Datateknik Computer Engineering Master's thesis Hantering av nätverkscache i DNS Two ye Hans Lindqvist i MITTUNIVERSITETET Avdelningen för informationssystem och -teknologi (IST) Examinator: Ulf Jennehag, [email protected] Handledare: Johannes Lindén, [email protected] Författare: Hans Lindqvist, [email protected] Utbildningsprogram: Datateknik, 180 hp Huvudområde: Datateknik Termin, år: VT, 2019 ii Hantering av nätverkscache i DNS Hans Lindqvist 2019-06-13 Sammanfattning Domännamnsystemet, DNS, utgör en fundamental del av användbarheten för Internet, men dess cachefunktion utmanas av adressers ökande storlek, antal och automatisering. Parallellt råder begränsad minneskapacitet hos vissa enheter i Internets utkant mot Internet of Things. Studien har tittat närmare på nutida behov av namnuppslagning och har då betraktat hur DNS påverkats av IPv6- adressutbredning, mobila enheter, innehållsleveransnätverk och webbläsarfunktioner. Undersökningen har i två fritt tillgängliga serverprogramvaror för DNS-uppslag sökt efter den optimala hanteringen av cache hos begränsade enheter i, eller på gränsen till, Sakernas Internet. Med hjälp av tillgången till öppen källkod för programmen, Unbound och PowerDNS Recursor, har dess respektive strukturer tolkats för att uppskatta och jämföra minnesbehov. Därefter har en simulering gjorts i en laborativ miljö med fiktiva DNS-data av verklighetstrogen karaktär för att mäta den faktiska förbrukningen av minne på DNS-serverns process. Vid simuleringen undveks att individuellt anpassa programmens inställningar, att blanda in data för DNSSEC, samt att införa minnesbegränsningar i testmiljön. Undersökningen av källkod beräknade att Unbound var mer optimalt för posttyperna A+AAAA medan PowerDNS Recursor var effektivare för posttypen PTR. För båda posttyperna som helhet visade mätningarna i simuleringen att Unbound kunde lagra DNS-data tätare än PowerDNS Recursor. -
The LPIC-2 Exam Prep I
The LPIC-2 Exam Prep i The LPIC-2 Exam Prep Copyright 2013 Snow B.V. The LPIC-2 Exam Prep ii Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Snow B.V. Copyright 2013 Snow B.V. The LPIC-2 Exam Prep iii COLLABORATORS TITLE : The LPIC-2 Exam Prep ACTION NAME DATE SIGNATURE WRITTEN BY Heinrich W. 2010 Klöpping, Beno T.J. Mesman, Piet W. Plomp, Willem A. Schreuder, Ricky Latupeirissa, Patryck Winkelmolen, Many, many Snow B.V. colleagues for peer reviewing and authoring updates., Jos Jansen, and Joost Helberg REVISION HISTORY NUMBER DATE DESCRIPTION NAME Copyright 2013 Snow B.V. The LPIC-2 Exam Prep iv Contents 0 Capacity Planning (200) 1 0.1 Measure and Troubleshoot Resource Usage (200.1) . .1 0.1.1 iostat .....................................................2 0.1.2 vmstat ....................................................2 0.1.3 netstat ....................................................3 0.1.4 ps .......................................................4 0.1.5 pstree .....................................................5 0.1.6 w .......................................................5 0.1.7 lsof ......................................................5 0.1.8 free ......................................................6 0.1.9 top . .6 0.1.10 uptime ....................................................7 0.1.11 sar ......................................................7 0.1.12 Match / correlate system symptoms with likely problems . .8 0.1.13 Estimate throughput and identify bottlenecks in a system including networking . .8 0.2 Predict Future Resource Needs (200.2) . .8 0.2.1 ........................................................9 0.2.2 Predict future growth . .9 0.2.3 Resource Exhaustion . .9 0.3 Questions and answers . 10 1 Linux Kernel (201) 11 1.1 Kernel Components (201.1) . 11 1.1.1 Different types of kernel images . -
Seguridad En DNS
Seguridad en DNS. Francisco José Bordes Romaguera Máster Interuniversitario en Seguridad de las Tecnologías de la Información y la Comunicación Seguridad empresarial Manuel Jesús Mendoza Flores Víctor García Font Domingo 22 de diciembre de 2019 i Esta obra está sujeta a una licencia de Reconocimiento-NoComercial- SinObraDerivada 3.0 España de Creative Commons ii FICHA DEL TRABAJO FINAL Título del trabajo: Seguridad en DNS Nombre del autor: Francisco José Bordes Romaguera Nombre del consultor/a: Manuel Jesús Mendoza Flores Nombre del PRA: Nombre y dos apellidos Fecha de entrega (mm/aaaa): 12/2019 Máster Interuniversitario en Seguridad de las Titulación: Tecnologías de la Información y la Comunicación Área del Trabajo Final: M1.849 - TFM-Seguridad empresarial aula 1 Idioma del trabajo: Español Palabras clave DNS, RPZ, malware, seguridad, ioc2rpz Resumen del Trabajo (máximo 250 palabras): Con la finalidad, contexto de aplicación, metodología, resultados i conclusiones del trabajo. Este trabajo expone una solución contra el acceso a dominios malintencionados que no requiere apenas cambios en cualquier infraestructura de red ya organizada. La solución de ioc2rpz permite gestionar de manera gráfica los dominios a los que queremos bloquear el acceso desde nuestra red a nivel de DNS y actualiza la configuración de nuestro servidor DNS. Los resultados del trabajo han sido que, sin propagar peticiones, nuestro servidor DNS devuelve respuestas NXDOMAIN a peticiones de dominios que hemos configurado en ioc2rpz que son maliciosos. Aplicar rpz nos permite proteger nuestra red de una manera proactiva y con pocos recursos dedicados a la gestión, aunque sí es necesario disponer de recursos destinados para el análisis e investigación. -
Copyrighted Material
Index Note to the Reader: Throughout this index boldfaced page numbers indicate primary discussions of a topic. Italicized page numbers indicate illustrations. 0 runlevel, 17, 21 HTTPS configuration, 474–482 1 runlevel, 17, 21 installing, 462–464 2 runlevel, 17, 18 log files, 467–468 3 runlevel, 17, 18 modules, 459, 467, 470–472, 473–474 4 runlevel, 17 apache2ctl command, 463–464 5 runlevel, 17, 18 apachectl command, 463 6 runlevel, 17 APPEND command, IMAP, 337 AppleTalk, 274 application layer, 279 A archive files, 51, 61 media storage considerations, 54–55 A flag, procmail, 353 ARP (Address Resolution Protocol), 289–290 a flag, procmail, 353 arp command, 289–290 AAAA resource record, 409 ARP table, 289–290 absolute domain names, 374 asymmetric encryption, 433–434 access logs, Apache, 467–468 DNSSEC (DNS Security Extensions), access lookup table, Postfix, 349 434–439 access points, 273–274, 274, 283 ATA over Ethernet (AoE), 234–235 AccessFileName directive, Apache, 466 ATAPI (Advanced Technology Attachment AccessFilename directive, Apache, 466 Packet Interface) drives, 221–222, 223 account feature, PAM, 594 attack vectors, 621 action commands, Sieve, 357 auth configuration setting, Dovecot, 360 action response codes, SMTP, 329, 330 auth feature, PAM, 594 address command, Sieve, 357 authentication ADDRESS configuration setting, Courier, 353 Apache, 470–472 address match list, 383 Courier, 359–360 Address Resolution Protocol (ARP), 289–290 Exim, 321 ads security mode, Samba, 522 IMAP, 335–336 Advanced Host Controller Interface (AHCI), LDAP, -
Domain Name Server
Domain name Server @Franck Jeannot - 2016 - F158 - V1.0 380 400 420 440 460 480 500 520 540 560 580 600 620 640 660 680 700 720 740 1 Definition The Internet Domain Name System (DNS) consists of the syntax to specify the names of entities in the Internet in a hierarchical manner, the rules used for delegating authority over names, and the system implementation that actu- ally maps names to Internet addresses. DNS data is maintained in a group of distributed hierarchical databases.1 2 RFCs and literature - Refer to a detailed list of RFCs at: https://www.isc.org/community/rfcs/dns/ - Introduction to DNS: https://tools.ietf.org/html/rfc1034 - Refer to http://lpic2.unix.nl/v3/ 3 LPI : Linux Professional Institute This document provides a DNS overview with a specific focus on the objectives of the LPI2 117-202 Certification. Refer to 2. 4 Acronyms and terminology BIND : Berkeley Internet Name Domain PTR : PoinTeR to another part of the domain name space RRs : Resource Records SOA (Start Of Authority) record is the first record in a zone file. The SOA record is used when using DNS to synchronize data between multiple computers. 1Introduction from ftp://ftp.isc.org/isc/bind9/9.10.4-P1/doc/arm/Bv9ARM.pdf 2https://www.lpi.org/study-resources/lpic-2-202-exam-objectives/ 1 5 Basic DNS server configuration 5.1 LPIC-2 : Objective 207.1 Description: Candidates should be able to configure BIND to function as a caching-only DNS server. This objective includes the ability to manage a running server and configure logging.34 Key Knowledge Areas: • BIND 9.x configuration files, terms and utilities • Defining the location of the BIND zone files in BIND configuration files • Reloading modified configuration and zone files • awareness of dnsmasq, djbdns and PowerDNS as alternate name servers. -
The DNS Security Mess D. J. Bernstein University of Illinois at Chicago
1 The DNS security mess D. J. Bernstein University of Illinois at Chicago; Technische Universiteit Eindhoven 2 The Domain Name System tue.nl wants to see http://www.ru.nl. Browser at tue.nl O \The web server '&! www.ru.nl"#%$ has IP address 131.174.78.60." Administrator at ru.nl Now tue.nl '&! "#%$ retrieves web page from IP address 131.174.78.60. 3 Same for Internet mail. tue.nl has mail to deliver to [email protected]. Mail client at tue.nl O \The mail server for '&! "#%$ ru.nl has IP address 192.87.102.77." Administrator at ru.nl Now tue.nl '&! "#%$ delivers mail to IP address 192.87.102.77. 4 Forging DNS packets tue.nl has mail to deliver to [email protected]. Mail client at tue.nl O \The mail server for '&! "#%$ ru.nl has IP address 204.13.202.78." Attacker anywhere on network Now tue.nl '&! "#%$ delivers mail to IP address 204.13.202.78, actually the attacker's machine. 5 How forgery really works Client sends query. Attacker has to repeat some parts of the query. Attacker must match • the name: ru.nl. • the query type: mail. (\MX".) • ≈ the query time, so client sees forgery before legitimate answer. • the query UDP port. • the query ID. 6 The hard way for attackers to do this: Control name, type, time by triggering client. Many ways to do this. 6 The hard way for attackers to do this: Control name, type, time by triggering client. Many ways to do this. Guess port and ID (or predict them if they're poorly randomized). -
DNS Survival Guide
DNS Survival Guide Artyom Gavrichenkov <[email protected]> A bit of a history: DNS 1983: (int32)*host_str; A bit of a history: DNS 1983: 1997-2017: (int32)*host_str; • load balancing • geobalancing • ASN policies A bit of a history: DNS 1983: 1997-2017: (int32)*host_str; • load balancing • geobalancing • ASN policies • failover • EDNS0 A bit of a history: DNS 1983: 1997-2017: (int32)*host_str; • load balancing • geobalancing • ASN policies • failover • EDNS0 • AAAA • DNSSEC • DANE, CAA, … Problem statement How should an Internet company maintain its DNS infrastructure? • In-house? • Outsourcing? Problem statement How should an Internet company maintain its DNS infrastructure? • In-house • How to choose a software product? • Outsourcing • How to choose a service provider? 1. How to choose a software product? Naïve approach: a) It must be scalable b) It should support features DNS benchmarks, 2013 • Knot (1.2.0 & 1.3.0-RC5) • Server: • Yadifa (1.0.2) Dual Xeon E5-2670 • NSD3 (3.2.15) 32Gb RAM DDR3 1333Mhz Intel X520-DA2 10Gbit • NSD4 (4.0.0b4) • Generator: • PowerDNS (3.3) Single Xeon E5-2670 • TinyDNS (1.05) 32Gb RAM DDR3 1333Mhz • Unbound (1.4.16) Intel X520-DA2 10Gbit • Pdnsd (1.2.8) • Gentoo Linux 3.7.9 DNS benchmarks, 2013. Setup • Vanilla DNS software! • Purpose: purely academic (who runs better codebase) • Authoritative: 300 zones • Caching: Same amount of data in cache DNS benchmarks, 2013. https://www.slideshare.net/ximaera/dns-server-benchmarking Knot NSD Unbound PowerDNS Pdnsd Yadifa Responses,K/s TinyDNS Queries, K/s DNS benchmarks, 2013. https://www.slideshare.net/ximaera/dns-server-benchmarking Knot NSD Unbound PowerDNS Pdnsd Yadifa Responses,K/s TinyDNS …WAIT. -
The LPIC-2 Exam Prep I
The LPIC-2 Exam Prep i The LPIC-2 Exam Prep 6th edition, for version 4.5 Copyright 2013-2017 Snow B.V. The LPIC-2 Exam Prep ii Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 Snow B.V. Copyright 2013-2017 Snow B.V. The LPIC-2 Exam Prep iii COLLABORATORS TITLE : The LPIC-2 Exam Prep ACTION NAME DATE SIGNATURE WRITTEN BY Written, updated and 2017 reviewed by many, many Snow B.V. colleagues. , Jos Jansen, and Joost Helberg REVISION HISTORY NUMBER DATE DESCRIPTION NAME Copyright 2013-2017 Snow B.V. The LPIC-2 Exam Prep iv Contents 0 Capacity Planning (200) 1 0.1 Measure and Troubleshoot Resource Usage (200.1) . .1 0.1.1 Objectives . .1 0.1.2 iostat .....................................................2 0.1.3 iotop .....................................................3 0.1.4 vmstat ....................................................3 0.1.5 netstat ....................................................4 0.1.6 ss .......................................................5 0.1.7 iptraf .....................................................6 0.1.8 ps .......................................................6 0.1.9 pstree .....................................................7 0.1.10 w .......................................................7 0.1.11 lsof ......................................................8 0.1.12 free ......................................................8 0.1.13 top . .8 0.1.14 htop ......................................................9 0.1.15 uptime .................................................... 10 0.1.16 sar ...................................................... 10 0.1.17 Match / correlate system symptoms with likely problems . 11 0.1.18 Estimate throughput and identify bottlenecks in a system including networking . 11 0.2 Predict Future Resource Needs (200.2) . 12 0.2.1 ........................................................ 13 0.2.2 Monitor IT infrastructure . 13 0.2.3 Predict future growth . 13 0.2.4 Resource Exhaustion .