Military Communications and Information Technology: A Trusted ...
Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...
396 Military Communications and Information Technology... In this paper, we identify cornerstones of the protocol design for future botnets. Besides using peer-to-peer-based mechanisms to avoid a single point of failure, they will employ cryptographic methods that are also used in many legitimate applications. Particularly, their command and control channel will use strong encryption and integrity checks to prevent reading or altering messages in transit and authentication for commands and updates. As a side effect, messages will no longer be available to network intrusion detection systems that rely on deep packet inspection, i.e. analyse packet payloads to detect the presence of malicious applications. Since this is the main mode of operation for most deployed network intrusion detection systems, we also analyse which properties cannot be obscured by these methods and explore how they can be used to achieve botnet detection in the future. The rest of this paper is organised as follows. In section II, we provide the definitions for netflows and botnets as a base for the following elaboration. The next section briefly discusses related approaches, followed by our analysis of future botnet designs in section IV. Section V provides the background for the detection of botnets by measuring features described in section VI. We then briefly summarise the host models required for our projected approach and provide measurement results for the named features. In sections IX and X, we provide an outlook on future work and summarise the conclusions derived in this paper. II. Background A. Netflows Typically, network protocols are developed following the OSI layer model, encapsulating higher level protocols in the payload section of the next lower layer’s protocol. In inter-networking, OSI layers 3 and 4 are of particular concern, where the former is responsible for transferring data between hosts in different networks and the latter provides services such as error correction or packet reordering to applications on those hosts. Nowadays, the only wide-spread implementations for layer 3 are the IP protocol versions 4 and and 6 (IPv4 and IPv6, respectively) and layer 4 is dominated by the TCP and UDP protocols. Applications using the latter protocols are identified by a 16 bit integer (or port), i.e. a tuple (IP address, type, port) identifies an endpoint that a particular application instance on a particular host may send or receive data at. Given two applications A and B communicating through a network, the conversation can be identified by a combined tuple (IP A , port A , type, port B , IP B ). Such a conversation is called a “netflow” or a flow for short. B. Botnets For the purpose of this paper, we define a botnet as a malware with access to a command and control (C 2 ) channel allowing a group or an individual to is-
Chapter 4: Information Assurance & Cyber Defence 397 sue commands to an infected system. While such a channel could use a different medium in theory, we further narrow this definition down to such botnets where the C 2 channel is implemented using the Internet or a similar wide area network. This is the case for all botnets deployed for commercial purposes and, while apparently designed to bridge an air-gapped system, even the Stuxnet malware provided an Internet-based C 2 channel [2]. We will use the term bot herder when referring to the group or individual controlling a botnet, without any further implications on how or why the herder acquired control over the botnet. III. Related literature Detecting botnets can be considered a special case of network-based intrusion detection. The most prominent examples in that field are Bro, first presented in [3], and Snort [4]. While allowing different levels of complexity for defining signatures, both are focused on discovering known malicious packet payloads described by the user. To some extent, an administrator with deep insight into the environment and applications she or he supervises may define signatures that describe abusive behaviour but generally this technique can only be used when the payload generated by a particular piece of malicious software is known to the user. [5] alleviates this requirement by introducing a system that is able to generate signatures from malware communication patterns learned from repeatedly executing a sample in a secure environment. However, in order to be able to generate a signature, an infection has to be detected and a sample of the malware be obtained first. Gu et al. follow a different approach [6], collecting data for each system in two domains, one for netflow data and another one for malicious activities. They then cluster data in each of these domains individually and treat co-occurrences of hosts in activity and netflow clusters as an indicator for those hosts being part of a botnet. While this eliminates the requirement for obtaining a sample for a malware, obtaining data for malicious activity requires the ability to detect such activity. I.e. while their approach shifts the focus, it will still work only when the attacks a botnet will carry out have been analysed and described appropriately before. The authors of [7] introduce an approach which measures several features for each observed flow. Based on their assumption that these features are normally distributed, they are able to assign an anomaly score to a measurement and visualise the expectation and actual measurement for a system. In contrast to the approaches described above, this does not require any knowledge of a malware that should be detected, but requires that both the distribution for an observed feature is Gaussian and that it will be affected by the malware’s traffic. Thus, feature selection is a critical element, as underlined by the author’s statement that for features with a distribution not fit well by a Gaussian curve, the accuracy of their approach was not satisfying.
- Page 347 and 348: Federated Cyber Defence System - Ap
- Page 349 and 350: Chapter 4: Information Assurance &
- Page 351 and 352: Chapter 4: Information Assurance &
- Page 353 and 354: Chapter 4: Information Assurance &
- Page 355 and 356: Chapter 4: Information Assurance &
- Page 357: Chapter 4: Information Assurance &
- Page 360 and 361: 360 Military Communications and Inf
- Page 362 and 363: 362 Military Communications and Inf
- Page 364 and 365: 364 Military Communications and Inf
- Page 366 and 367: 366 Military Communications and Inf
- Page 368 and 369: 368 Military Communications and Inf
- Page 370 and 371: 370 Military Communications and Inf
- Page 372 and 373: 372 Military Communications and Inf
- Page 374 and 375: 374 Military Communications and Inf
- Page 377 and 378: Development of High Assurance Guard
- Page 379 and 380: Chapter 4: Information Assurance &
- Page 381 and 382: Chapter 4: Information Assurance &
- Page 383 and 384: Chapter 4: Information Assurance &
- Page 385 and 386: Chapter 4: Information Assurance &
- Page 387 and 388: Chapter 4: Information Assurance &
- Page 389 and 390: Chapter 4: Information Assurance &
- Page 391 and 392: Chapter 4: Information Assurance &
- Page 393 and 394: Chapter 4: Information Assurance &
- Page 395: Network Traffic Characteristics for
- Page 399 and 400: Chapter 4: Information Assurance &
- Page 401 and 402: Chapter 4: Information Assurance &
- Page 403 and 404: Chapter 4: Information Assurance &
- Page 405 and 406: Chapter 4: Information Assurance &
- Page 407 and 408: Chapter 4: Information Assurance &
- Page 409 and 410: Chapter 4: Information Assurance &
- Page 411 and 412: Chapter 4: Information Assurance &
- Page 413 and 414: Chapter 4: Information Assurance &
- Page 415 and 416: Methodology for Gathering Data Conc
- Page 417 and 418: Chapter 4: Information Assurance &
- Page 419 and 420: Chapter 4: Information Assurance &
- Page 421 and 422: Chapter 4: Information Assurance &
- Page 423 and 424: Chapter 4: Information Assurance &
- Page 425 and 426: Chapter 4: Information Assurance &
- Page 427 and 428: Chapter 4: Information Assurance &
- Page 429: Chapter 4: Information Assurance &
- Page 432 and 433: 432 Military Communications and Inf
- Page 434 and 435: 434 Military Communications and Inf
- Page 436 and 437: 436 Military Communications and Inf
- Page 439 and 440: On Multi-Level Secure Structured Co
- Page 441 and 442: Chapter 4: Information Assurance &
- Page 443 and 444: Chapter 4: Information Assurance &
- Page 445 and 446: Chapter 4: Information Assurance &
396 <strong>Military</strong> <strong>Communications</strong> <strong>and</strong> <strong>Information</strong> <strong>Technology</strong>...<br />
In this paper, we identify cornerstones of the protocol design for future botnets.<br />
Besides using peer-to-peer-based mechanisms to avoid a single point of failure, they<br />
will employ cryptographic methods that are also used in many legitimate applications.<br />
Particularly, their comm<strong>and</strong> <strong>and</strong> control channel will use strong encryption<br />
<strong>and</strong> integrity checks to prevent reading or altering messages in transit <strong>and</strong> authentication<br />
for comm<strong>and</strong>s <strong>and</strong> updates. As a side effect, messages will no longer be<br />
available to network intrusion detection systems that rely on deep packet inspection,<br />
i.e. analyse packet payloads to detect the presence of malicious applications. Since<br />
this is the main mode of operation for most deployed network intrusion detection<br />
systems, we also analyse which properties cannot be obscured by these methods <strong>and</strong><br />
explore how they can be used to achieve botnet detection in the future.<br />
The rest of this paper is organised as follows. In section II, we provide the definitions<br />
for netflows <strong>and</strong> botnets as a base for the following elaboration. The next<br />
section briefly discusses related approaches, followed by our analysis of future botnet<br />
designs in section IV. Section V provides the background for the detection of botnets<br />
by measuring features described in section VI. We then briefly summarise the host<br />
models required for our projected approach <strong>and</strong> provide measurement results for<br />
the named features. In sections IX <strong>and</strong> X, we provide an outlook on future work<br />
<strong>and</strong> summarise the conclusions derived in this paper.<br />
II. Background<br />
A. Netflows<br />
Typically, network protocols are developed following the OSI layer model,<br />
encapsulating higher level protocols in the payload section of the next lower layer’s<br />
protocol. In inter-networking, OSI layers 3 <strong>and</strong> 4 are of particular concern, where<br />
the former is responsible for transferring data between hosts in different networks<br />
<strong>and</strong> the latter provides services such as error correction or packet reordering to<br />
applications on those hosts. Nowadays, the only wide-spread implementations for<br />
layer 3 are the IP protocol versions 4 <strong>and</strong> <strong>and</strong> 6 (IPv4 <strong>and</strong> IPv6, respectively) <strong>and</strong><br />
layer 4 is dominated by the TCP <strong>and</strong> UDP protocols.<br />
Applications using the latter protocols are identified by a 16 bit integer (or port),<br />
i.e. a tuple (IP address, type, port) identifies an endpoint that a particular application<br />
instance on a particular host may send or receive data at. Given two applications<br />
A <strong>and</strong> B communicating through a network, the conversation can be identified<br />
by a combined tuple (IP A , port A , type, port B , IP B ). Such a conversation is called<br />
a “netflow” or a flow for short.<br />
B. Botnets<br />
For the purpose of this paper, we define a botnet as a malware with access<br />
to a comm<strong>and</strong> <strong>and</strong> control (C 2 ) channel allowing a group or an individual to is-