Passive-Aggressive Resistance: OS Fingerprint Evasion
If you have read up to this point, you are at least no doubt a little curious as to why one would go to the trouble of OS fingerprint evasion. Good question! I think the logic here varies from person to person. Everyone has his or her own reasons for wanting, or not wanting for that matter, operating system obscurity.
For some, the extra layer of obscurity helps them feel fuzzy and warm inside. Like the people who feel the need to remove the issue banner from their Telnet login screens, but resort to Telnet rather than SSH for remote access security (obscure, but technically less secure). For others, the notion of operating system obscurity at the network level allows them to fine-tune and tweak their IDS (intrusion detection system) since they have a fairly good idea not only of what should be coming into their network, but also of what data should be leaving it (obscure, cautious and hopefully secure). Some might even have a need for security, where every network they plug in to is a potential hostile network; and the more obscure their operating system is, the bigger the window of opportunity they have to complete whatever the task is at hand without being noticed (obscure, cautious, secure and probably reading your e-mail). Finally, there are those of us who do it for fun, because we can and because we get some small kick out of being able to fool the unknown individuals around us who persist on launching scans in our direction (yes, guilty as charged).
Now it's time to try our luck at fingerprint evasion. Familiar with some of the common techniques used in determining a host's operating system, we can reverse engineer these concepts to aid us in hiding our operating identities.
First, we need to make sure that all patches are in place and the system is secured. As I stated before, obscurity should only be entertained after security has been implemented. I'm sure some would disagree here, relying solely upon obscurity for their means to a secured system, but what good is obscurity if that script kid33's automated script gains root on your machine tonight? I'm willing to bet once he has root access, what flavor of Linux you are running isn't on his or her list of things to figure out.
Second, we need to observe our services. Do they match up with the operating system we are hoping to pass ourselves off as using? In most cases this isn't as much of a concern since most UNIX environments share similar if not the same services. But if you are hoping to present yourself as a Windows machine, or even a Cisco router for that matter, it may not be to your advantage to show up having IRCd running. Make an effort in matching up your services with a suitable decoy host.
While we're on the subject of services, it is also a good idea to begin greping through the source code of these services looking for banners or common identifiers of the services. Some subtle identifiers could be the supporting of ASP pages or web content that is served compressed in gzip format. For most people this will be a lot of work. Again, it's up to you to gauge what level of obscurity and conformity with your new decoy host you are trying to achieve.
Next, we need to look at how our host appears on a network vs. how our decoy host should look on a network. To make this a little bit easier I suggest studying already documented materials, namely the current fingerprint files used by the tools themselves. Time should be taken to note not just how your decoy host responds to usual queries, but also what special flags it supports in TCP. TCP flags are useful information for outsiders to determine what OS you are running. The fingerprint files don't include all possible responses a host might give, just simple techniques that work reproducibly. Depending on what level of obscurity you hope to achieve, it may be worth looking into fingerprint information not used by nmap (OSPF, OOB, IPv6, etc.). Or the joy of thoroughness could be outweighed by the sleepless nights you would spend gathering this information.
Finally, a decision needs to be made. Are you crafty, or are you paranoid? If you answer to the latter, then you most likely want to continue by obfuscating your client software. As mentioned above, a host's client software tends to give out all kinds of information regarding the system, either directly or indirectly. In our previous example an IRC client lists itself as being for Win32, but there are also more subtle ways of determining a host, such as reading the e-mail headers of outgoing mail. Once again, it all comes down to how many sleepless nights you are willing to spend before your system meets your criteria.
OS fingerprint evasion is like any other aspect of security; it takes planning, proper execution and most importantly, understanding. If security policies are not properly implemented, the system could be more vulnerable than if these policies were not implemented at all.
Popularity gives way to recognition. In most realms of software, popularity is a great thing; it brings attention to all your hard work and determination. In the case of OS fingerprint evasion, recognition works against you. If you are using a popular tool or package, eventually vulnerabilities and particulars will be discovered; this is inevitable. These same software-specific identifiers will allow others to fingerprint your counter-measure accurately rather than the operating system itself.
Most every OS attempts to make its TCP ISN sequencing random, in attempt to thwart TCP hijacking and more complex attacks on the system. If your chosen implementation of evasion attempts to alter TCP initial sequence numbers, great care should be taken to ensure you do not downgrade this functionality and put your host at risk to these types of attacks.
As with any software package that makes it onto your system, application security should be a primary concern. Part of the evasion process is masking existing services; the other comes in the form of code, which is meant to filter your traffic and mask what you put on the wire. Great care should be taken to ensure that the application produced for this task is secure through good programming practices and rigorous testing. All it takes is one poorly thought-out strcpy() to turn this asset quickly into a liability.
One of the evasion tactics previously listed is to alter the service banners of software that identifies itself. Be careful because some add-on software packages actually use these same banners to determine compatibility with the current system software.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
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