Passive-Aggressive Resistance: OS Fingerprint Evasion
OS fingerprinting is a process for determining the operating system a remote host computer is running, based on characteristics of the data returned from the remote host. This can be as simple as connecting up to the host and reading a service banner or as complex as statistical analysis of TCP initial sequence numbers and flags. An outsider has the capability to discover general information, such as which operating system a host is running, by searching for OS-specific differences in implementation of the TCP stack. In some cases, these differences can reveal information as detailed as the OS version number and processor architecture.
By pinpointing the exact OS of a host, an attacker can launch an educated and precise attack against a target machine. In a world of buffer overflows, knowing the exact flavor of an OS and architecture could be all the opportunity an attacker needs. By using software such as Netfilter for Linux, an administrator can evade accurate OS-fingerprinting methods and in some cases even manipulate the results gathered by the external force. While these practices should never be considered a sound security solution, sometimes they can deter and even confuse a would-be attacker if the host poses as an obscure network entity.
While fingerprint evasion does offer a nice layer of obscurity as to the actual OS a host is running, it does not in any way secure the host from various vulnerabilities. Security practices and policies attempt to raise the level of skill required to compromise the system, obscurity only attempts to mask the actual target. Even if your system appears to be running Microsoft IIS5 to the world, this won't protect you if you are running a vulnerable version of let's say sendmail, and some script kiddy's automated scanner attempts to exploit you. Fingerprint evasion is meant to deter attacks, not prevent them.
Before attempting to dissuade a potential attacker through OS deception, one must familiarize themselves with the tools and methods used in fingerprinting an OS. The term “attacker” here is used loosely and encompasses those who would attempt to fingerprint a host or those who might have the intentions of doing the system harm. Security has been, and in the writer's mind always will be, a sequence of measure and counter-measure scenarios. By becoming accustomed to the tools and methodologies available for this type of attack you cannot only prepare and plan for current engagements, but also gain insight into what the future may have in store.
Several publicly available tools exist for attempting to fingerprint an OS. Of these tools, one seems to be the popular choice: nmap (www.insecure.org/nmap/index.html) by Fyodor of Insecure.org. nmap uses several techniques for attempting to determine the host operating system from a network level, some of them primitive in their approach and others more complex, requiring a good understanding of the TCP/IP protocol and protocol standards. Of the methods nmap incorporates, some of the most notable are:
FIN Probing—by sending a packet to an open port on a host with nothing more than the FIN flag set in the packet, an attacker can glean information from certain hosts that respond to the requests. This behavior is non-RFC-compliant so it is a good indicator of OS.
TCP ISN Sampling—TCP packet ISN (initial sequence number) sampling can be a valuable way to determine and categorize the remote host. By watching the ISNs for patterns an attacker can make an educated guess as to the host OS.
ICMP Error Messaging—through the use of ICMP (internet control message protocol) error messages, an attacker can find useful information based on the host responses. Particular areas of interest are the checksums, error message echo integrity and TOS (type of service) fields in the reply packets.
TCP Options—perhaps the most revealing aspect of any TCP stack is how it handles optional TCP flags and data. By making specific requests to a host and varying window scales and segment sizes, one can determine which operating system a host is running based on its willingness to accept or respond with these optional parameters.
While all of these methods of OS fingerprinting are at the packet level, great care should be taken to understand your system at a service level. An attacker could sort and compare packet structures but will often simply query a web server for the “Server” field in the HTTP response header. Knowing which services readily identify themselves, and more importantly the operating system architecture, will show us other avenues that can be used for remote information retrieval.
Client modesty (or lack thereof) can be an excellent way to glean information from a host as well. Unlike the other options, this process can be completely passive. By watching how a client application presents itself to a service, you can make a reasonable guess at the operating system and possibly the architecture. Of these clients, web browsers, e-mail clients and IRC (internet relay chat) clients are most often the biggest offenders. If we were on IRC and requested a CTCP version from a user, and received the reply of “mIRC32 v5.81 K.Mardam-Bey”, we could make an educated guess at this point that the host is running some form of the Windows operating system.
Finally, there is exploit testing. While less tactful, it can nevertheless be useful in discovering the operating system of a host. By initiating a series of OS-specific denial-of-service attacks an outsider can test to see if a host is vulnerable. This can determine which rating system a host is running, usually down to the patch level. The Windows community should be grateful that Fyodor and the other fingerprinting-tool authors didn't decide to incorporate this method into their usual slew of scanning techniques.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide