Network Security Knowledge Area
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Adopting Encrypted DNS in Enterprise Environments
National Security Agency | Cybersecurity Information Adopting Encrypted DNS in Enterprise Environments Executive summary Use of the Internet relies on translating domain names (like “nsa.gov”) to Internet Protocol addresses. This is the job of the Domain Name System (DNS). In the past, DNS lookups were generally unencrypted, since they have to be handled by the network to direct traffic to the right locations. DNS over Hypertext Transfer Protocol over Transport Layer Security (HTTPS), often referred to as DNS over HTTPS (DoH), encrypts DNS requests by using HTTPS to provide privacy, integrity, and “last mile” source authentication with a client’s DNS resolver. It is useful to prevent eavesdropping and manipulation of DNS traffic. While DoH can help protect the privacy of DNS requests and the integrity of responses, enterprises that use DoH will lose some of the control needed to govern DNS usage within their networks unless they allow only their chosen DoH resolver to be used. Enterprise DNS controls can prevent numerous threat techniques used by cyber threat actors for initial access, command and control, and exfiltration. Using DoH with external resolvers can be good for home or mobile users and networks that do not use DNS security controls. For enterprise networks, however, NSA recommends using only designated enterprise DNS resolvers in order to properly leverage essential enterprise cybersecurity defenses, facilitate access to local network resources, and protect internal network information. The enterprise DNS resolver may be either an enterprise-operated DNS server or an externally hosted service. Either way, the enterprise resolver should support encrypted DNS requests, such as DoH, for local privacy and integrity protections, but all other encrypted DNS resolvers should be disabled and blocked. -
The Internet in Iot—OSI, TCP/IP, Ipv4, Ipv6 and Internet Routing
Chapter 2 The Internet in IoT—OSI, TCP/IP, IPv4, IPv6 and Internet Routing Reliable and efficient communication is considered one of the most complex tasks in large-scale networks. Nearly all data networks in use today are based on the Open Systems Interconnection (OSI) standard. The OSI model was introduced by the International Organization for Standardization (ISO), in 1984, to address this composite problem. ISO is a global federation of national standards organizations representing over 100 countries. The model is intended to describe and standardize the main communication functions of any telecommunication or computing system without regard to their underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard protocols. The OSI is a conceptual model of how various components communicate in data-based networks. It uses “divide and conquer” concept to virtually break down network communication responsibilities into smaller functions, called layers, so they are easier to learn and develop. With well-defined standard interfaces between layers, OSI model supports modular engineering and multivendor interoperability. 2.1 The Open Systems Interconnection Model The OSI model consists of seven layers as shown in Fig. 2.1: physical (Layer 1), data link (Layer 2), network (Layer 3), transport (Layer 4), session (Layer 5), presentation (Layer 6), and application (Layer 7). Each layer provides some well-defined services to the adjacent layer further up or down the stack, although the distinction can become a bit less defined in Layers 6 and 7 with some services overlapping the two layers. • OSI Layer 7—Application Layer: Starting from the top, the application layer is an abstraction layer that specifies the shared protocols and interface methods used by hosts in a communications network. -
Lecture: TCP/IP 2
TCP/IP- Lecture 2 [email protected] How TCP/IP Works • The four-layer model is a common model for describing TCP/IP networking, but it isn’t the only model. • The ARPAnet model, for instance, as described in RFC 871, describes three layers: the Network Interface layer, the Host-to- Host layer, and the Process-Level/Applications layer. • Other descriptions of TCP/IP call for a five-layer model, with Physical and Data Link layers in place of the Network Access layer (to match OSI). Still other models might exclude either the Network Access or the Application layer, which are less uniform and harder to define than the intermediate layers. • The names of the layers also vary. The ARPAnet layer names still appear in some discussions of TCP/IP, and the Internet layer is sometimes called the Internetwork layer or the Network layer. [email protected] 2 [email protected] 3 TCP/IP Model • Network Access layer: Provides an interface with the physical network. Formats the data for the transmission medium and addresses data for the subnet based on physical hardware addresses. Provides error control for data delivered on the physical network. • Internet layer: Provides logical, hardware-independent addressing so that data can pass among subnets with different physical architectures. Provides routing to reduce traffic and support delivery across the internetwork. (The term internetwork refers to an interconnected, greater network of local area networks (LANs), such as what you find in a large company or on the Internet.) Relates physical addresses (used at the Network Access layer) to logical addresses. -
The ISP Column Diving Into The
The ISP Column A column on various things Internet October 2018 Geoff Huston Diving into the DNS DNS OARC organizes two meetings a year. They are two-day meetings with a concentrated dose of DNS esoterica. Here’s what I took away from the recent 29th meeting of OARC, held in Amsterdam in mid-October 2018. Cloudflare's 1.1.1.1 service Cloudflare have been running an open public DNS resolver service on 1.1.1.1 for more than six months now. The service, based on the Knot resolver engine, is certainly fast (http://bit.ly/2PBfoSh), and Cloudflare's attention to scale and speed is probably appreciated by users of this service. However, in a broader Internet environment that is now very aware of personal privacy it’s not enough to be fast and accurate. You have to be clear that as an operator of a public DNS resolution service you may be privy to clients’ activities and interests, and you need to clearly demonstrate that you are paying attention to privacy. Not only does this include appropriate undertakings regarding the way you handle and dispose of the logs of the resolvers' query streams, but also in being mindful of the way that users can pass queries to the service. The 1.1.1.1 service supports DNS over TLS 1.3 and 1.2 using the GnuTLS system. This supports long-lived connection with client systems and also supports session resumption. There are a number of DNS tools that can use the DNS over a TLS connection including kdig (http://bit.ly/2A9f9rX, http://bit.ly/2OoLu7a), GetDNS (https://getdnsapi.net/), Unbound (http://bit.ly/2CIKEf0), Android P and the Tenta browser (https://tenta.com/). -
Ikev2 Configuration for Encrypted DNS
IKEv2 Configuration for Encrypted DNS draft-btw-add-ipsecme-ike Mohamed Boucadair (Orange) Tirumaleswar Reddy (McAfee, Inc.) Dan Wing (Citrix Systems, Inc.) Valery Smyslov (ELVIS-PLUS) July 2020, IETF#108 Agenda • Context • A Sample Use Case • IKE Configuration Attribute for Encrypted DNS • Next Steps 2 Problem Description • Several schemes to encrypt DNS have been specified – DNS over TLS (RFC 7858) – DNS over DTLS (RFC 8094) – DNS over HTTPS (RFC 8484) • …And others are being specified: – DNS over QUIC (draft-ietf-dprive-dnsoquic) • How to securely provision clients to use Encrypted DNS? This use can be within or outside the IPsec tunnel 3 A Sample Use Case: DNS Offload • VPN service providers can offer publicly accessible Encrypted DNS – the split-tunnel VPN configuration allows the client to access the DoH/DoT servers hosted by the VPN provider without traversing the tunnel 4 A Sample Use Case: Protecting Internal DNS Traffic • DoH/DoT ensures DNS traffic is not susceptible to internal attacks – see draft-arkko-farrell-arch-model-t-03#section-3.2.1 • encrypted DNS can benefit to Roaming Enterprise users to enhance privacy – With DoH/DoT the visibility of DNS traffic is limited to only the parties authorized to act on the traffic (“Zero Trust Architecture”) 5 Using IKE to Configure Encrypted DNS on Clients • New configuration attribute INTERNAL_ENC_DNS is defined to convey encrypted DNS information to clients: – Encrypted DNS type (e.g., DoH/DoT) – Scope of encrypted DNS use – One or more encrypted DNS server IPv6 addresses • For IPv4 -
Lesson-13: INTERNET ENABLED SYSTEMS NETWORK PROTOCOLS
DEVICES AND COMMUNICATION BUSES FOR DEVICES NETWORK– Lesson-13: INTERNET ENABLED SYSTEMS NETWORK PROTOCOLS Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 1 Raj Kamal, Publs.: McGraw-Hill Education Internet enabled embedded system Communication to other system on the Internet. Use html (hyper text markup language) or MIME (Multipurpose Internet Mail Extension) type files Use TCP (transport control protocol) or UDP (user datagram protocol) as transport layer protocol Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 2 Raj Kamal, Publs.: McGraw-Hill Education Internet enabled embedded system Addressed by an IP address Use IP (internet protocol) at network layer protocol Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 3 Raj Kamal, Publs.: McGraw-Hill Education MIME Format to enable attachment of multiple types of files txt (text file) doc (MSOFFICE Word document file) gif (graphic image format file) jpg (jpg format image file) wav format voice or music file Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 4 Raj Kamal, Publs.: McGraw-Hill Education A system at one IP address Communication with other system at another IP address using the physical connections on the Internet and routers Since Internet is global network, the system connects to remotely as well as short range located system. Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 5 Raj Kamal, Publs.: McGraw-Hill Education -
Securing Internet of Things with Lightweight Ipsec
CORE Metadata, citation and similar papers at core.ac.uk Provided by Swedish Institute of Computer Science Publications Database SICS Technical Report T2010:08 ISSN:1100-3154 Securing Internet of Things with Lightweight IPsec Shahid Raza1, Tony Chung2, Simon Duquennoy1, Dogan Yazar1, Thiemo Voigt1, Utz Roedig2 1Swedish Institute of Computer Science, Kista, Sweden fshahid, simonduq, dogan, [email protected] 2Lancaster University Computing Department, Lancaster, UK fa.chung, [email protected] February 7, 2011 Abstract Real-world deployments of wireless sensor networks (WSNs) require secure communication. It is important that a receiver is able to verify that sensor data was generated by trusted nodes. In some cases it may also be necessary to encrypt sensor data in transit. Recently, WSNs and traditional IP networks are more tightly integrated using IPv6 and 6LoWPAN. Available IPv6 protocol stacks can use IPsec to secure data exchange. Thus, it is desirable to extend 6LoWPAN such that IPsec communication with IPv6 nodes is possible. It is beneficial to use IPsec because the existing end-points on the Internet do not need to be modified to communicate securely with the WSN. Moreover, using IPsec, true end-to-end security is implemented and the need for a trustworthy gateway is removed. In this paper we provide End-to-End (E2E) secure communication between an IP enabled sensor nodes and a device on traditional Internet. This is the first compressed lightweight design, implementation, and evaluation of 6LoW- PAN extension for IPsec on Contiki. Our extension supports both IPsec's Au- thentication Header (AH) and Encapsulation Security Payload (ESP). -
Internetworking and Layered Models
1 Internetworking and Layered Models The Internet today is a widespread information infrastructure, but it is inherently an insecure channel for sending messages. When a message (or packet) is sent from one Website to another, the data contained in the message are routed through a number of intermediate sites before reaching its destination. The Internet was designed to accom- modate heterogeneous platforms so that people who are using different computers and operating systems can communicate. The history of the Internet is complex and involves many aspects – technological, organisational and community. The Internet concept has been a big step along the path towards electronic commerce, information acquisition and community operations. Early ARPANET researchers accomplished the initial demonstrations of packet- switching technology. In the late 1970s, the growth of the Internet was recognised and subsequently a growth in the size of the interested research community was accompanied by an increased need for a coordination mechanism. The Defense Advanced Research Projects Agency (DARPA) then formed an International Cooperation Board (ICB) to coordinate activities with some European countries centered on packet satellite research, while the Internet Configuration Control Board (ICCB) assisted DARPA in managing Internet activity. In 1983, DARPA recognised that the continuing growth of the Internet community demanded a restructuring of coordination mechanisms. The ICCB was dis- banded and in its place the Internet Activities Board (IAB) was formed from the chairs of the Task Forces. The IAB revitalised the Internet Engineering Task Force (IETF) as a member of the IAB. By 1985, there was a tremendous growth in the more practical engineering side of the Internet. -
A Cybersecurity Terminarch: Use It Before We Lose It
SYSTEMS ATTACKS AND DEFENSES Editors: Davide Balzarotti, [email protected] | William Enck, [email protected] | Samuel King, [email protected] | Angelos Stavrou, [email protected] A Cybersecurity Terminarch: Use It Before We Lose It Eric Osterweil | George Mason University term · in · arch e /’ t re m , närk/ noun an individual that is the last of its species or subspecies. Once the terminarch dies, the species becomes extinct. hy can’t we send encrypt- in the Internet have a long history W ed email (secure, private of failure. correspondence that even our mail To date, there has only been one providers can’t read)? Why do our success story, and, fortunately, it is health-care providers require us to still operating. Today, almost ev- use secure portals to correspond erything we do online begins with a with us instead of directly emailing query to a single-rooted hierarchical us? Why are messaging apps the global database, whose namespace only way to send encrypted messag- is collision-free, and which we have es directly to friends, and why can’t relied on for more than 30 years: we send private messages without the Domain Name System (DNS). user-facing) layer(s). This has left the agreeing to using a single platform Moreover, although the DNS pro- potential to extend DNSSEC’s verifi- (WhatsApp, Signal, and so on)? Our tocol did not initially have verifica- cation protections largely untapped. cybersecurity tools have not evolved tion protections, it does now: the Moreover, the model we are using to offer these services, but why? DNS Security Extensions (DNS- exposes systemic vulnerabilities. -
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. -
DNS As a Multipurpose Attack Vector
PANEPISTHMIO AIGAIOU DIDAKTORIKH DIATRIBH To Prwtόκοllo DNS wc Poluleitουργικός Forèac EpÐjeshc Suggrafèac: Μάριoc Anagnwstόπουλος Epiblèpwn: Αναπληρωτής Kaj. Ge¸rgioc Καμπουράκης Diatrιβή gia thn aπόκτηση Didaktorikoύ Dipl¸matoc tou ErgasthrÐou Ασφάλειας Plhroforiak¸n kai Epikoinwniak¸n Συστημάτwn Τμήματoc Mhqanik¸n Plhroforiak¸n kai Epikoinwniak¸n Συστημάτwn Septèmbrioc, 2016 University of the Aegean Doctoral Thesis DNS as a multipurpose attack vector Author: Marios Anagnostopoulos Supervisor: Associate Prof. Georgios Kambourakis A thesis submitted in fulfilment of the requirements for the degree of Doctor of Philosophy at the Laboratory of Information and Communication Systems Security Department of Information and Communication Systems Engineering September, 2016 Declaration of Authorship I, Marios Anagnostopoulos, declare that this thesis entitled, \DNS as a multipurpose attack vector" and the work presented in it are my own. I confirm that: This work was done wholly while in candidature for a research degree at this University. Where I have consulted the published work of others, this is always clearly at- tributed. Where I have quoted from the work of others, the source is always given. With the exception of such quotations, this thesis is entirely my own work. I have acknowledged all main sources of help. Where the thesis is based on work done by myself jointly with others, I have made clear exactly what was done by others and what I have contributed myself. Signed: Date: September 28, 2016 i Advising Committee of this Doctoral -
Performance Evaluation of HTTP/2 Over TLS+TCP and HTTP/2 Over QUIC in a Mobile Network
View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Scitech Research Journals Journal of Information Sciences and Computing Technologies(JISCT) ISSN: 2394-9066 SCITECH Volume 7, Issue 1 RESEARCH ORGANISATION| March 22, 2018 Journal of Information Sciences and Computing Technologies www.scitecresearch.com/journals Performance Evaluation of HTTP/2 over TLS+TCP and HTTP/2 over QUIC in a Mobile Network Yueming Zheng, Ying Wang, Mingda Rui, Andrei Palade, Shane Sheehan and Eamonn O Nuallain School of Computer Science and Statistics Trinity College Dublin Dublin 2, Ireland Abstract With the development of technology and the increasing requirement for Internet speed, the web page load time is becoming more and more important in the current society. However, with the increasing scale of data transfer volume, it is hard for the current bandwidth used on the Internet to catch the ideal standard. In OSI protocol stack, the transport layer and application layer provide the ability to determine the package transfer time. The web page load time is determined by the header of the package when the package is launched into the application layer. To improve the performance of the web page by reducing web page load time, HTTP/2 and QUIC has been designed in the industry. We have shown experimentally, that when compared with HTTP/2, QUIC results in lower response time and better network traffic efficiency. Keywords: HTTP/2, QUIC, TCP, emulation, Mininet, Mininet-Wifi 1. Introduction The web page response time is one of the most important criteria for the network performance.