CipherShed: TrueCrypt's Replacement

TrueCrypt was an open source software program that enabled you to encrypt your computer files using keys that were protected by a separate TrueCrypt passphrase. It allowed users to create hidden volumes whose existence would only be revealed with a secret password. The encryption is transparent to the user and it is done locally at the user’s PC. On Wednesday, May 28^th, a message was posted on the TrueCrypt website, alerting TrueCrypt users not to use the application because it isn’t secure enough.

Ever since then, users have been looking for an alternative, safe encryption utility solution.

Cryptographers Matthew Green and Kenneth White, Principal Scientist at Social & Scientific Systems, head the Open Crypt Audit Project and have been considering to take over TrueCrypt’s development and are working on the second phase of its audit process.

  The audit process consists of a thorough analysis of TrueCrypt’s code that accountable for the actual encryption process.  A TrueCrypt developer has expressed disapproval for the project, which could potentially fork the software (taking a copy of source code from on software package and start independent development on it).  "I don't feel that forking TrueCrypt would be a good idea, a complete rewrite was something we wanted to do for a while," he said. "I believe that starting from scratch wouldn't require much more work than actually learning and understanding all of TrueCrypt's current codebase. I have no problem with the source code being used as reference."

CypherShed Development

As the need for a secure alternative to TrueCrypt escalades, there have been several other attempts to fork the software.

 One of these projects is called CipherShed. According to the TrueCrypt open source license, use of the code is permitted if all references to TrueCrypt are removed from it, and if the final software doesn’t contain "TrueCrypt" in its name.

"CipherShed is cross-platform; it will be available for Windows, Mac OS and GNU/Linux," the developers say.

CipherShed is a program that can be used to create encrypted files or encrypt entire drives (including USB flash drives and external HDDs). There’s no complicated commands or knowledge required; a simple wizard guides you step-by-step through every process. After creating an encrypted file or disk drive, the encrypted volume is mounted through CipherShed. The mounted volume shows up as a regular disk that can be read and written to on-the-fly. The encryption is transparent to the operating system and any programs. When finished, the volume can be unmounted, and stored or transported elsewhere, fully secured. Encryption volumes can be moved from OS-to-OS (eg, Windows to Mac) with full compatibility.

CipherShed is still under development.  According to project initiator, Jos Doekbrijder, an alpha release of CipherShed will be made available for download soon. The goal for its first release includes the following:

• Scrub forked code of images and the name TrueCrypt
• Fix known security issues pointed out by security experts
• Recompile binaries for Windows, Linux, and Mac, with updated libraries
• Openly review changes, and solicit feedback from security community
• Release signed binaries and source packages

This release will be based on the latest full version of TrueCrypt (v7.1a), but eventually the group is aiming to create an entirely new product that will contain none of TrueCrypt's code.

Monitoring DNS Traffic for Threats

Here are several methods to monitor DNS traffic for security threats.
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 Networks, Cisco Systems, WatchGuard). Sonicwall and Palo Alto can detect and block certain DNS tunneling traffic, as well.

Intrusion detection systems
Whether you use Snort, Suricata, 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.

(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.
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