Network Device Enumeration and Identification Using Passive Asset Detection

Full text

(1)LiU-ITN-TEK-A--21/015-SE. Network Device Enumeration and Identification Using Passive Asset Detection Filip Klang 2021-06-03. Department of Science and Technology Linköping University SE-601 74 Norrköping , Sw eden. Institutionen för teknik och naturvetenskap Linköpings universitet 601 74 Norrköping.

(2) LiU-ITN-TEK-A--21/015-SE. Network Device Enumeration and Identification Using Passive Asset Detection The thesis work carried out in Datateknik at Tekniska högskolan at Linköpings universitet. Filip Klang Norrköping 2021-06-03. Department of Science and Technology Linköping University SE-601 74 Norrköping , Sw eden. Institutionen för teknik och naturvetenskap Linköpings universitet 601 74 Norrköping.

(3) Abstract As society strives for an increasing amount of connectivity and digitalization to increase accessibility and productivity, society is also more vulnerable then ever before. Thus, societal, business and personal infrastructure is the most vulnerable it has ever been. Therefore, the need for systems that can digitally catalog all devices within a network and provide information about each and every device, what other devices it is communicating with and its placement within the network, along with providing ways to identify potential threats before it is to late, is at an all time high. This report presents the process of designing, developing and using a system aimed at performing passive asset detection and how it can lead to an increased visibility and knowledge of a network. The system is developed using C++, Python and the graph database Neo4j, which also provides a tool called Bloom to interactively visualize the database using custom Bloom perspectives. It uses direct informational gain to make initial assumptions about a device, subnetwork or network and tries to strengthen these assumptions using indirect information that is gained by passively analyzing traffic, provided over a longer period of time. Data can be supplied using either pcap files or by using the live capture feature and should be recorded at the router closest to the end point devices in each individual subnetwork to work optimally..

(4) Acknowledgments I would like to begin by expressing my sincere appreciation to my supervisors at Sectra, Emil Gustafsson and Ioana Rhode, for supplying me with answers to many of my questions, for reading my report and providing much appreciated feedback, and also for giving me a personal office space in the light of the COVID-19 pandemic. I would also like to thank all employees within the Critical Infrastructure department for making me feel like a part of the team and welcoming me with open arms. Additionally, I also want to thank my supervisor at LiU, Pierangelo Dell’Acqua, for continuously reading my report and providing me with valuable feedback throughout my thesis work.. iv.

(5) Contents Abstract. iii. Acknowledgments. iv. Contents. v. List of Figures. vii. List of Tables. viii. 1. 2. 3. 4. Introduction 1.1 Motivation . . . . . 1.2 Aim . . . . . . . . . 1.3 Research Questions 1.4 Delimitations . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 1 1 2 2 2. Theory 2.1 Asset Detection . . . . . . . . . . . . . . . . . 2.1.1 Active Asset Detection . . . . . . . . . 2.1.2 Passive Asset Detection . . . . . . . . 2.1.3 Advantage of Passive Asset Detection 2.2 Internet Protocol Suite . . . . . . . . . . . . . 2.2.1 Data Link Layer . . . . . . . . . . . . . 2.2.2 Network Layer . . . . . . . . . . . . . 2.2.3 Transport Layer . . . . . . . . . . . . . 2.2.4 Application Layer . . . . . . . . . . . 2.2.5 OS Fingerprinting . . . . . . . . . . . 2.3 Graph Database . . . . . . . . . . . . . . . . . 2.4 Related Work . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 3 3 3 4 4 4 5 6 7 8 10 10 10. Method 3.1 Tools and Frameworks . . . . . . . . . . . . . 3.2 Modeling the Target Network . . . . . . . . . 3.3 Creating the Passive Asset Detection System 3.3.1 Packet Miner . . . . . . . . . . . . . . 3.3.2 Database Handler . . . . . . . . . . . . 3.3.3 Inter-process Communication . . . . . 3.3.4 Database and Visualizer . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 12 12 13 14 14 14 15 15. Results 4.1 Passive Asset Detection System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Packet Miner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Database Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17 17 18 20. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. v. . . . .. . . . .. . . . ..

(6) 4.1.3 5. 6. Database and Data Visualizer . . . . . . . . . . . . . . . . . . . . . . . . .. 20. Discussion 5.1 Results . . . . . . . . . . . . . . . . . . . . . 5.1.1 Passive Asset Detection System . . . 5.1.2 Protocols and Data . . . . . . . . . . 5.1.3 Packet Miner and Database Handler 5.2 Method . . . . . . . . . . . . . . . . . . . . . 5.2.1 Packet Miner and Protocol Selection 5.3 The Work in a Wider Context . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 21 21 21 22 22 23 23 23. Conclusion 6.1 Research Questions . . . . . . . . . 6.2 Future Work . . . . . . . . . . . . . 6.2.1 System Components . . . . 6.2.2 Increased Information Gain. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 24 24 25 25 25. . . . .. . . . .. Bibliography. . . . .. . . . .. . . . .. 26. vi.

(7) List of Figures 2.1 2.2 2.3 2.4. 2.5. Layout of an Ethernet type II frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contents of the Ethernet type II frame header seen in figure 2.1 . . . . . . . . . . . Structure of a 48-bit MAC address . . . . . . . . . . . . . . . . . . . . . . . . . . . . Three-way TCP handshake between client A and B. Client A sends a synchronize (SYN) packet to Client B, illustrated by [1] in the figure. Client B acknowledges the SYN packet and returns a SYN + acknowledgement (ACK) packet, illustrated by [2] in the figure. Finally, client A acknowledges that they have received the SYN + ACK packet by returning a simple ACK packet, illustrated by [3] in the figure. . . Comparison between a relational data model and a graph property model. . . . . .. 8 11. 3.1 3.2 3.3 3.4. The target network used during development of the system. . . . The target network used to evaluate the impact of subnetworks. . Abstraction of the entry points and output from the packet miner. Graph database model. . . . . . . . . . . . . . . . . . . . . . . . . .. 13 13 15 16. 4.1. An overview of how tapped network packets become queryable data objects when it passes through the system components. . . . . . . . . . . . . . . . . . . . . . . . . A flowchart of the system when started in file mode. . . . . . . . . . . . . . . . . . . A flowchart of the system when started in tap mode. All colored lines are a part of the main event loop where different colors indicate different threads. . . . . . . An example of how the interactive Bloom perspective can visualize the database. .. 4.2 4.3 4.4. vii. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 5 5 5. 17 18 19 20.

(8) List of Tables 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8. Interesting data in IPv4 packets . . . . . . . . . . . . . . . . . . . . Interesting data in IPv6 packets . . . . . . . . . . . . . . . . . . . . Availability of message types in ICMPv4 & ICMPv6 . . . . . . . . Interesting data in UDP packets . . . . . . . . . . . . . . . . . . . . Interesting data in TCP packets. X denotes variable data length . Interesting data in HTTP packets. X denotes variable data length Availability of information in DHCP & DHCPv6 packets . . . . . Message translations between DHCP & DHCPv6 . . . . . . . . . .. viii. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 6 6 6 7 7 8 10 10.

(9) 1. Introduction. As time goes by, companies strive for digitalization at an ever-increasing rate [31]. This digitalization makes it more difficult for system administrators to keep track of all the devices in use by their own company. Computers, phones, tablets, printers, speakers, cameras, sensors and various appliances are all examples of devices that today commonly connect to the internet and share its information with other devices on a network or on the internet. At a certain point it becomes unfeasible to update information about these devices as it would simply require too much manual labor to keep the data up to date. Today there exists tools to aid system administrators in doing this work by scanning a network for devices that are currently connected to it. However, as the number of devices increase, it would eventually require a large amount of extra traffic flowing over the network to simply index what is connected and thus producing a lot of unnecessary traffic. Secondly, if there is a device connected with the intent of staying hidden, this sort of scan would end up not yielding data for such a device as it can choose to not respond to these well known scans or probes.. 1.1. Motivation. A more modern way to index what is on a network is to use the normal and already existing network traffic. This traffic (or data) can help label and identify the device it is being sent from and to. Over time, by recording network traffic and its data-of-data, also known as metadata, a comprehensive map of all the devices within a network can be pieced together. This is also known as Passive Asset Detection (PAD). This map contains what could be considered a device fingerprint for each device on a network. Each fingerprint consists of device information such as which Operating System (OS) it is running, what services it is running and which other devices it has communicated with. However, solutions such as Passive Real-Time Asset Detection System1 (PRADS) identifies and labels a device on a message-by-message basis using static rulesets. This means that PRADS identifies any device based on its last acquired information. Therefore, if a device were labeled to be a Linux device and new data indicates that the device is a Windows device, 1 Passive. Real-Time Asset Detection System - https://github.com/gamelinux/prads. 1.

(10) 1.2. Aim PRADS would identify the device to be running Windows without considering previously acquired data and assumptions.. 1.2. Aim. The aim is to develop a system that leverages data passively acquired over time to fingerprint devices on a network without their knowledge. The system should use any previously made assumptions about a device to strengthen the likelihood of such an assumption being correct. The system should also be able to handle live network traffic as well as recorded network traffic stored in Packet Capture (PCAP)-files. Lastly, all of this data should be made available for graphical analysis that system administrators can utilize to find potential threats and problems.. 1.3. Research Questions. 1. Which network packet data is meaningful to analyze in a passive asset detection system in order to strengthen assumptions made over time? 2. How can a passive asset detection system be designed to handle networks consisting of one or more subnetworks? 3. How can the passive asset detection system lead to an increased understanding of the network?. 1.4. Delimitations. The report will not take into consideration evil devices that intentionally tries to modify its own device parameters to appear as another device or as if it is using services or applications it simply does not use. Additionally, due to the Covid-19 pandemic, there has been a limited possibility to conduct field studies in the form of external network recording/monitoring. Due to this, the author’s home network and simulated networks using GNS3 has been the sources of verifiable data used during development and thus might have different levels of success on large networks.. 2.

(11) 2. Theory. In this chapter, theory relevant for developing a passive network parser and a device fingerprinting algorithm is presented. The main part of the chapter gives the reader an in-depth understanding of what network traffic really is and what information can be gained from it. Additionally, a brief description of graph databases is presented.. 2.1. Asset Detection. There exists two main ways of conducting asset detection. The two methods are labeled as active and passive [5], and are briefly described below.. 2.1.1. Active Asset Detection. Active asset detection is conducted by continuously probing a network by sending requests tailored to produce a specific response from a given host. The host response gives indications about running services, system architectures and potentially operating system information. The most common methods of active scanning are [4]: • Ping sweeps using different protocols that exist within the network and transport layer. Ping sweeps can identify the existence of a device by sending a ping to a specific IP address and waiting for a response. If a response is received, there must be a device behind that IP address. Transmission Control Protocol (TCP) sweeping is a commonly used method that in addition to establishing device existence also provides OS specific information about the device as the answers are normally OS specific. • Port scanning can be used when the existence of a host is known. By connecting to different ports using either TCP or User Datagram Protocol (UDP), this scanning method can be used to enumerate services running on the host. • Operating system detection is somewhat related to port scanning as many ports are operating system dependent. However, certain services requires further interaction to generate OS specific information. This includes methods such as banner grabbing and TCP/IP probing.. 3.

(12) 2.2. Internet Protocol Suite By scanning an entire network potential security vulnerabilities can be discovered that are tied to specific services and/or operating systems [4, 41].. 2.1.2. Passive Asset Detection. Passive asset detection means that no additional traffic is generated and that all information is harvested from the existing network traffic [28, 32]. Traffic is harvested by strategically placing network taps within the network [9]. When packets pass by a tap it is duplicated (mirrored) and either directly dispatched to a live parser or stored in .pcap or .pcapng files for offline analysis [22, 30]. From this traffic, information about open ports, running services, operating systems and even usability patterns can be deduced. There is a lot of information to gain about a host when all of its network traffic is mapped back to it over a longer period of time.. 2.1.3. Advantage of Passive Asset Detection. When it comes to maintaining an overview of a growing network over a longer period of time, active detection methods starts to fall behind the passive detection methods. Some of the main issues with active detection are: • Asset discovery requires continuous updates to keep the acquired information up to date. As active detection does not utilize any existing network traffic it has to create more and more custom traffic (probes) to meet discovery demands and keep up with the changes in the network. • Information lifetime becomes a concern on larger networks when running a fully active discovery method as no additional information is received about a device outside of the probes sent to it. • Active scanning can easily be noticed by a device keen on staying hidden. There exists a multitude of ways to stay hidden or deceiving the discovery algorithm by carefully crafting the response to ping sweeps, port scans or banner grabbing [6, 12, 25, 40]. In contrast to the issues mentioned above, a concern with fully passive detection methods is "what you see is what you get". This means that information that is not sent over the network will never be discovered. However, by tapping in to the traffic sent from and to each device on a network, more advanced relationships can be derived. Having access to additional information such as the headers from HTTP requests, the client handshake from HTTPS requests or occasional NetBIOS queries that contain detailed device information gives further possibilities of device fingerprinting compared to a fully active solution. More information can be gathered about every single device and the information will always be up to date.. 2.2. Internet Protocol Suite. As briefly described in section 1.1 and 2.1.2, a passive asset detection algorithm relies on access to the normal traffic flow of a network. Network traffic consists of different types of packets, also known as datagrams or frames, sent from a device using a certain network protocol within the internet protocol suite, also known as the TCP/IP model [8, 21]. The following sections will dissect the TCP/IP model and define which data from each of the chosen protocols and layers will be used to develop the asset detection algorithm.. 4.

(13) 2.2. Internet Protocol Suite. 2.2.1. Data Link Layer. In the Ethernet standard, the communication occurs between two physical devices known as network interface controllers (NICs). The data link layer connects the network layer above and the physical layer below. Therefore, the role of the data link layer is to send and receive frames which are encapsulated network packets (data) between NICs within a local area network (LAN) or wireless area network (WAN). Media Access Control (MAC) Sub-layer The data link layer consist of two sub-layers, the MAC sub-layer and the logical link control (LLC) sub-layer. The MAC sub-layer is responsible for addressing. An Ethernet type II (E2) frame consists of a header, data and trailer section as seen in figure 2.1.. Figure 2.1: Layout of an Ethernet type II frame Furthermore, the header of the E2 frame is structured according to figure 2.2. From the E2 header, a source and destination MAC address can be found for any packet sent over a network.. Figure 2.2: Contents of the Ethernet type II frame header seen in figure 2.1 A MAC address is a 48-bit (6 byte) unique identifier for a NIC consisting of two 24-bit (3 byte) sections. The first 24 bits correspond to the Organizationally Unique Identifier (OUI) and the last 24 bits to a Universally Administered Address (UAA) [26]. An example of a valid MAC address can be seen in figure 2.3.. Figure 2.3: Structure of a 48-bit MAC address. 5.

(14) 2.2. Internet Protocol Suite. 2.2.2. Network Layer. The next layer in the TCP/IP model is the network layer which is responsible for the functionality and information related to transferring packets between networks. Internet Protocol version 4 (IPv4) IPv4 contains information such as the packets internet source address and destination address, known as the IP address. The IP address can be used to identify if a device resides within the local network or somewhere on the internet [11]. Furthermore, IPv4 contains information about the number of allowed router/gateway jumps (time to live) and fragmentation flags which have been deemed useful in OS fingerprinting [32, 2]. RFC 791 [37] contains information about the protocol in its entirety. Name. Size (bits). Source address Destination address Time to live Fragmentation flag. 32 32 8 3. Table 2.1: Interesting data in IPv4 packets. Internet Protocol version 6 (IPv6) Similar to IPv4, IPv6 contains information about the sender and receivers IP address and a field called hop limit, which is almost identical to the time to live field that can be seen in IPv4. Table 2.2 shows all the data that will be harvested from IPv6 and the respective data size. RFC 8200 [13] contains details regarding IPv6 and the parameters mentioned above. Name Source address Destination address Hop limit. Size (bits) 128 128 8. Table 2.2: Interesting data in IPv6 packets. Internet Control Message Protocol version 4 & 6 (ICMP & ICMPv6) ICMP and ICMPv6 are both part of IPv4 and IPv6 respectively, which most commonly handles error reporting and network diagnostics. According to RFC 792 and 4443 [10, 36], the categories are split into error messages and informational messages. There exists two particularly interesting message types, the router advertisement message and neighbour advertisement message. Both messages can be used to identify which devices on a network are routers by observing the source IP address in combination with certain protocol flags. Table 2.3 shows the availability of the message types for both ICMPv4 and ICMPv6. Message Type Router advertisement Neighbour advertisement. ICMPv4 Yes No. ICMPv6 Yes Yes. Table 2.3: Availability of message types in ICMPv4 & ICMPv6. 6.

(15) 2.2. Internet Protocol Suite. 2.2.3. Transport Layer. The transport layer provides services such as data integrity, enforcing same order delivery and assuring that both the sender and receiver agrees on rate of transmission to not suffer from underflow or overflow. The transport layer works with the network layer and the application layer by: • Breaking application layer messages down into packets that can be sent by the network layer. • Reassembling packets from the network layer into messages that can be passed to the application layer. User Datagram Protocol (UDP) UDP is a minimalistic and connectionless fire-and-forget protocol which according to RFC 768 [38] allows applications to send messages or datagrams to other computers on the IP network. UDP carries little information apart from the payload itself, thus having a low overhead. However, such low overhead also means that there is not a lot of useful data to harvest from a UDP datagram. Table 2.4 shows all the data that will be harvested from UDP datagrams passing through the system. Name. Size (bits). Source port Destination port Data length. 16 16 16. Table 2.4: Interesting data in UDP packets. Transmission Control Protocol (TCP) Compared to UDP, TCP is a connection based communication protocol which relies on setting up a connection using a three-way handshake. The three-way handshake is illustrated in figure 2.4. As stated by both Anderson & McGrew [2] and Beverly [7], the device parameters sent along with the SYN packet in the initial handshake sequence can be used to deduce the device operating system. This method is known as TCP/IP fingerprinting and is explained further in section 2.2.5. RFC 793 [37] contains a detailed explanation of all the chosen protocol parameters seen in table 2.5. Name. Size (bits). Source port Destination port Windows Size Flags Options. 16 16 16 16 8˚X. Table 2.5: Interesting data in TCP packets. X denotes variable data length. 7.

(16) 2.2. Internet Protocol Suite. Figure 2.4: Three-way TCP handshake between client A and B. Client A sends a synchronize (SYN) packet to Client B, illustrated by [1] in the figure. Client B acknowledges the SYN packet and returns a SYN + acknowledgement (ACK) packet, illustrated by [2] in the figure. Finally, client A acknowledges that they have received the SYN + ACK packet by returning a simple ACK packet, illustrated by [3] in the figure.. 2.2.4. Application Layer. The application layer allows for applications to communicate using arbitrary application protocols that rely on the existence of the physical layer, data link layer, network layer and transport layer. Hypertext Transfer Protocol (HTTP) As stated by RFC family 7230-7235 [15, 16, 17, 18, 19, 20], HTTP is a "stateless applicationlevel protocol for distributed, collaborative, hypertext information systems". The protocol is mostly known for being the core of the World Wide Web. When a device makes a request using HTTP, it passes along detailed information about itself using a User-Agent header. The field sometimes contains information about which application was used to send the request and also which OS the device is running. Anderson & McGrew [2] has also shown that the User-Agent header has the most information gain when compared to TCP and TLS fingerprinting in the context of OS fingerprinting. Furthermore, visited websites, downloaded files and locally hosted web servers can also be mined using data fields shown in table 2.6. RFC 7231 [20] contains detailed explanations of the data fields described in this section. Name. Size (bits). User-Agent Content-Type Host Server. 8˚X 8˚X 8˚X 8˚X. Table 2.6: Interesting data in HTTP packets. X denotes variable data length. NetBIOS According to RFC 1001 [24], NetBIOS itself is not a protocol but a service. However, the standard defined in RFC 1001 is a protocol that supports NetBIOS services and will be ref8.

(17) 2.2. Internet Protocol Suite ered to as the NetBIOS protocol in this thesis. As NetBIOS is commonly found on Windows devices, the NetBIOS protocol can be used to both identify, enumerate and label Windows devices. Below follows a list of interesting information that can be found within the scope of the NetBIOS protocol: • The NetBIOS datagram service (nbds) contains information about the source and destination host names as the NetBIOS names are defaulted to the hostname of a given computer. Additionally, information about the role of the device is also passed along with a datagram, indicating if the device is for example a workstation or a server. • The NetBIOS name service (nbns) serves a different purpose compared to the nbds, however the same information regarding the hostname and role of a device can be derived from these packets as well. • The Microsoft Windows Broswer Protocol (MWBP) is implemented on top of the nbds and Server Message Block (SMB) protocol. MWBP contains different messages identified by a command id, where command id 1 signifies the Host Announcement (MWBP-HA) message. In the context of device information, the MWBP-HA message is the richest part of NetBIOS, according to the author. Below follows a list of all device specific information found in a MWBP-HA message: – Computer hostname – OS major version – OS minor version – MWBP major version – MWBP minor version – Device type Dynamic Host Configuration Protocol (DHCP & DHCPv6) Both versions of the DHCP were designed to dynamically lease IP addresses to devices within a network. When the lease expires the temporary address either goes back into the address pool or is renewed and kept by the client. When these transactions occur between the server and a client, a plethora of information is sent back and forth regarding the state of the local network. In table 2.7 useful information that can be found in both versions of DHCP can be seen. Below follows a short description of the data: • Vendor class and enterprise number provides another way to pinpoint what OS a device is running by mapping the value of the field to a list of well known vendor classes. • Subnet mask provides a useful way, albeit only being available for DHCP, to determine the IPv4 address range of the local network. • The DHCP server and DNS server field allows for identification of which device within the network acts as a DHCP and DNS server. • IP address lease time discloses the amount of time until a specific IP address has to be rebound or returned to the lease pool. DHCP and DHCPv6 are described in its entirety in RFC 2131-2132 [1, 14] and RFC 8415 [34] respectively. Lastly, table 2.8 shows the available message types and how they translate between the different versions of DHCP.. 9.

(18) 2.3. Graph Database Data Vendor class Enterprise number Subnet mask DHCP server DNS server IP address lease time. DHCP Yes Yes Yes Yes Yes Yes. DHCPv6 Yes Yes No Yes Yes Yes. Table 2.7: Availability of information in DHCP & DHCPv6 packets DHCP Discover Offer Request Acknowledge. DHCPv6 Solicit Advertise Request Reply. Table 2.8: Message translations between DHCP & DHCPv6. 2.2.5. OS Fingerprinting. One major part of creating a device fingerprint is deducing the OS it is running. Recently, a report published by Anderson & McGrew [2] at Cisco Systems studied the means of multisession fingerprinting in regards to operating systems. They showed that by combining different packet data that has been captured over multiple sessions, a higher OS deduction accuracy can be achieved compared to single packet guesses. Therefore, the OS deduction incorporated in the system presented in this thesis will be based on some of the methods described by Anderson & McGrew. Additionally, Lastovicka et al. [29] drew similar conclusions to Anderson & McGrew [2] using a multi-session model, that usage of the HTTP User-Agent header field is the most accurate way of labeling operating systems. The biggest concern with labeling by HTTP headers, mentioned by both Anderson & McGrew and Lastovicka et al. is that unencrypted HTTP connections and requests are on a decline. Both Mozilla [33] and Google [23] are actively making changes to phase out HTTP in favor of their encrypted counterparts within their browsers which will reduce the usability of this fingerprinting method drastically in the coming years.. 2.3. Graph Database. A graph database is a tool for storing data where equal amount of weight is put on the relationships between data as the data itself. In the case of Neo4j [35], the database model is based partly on the property graph model. The property graph model is, according to both Angles [3] and the creators of Neo4j [35], from a data modeling point of view, a way for nodes to represent entities, edges to represent relationships and properties to represent data or relationship features. A comparison between the graph property model to the relational data model can be seen in figure 2.5. Both models store which devices have accessed a certain website. One major difference between the models is that the graph property model completely disregards the join table and stores the relationships as is.. 2.4. Related Work. There exists an open source software called Passive Real-time Asset Detection System (PRADS) [39]. PRADS performs passive network analysis on a packet-by-packet basis which 10.

(19) 2.4. Related Work. Figure 2.5: Comparison between a relational data model and a graph property model.. means that it takes a packet and mines what it deems to be interesting information and outputs it to a file or stream. As the project currently states in its README, it does not utilize permanent storage nor does it supply a way of viewing the output data in any way.. 11.

(20) 3. Method. As the thesis aims to analyze many different types of network protocols, the implementation process was iterative. First, an interesting network protocol was identified and researched. If the protocol was deemed relevant for asset detection, harvesting of such protocol packets was implemented into the packet miner. Furthermore, the database import script was then updated to support the new protocol and the data it provided to the system. This process then repeated until all the chosen network protocols had been implemented and integrated into the system.. 3.1. Tools and Frameworks. For network packet analysis the cross-platform software Wireshark1 was used to dissect and analyze chosen network protocols and their contents. Wireshark was used to both find interesting network protocols and to verify that the resulting implementation contains correct protocol data. The packet mining algorithm was written in C++ on top of a library called PcapPlusPlus2 which provided a way to read pcap files or capture live traffic whilst also providing implementations for parsing certain network protocols out of the box. Compared to other C/C++ based packet capture libraries, PcapPlusPlus provided the perfect mix between abstraction and performance3 , making it a good choice for this thesis. Additional protocol parsers have been implemented manually according to the relevant RFC specification and information about what data is extracted can be seen in section 2.2. Lastly, a database import script was written in Python. To store all the data, the graph database Neo4j4 was used. Neo4j also provides a way to visualize and interact with all the data using Neo4j Bloom5 , which is a graph exploration application.. 1 Wireshark. - https://www.wireshark.org - https://pcapplusplus.github.io 3 PcapPlusPlus Benchmarks - https://pcapplusplus.github.io/docs/benchmark 4 Neo4j - https://neo4j.com 5 Neo4j Bloom - https://neo4j.com/product/bloom 2 PcapPlusPlus. 12.

(21) 3.2. Modeling the Target Network. 3.2. Modeling the Target Network. When developing the system it was important that the data used as a basis for evaluation was acquired from a trustworthy and controllable source. Instead of setting up a physical network, GNS3 6 was used to simulate a small network where every single part of the network was controllable from a graphical interface. Figure 3.1 and 3.2 show the networks used during creation of the system and modelling of the database. Additionally, GNS3 seamlessly integrates with Wireshark and traffic can be tapped at any point in the network which motivates the decision to use Wireshark. The target networks consisted of four computers, two of which ran Windows 10 and two that ran Ubuntu 20.04 (Linux).. Figure 3.1: The target network used during development of the system. The difference between the two networks were that they consisted of different number of subnetworks. The main network seen in figure 3.1 consist of a single network whilst the secondary network seen in figure 3.2 consists of two subnetworks.. Figure 3.2: The target network used to evaluate the impact of subnetworks.. 6 GNS3. - https://www.gns3.com. 13.

(22) 3.3. Creating the Passive Asset Detection System. 3.3. Creating the Passive Asset Detection System. All packets passing through a specified network interface are tapped and mined using C++. The selected data is passed to Python which uses the Neo4j Python driver [27] to handle database transactions.. 3.3.1. Packet Miner. The packet miner, which is the core of the fully passive detection system, is written in C++ using the PcapPlusPlus library. One of the major reasons for this design choice is that the underlying capture libraries (libpcap for unix systems and Npcap for windows systems) are both written in C/C++ which makes the miner a fully native application, contributing to a higher baseline performance. Furthermore, the miner is developed as a cross-platform application, designed to work on a wide range of devices. The miner outputs its data using Comma Separated Value (CSV) files. The CSV files are designed to contain data defined at compile time that is later found during the packet mining. The CSV files are separated into three categories: • Protocols layered on top of IPv4. A few examples of filenames are: – dhcp.csv - DHCP over IPv4 – icmp.csv - ICMP over IPv4 – http.csv - HTTP over IPv4 • Protocols layered on top of IPv6. A few example of filenames are: – dhcpv6.csv - DHCP over IPv6 – icmpv6.csv - ICMP over IPv6 – http6.csv - HTTP over IPv6 • Observational data, for example router and host announcements. They are tagged with observation type after their protocol and IP version. A few examples of filenames are: – mwbp_ha.csv - MWBP over IPv4 - Host Announcements – icmpv6_ra.csv - ICMP over IPv6 - Router Announcements The reason for partitioning data of similar type into multiple files dependent on IP version is that Neo4j performs better when running specific queries. This means that more general queries containing a lot of conditionals, for example if-statements, will suffer reduced performance as the input data size grows. Therefore, the data is split into specific CSV files so that import queries only have to deal with a single type of data, reducing the amount of conditional statements and thus reduces branching. Additionally, the system should be able to handle both offline and online data, meaning that it should be able to process previously acquired pcap files or monitor a network interface. The two different ways of starting the program should lead to the same output as can be seen in figure 3.3.. 3.3.2. Database Handler. As there exists no official C++ driver for Neo4j, and there simply not being enough time to create a robust custom driver, a decision to go with the Python driver was made. Neo4j provides an officially supported driver which uses the custom Bolt API to communicate with the database. The importer should contain two different entry points, similar to that of the miner, depending on the mode that the system was started in. One mode should simply read a set of output data and insert it into the database whilst the second mode should continuously update the database until the miner is terminated. 14.

(23) 3.3. Creating the Passive Asset Detection System. Figure 3.3: Abstraction of the entry points and output from the packet miner.. 3.3.3. Inter-process Communication. As explained in section 3.3.1 and 3.3.2, the directional communication between the miner and the importer is handled using CSV files. However, to provide the importer with an acknowledgement that all files have been successfully written, the miner creates a .chk (checkpoint) file after closing all open file handles and errors have occured. When the importer detects the existence of the checkpoint file, the import routine fires and the checkpoint file is deleted. Therefore, when the import routine finishes, the importer either idles until the creation of the next checkpoint file or terminates depending on which mode the miner was started in.. 3.3.4. Database and Visualizer. As briefly mentioned in section 3.1, Neo4j provides a tool called Bloom to visualize the database in the form of the graph property model. However, visualization stems from the database model created and updated by the database handler. An overview of the database layout can be seen in figure 3.4. The entities, which in the figure can be identified as nodes with different colors, are points of interest when creating an overview of a network. The graph can be seen as an overview of the monitored network defined by the devices within it. Each device is uniquely identified by its MAC address and thus assumed to be unique within the network. Additional nodes are created and related to a device, an example being the purple IPv4 node and the turquoise IPv6 node as seen in figure 3.4.. 15.

(24) 3.3. Creating the Passive Asset Detection System. Figure 3.4: Graph database model.. 16.

(25) 4. Results. In this section, the result from the creation of the passive asset detection system is presented. Firstly, an overview of the entire system is given, followed by a description of each core part of the system.. 4.1. Passive Asset Detection System. The system consists of three major components which are labeled Packet miner, Database handler and Neo4j in figure 4.1. Traffic that passes a tap, represented in the figure as a router, can either be recorded into a pcap file or directly interpreted by the Packet miner, depending on operational mode. The miner outputs data in a format that the database handler understands. The handler proceeds to input the data into the database and handle any other communication with the database as long as the system is alive.. Figure 4.1: An overview of how tapped network packets become queryable data objects when it passes through the system components.. 17.

(26) 4.1. Passive Asset Detection System. 4.1.1. Packet Miner. The packet miner has two operational modes which constitutes to both offline and online capture. One mode takes one or more pcap files and produces a combined output that can be read by the handler. The second mode is used for continuous operation on an active network connection and continuously outputs data to the database handler. Additionally, the system is designed to support low resource single-board computers by batching large capture files that will not fit into memory and exploiting parallelism by utilizing multiple CPU cores and threads to speed up packet mining. File Mode The system starts in file mode when supplied with a -f flag. The command line argument is assumed to be a relative path to one or more pcap files containing capture data belonging to the tapped network. After mining the input files and creating all CSV files, it invokes the Python import script. A valid command to start the system in file mode looks like system.exe -f pcap/net_2021_04_29.pcap. A flowchart of the system running in file mode can be seen in figure 4.2. Figure 4.2: A flowchart of the system when started in file mode.. Tap Mode The tap mode is the default mode for the system meaning it requires no command line arguments to invoke this mode. When starting the system in tap mode, it starts the miner along with invoking the tap mode of the python import script. The miner captures network packets passing through the default network interface unless specified by the user and saves them to 18.

(27) 4.1. Passive Asset Detection System memory in batches. After a set amount of time, it mines the tapped packets whilst continuing to tap the next batch of packets. When the miner has successfully written all files it alerts the python import script of successful writing. This mode runs until the system is stopped by the user. A flowchart of the system running in tap mode can be seen in figure 4.3. Figure 4.3: A flowchart of the system when started in tap mode. All colored lines are a part of the main event loop where different colors indicate different threads.. 19.

(28) 4.1. Passive Asset Detection System. 4.1.2. Database Handler. The database handler is developed such that it should never be started manually. Instead, the database handler will always be started by the miner and given operation specific information on how to interact with the Neo4j database. Additionally, any custom database actions can be implemented directly into the handler and will be run every time the handler is invoked by the miner. The handler operates in a sequential manner, as certain graph attributes have to exist before relationships can be created. An example of this is that the device node has to exists before it can be assigned an IPv4 address and thus the device node will always be created before the IPv4 node.. 4.1.3. Database and Data Visualizer. As the database is populated, changes can be viewed in real-time using the Neo4j browser or the interactive visualization tool Bloom. Figure 4.4 shows how Bloom is used to visualize five devices on a smaller network, which addresses belong to said devices, and if it has any open ports. The visualization is composed using a Bloom perspective that can be tailored to visualize certain parts of the database.. Figure 4.4: An example of how the interactive Bloom perspective can visualize the database.. 20.

(29) 5. Discussion. In this chapter, discussion about the method and result is presented as well as a brief discussion of the ethics and concerns regarding informational security for a system designed to monitor an entire network.. 5.1. Results. In this section, the packet miner, database handler and database is discussed along with why the system contributes to increased knowledge of networks and subnetworks.. 5.1.1. Passive Asset Detection System. Increasing the understanding of a network can mean different things in different settings. One might want to transition from keeping a manual inventory of company devices to an automated system that observes, labels and reports about new and recurring devices. In this setting the increased understanding comes from the added benefit of seeing every single devices that is on a network, even the ones who are not supposed to be there. Additionally, information about devices will be continuously updated over time which otherwise would require another round of manual inspection. A second way that the system can lead to increased understanding of a network is because of its fully passive trait. By running a fully active detection solution like the ones mentioned in section 2.1.1, some devices with malicious intent will know what type of analysis or detection method to expect by monitoring the probes sent out by active detection systems. The most obvious use of the probes are to fingerprint devices by the response they return to the sender. However, if a device is keen on staying hidden they can also fingerprint the probes and return specifically tailored data to fool the active detection system. Thus, when a fully passive detection system incorporates all the components mentioned in this report, it is far from trivial for a potential attacker to hide without being flagged or spotted as they would never know what parameters are being monitored. Especially if the goal is, like with this thesis, to have full informational coverage and analyze exactly all data that passes the point of interest.. 21.

(30) 5.1. Results The third, and perhaps the biggest, advantage is the topology and communication information that is gained along side the device based information. On a general level, the entire network will be properly sectioned in to its actual subnetworks which, on both a visual and informational level, sometimes yields information capable of detecting devices that are either misplaced or have a malicious intent without even looking for such a device specifically. Additionally, as all devices and their communication patterns are also recorded, it can be equally trivial to see if a device is communicating with another device, both inside and outside of the network, that it is not intended to communicate with and take actions accordingly. Lastly, the system can also be used as a confirmation tool alongside already existing tools used to monitor a network. If a tool reports problems regarding a device within a network, the system described in this thesis can be used to gain an understanding of the device and, depending on what the reported problem is, it can either display detailed information about the device which might indicate if the problem is a false positive or it can directly point at the problem and thus confirming the problem reported by the other tool.. 5.1.2. Protocols and Data. The protocols supported by the system were chosen based on whether they provided direct or indirect information about a certain network or device attribute with a slight prioritization on direct information gain. As an example, protocols that provided direct information about routers within a network such as ICMP, ICMPv6 and DHCP were complimented by indirect information sources such as TCP and UDP. Whilst TCP and UDP does not contain any information about routers as is, together with direct indicators, they help strengthen the assumption about a specific device being a router by monitoring the source and destination address of all packets sent using TCP and UDP over time. This logic can be applied to most types of identification and labeling done by the system albeit not currently supported for all attributes.. 5.1.3. Packet Miner and Database Handler. For the purpose of this thesis, there is a clear advantage of merging the packet miner and database handler, using a low level language that also performs well when talking to the database over the Bolt protocol. One could implement a custom Neo4j Driver in C++ and making use of the modern language features implemented in C++17-23 and thus merging the database handler into the packet miner. Another alternative would be to rewrite both the packet miner and the database handler in another language like Rust that already has packet parsing capabilities along with a Neo4j driver. The two major benefits of combining the components into one is described below: • Merging the components removes the need for an entire section of code that revolves around creating and reading custom files from two different components. Currently, if data from a protocol should be inserted into the database, it has to be implemented both in the file creating logic of the packet miner and the file reading logic of the database handler. This both increases the amount of work needed to implement new features and the chance of erroneous read-write operations. • Merging the components completely removes the overhead of the current inter-process communication method using input and output files. A merged component could leverage data already loaded into main memory to speed up execution and reduce the amount of overhead. Although, developing the packet miner and database handler as two separate components means, even if they are designed to work together, that they could be run as separate entities. For the packet miner, this means that it could also be used as a customizable data 22.

(31) 5.2. Method extraction tool for use in any other analytical software that allows importing of external data. However, the database handler becomes meaningless as a standalone tool as it requires a specific type of input to produce a specific type of output and therefore cannot be adapted to work in a different system without changes in both the import and export logic.. 5.2. Method. In this section potential development problems and hurdles are discussed along with why, out of the many existing protocols, the protocols presented in this thesis were the choice of initial implementation.. 5.2.1. Packet Miner and Protocol Selection. The system was developed using a methodology similar to test-driven development (TDD). This means that protocols were identified and implemented depending on what type of information the system needed. An example of this is router discovery, where the need for labeling routers arose and the goal was set to be able to pin-point which devices within the network were routers. After establishing the need for router discovery, protocols containing information regarding what devices might be routers or what type of meta information could point to a device being a router was researched. After identifying which protocols would, directly or indirectly, give information about routers within the network, parsing of such protocols were implemented, the database handler was updated to support such protocols and lastly the Bloom perspectives were updated to visualize the new information. One problem with development using this methodology is that the system will lack capabilities in identifying device or network characteristics that have not specifically been targeted without adding entirely new protocols or updating the already existing perspectives. Another caveat with the system is adaptability to different types of networks. The first thing that comes to mind is examples like industrial control systems (ICS) that sometimes use very specific types of protocols and communication patterns. There exists protocols that contain a great deal of information about ICS devices, but those protocols are also rendered useless within a different type of network, like the ones presented in section 3.2 and vice versa. Thus, protocols that were overly specific were simply ignored during development, even if they could have contributed with information regarding a specific development goal.. 5.3. The Work in a Wider Context. When developing a system that constantly and continuously monitors devices within a network it is important to discuss informational security and ethics. As the system mines all packets that passes each point of interest, it could under certain circumstances gain access to information that, from an asset detection perspective, is irrelevant to gain further understanding of the network but could instead be mapped to the user of the device. However, as this tool is intended to be used as a monitoring tool by actors authorized to do so by the owners of each individual network, the risk of misuse from an ethical perspective is very low. To gain full understanding of a network and all devices within it, the person using the system in bad faith must therefore have gained physical access, or at the very least have gained full remote access, to one or more devices within a network that is already conducting tapping. Therefore, from a security and ethics perspective, the system presented in this thesis does not lead to an increased risk of informational infringement compared to any other network analysis tool that is already in wide use today.. 23.

(32) 6. Conclusion. The aim of the thesis was to develop a fully passive asset detection system using data collected from multiple network protocols to strengthen predictions about the network. Individual devices, device-to-device communication and network topology are three major informational components that can be viewed when running the system for an extended period of time.. 6.1. Research Questions. Which network packet data is meaningful to analyze in a passive asset detection system in order to strengthen assumptions made over time? Information about a device or subnetwork can either be gained through protocols that directly supply such information or by protocols that, complemented with a direct source, contribute with indirect information over a longer period of time. By including time as a fundamental component to device and subnetwork enumeration and labeling, the amount of available data sources increase, and thus also increases the amount of meaningful data that can be used to strengthen assumptions about devices, subnetworks and networks. How can a passive asset detection system be designed to handle networks consisting of one or more subnetworks? By either recording traffic into pcap files or directly running the miner in tap mode at the point closest to the end devices for each individual subnetwork, information about an entire network can be acquired. Each subnetwork is then seamlessly integrated into the same database using information about where the data was collected within the network and thus gives a topology overview of the entire network in combination with detailed information about each and every device on the network. How can the passive asset detection system lead to an increased understanding of the network? The system aims to provide detailed information about a network over a longer period of time. By including information acquired during events like device startup, reboot or renewals 24.

(33) 6.2. Future Work which might not happen once per day but instead once per week, month or even longer periods of time, additional assumptions can be made about one or more devices on the network. Assumptions that are made using information seen only once using a single source could lead to a chain of incorrect assumptions about a device or network. Additionally, by using the Bloom visualizer, relationships or issues that might not have been spotted by the system can instead be spotted by an operator and allow for appropriate incident response, if deemed necessary.. 6.2. Future Work. This section can be broken down into two parts. The first part contains potential improvements to the system and its components including the inter-process communication. The second part describes improvements to the analytical part of the system and how it makes assumptions about devices, subnetworks and networks.. 6.2.1. System Components. The biggest improvement to the system would be to move the database handler into the same component as the miner. That means, instead of having the packet miner and database handler be two separate components linked together by inter-process communication, the handler is merged into the miner to simplify communication and increase throughput. Potentially, this could be done by merging the components into one and rewriting it in Rust to make use of the safe concurrency, native support of constructs used in networking, such as IP addresses, and a simplified way of communicating with the database using the Bolt protocol which is native to Neo4j.. 6.2.2. Increased Information Gain. The biggest informational gain would be to implement parsing for more protocols that exist in the wild. There exists a plethora of protocols containing small bits of information that, together with information from other protocols, can help strengthen assumptions made about devices or networks. As mentioned briefly in the theoretical section, even the existence of a protocol can help pointing the system in the right direction for future assumptions. Additionally, improving the way that the system uses previously made assumptions to strengthen future assumptions by implementing a proper scoring/weighting system would improve the reliability of the assumptions. On the topic of OS detection, which is covered briefly, a properly trained and tuned machine learning algorithm would help improving the correctness of OS labels that are given to devices and could tie into the improved scoring/weighting system.. 25.

(34) Bibliography. [1]. Steve Alexander and Ralph Droms. DHCP Options and BOOTP Vendor Extensions. RFC 2132. RFC Editor, Mar. 1997. URL: http://www.rfc-editor.org/rfc/rfc2132. txt.. [2]. Blake Anderson and David McGrew. “OS fingerprinting: New techniques and a study of information gain and obfuscation”. In: 2017 IEEE Conference on Communications and Network Security (CNS). IEEE. 2017, pp. 1–9.. [3]. Renzo Angles. The Property Graph Database Model. 2018.. [4]. Ofir Arkin. “Network scanning techniques”. In: Publicom Communications Solutions (1999).. [5]. Sergei Bantseev and Isabelle Labbé. Study of tools for network discovery and network mapping. Tech. rep. COMMUNICATIONS RESEARCH CENTRE OTTAWA (ONTARIO), 2003.. [6]. David Barroso Berrueta. A practical approach for defeating Nmap OS-Fingerprinting. 2003.. [7]. Robert Beverly. “A robust classifier for passive TCP/IP fingerprinting”. In: International Workshop on Passive and Active Network Measurement. Springer. 2004, pp. 158–167.. [8]. Robert Braden et al. Requirements for internet hosts–communication layers. Tech. rep. 1989.. [9]. Claude Chaudet, Eric Fleury, Isabelle Guérin Lassous, Hervé Rivano, and Marie-Emilie Voge. “Optimal positioning of active and passive monitoring devices”. In: Proceedings of the 2005 ACM conference on Emerging network experiment and technology. 2005, pp. 71– 82.. [10]. Alex Conta, Stephen Deering, and Mukesh Gupta. Internet control message protocol (icmpv6) for the internet protocol version 6 (ipv6) specification. Tech. rep. RFC 4443, March, 2006.. [11]. M Cotton, L Vegoda, R Bonica, and B Haberman. Special-purpose IP address registries. Tech. rep. 2013, pp. 2070–1721.. [12]. A Crenshaw. OSfuscate: change your windows OS TCP/IP fingerprint to confuse P0f, NetworkMiner, ettercap, Nmap and other OS detection tools. 2008.. [13]. Steve Deering, Robert Hinden, et al. Internet protocol, version 6 (IPv6) specification. Tech. rep. 2017.. 26.

(35) Bibliography [14]. Ralph Droms. Dynamic Host Configuration Protocol. RFC 2131. RFC Editor, Mar. 1997. URL : http://www.rfc-editor.org/rfc/rfc2131.txt.. [15]. R. Fielding, Y. Lafon, and J. Reschke. Hypertext Transfer Protocol (HTTP/1.1): Range Requests. RFC 7233. RFC Editor, June 2014. URL: http://www.rfc-editor.org/rfc/ rfc7233.txt.. [16]. R. Fielding, M. Nottingham, and J. Reschke. Hypertext Transfer Protocol (HTTP/1.1): Caching. RFC 7234. RFC Editor, June 2014. URL: http://www.rfc- editor.org/ rfc/rfc7234.txt.. [17]. R. Fielding and J. Reschke. Hypertext Transfer Protocol (HTTP/1.1): Authentication. RFC 7235. RFC Editor, June 2014. URL: http://www.rfc-editor.org/rfc/rfc7235. txt.. [18]. R. Fielding and J. Reschke. Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. RFC 7232. RFC Editor, June 2014. URL: http : / / www . rfc - editor . org / rfc / rfc7232.txt.. [19]. R. Fielding and J. Reschke. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. RFC 7230. RFC Editor, June 2014. URL: http://www.rfc- editor.org/ rfc/rfc7230.txt.. [20]. R. Fielding and J. Reschke. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. RFC 7231. RFC Editor, June 2014. URL: http : / / www . rfc - editor . org / rfc / rfc7231.txt.. [21]. Behrouz A Forouzan and Sophia Chung Fegan. TCP/IP protocol suite. McGraw-Hill Higher Education, 2010.. [22]. Luis Martin Garcia. “Programming with libpcap-sniffing the network from our own application”. In: Hakin9-Computer Security Magazine 2 (2008), p. 2008.. [23]. Google. Protecting users from insecure downloads in Google Chrome. Feb. 2020. URL: https : / / blog . chromium . org / 2020 / 02 / protecting - users - from insecure.html. (Accessed: 2021-04-15).. [24]. Network Working Group et al. “Protocol standard for a Netbios service on a tcp/udp transport: concepts and methods”. In: IETF RFC 1001 (1987).. [25]. Nelson E Hastings and Paul A McLean. “TCP/IP spoofing fundamentals”. In: Conference Proceedings of the 1996 IEEE Fifteenth Annual International Phoenix Conference on Computers and Communications. IEEE. 1996, pp. 218–224.. [26]. IEEE. IEEE SA - MAC Infographic. URL: https : / / standards . ieee . org / products-services/regauth/mac.html. (Accessed: 2021-03-02).. [27]. Neo4j Inc. Neo4j Python Driver. URL: https://neo4j.com/docs/api/pythondriver/current/. (Accessed: 2021-03-11).. [28]. Mats Erik Klepsland. “Passive Asset Detection using NetFlow”. MA thesis. 2012.. [29]. Martin Lastovicka, Tomas Jirsik, Pavel Celeda, Stanislav Spacek, and Daniel Filakovsky. “Passive os fingerprinting methods in the jungle of wireless networks”. In: NOMS 20182018 IEEE/IFIP Network Operations and Management Symposium. IEEE. 2018, pp. 1–9.. [30]. Xiaofan Lu, Weijia Sun, and Huiping Li. “Design and research based on WinPcap network protocol analysis system”. In: 2010 International Conference on Computer, Mechatronics, Control and Electronic Engineering. Vol. 1. IEEE. 2010, pp. 486–488.. [31]. Shahar Markovitch and Paul Willmott. “Accelerating the digitization of business processes”. In: McKinsey-Corporate Finance Business Practise (2014), pp. 1–4.. 27.

(36) Bibliography [32]. Chris Mavrakis. “Passive asset discovery and operating system fingerprinting in industrial control system networks”. In: Wayback archive: http://web.archive.org/web/20190307110951/ https://pure.tue.nl/ws/files/46916656/8401711.pdf (2015), pp. 840171–1.. [33]. Mozilla. Deprecating Non-Secure HTTP. Apr. 2015. URL: https : / / blog . mozilla . org/security/2015/04/30/deprecating- non- secure- http/. (Accessed: 2021-04-15).. [34]. T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, and T. Winters. Dynamic Host Configuration Protocol for IPv6 (DHCPv6). RFC 8415. RFC Editor, Nov. 2018.. [35]. Neo4j. What is a Graph Database? 2021. URL: https : / / neo4j . com / developer / graph-database/. (Accessed: 2021-04-15).. [36]. J. Postel. Internet Control Message Protocol. STD 5. RFC Editor, Sept. 1981. URL: http: //www.rfc-editor.org/rfc/rfc792.txt.. [37]. Jon Postel. Transmission Control Protocol. STD. RFC Editor, Sept. 1981. URL: http:// www.rfc-editor.org/rfc/rfc793.txt.. [38]. Jon Postel et al. User datagram protocol. STD. 1980. URL: https://www.rfc-editor. org/rfc/rfc768.txt.. [39]. Open Source. Passive Real-time Asset Detection system. URL: https://github.com/ gamelinux/prads. (Accessed: 2021-04-23).. [40]. Sean Whalen. “An introduction to arp spoofing”. In: Node99 (2001).. [41]. Jeff C Wu. Automatic discovery of network elements. US Patent 5,185,860. Feb. 1993.. 28.

(37)

No results found