See discussions, stats, and author profiles for this publication at: [Link]

net/publication/304605252

A deception based approach for defeating OS and service fingerprinting

Conference Paper · September 2015

DOI: 10.1109/CNS.2015.7346842

CITATIONS READS
39 3,700

3 authors:

Massimiliano Albanese Ermanno Battista

George Mason University University of Naples Federico II
136 PUBLICATIONS 2,325 CITATIONS 18 PUBLICATIONS 254 CITATIONS

SEE PROFILE SEE PROFILE

Sushil Jajodia
George Mason University
872 PUBLICATIONS 40,019 CITATIONS

SEE PROFILE

All content following this page was uploaded by Massimiliano Albanese on 19 March 2018.

The user has requested enhancement of the downloaded file.

 2015 IEEE Conference on Communications and Network Security (CNS)

A Deception Based Approach for Defeating

OS and Service Fingerprinting

Massimiliano Albanese∗ , Ermanno Battista† , and Sushil Jajodia∗

∗ Center
for Secure Information Systems
George Mason University, Fairfax, VA 22030, USA
Email: {malbanes,jajodia}@[Link]
† Department of Electrical Engineering and Information Technology

University of Naples Federico II, Naples, NA 80125, Italy

Email: {[Link]}@[Link]

Abstract—Cyber attacks are typically preceded by a recon- services. Differently from many existing techniques, we do so
naissance phase in which attackers aim at collecting critical without changing the actual configuration of the system. In
information about the target system, including information about fact, our approach mainly consists in manipulating outgoing
network topology, services, operating systems, and unpatched traffic such that, not only important details about operating
vulnerabilities. Specifically, operating system fingerprinting aims systems and services are not revealed, but the traffic also re-
at determining the operating system of a remote host in either
a passive way, through sniffing and traffic analysis, or an active
sembles traffic generated by hosts and networks with different
way, through probing. Similarly, service fingerprinting aims at characteristics.
determining what services are running on a remote host. In Experiments conducted on a prototypal implementation
this paper, we propose an approach to defeat an attacker’s show that the overhead introduced by the proposed approach is
fingerprinting effort through deception. To defeat OS fingerprint- negligible, thus rendering this solution completely transparent
ing, we manipulate outgoing traffic so that it resembles traffic to legitimate users. At the same time, our approach can
generated by a host with a different operating system. Similarly, effectively deceive the attackers, and steer them away from
to defeat service fingerprinting, we modify the service banner by critical resources we wish to protect.
intercepting and manipulating certain packets before they leave The remainder of the paper is organized as follows.
the host or network. Experimental results show that our approach Section II introduces the technical background behind our
can efficiently and effectively deceive an attacker.
work, and discusses several fingerprinting tools an attacker
may use. Section III presents our approach to defeating these
I. I NTRODUCTION tools, whereas Section IV provides a detailed description of
Cyber attacks are typically preceded by a reconnaissance a preliminary implementation of our approach. Section V
phase in which attackers aim at collecting valuable infor- presents the results of our experiments. Finally, Section VI
mation about the target system, including information about discusses related work and Section VII gives some concluding
network topology, service dependencies, operating systems and remarks.
unpatched vulnerabilities. Unfortunately, when system config-
urations are static, attackers will always be able, given enough II. T ECHNICAL BACKGROUND
time, to acquire accurate knowledge about the target system,
which in turn enables them to engineer effective attacks. To Operating System (OS) fingerprinting is the practice of
address this problem, many adaptive techniques have been determining the operating system of a remote host on a
devised to dynamically change some aspects of a system’s network. This may be accomplished either passively – by
configuration or attack surface in order to introduce uncertainty sniffing and analyzing network packets traveling between hosts
for the attacker [1], [2]. A system’s attack surface has been – or actively – by sending carefully crafted packets to the target
defined as the “subset of the system’s resources (methods, host and analyzing the responses [4].
channels, and data) that can be potentially used by an attacker
Active fingerprinting approaches are typically more sophis-
to launch an attack” [3]. Dynamically altering or shifting a
ticated than passive fingerprinting. In the simplest scenario,
system’s attack surface has proven to be an effective strategy
the attacker does not resort to stealth techniques and gathers
to thwart or significantly delay attacks. However, this type of
information about the OS by trying to connect to the host.
approaches can potentially introduce significant overhead for
For instance, while establishing a connection via the standard
the defender.
Telnet or SSH protocol, the OS version is often sent to
In this paper, we go beyond simply introducing uncertainty
the client as part of a welcome message. Moreover, some
for the attacker, and propose an approach to deceive potential
FTP server implementations allow to retrieve this information
intruders into making incorrect inferences about important
through the SYST command.
system characteristics, including operating systems and active
In general, active fingerprinting techniques trigger the
This work was partially supported by the Army Research Office under grants
W911NF-13-1-0421, W911NF-09-1-0525, and W911NF-13-1-0317, and by target into sending one or more responses, which are then
the Office of Naval Research under grants N00014-12-1-0461 and N00014- analyzed by the attacker to infer the type and version of the OS
13-1-0703 installed on the remote host. Carefully crafted ICMP, TCP and

978-1-4673-7876-5/15/$31.00 ©2015 IEEE 253

 2015 IEEE Conference on Communications and Network Security (CNS)

TABLE I. OS- DEPENDENT IP AND TCP PARAMETERS

ports on the target host [5]. These probes are specially de-
Operating System IP Initial TTL TCP Window Size signed to exploit the differences in the way different operating
Linux Kernel 2.4/2.6 64 5,840 systems implement aspects of the protocols where standard
Windows XP 128 65,535 specifications leave some degree of freedom to developers.
Windows 7 128 8,192 After sending probes, Nmap listens for responses. Dozens of
attributes in those responses are analyzed and combined to
generate a fingerprint.
UDP packets are sent to the target in order to observe how it A series of 6 TCP probes is sent to generate 4 test response
responds to both valid and invalid packets. For instance, in the lines used for gathering information about sequence number
case of TCP probes, features that can be used to distinguish generation. Then an ICMP test follows. This test involves
between different operating systems include: (i) the order in sending two ICMP echo request packets to the target. The
which the TCP Options are formatted and (ii) the total length results of these two probes are combined. Then 6 TCP tests
of TCP Options. Additionally, the IP header may reveal some follow. The last test is an UDP packet sent to a closed port. The
information about the nature of the OS. character “C” (0x43) is repeated 300 times in the data field. If
Conversely, passive fingerprinting consists in using a the port is truly closed and there is no firewall in place, Nmap
packet sniffer to passively collect and analyze packets traveling expects to receive an ICMP port unreachable message.
between hosts. A simple passive method consists in inspecting Limitations: The probes are well known, so they can be
the Time To Live (TTL) field in the IP header and the TCP identified and filtered. The Nmap approach is flawed by design
Window Size of the SYN or SYN+ACK packet in a TCP [6]. If the target is behind multiple filtering devices, each with
session. The values of both the initial TTL and the TCP a different configuration policy, the attacker may end up with
Window Size depend on the specific OS implementation, as a signature that is built using responses generated by different
shown in Table I. One reason for this is that RFC specifications systems. For instance, assume the first filtering device – instead
define intervals of values and recommended values, but do not of the true target – answers to TCP SYN+ACK packets with
mandate specific values. For instance, RFC 1700 recommends TCP RST+ACK and also spoofs the IP address of the true
to initialize TTL to 64. Of course, relying only on the TTL target: the attacker will then derive a signature that is built
value is not sufficient to determine the OS because, given with some packets sent by the true target and other packets
the nature of this parameter, the TTL decreases as a packet sent by different systems.
traverses the network, and inferring the correct initial TTL
may not always be possible. 2) SinFP3: The development of SinFP was prompted by
the need to reliably identify a remote host’s operating system
Many different fingerprinting tools are available today. under worst-case network conditions [6]. Worst-case network
To better assess the impact of the approach presented in conditions can be assumed to be characterized by the following
this paper, we have defined a taxonomy to classify existing facts: (i) only one TCP port is open; (ii) traffic to all other TCP
fingerprinting tools based on the different approaches they and UDP ports is dropped by filtering devices; (iii) stateful
implement. Figure 1 shows the proposed taxonomy. Given the inspection is enabled on the open port; and (iv) filtering devices
variety of existing tools, it is practically impossible to develop with packet normalization are in place. In this scenario, only
a single technique that would defeat all of them. However, the standard probe packets that use the TCP protocol can reach
proposed approach is effective against the most widely used the target and elicit a response packet.
fingerprinting tools. The tools that we explicitly target in our
work are shown in boldface, whereas other tools that are at SinFP uses three probes: the first probe P1 is a standard
least partially impacted by our deception techniques are shown packet generated by the connect() system call, the second
with a colored background. probe P2 is the same as P1 but with different TCP Options,
and the third probe P3 has no TCP Options and has the TCP
Network Traffic p0f SYN and ACK flags set. The first two probes elicit two TCP
Passive
Analysis sinfp3 Nessus SYN+ACK responses from the target. The third probe has the
nmap
OS objective of triggering the target into sending a TCP RST+ACK
Banner Grubbing amap
Fingerprinting Application Level
Handshaking amap
response. After the three probes have been sent and the three
Active nmap replies have been received, a signature is built from the analysis
TCP Responses
TCP/IP Stack sinfp3 of the response packets. Then, a signature matching algorithm
Xprobe searches in a database for a corresponding operating system
nmap fingerprint.
ICMP Responses
Xprobe
ISN Analysis nmap The analysis of the responses considers both IPv4 headers1
Time Analysis cron-os and TCP headers. With respect to IPv4 headers, the following
fields are analyzed [6]:
Fig. 1. Taxonomy of OS fingerprinting tools
TTL: Some systems may use different initial TTL values for
different types of packets. Specifically, the initial TTL for
A. Fingerprinting Tools a TCP SYN+ACK may be different from the initial TTL
for a TCP RST+ACK. Therefore, the difference between
1) Nmap: Nmap OS fingerprinting works by sending up to
16 TCP, UDP, and ICMP probes to known open and closed 1 It also supports IPv6.

254
 2015 IEEE Conference on Communications and Network Security (CNS)

the TTL values of the responses to probes P2 and P3 can implement exactly the same TCP Options, nor in the same
be used in the computation of the fingerprint. order. Thus, when only the MSS option is in the TCP header,
ID: The ID of the request is compared to the ID of the the risk of misidentification is high. SinFP also suffers from
response. In the computation of the fingerprint, the fol- the same limitation of all knowledge-based fingerprinting tools.
lowing cases are considered: (i) the response’s ID is 0; Their capability to identify a system is limited by the existence
(ii) the response’s ID is the same as the request’s ID; (iii) of a corresponding fingerprint in the database.
the response’s ID is obtained by adding 1 to the request’s
ID. 3) Xprobe: Xprobe2 is an active operating system finger-
Don’t Fragment bit: Fingerprint computation considers printing tool with a different approach to OS fingerprinting.
whether the response has the Don’t Fragment bit set Xprobe2 relies on fuzzy signature matching and probabilistic
or not. guesses.
Limitations: It appears that Xprobe2 is not maintained
With respect to TCP headers, the following fields are analyzed anymore, with the last version released in 2005. As a
[6]: consequence, it can only be used to scan outdated legacy
systems. Tested against a Ubuntu 12.04 machine (Kernel
Sequence number: The TCP sequence number of the request version 3.02), it returns Running OS: "Linux Kernel
is compared with the sequence number of the response. 2.4.22" (Guess probability: 100%). Tested
In the computation of the fingerprint, the following cases against a Windows 7 machine (with no firewall), it returns
are considered: (i) the response’s sequence number is 0; Running OS: "Microsoft Windows 2003 Server
(ii) the response’s sequence number is the same as the Standard Edition" (Guess probability:
request’s sequence number; (iii) the response’s sequence 93%).
number is obtained by adding 1 to the request’s sequence
number. 4) p0f: p0f (v3) is a tool that utilizes an array of sophisti-
Acknowledgment number: The same analysis as for the se- cated, purely passive traffic fingerprinting mechanisms to iden-
quence number is applied. tify the players behind any incidental TCP/IP communication
TCP flags and TCP window size: They are used as part of [7]. Its fingerprint contains:
the signature.
TCP Options: They are also used as part of the signature. 1) ver: IP protocol version.
Specifically, if either the MSS (Maximum Segment Size) 2) ittl: Initial TTL used by the OS.
value or the Window Scale value are specified they are 3) olen: Length of IPv4 options or IPv6 extension headers.
used to create their own signature’s elements. 4) mss: Maximum Segment Size (MSS), if specified in TCP
Options.
An example of SinFP report against a Windows 7 target is 5) wsize: Window Size, expressed as a fixed value or a
reported in Figure 2. The packets exchanged during the scan multiple of MSS, of MTU, or of some random integer.
are shown in Figure 3. 6) scale: Window Scaling factor, if specified in TCP Op-
tions.
7) olayout: Comma-delimited layout and ordering of TCP
... Options, if any. Supported values: explicit end of options,
score 100: Windows: Microsoft: Windows: Vista (RC1)
score 100: Windows: Microsoft: Windows: Server 2008 no-op option, maximum segment size, window scaling,
score 100: Windows: Microsoft: Windows: 7 (Ultimate) selective ACK permitted, timestamp.
score 100: Windows: Microsoft: Windows: Vista 8) quirks: Comma-delimited properties observed in IP or
TCP headers.
9) pclass: Payload size.
Fig. 2. SinFP report against a Windows 7 host
Limitation: The initial TTL value is often difficult to
determine since the TTL value of a sniffed packet will vary
SinFP Web Server:80
depending on where it is captured. The sending host will set
[SYN] Seq:0; Win: 5840; MSS: 1460;
the TTL value to the OS’s default initial TTL value, but this
1st Probe value will then be decremented by one for every router the
[SYN+ACK] Seq:0; Ack: 1; Win: 14600; MSS: 1460;
Response packet traverses on its way to the destination IP address. An
[SYN] Seq:0; Win: 5840; MSS: 1460; Timestamp; observed IP packet with a TTL value of 57 can therefore be
SAckPerm
2nd Probe expected to be a packet with an initial TTL of 64 that has
[SYN+ACK] Seq:0; Ack: 1; Win: 14480; MSS: 1460; done 7 hops before it was captured. Additionally, this tool
SAckPerm; Timestamp; WScale: 8
Response also suffers from the TCP Options entropy issue described for
SinFP.
Fig. 3. Packets exchanged during a SinFP scan
5) amap: Amap [8] is an application-level service finger-
printing tool that probes services running on a remote server on
Limitations: When there are too few TCP Options in P2’s a given port to identify the specific application that is listening
response, the signature’s entropy becomes weak [6]. In fact, on that port. Its purpose is to identify services that are not
TCP Options are the most discriminant characteristics that running on standard ports. Amap has a list of “triggers” which
compose a signature. That is because virtually no two systems include binary as well as text handshake messages.

255
 2015 IEEE Conference on Communications and Network Security (CNS)

Amap has been used as an indirect OS fingerprinting tool, os fingerprint ssh† Attempts to identify the remote OS from
meaning that it could infer the OS type from the services it is the SSH banner.
running [4]. It is worth noting that this approach relies heavily os fingerprint telnet† Attempts to identify the remote OS
on a direct match between the default application daemon and from the Telnet banner.
the underlying OS as it is inferring the nature of the OS rather os fingerprint uname If SSH credentials of the remote
than specifically testing it. UNIX hosts are provided, the results of ‘uname -a’ are
obtained.
Limitation: Amap is not very stealthy [4]: 11 parallel os fingerprint linux distro If SSH credentials of the remote
connections sending an unexpected message at the application Linux host are provided, the specific release is obtained.
protocol level are surely recorded in the application log file, os fingerprint xprobe† Attempts to identify the OS type and
provided that the application maintains a good logging level. version by sending more or less incorrect ICMP requests
Apart from logging at the application level, it is difficult to using the techniques outlined in [10].
detect an Amap probe since it uses the OS system calls to the
TCP/IP stack and therefore no signature can be found at the Each of these plugins reports a confidence level for their
level of the TCP, UDP or IP packets. Nevertheless, it is still scan results. An example of Nessus output for OS identification
possible to write IDS rules that are able to detect probes. is reported in Figure 4.
6) Nessus: Nessus provides a comprehensive analysis of a
target, including information about its OS and vulnerabilities. The remote host is running Linux Kernel 2.4
Nessus does not implement its own OS fingerprint mecha- Confidence Level : 70
nism but relies on the output of several different tools. It is Method : SinFP
interesting to study how Nessus performs the OS detection The remote host is running Linux Kernel 2.6
because each of the methods being used can also be adopted Confidence Level : 60
independently by an attacker. For instance, an attacker can Method : ICMP
perform a scan through nmap or Nessus, identify the open
ports and then use SinFP or other scripts to infer the operating
system listening on a specific port. Fig. 4. Nessus OS identification report

In the following we will use † to denote a method that Limitation: Nessus’s approach to fingerprinting can be
is likely to be adopted by an attacker who is targeting a very effective when used during a “credentialed” scan. Oth-
system behind a firewall and aims at discovering the target erwise, it will report partial information and in some cases it
OS fingerprint. will not use all the plugins it is equipped with. In the case
we are targeting a host behind a firewall and NAT translates
Tenable Research introduced a highly accurate form of port 22 to a server and port 80 to another, the Nessus result
operating system identification [9]. This method combines is likely to report only the OS information that has been
the outputs of various other plugins that execute separate gathered through the os fingerprint ssh plugin. Moreover, in
techniques to guess or identify a remote operating system. case the os fingerprint sinfp plugin is used, only the first entry
Specifically, this process takes inputs from the following other of SinFP’s result, which has a confidence level greater than
scripts, each reporting its own OS guessing: 70%, is reported. For instance, due to the fact that Windows
2008 Server, Windows Vista and Windows 7 share the same
os fingerprint ftp† Uses the remote FTP banner to attempt fingerprint, a Windows 2008 Server can be misidentified as a
to identify the underlying operating system. Window Vista host (see Figure 2).
os fingerprint html† Uses the HTML content returned by
certain HTTP requests to fingerprint the remote OS. Nessus’s approach to identify vulnerabilities is strictly de-
os fingerprint http† Uses the remote web server signature pendent on service banners and welcome messages. Generally,
to infer the version of the Windows or Linux distribution Nessus merely checks if the service’s version present in the
running on the remote host. service’s banner belongs to a certain interval. For instance,
os fingerprint mdns† If an mDNS server is present, will if a vulnerability is know to be present in a service up until
perform a highly accurate identification of Apple OS X version 2.0, it is really simple to make Nessus generate false
systems. negatives by exposing a fake service banner claiming that the
os fingerprint msrprc Identifies the remote version and ser- service version is higher than 2.0.
vice pack of Windows by making certain MSRPC re-
quests against the remote Windows box. III. S OLUTION D ESIGN
os fingerprint ntp Queries the Network Time Protocol dae-
mon to perform a highly accurate OS guess. With respect to OS fingerprinting, our approach to deceive
os fingerprint sinfp† Implements the SinFP TCP/IP finger- attackers relies on modifying outgoing traffic in a way that
printing algorithm. Only requires one open port to finger- such traffic resembles traffic generated by a different protocol
print an OS. stack implementation. As we pointed out in Section II, protocol
os fingerprint smb Identifies the remote Windows OS based specifications may leave some degrees of freedom to develop-
on a query to SMB. ers. The choices that a developer makes with respect to (i)
os fingerprint snmp If credentials are available to perform default values (e.g., initial TTL, size of the TCP window), (ii)
an SNMP query, data from the ‘sysDesc’ parameter is length of TCP Options, or (iii) order of the TCP Options may
reported. reveal the nature of the operating system or even the type of

256
 2015 IEEE Conference on Communications and Network Security (CNS)

device (e.g., firewall, switch, router, printer or general purpose However, this approach is not applicable to all cate-
machine). gories of services. Services that actively use the banner
information during the connection process (such as SSH)
All the information required to impersonate a certain
require us to use a non-transparent approach. For instance,
operating system or device can be extracted from the SinFP’s
the SSH protocol actively uses the banner information while
signature database. All the outgoing packets that may reveal
generating hashes in the connection phase. The banner
relevant information about the OS are modified to reflect the
format is “SSH-protocolversion-softwareversion
deceptive signature, as shown in Figure 5.
comments\r\n”. Even though this approach can deceive
DECEPTIVE SIGNATURE
tools like nmap and amap, modifying the banner will cause
General
TCP Flags TCP Window
TCP Options
MSS WScale
legitimate user to receive termination messages from the
Information Format
server3 such as: (i) Bad packet length or (ii) Hash Mismatch.
B11113 F0x12 W4344 O0204... M1460 S8

In summary, defeating passive tools requires to modify all

Version IHL Type of Service Total Length outgoing packets, whereas defeating active tools only requires
Identification xDM Fragment Offset
TTL Protocol Checksum IP
to alter those packets that are likely to be part of an attacker’s
Source Address Header
probes.
Destination Address
IP Options (Variable Length)
Kernel Module
Source Port
Sequence Number
Destination Port
IV. I MPLEMENTATION
Acknowledgment Number
Offset Reserv. CEUA
AP R S F Window
TCP
Header MODIFIED We implemented kernel modules that use the Netfilter
OUTGOING
Checksum Urgent Pointer PACKET POST ROUTING hook to process and modify relevant in-
TCP Options (Variable Length)
OUTGOING PACKET
formation in the IP header, TCP header and TCP payload.
Netfilter is a packet handling engine introduced in Linux Ker-
nel 2.4. It enables the implementation of customized handlers
Fig. 5. Manipulation of outgoing traffic to reflect deceptive signatures to redirect, reject or alter incoming and outgoing packets.
Netfilter can be extended with hooks. A hook is a function
The most critical step in this process is the manipulation handler that allows specific kernel modules to register callback
of the TCP Options. In order to present the attacker with a functions within the kernel’s network stack. A registered
deceptive signature, not only we need to modify some param- callback function is then called back for every packet that
eters, but we also need to reorder the options and correctly traverses the net filter stack. We used the POST ROUTING
place no-operation2 to obtain the right options length. The TCP hook to alter the packets just before they are finally sent out.
Options format can be inferred from the signature. Modifying Specifically, we implemented an operating system fin-
the Options length requires to adjust the total length field in the gerprint module to modify the responses to the SinFP’s
IP header, the Offset value in the TCP header and subsequently probes and a service fingerprint module to modify banner
adjust the sequence numbers. On the bright side, we noticed information for specific services.
that the majority of commonly used operating systems share
the same length for TCP Options. See Section V-B3 for some
A. Operating system fingerprint module
examples of deceptions that can be created with this method
even considering the case of different TCP Options lengths. The hook function checks if the packet is a response to
the first SinFP’s probe (P1): an ACK+SYN packet with a
With respect to service fingerprinting, we need to consider
length of 44 bytes (in the case of an underlying Linux Kernel
the following two cases: (i) the service banner can be modified
3.02). If this is the case, the packet is altered in order to
through configuration files, and (ii) the service banner is hard-
mimic a particular operating system (more details are provided
coded into the service executable. Being able to modify the
later), otherwise the module checks whether the packet is
packet carrying the identifying information before it leaves
an ACK+SYN with a length 60 bytes (in the case of an
the host (or the network) enables to successfully address both
underlying Linux Kernel 3.02). This packet is used in most
scenarios. Moreover, even if services are under our control,
TCP connections and may be a response to the second SinFP’s
we prefer to alter service banners in a completely transparent
probe (P2). If so, the packet is modified accordingly, based on
way. Our long term goal is to develop a network appliance
the target OS fingerprint.
that can be deployed at the network boundary and which is
able to transparently manipulate services and operating system Additionally, we verified that this approach can deceive the
fingerprints. p0f tool when we modify the TTL value of all IP packets and
the window size value of all TCP packets.
It is worth noting that, when the original service banner is
replaced with a deceptive banner of a different length, we need During the packet manipulation stage, we track whether
to: (i) adjust the size of the packet based on the difference in any of the following has been altered: the IP Header, the TCP
length between the two banners, (ii) modify the total length header, the length of TCP Options, the TCP payload or its
field in the IP header, (iii) modify the sequence numbers in size. Based on this information, we will:
order to be consistent with the actual amount of bytes sent,
and (iv) correctly handle the case of fragmented packets, which • modify the IP Total length value, if the size of the TCP
requires to reassemble a packet before modifying it. payload has changed;
2 As specified in RFC 793, this option code may be used between options, 3 Errors occurs only during the connection phase, and altering the banner
for example, to align the beginning of a subsequent option on a word boundary. will not affect previously established connections.

257
 2015 IEEE Conference on Communications and Network Security (CNS)

• recompute the TCP Offset value in the TCP header and 26 // it for re-injecting it in the right position later
the IP Total length, if the length of the TCP Options has 27 timestamp = get_tcp_timestamp();
28
changed; 29 set_id();
• recompute the TCP checksum, if the TCP header and/or 30 set_df_bit();
31 set_ittl();
the TCP payload have been altered; 32 set_tcp_window();
• recompute the IP checksum, if the IP header has been 33 set_tcp_flags();
altered. 34 set_tcp_sequence();
35 set_tcp_ack();
36
In order to modify the responses such that they appear to 37 if(new_option_len != option_len)
have been generated by a specific OS, we created a script that 38 {
39 modify_packet_size(); //expands or shrinks
(i) extracts the required characteristics of the responses to the 40 //packet and updates IP Lenght and Offset
first and second probe from SinFP’s signature database, and 41 }
42 set_tcp_options(timestamp, MSS, WScale, Option_Layout);
(ii) generates the C code necessary to alter the responses. The 43 }
script determines how the following policies should be set up: 44
45 if(tcpHeader_modified)
46 {
• ID policy: the ID could be a fixed value different from 47 tcp->check = 0;
zero, zero or a random number. 48 tcp->check = tcp_csum();
• Don’t fragment bit policy: the DF bit can be enabled or 49 }
50
disabled. 51 if(ipHeader_modified)
• Sequence Number policy: the sequence number can be 52 {
53 ip->check = 0;
zero or not altered. 54 ip->check = ip_csum();
• Ack Number policy: the ack number can be zero or not 55 }
altered.
Listing 1. OS deception kernel module
• TCP Flags policy: the TCP flags value is copied from
the signature.
• TCP Window Size policy: the Window size is copied
from the signature. B. Service Fingerprint Module
• TCP MSS Option policy: the MSS value is copied from In order to alter the service fingerprint, we modify the
the signature. banner sent by the application either at the time of establishing
• TCP WScale Option policy: the WScale is copied from a connection or in the header of each application-level protocol
the signature. data unit. Packets matching the service source port one wants
• TCP Options policy: the TCP Options layout is copied to protect are analyzed. If a packet contains data, the banner
from the signature. string is searched and subsequently replaced. When replacing
the banner, the packet size can vary: the packet is then resized
The generated code is then compiled in order to build according to the specific case. Listing 2 shows the sample
the actual kernel module. The scheme of the resulting kernel pseudo-code for the case of an Apache Server5 .
module is presented in Listing 14 . We assume that all the set
1 #define FAKE_APACHE_BANNER "Apache/1.1.23"
and get functions are able to access the packet and track if the 2 ...
IP or TCP header have been modified. 3 if (ntohs(tcph->source) == 80 && len > 0)
4 {
1 if(ip->protocol == TCP && ip->len == 44 && tcp->ack == 1 && 5 // Pointers to where to store the start and end address
tcp->syn == 1) 6 // of the Apache Banner String for substitution
2 { 7 char *b = NULL, *l = NULL;
3 //Probably 1st sinfp3’s probe Response 8
4 set_id(); 9 // Pointer to the TCP payload
5 set_df_bit(); 10 char *p= (char *)((char *)tcph+(uint)(tcph->doff*4));
6 set_ttl(); 11
7 12 b = strstr(p, "\r\nServer:"); //String Search
8 set_tcp_window(); 13 if (b != NULL) l = strstr( ((char *)b + 10), "\r\n");
9 set_tcp_flags(); 14
10 set_tcp_sequence(); 15 if (b != NULL && l != NULL)
11 set_tcp_ack(); 16 {
12 17 // b points to \r\nServer: x, so we add 10 to move to
13 if(new_option_len != option_len) 18 // the beginning of x
14 { 19 uint8_t signature_len = l - (b + 10);
15 modify_packet_size(); //expands or shrinks 20
16 //packet and updates IP Lenght and Offset 21 if (signature_len != (sizeof(FAKE_APACHE_BANNER)-1))
17 } 22 {
18 23 resize_packet();
19 set_tcp_options(MSS, WScale, Option_Layout); 24 }
20 } 25 copy(b + 10, FAKE_APACHE_BANNER,sizeof(
21 else if(ip->protocol == TCP && ip->len == 60 && tcp->ack == FAKE_APACHE_BANNER)-1);
1 && tcp->syn == 1) 26 }
22 { 27 ...
23 //Probably 2nd sinfp3’s probe Response 28 }
24
25 // Extract the timestamp value from the packet and save Listing 2. Service deception kernel module
4 We omit the code dealing with sequence numbers adjustment for reasons
of space. 5 For the sake of conciseness, we omit the code for checksum recomputation.

258
 2015 IEEE Conference on Communications and Network Security (CNS)

V. E VALUATION 70000
65000
A. Legitimate User Perspective 60000
In the first set of experiments, we evaluated our approach 55000
from the point of view of legitimate users interacting with 50000

Kb/s
the system being defended. Our goal is to make manipulation 45000
of outgoing traffic completely transparent to users from both 40000
a functional and a performance perspective. To this end, we 35000
run performance tests with the Apache Benchmark, testing the 30000
server’s ability to process 20,000 requests, with a maximum
25000
of 200 simultaneous active users. The results are shown in
Figure 6. 20000

al

he

e
p3

0 f
ch

ch
in

+p
ac
nf
rig

pa

pa
Si

p3
Ap
O

+A

+A
100

nf
Si
p3

0f
+p
90

nf
Si

p3
80

nf
Si
Percentage served

70
60
Fig. 7. FTP Transfer Rate (500 MB file)
50 ab -k -c 200 -n 20000
Document Length: 12629 bytes
40
Original TABLE II. R ESULTS OF N ESSUS SCANS
30 Sinfp3
Apache Without Deception With Deception
20 Sinfp3+Apache
10 Sinfp3+p0f Device Type General Purpose 85% General Purpose 65%
Sinfp3+p0f+Apache OS Ubuntu 12.04 85% Windows Vista 65%
0
0 15 30 45 60 75 90 105 120 135 150 165 180 195 210 225 6
Info 13 15
Time in ms Low 0 0
Medium 0 2 (100%: False Positives)
Fig. 6. Apache Benchmark High 0 2 (100%: False Positives)
Critical 0 0

The tests we performed involved different system config-

uration scenarios: (i) the behavior of the system is not altered
(Original); (ii) the kernel module to alter the OS fingerprint and B. Attacker Perspective
deceive only active fingerprinting tools is enabled (Sinfp3); In the second set of experiments, we evaluated our ap-
(iii) the kernel module to alter the service fingerprint is enabled proach from the point of view of an attacker trying to deter-
(Apache); (iv) both modules from scenarios (ii) and (iii) are mine the operating system of a remote host or the type of
enabled (Sinfp3+Apache); (v) the kernel module to alter the services running on it.
OS fingerprint and deceive both active and passive fingerprint-
ing tools is enabled (Sinfp3+p0f); and (vi) both modules from 1) Nessus: In order to test how our approach can deceive
scenarios (iii) and (v) are enabled. an attacker using Nessus, we audited the system with and
without the deceptive Kernel Module enabled. Table II shows
The performance degradation for scenario (ii) is negligible,
the results of the respective Nessus scans. The original system
as only two packets need to be altered for each connection. On
is a fully patched Ubuntu 12.04 server and has no known
the other hand, when the OS fingerprint kernel module alters
vulnerabilities. When no deception is used, the system is
all the outgoing packets (scenario (v) above), there is a slight
correctly identified, and all the information derived by Nessus
delay in the response time due to the greater number of packets
is accurate.
that need to be altered. When the Service Fingerprint Kernel
Module is enabled (scenario (iii) above), the response time Next, we deceived both OS and service fingerprinting by
increases due to the string comparison operations performed exposing a Windows 7/Vista OS fingerprint and an Apache
to identify and replace the banner information. It is clear from 2.2.1 service fingerprint. When the deception mechanism is
Figure 6 that the Service Fingerprint Kernel Module has the enabled, the OS is misidentified accordingly. Moreover, de-
largest impact on the performance of the system. However, ceiving service fingerprinting leads to false positives in the
even in the worst-case scenario, the performance degradation identification of vulnerabilities.
is limited.
2) Fingerprinting Tools: Table III reports the results of
Using the same scenarios, we have also tested the overhead scans performed with different fingerprinting tools. As one
introduced by the kernel modules on large data transfers by can see, our approach is able to effectively deceive several
uploading a 500MB file to an FTP server. Most packets will not fingerprinting tools. For instance, we are able to alter the
be altered, but the conditions of the if statements in the kernel perception of the target system even when the attacker uses
modules need to be evaluated, thus adding some overhead, either nmap or Xprobe++, which adopt a different probing
which will eventually affect the net transfer rate. As we can scheme.
see from Figure 7, the more conditions need to be evaluated
the greater the effect on performance is going to be. 6 60% True Positives; 13.33%: False Positives; 26.67%: Induced Info

259
 2015 IEEE Conference on Communications and Network Security (CNS)

TABLE III. OS F INGERPRINTING T OOLS D ECEPTION

aa
aa Tool
aa Sinfp3 p0f nmap Xprobe++
a
Deception aa
a
Linux 3.0.x-3.2.x (94%)
None Linux 3.x Linux 2.6.x-3.x Linux 2.4.19-28 (94%)
Linux 2.4.x-2.6.x (73%)
Server 2008/Vista/7 (100%)
Windows Server 2008 Windows 7/8 Unknown Linux 2.4.26 (78%)
FreeBSD 7.0-9.0 (73%)
Firewall Fortigate Firewall Fortigate 100%) Unknown Unknown Linux 2.4.23 (94%)
NetBSD 5.0.2 NetBSD 5.0.2 (98%) Unknown Unknown Linux 2.4.21 (92%)
Server 2008/Vista/7 (98%)
Windows Server 2008 (Partial) Windows 7/8 Unknown Linux 2.4.26 (81%)
FreeBSD 7.0-9.0 (73%)
Windows Server 2008 (Partial) Server 2008/Vista/7 (88%) Unknown Unknown Linux 2.4.14 (81%)

3) Unconventional Fingerprints: By intelligently crafting of the TCP segment. Modifying this value makes the host to
responses to SinFP probes it is possible to force attackers announce a different limit for its capabilities. Consider two
into misclassifying a remote host as any of a broad variety hosts hA and hB , where hB is the host being altered. hA sends
of networked assets. For instance, a conventional Linux-based a SYN packet with an MSS of 1,460 and hB responds with
Server can be fingerprinted as a network switch, an ADSL a SYN/ACK that has an MSS of 1,480. hA will not send any
gateway or even a printer. Of course these unconventional packets with a segment larger than 1,480 bytes to hB . Note
fingerprints will force the attackers to derive an inconsistent that hA is not required to send segments of exactly 1,480 but
map of the target network: it is really unlikely that a company it is required not to exceed this limit. For the same reason, it
web server is hosted on a Laserjet Printer. is not possible to advertise a larger value than what hosts are
able to handle.
We have successfully created SinFP deceptions for different
network monitoring appliances, firewalls and printers. A partial Window and Windows Scale Factor. These two param-
SinFP output for the case of an HP Officejet 7200 Printer is eters affect the TCP flow control, which regulates the amount
reported in Figure 8, whereas Figure 9 illustrates the steps of data a source can send before receiving an acknowledgment
involved in forcing the attacker to believe that the target device from the destination. A sliding window is used to make
is a printer. transmissions more efficient and control the flow so that the
destination is not overwhelmed with data. The TCP Window
scale factor is used to scale the window size by a power
...
score: 100: Printer: HP Officejet 7200 of 2. The window size may vary during the data transfer
score: 100: Printer: HP Officejet Pro L7600 while the scale factor is determined once at the time of
score: 73: Appliance: APC AP9319 establishing a connection. Modifying the window size can alter
...
the throughput: if the window is smaller than the available
bandwidth multiplied by the latency then the sender will send
a full window of data and then sit and wait for the receiver to
Fig. 8. HP Officejet 7200 Printer
acknowledge the data. This results in lower performance.
Selective ACK. Selective acknowledgment allows the
sender to have a better idea of which segments are actually
5 Sinfp3 Result
lost and which have arrived out of order. If we disable the
2 SACK permitted option for a host that supports it, we may limit
1 Sinfp3 Probes performance, depending on the capabilities of the counterpart.

4 Responses 3 DMZ
Attacker VI. R ELATED W ORK
Firewall
Various techniques have been proposed to defeat finger-
Fig. 9. SinFP Printer Deception printing [8]. Among them, the simplest and most intuitive
is the modification of the default values of a TCP/IP stack
implementation, such as the TTL, Window Size or TCP
C. Drawbacks Options. Reconnaissance tools, such as nmap or Xprobe2, are
able to identify a service or an operating system by exploiting
Altering some parameters of the TCP header can affect the
protocol specifications that give developers some freedom
connection performance, when legitimate users actively use
and analyzing packets that can reveal implementation specific
the protocol based on the modified parameters. In such cases,
details about the host [5], [11]. Another interesting approach is
the proposed mechanism is not completely transparent, and
the TCP/IP stack “fingerprint scrubber”. A fingerprint scrubber
drawbacks include those listed in the following.
is a tool aimed at restricting a remote user’s ability to determine
Maximum Segment Size (MSS). This parameter defines the operating system of another host on the network. It is
the largest unit of data that can be received by the destination typically a software component that is transparently deployed

260
 2015 IEEE Conference on Communications and Network Security (CNS)

between the Internet and the network under protection7 and With respect to OS fingerprinting, our approach consists in
performs a set of kernel modifications to avoid recognition of modifying outgoing traffic so that it resembles traffic generated
the operating system based on the characteristics of IP and TCP by a host with a different operating system. As for service
implementations. It works both at the network and transport fingerprinting, our approach consists in modifying the service
layers by converting traffic from a heterogeneous group of banner by intercepting packets before they leave the host
hosts into sanitized packets that do not reveal information or network. Experiments have shown that our approach is
about a host’s operating system. For example, for all the effective and introduces only a negligible overhead.
packets generated by all the hosts in the protected network,
it normalizes the IP header flags, forces all ICMP error Our ultimate goal is to create a network appliance that
messages to contain data payloads of only 8 bytes, keeps can intercept outgoing traffic and transparently masquerade
track of the open TCP connections by following the three- services and operating system fingerprints.
way handshake, and blocking all TCP packets that do not
belong to a valid three-way handshake sequence, reorders the R EFERENCES
TCP options within the TCP header. The fingerprint scrubber [1] S. Jajodia, A. K. Ghosh, V. S. Subrahmanian, V. Swarup, C. Wang,
was tested against nmap, which was completely unable to and X. S. Wang, Eds., Moving Target Defense II: Application of Game
determine the operating system. This approach significantly Theory and Adversarial Modeling, 1st ed., ser. Advances in Information
Security. Springer, 2013, vol. 100.
differs from the approach we propose in this paper, in that,
[2] S. Jajodia, A. K. Ghosh, V. Swarup, C. Wang, and X. S. Wang, Eds.,
instead of simply hiding information about OS and services, Moving Target Defense: Creating Asymmetric Uncertainty for Cyber
we provide the attacker with misleading information. Threats, 1st ed., ser. Advances in Information Security. Springer, 2011,
vol. 54.
Other existing approaches to defeating fingerprinting in- [3] P. K. Manadhata and J. M. Wing, “An attack surface metric,” IEEE
clude [4]: Transactions on Software Engineering, vol. 37, no. 3, pp. 371–386,
May 2011.
• Altering all public service banners to something non-
[4] C. Trowbridge, “An overview of remote operating system fingerprint-
committal. ing,” SANS Institute InfoSec Reading Room, July 2003.
• Searching content files for ‘incriminating’ strings that can [5] G. F. Lyon, Nmap Network Scanning: The Official Nmap Project Guide
give away information about the OS. For instance, web to Network Discovery and Security Scanning. [Link], January
pages may include comments automatically generated that 2009.
identify the authoring tool. [6] P. Auffret, “SinFP, unification of active and passive operating system
fingerprinting,” Journal in Computer Virology, vol. 6, no. 3, pp. 197–
Network protocol fingerprinting refers to the process of 205, August 2010.
identifying specific features of a network protocol implementa- [7] M. Zalewski, “p0f v3 (version 3.06b),” [Link]
tion by analyzing its input/output behavior [12]. These features p0f3/, January 2012.
may reveal specific information such as protocol version, [8] A. Rana, “What is AMap and how does it fingerprint applications?”
vendor information and configurations. Reconnaissance tools [Link] March 2014.
store known system’s features and compare them against the [9] R. Gula, “Enhanced operating system identifi-
cation with Nessus,” [Link]
scan responses in order to match a fingerprint. Watson et enhanced-operating-system-identification-with-nessus, February
al. [11] adopted protocol scrubbers in order to remove TCP 2009.
protocol ambiguities. They used a fingerprint scrubber to [10] O. Arkin, “ICMP usage in scanning - the complete know-how,”
restrict an attacker’s ability to determine the operating system [Link] Scanning [Link], June
of a protected host. Moreover, some proof-of-concept software 2001.
and kernel patches have been proposed to alter a system [11] D. Watson, M. Smart, G. R. Malan, and F. Jahanian, “Protocol
fingerprint [13], such as IP Personality and Stealth Patch. scrubbing: network security through transparent flow modification,”
IEEE/ACM Transactions on Networking (TON), vol. 12, no. 2, pp. 261–
Unfortunately, these tools are not maintained anymore and 273, 2004.
their last releases target quite old Linux kernels (2.4.x). For this
[12] G. Shu and D. Lee, “Network protocol system fingerprinting - a formal
reason it was not relevant to perform a comparative analysis approach,” in Proceedings of the 25th IEEE International Conference
with our approach. on Computer Communications (INFOCOM). IEEE, April 2006, pp.
1–12.
[13] B. David Barroso, “A practical approach for defeating nmap os-
VII. C ONCLUSIONS fingerprinting,” [Link] Jan-
uary 2013.
In this paper, we have proposed an efficient and effective
approach to defeat an attacker’s reconnaissance effort by
inducing an incorrect view of the target system. As all cyber
attacks are typically preceded by a reconnaissance phase in
which attackers aim at collecting critical information about
the target system, disrupting this phase of an attack may
be extremely effective in thwarting or at least delaying the
attack. Specifically, in this paper we aim at defeating operating
system fingerprinting and service fingerprinting, which are
respectively used to determine the operating system of a remote
host and the type of services running on it.
7A typical placement would be on the firewall.

View publication stats

261