"Preventing remote OS detection via tcp/ip stack fingerprinting" - An excellent security improvement module describing how you can mask your operating system from tcp/ip stack fingerprinting tools such as nmap and queso while still being functional.
e1c58672b07ad691715912417bd4cc43c6bca3ffa42e3b72596bad8e9e6e91e7<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE>P G C I</TITLE>
</HEAD>
<BODY>
<TABLE BORDER CELLSPACING=4 CELLPADDING=4 >
<TR ALIGN=LEFT VALIGN=TOP>
<TD BGCOLOR="#CCCCCC"><FONT FACE="arial,helvetica"><FONT SIZE=-1>Applies
to the practice:</FONT></FONT>
<BR><FONT FACE="arial,helvetica"><FONT SIZE=-1><A HREF="http://www.pgci.ca/emain.html">Preventing
remote OS detection via tcp/ip stack fingerprinting</A></FONT></FONT>
<P><FONT FACE="arial,helvetica"><FONT SIZE=-1>Applicable technologies:</FONT></FONT>
<BR><FONT FACE="arial,helvetica"><FONT SIZE=-1>Solaris and unix derivatives;
tcp/ip tweaking</FONT></FONT></TD>
</TR>
</TABLE>
<P><B>Abstract</B>
<P>A technique exists to determine a remote operating system by sending
obscure tcp packets and analyzing the response. Two utilites known as <A HREF="http://apostols.org/projectz/queso/">queso</A>
and <A HREF="http://www.insecure.org/nmap/index.html">nmap</A> can determine
with enough precision your operating system. For the curious, we have provided
a link
<A HREF="http://false.net/nettool/">here</A> to a working os detection
tool.
<P>Netcraft also proclaims your operating system type with their web survey,
analyzing
<BR>the httpd servers response. It can be found <A HREF="http://www.netcraft.com/">here</A>.
<P><B>So how can we mask our operating system from these tcp/ip stack fingerprinting
tools while still being functional?</B>
<P>We must first look at what is sent to our tcp/ip stack, and how the
operating system responds to these sometimes obscure packets.
<P>Here are the packets that are sent:
<P>
0 SYN * THIS
IS VALID, used to verify LISTEN
<BR>
1 SYN+ACK * Response to our SYN request (but we didn't send one)
<BR>
2 FIN
<BR>
3 FIN+ACK
<BR>
4 SYN+FIN * THIS IS NOT SEEN IN THE WILD
<BR>
5 PSH
<BR>
6 SYN+XXX+YYY * XXX & YYY are unused TCP flags
<P>Here is what Solaris 2.x would respond, depending on many factors:
<P>*- Firewalled Solaris 2.x
<BR>0 1 1 2398 SA
<BR>1 - - - -
<BR>2 - - - -
<BR>3 - - - -
<BR>4 - - - -
<BR>5 - - - -
<P>* Solaris 2.x
<BR>0 1 1 2398 SA
<BR>1 0 0 0 R
<BR>2 - - - -
<P>* Solaris 2.x
<BR>0 1 1 2238 SA
<BR>1 0 0 0 R
<BR>2 - - - -
<P>The two first packets are sent. Packet one contains a SYN, to initiate
the connection, the response from the target host is SYN-ACK (standard),
with a window field of 2238 (depending) in hex. Packet two contains a SYN-ACK
which generates a valid RST from the host (no connection was initiated
by the host, hence the RST response tearing it down.)
<P>A determining factor seems to be the window field, which happens to
be a modifiable parameter in Solaris's TCP/IP stack.
<P><B>TCP_MSS_DEF</B>
<P>This parameter determines the default MSS (maximum segment size) for
non-local destinations. The MSS is the largest chunk of data that TCP will
send to the recieving end.
<P>Whenever a connection is about to be established, the segment size used
will be set to the <I>minimum of the smallest MTU of an outgoing interface,
and from the MSS anounced by the peer</I>. Each end annouces its MSS, (the
option can only appear in a SYN segment) and if one end does not recieve
an MSS option, a default of 536 is assumed. (This allows for a 20-byte
IP header and a 20-byte TCP header to fit into a 576 byte IP datagram)
<P>In general, the larger the MSS, the better, until fragmentation occurs.
This value can be set to the MTU of the outgoing interface - 40 bytes,
if the value is bigger than 536. Queso expects to see a window of 8760
(2238 in hex) or 9112 (2398 in hex) and uses this information to determine
the OS.
<P><B>The solution under solaris 2.x </B>
<P><FONT FACE="Arial,Helvetica">Preventing queso and company from determining
our OS. This value can be set higher that 536, without any serious side
effects. You can add this to the <A HREF="stack.html">secureip</A> script
from a previous module.</FONT>
<P>ndd -set /dev/tcp tcp_mss_def 546
<BR>echo "setting default MSS to 546"
<P><B>The solution under Linux 2.0.35 </B><B></B>
<P>For linux, the repsonse is different, but the solution the same.
<P>* Linux 2.0.35 to 2.0.9999 :)
<BR>0 1 1 7FE0 SA * Valid, but the window value can be tweaked i'm sure.
<BR>1 0 0 0 R * Valid
<BR>2 - - - -
<BR>3 0 0 0 R
<BR>4 1 1 7FE0 SFA * This one can be filtered without any problems..
<BR>5 - - - -
<BR>6 1 1 7FE0 SA * unknown options can also be filtered.
<P>One could easily get the ip filter package from <A HREF="http://coombs.anu.edu.au/ipfilter">coombs.anu.edu.au</A>
and
<BR>setup the following rule to block packet #4.
<P>block in on le0 proto tcp from any to any flags SF/SF
<P>
<HR WIDTH="100%">
<P><B>Masking the operating system (from an application perspective) </B>
<P>1. If you use sendmail, change this field in sendmail.cf, <I>O
SmtpGreetingMessage</I> and modify the <I>sendmail.hf</I> file to something
nifty.
<P>2. Use a statically linked ls for your public ftp server, and then make
it execute only and owned by root. Use <B>truss -f chroot ~ftp /bin/ls
-l </B>to figure out dependencies
<BR>on different libraires. I've heard of ldd, use that if you want. Grab a copy of fileutils <A
HREF="ftp://gatekeeper.dec.com/pub/GNU/fileutils/">here.</A>
<P>3. Under Solaris, modify the /etc/default/telnetd file to read:
<P><B>@paranoia> more /etc/default/telnetd </B>
<BR><B>BANNER=""</B>
<P>For unix variants, look for a file called issue or issue.net. You shouldn't
even be running telnet; using SSH is for the security conscious.
<P>4. Depending on the web server, a few hacks can be made to prevent
from knowing the operating system. <A HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1945.html">RFC1945</A>
states:
<BR>
<BLOCKQUOTE><I>10.14 Server</I>
<P><I> The Server response-header field contains information
about the</I>
<BR><I> software used by the origin server to handle the request.
The field</I>
<BR><I> can contain multiple product tokens (Section 3.7) and
comments</I>
<BR><I> identifying the server and any significant subproducts.
By</I>
<BR><I> convention, the product tokens are listed in order
of their</I>
<BR><I> significance for identifying the application.</I>
<P><I> Server
= "Server" ":" 1*( product | comment )</I>
<P><I> Example:</I>
<P><I> Server: CERN/3.0 libwww/2.17</I></BLOCKQUOTE>
<BLOCKQUOTE> <I>Note: Revealing the specific software version of the
server may</I>
<BR><I> allow the server machine to become more vulnerable to attacks</I>
<BR><I> against software that is known to contain security holes.
Server</I>
<BR><I> implementors are encouraged to make this field a configurable</I>
<BR><I>option. </I></BLOCKQUOTE>
Here is a hack for the <A HREF="www.apache.org">Apache 1.3.4</A> web server
(since <A HREF="http://www.apache.org/docs/mod/mod_headers.html">mod_headers</A>
does not offer this option).
<P><I>The Header directives are processed just before the response is sent
by its handler. These means that some headers that are added just before
the response is sent cannot be unset or overridden. This includes headers
such as "Date" and "Server". </I>
<P><B>Insert this somewhere before using getnull()</B>
<P>int getnull(void)
<BR>{
<BR>return 0;
<BR>}
<P><B>http_protocol.c: @ line 1298, </B>
<P> /* ap_send_header_field(r, "Server", ap_get_server_version());
*/
<BR> ap_send_header_field(r, "Server", getnull());
<P><B>http_protocol.c: @ line 566,</B>
<P>/* ap_table_setn(r->headers_out, "Last-Modified",
<BR>
ap_gm_timestr_822(r->pool, mod_time)); /*
<P>ap_table_setn(r->headers_out, "\nLast-Modified",
<BR>
ap_gm_timestr_822(r->pool, mod_time));
<BR>
<P>Comments can go to <A HREF="mailto:gilbert@pgci.ca">gilbert@pgci.ca</A>
<pre>
----------------------------------------------------------------------------------
Date: Mon, 22 Feb 1999 15:57:49 -0800
From: route@RESENTMENT.INFONEXUS.COM
To: BUGTRAQ@netspace.org
Subject: Re: Preventing remote OS detection
[Patrick Gilbert wrote]
|
| There are many other ways to determine the operating system as well,
| most of which are described in a fairly recent phrack article (number 54
| if I am correct)
You are correct. Phrack 54-09. http://www.phrack.com
| How can we mask our operating system from these tcp/ip stack
| fingerprinting tools while still being functional?
|
| The answer can be found in the latest security improvement module at:
|
| http://www.pgci.ca/fingerprint.html
While this article does offer some good advice towards risk mitigation,
there are a few key points I'd like to bring to the table.
The proposed Solaris solution (to change the default MSS to a larger value)
is still easily fingerprintable. Perhaps experimenting with psuedo-random
values within a `safe` threshold would be a bit better, but this too can
be fingerprinted.
The article does mention a few TCP fingerprint techniques, but not TCP
options, many of which are very stack specific.
The article doesn't touch down on the prevention of IP or ICMP related
fingerprinting. There's a probably good reason for this. It's somewhat
difficult and very implementation specific.
Filtering fringe packets will work to dissuade certain fingerprint checks,
others are based off of `normal` packets. For example, ICMP unreachable
packets are often filled with stack specific information. And the Solaris
stack seems to be one of the only ones out there that does path MTU
discovery by default (this is easily noticable by the presense of the DF
bit in the IP header).
The fact of the matter is that most of these fixes are stopgap measures and
not very extensible. The proper fix is standards compliance and ubiquitous
support. Of course the question then becomes which standards do we adhere
to, and what is to be done if there isn't standard defined behavior for
some instance...? That's a good one. I say, close the Internet for
repairs.
--
I live a world of paradox... My willingness to destroy is your chance for
improvement, my hate is your faith -- my failure is your victory, a victory
that won't last.
</pre>
</BODY>
</HTML>
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed