Previous month:
January 2015
Next month:
March 2015

February 2015

A Hacker Personality Quadrant

Science Daily reports that associate professor Kevin Steinmetz of Kansas State University has published a research article in which he attempts to answer the questions: "What is a hacker and what does it mean to hack?" According to Science Daily, Steinmetz, who conducted an ethnographic study to find his answer, "Hacking is a late-modern transgressive craft."

This characterization reinforces the current and dominantly held definition of hacker. Steinmetz's might be an appropriate characterization for the purposes of criminology; however, characterizing all hacking as transgressive is incorrect. My observations after more than 40 years of working with hacking nee software development nee computer programming lead me to a different assertion, one I first attempted to describe an article, Security Hats: black or white, there is no grayscale:

All of the activities Steinmetz attributes are as readily applied to ethical hacking as transgressional.

The populist views of hacking - from pimply little social misfits who live in garages or basements and wreck havoc on governments or corporations for notoriety's sake, to Bondesque evil geniuses - portray only one segment of the hacker population. Another is recorded in Brian Harvey's, What is a Hacker?, where he describes hackers as asethete hobbyists. Harvey explores both hacker aesthetic and ethic and asserts, "To embrace the aesthetic life is not to embrace evil; hackers need not be enemies of society". 

Let's review how Steinmetz compares hacking to craftwork. He uses eight analogs:

  1. A particular mentality
  2. An emphasis on skill
  3. A sense of ownership over tools and objects of labor
  4. Guild-like social and learning structures
  5. A deep sense of commitment.
  6. An emphasis on process over result
  7. A common phenomenological experience
  8. Tendencies toward transgression

Let's juxtapose several of Steinmetz' transgressional craftsman's characteristics against Harvey's ethical hacker. For this, I'm primarily using the characteristics I see among information security, security operations, and security research colleagues for comparison against the criminal characteristics I come to understand from my work with security communities.

A particular mentality. In my experience, the transgressional hacker is biased towards notoriety, self-interest or financial reward: some hackers may be transgressors because they hack to protest suppression of rights and their activities violate laws. The ethical hacker is biased towards fun, innovation, satisfaction. Where transgressional hackers may work grudgingly with others or by necessity, ethical hackers often seek others (particularly to share information) and work well in groups or teams. 

A sense of ownership over tools and objects of labor. The nature and character of underground markets for trading tools and objects of labor supports Steinmetz' notion that transgressional hackers are possessive. But some protest- or resistance transgressors share their hacks, and ethical hackers are more generous: security or investigative software or web portals are quite commonly made available as open source, or free of charge, by individuals and security companies with commercial interest. 

Guild-like social and learning structures. In my experience, criminal-transgressional hackers are not guild-like in the truest definition of guild, but rather a collection of conspirators. Ethical hackers are more characteristically guild-like, especially where such communities not only expect mutual respect and common purpose but require members to be vetted and adhere to strict acceptable use practices.

A deep sense of commitment. It's arguable that both transgressional and ethical hackers can be deeply committed, at the very least, the most talented hackers are aesthetes.

HackerpersonalityquadrantBased on these juxtapositions, I would alternatively propose to depict hackers along two axes: transgressional versus moral and public, and interest versus self-beneficial. For my purposes, public interest encompasses principles of "do no harm", "common good", and protest or "(civil) disobedience". Self-beneficial encompasses notoriety or financial gain, personal or corporately commercial.

In the figure to the right, I place a sampling of "guilds" in these quadrants, one man's attempt to fold aesthetic and ethic into the study.

Does this depict what a hacker is and what does it mean to hack more correctly than Steinmetz? 

Share your opinion with me on Twitter @securityskeptic.  Thanks!

 


5 Ways To Monitor DNS Traffic For Security Threats

Check out these examples of how to implement real-time or offline traffic monitoring using common commercial or open source security products.

In Monitor DNS Traffic & You Just Might Catch A RAT, I described how inspecting DNS traffic between client devices and your local recursive resolver could reveal the presence of botnets in your networks. Today, I'll share how you can monitor traffic using security systems and name resolvers you may already have deployed.

Firewalls

Let's begin at the most prevalent security system: your firewall. All firewalls should let you define rules to prevent IP spoofing. Include a rule to deny DNS queries from IP addresses outside your allocated numbers space to prevent your name resolver from being exploited as an open reflector in DDoS attacks.

Next, enable inspection of DNS traffic for suspicious byte patterns or anomalous DNS traffic to block name server software exploit attacks. Documentation describing how popular firewalls provide this feature is readily available (e.g., Palo Alto NetworksCisco SystemsWatchGuard). Sonicwall and Palo Alto can detect and block certain DNS tunneling traffic, as well.

Intrusion detection systems

Whether you use SnortSuricata, or OSSEC, you can compose rules to report DNS requests from unauthorized clients. You can also compose rules to count or report NXDOMAIN responses, responses containing resource records with short TTLs, DNS queries made using TCP, DNS queries to nonstandard ports, suspiciously large DNS responses, etc. Any value in any field of the DNS query or response message is basically "in play." You're essentially limited only by your imagination and mastery of DNS. Intrusion prevention services in firewalls provide permit/deny rules for many of the most common of these checks.

Traffic analyzers

Use cases for both Wireshark and Bro show that passive traffic analysis can be useful in identifying malware traffic. Capture and filter DNS traffic between your clients and your resolver, and save to a PCAP file. Create scripts to search the PCAP for the specific suspicious activities you are investigating, or use PacketQ (originally DNS2DB) to SQL query the PCAP file directly. SMB shops with a spare Windows system can use Microsoft Network Monitor 3.4 (nmcap3) as effectively: a single filter for DNS traffic and you can monitor effectively on your familiar OS. 

Dnssniffer

Alternatively, try Nirsoft's DNS Query Sniffer (dnsquerysniffer.exe). This free utility captures DNS traffic, parses each query or response and lets you save the message streams from your monitoring activity.

If you have anyone in your organization who's familiar with command line (Linux or DOS), even a simple script to tcpdump DNS can be effective. 

(Remember to block your clients from using any resolver or nonstandard port other than your local resolvers).

Passive DNS replication

This involves using sensors at resolvers to create a database that contains every DNS transaction (query/response) through a given resolver or set of resolvers. Including passive DNS data in your analysis can be instrumental in identifying malware domains, especially in cases where the malware uses algorithmically generated domain names (DGAs). Palo Alto Networks firewalls and security management systems that use Suricata as an IDS engine (like AlienVault USM or OSSIM) are examples of security systems that pair passive DNS with IPS to block known malicious domains.

Logging at your resolver

The logs of your local resolvers are a last and perhaps most obvious data source for investigating DNS traffic. With logging enabled, you can use tools like Splunk plus getwatchlist or OSSEC to collect DNS server logs and explore for known malicious domains. If you're a small business and want more control or visibility into your local resolver than your broadband router provides, consider investing $50-100 and add a Raspberry Pi to your network as a local resolver. It's actually quite simple to install Raspbian OS using NOOBS. Follow the instructions from this Pi community article to install the lightweight recursive resolver, dnsmasq. Enable the logging facility, which provides human readable audit of DNS traffic. Ten year olds are learning OS and programming basics on Raspberry Pi, so don't be intimidated. 

Despite peppering this column with links to documentation, case studies, and examples, I've barely scratched the surface of the many ways you can monitor DNS traffic. And bear in mind that you can use several of these methods in a complementary manner.