Network Security Hacks [Electronic resources] نسخه متنی

Hack 40 Block OS Fingerprinting

Keep outsiders on a need-to-know basis
regarding your operating systems.

When performing network
reconnaissance, one very valuable piece of information for would-be
attackers is the operating system running on each system discovered
in their scans. From an attacker's point of view,
this is very helpful in figuring out what vulnerabilities the system
might have or which exploits may work on a system. Combined with the
knowledge of open ports found during a port-scan, this information
can be devastating. After all, an RPC exploit for SPARC Solaris
isn't very likely to work for x86 Linuxthe
code for the portmap daemon isn't common to both
systems, and they have different processor architectures. Armed with
the knowledge of a given server's platform,
attackers can very efficiently try the techniques most likely to
grant them further access without wasting time on exploits that
cannot work.

Traditionally, individuals performing network reconnaissance would
simply connect to any services detected by their port-scan, to see
which operating system the remote system is running. This works
because many daemons, such as Sendmail, Telnet, and even FTP, readily
announce the underlying operating system, as well as their own
version numbers. Even though this method is easy and straightforward,
it is now seen as intrusive since it's easy to spot
someone connecting in the system log files. Additionally, most
services can be configured not to disclose this sensitive
information. In response, more sophisticated methods were developed
that do not require a full connection to the target system to
determine which operating system it is running. These methods rely on
the eccentricities of the host operating system's
TCP/IP stack and its behavior when responding to certain types of
packets. Since individual operating systems respond to these packets
in a particular way, it is possible to make a very good guess at what
OS a particular server is running based on how it responds to
probe packets, which normally
don't show up in log files. Luckily, such probe
packets can be blocked at the firewall to circumvent any operating
system detection attempts that deploy methods like this.

One popular tool that employs such OS detection methods is Nmap (http://www.insecure.org/nmap/), which not
only allows you to detect the operating system running on a remote
system, but also perform various types of port-scans.

Attempting to detect an operating system with Nmap is as simple as
running it with the -O switch. Here are the
results of scanning an OpenBSD 3.3 system:

# nmap -O puffy
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-02 19:14 MST
Interesting ports on puffy (192.168.0.42):
(The 1653 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
13/tcp  open  daytime
22/tcp  open  ssh
37/tcp  open  time
113/tcp open  auth
Device type: general purpose
Running: OpenBSD 3.X
OS details: OpenBSD 3.0 or 3.3
Nmap run completed -- 1 IP address (1 host up) scanned in 24.873 seconds

To thwart Nmap's efforts, we can
employ firewall rules that
block
packets used for operating-system probes. These are fairly easy to
spot, since several of them have invalid combinations of TCP flags.
Some of the tests that Nmap performs cannot be blocked by PF by
simply adding block rules, but they can be blocked
if stateful filtering and a default deny policy have been implemented
in the ruleset. This is because some of the tests make use of TCP
options, which cannot be filtered with PF.

To block these fingerprinting attempts with
OpenBSD's PF, we can put rules similar to these in
our /etc/pf.conf:

set block-policy  return
block in log quick proto tcp flags FUP/WEUAPRSF
block in log quick proto tcp flags WEUAPRSF/WEUAPRSF
block in log quick proto tcp flags SRAFU/WEUAPRSF
block in log quick proto tcp flags /WEUAPRSF
block in log quick proto tcp flags SR/SR
block in log quick proto tcp flags SF/SF

This also has the side effect of logging any attempts to the
pflog0 interface. Even if we
can't block all of Nmap's tests, we
can at least log some of the more unique attempts, and possibly
confuse it by providing an incomplete picture of our operating
system's TCP stack behavior. Packets that have
triggered these rules can be viewed with tcpdump
by running the following commands:

# ifconfig pflog0 up
# tcpdump -n -i pflog0

Now let's look at the results of an Nmap scan after
enabling these rules:

# nmap -O puffy 
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-12-02 22:56 MST
Interesting ports on puffy (192.168.0.42):
(The 1653 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
13/tcp  open  daytime
22/tcp  open  ssh
37/tcp  open  time
113/tcp open  auth
No exact OS matches for host (If you know what OS is running on it, see 
http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.48%P=i686-pc-linux-gnu%D=12/2%Time=3FCD7B3F%O=13%C=1)
TSeq(Class=TR%IPID=RD%TS=2HZ)
T1(Resp=Y%DF=Y%W=403D%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=Y%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=Y%W=0%ACK=O%Flags=AR%Ops=)
T4(Resp=Y%DF=Y%W=4000%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=134%RID=E%RIPCK=F%UCK=E%ULEN=134%DAT=E)
Nmap run completed -- 1 IP address (1 host up) scanned in 27.028 seconds

As you can see, this time the attempt was unsuccessful. But if you
are feeling particularly devious, simply confusing Nmap attempts may
not be enough. What if you want to actually trick would-be attackers
into believing that a server is running a different OS entirely? For
example, this could be useful when setting up a honeypot [Hack #94] to attract miscreants away
from your critical servers. If this sounds like fun to you, read
on.