blueblog - by Christian J. Dietrich

Performance Profiling Analysis using perf

nospam@example.com (Christian J. Dietrich) — Mon, 08 Apr 2013 22:22:00 +0200

While most of the stuff we analyze is Windows malware, when it comes to implementing detection or analysis approaches, we surely turn to GNU/Linux. One of the best tools I stumbled upon when it comes to profiling, i.e. analyzing the execution performance of C code under Linux is perf. Since most of the time we have to develop code that has to run fast, especially when dealing with carrier-grade network links of 10 GbE, profiling is inevitable. perf is extremely useful as it barely adds any overhead, is easy to use and precise. For example, in order to measure while running a userspace application, perf is called as easy as:



perf record -g ./application [params and args for the application]

On a multicore system, the performance overhead induced by perf while monitoring a single-threaded application is hardly noticeable. But the real magic lies within the simple yet powerful result reporing. In order to get a histogram of time spent in each function, it is as simple as



perf report

The first column shows the relative amount of time spent in the respective function. At the top, the functions where most computing time is consumed are displayed. This provides the developer with a quick view on the functions which potentially profit most from code optimizations. Thus, as shown in the example screenshot above I would dig into the libmagic stuff first. The console user interface is interactive and allows to navigate and dig down tree-structured call chains. In addition, it can annotate the assembly using the surrounding C source code, as shown here (simply press 'a'):

Finally, perf can print an annotated call graph snippet using

perf report -g

Note that the code should be compiled with -fno-omit-frame-pointer and -ggdb. To me, one of the results clearly indicated to use tcmalloc instead of the standard glibc malloc. I can really recommend profiling with perf.

Tracking the Command and Control Activity of Botnets

nospam@example.com (Christian J. Dietrich) — Wed, 13 Feb 2013 22:22:00 +0100

As part of our research on botnets, we developed recognition techniques for botnet command and control flows, such as CoCoSpot. Obviously, we use these techniques to track C&C channels and their activities. Throughout our analysis period of more than three years, we have seen several botnets come and go. Some botnets have faced dedicated takedowns, such as Rustock, Mariposa, Mega-D, Kelihos and Pushdo, while others cease without further ado.

By help of our tracking means, we are able to classify the activity of C&C channels. The following figure graphs the activity of some 25+ prevalent botnets in terms of consecutive C&C activity by family, as seen and covered by our tracking means, as well as public attention. The x-axis reflects the time period since February, 1st, 2010 until February, 13th, 2013, while the y-axis lists botnet families. A star depicts a dedicated takedown action. Note that, in case of Mariposa and Mega-D, the takedown actions have taken place before the beginning of the time period in this graph. The Mariposa takedown has occurred on December 23rd, 2009, and Mega-D has been taken down in November 2009. In these cases, the stars are placed on the start of the time period in order to visualize the preceding takedown. A thin black line with black markers represents the time period where new binaries are distributed, but none of the binaries exhibit an active C&C channel. Inactive C&C channels are caused, for example, by outdated binaries, unreachable C&C servers or sinkholing (possibly after successful takedowns). The Rustock takedown operation b107 by Microsoft's DCU is an example of such a successful takedown. Similarly, the Harnig botnet, which is believed to have been the main distributor of Rustock (most likely via pay-per-install), exhibits inactive C&C since March, 2011. This correlates to the time of the Rustock takedown operation. Coincidence?

C&C activity of botnets over time

In contrast to inactive C&C, a thick red bar represents the time periods where active C&C communication has been observed, and this is where things get really interesting. Every time I look at this graph, I am astonished by the fact that some botnets manage to operate successfully since several years. Cutwail, Virut, Sality, Palevo and Lethic are mere examples for such long-living botnets. However, their strategies for continued operation differ. While Sality has had a builtin peer-to-peer (P2P) component for years, Virut has experienced the comfort of using just a handful of domains in order to contact the C&C server. In case the domains cannot be resolved, a domain generation algorithm (DGA) kicks in. However, only recently, a takedown operation addressed Virut. Palevo seems to keep it simple, neither P2P nor DGA nor significantly low TTLs on the DNS responses (which could indicate fast flux). Instead Palevo seems to rely on new and migrating domains. Similar to Palevo, Lethic manages to bootstrap its C&C by plain old DNS resolution. These are just some examples of long-lasting botnets with active C&C, most of which have a centralized primary C&C architecture. In contrast to botnets with centralized C&C, several peer-to-peer botnets have emerged. Storm, Miner, ZeroAccess, Kelihos and Zeus P2P exhibit a primary C&C which is based on a P2P network, probably motivated by increased resilience. While Storm and Miner ceased, ZeroAccess, Kelihos and Zeus P2P show significant C&C activity — an observation also covered in our yet-to-be-published research paper on P2P botnet resilience.

On the sustain of botnet takedowns
What do we learn from this? On the one hand, as can be seen in the figure, the takedowns of the Bredolab as well as the Rustock botnet have a long-lasting effect. Although for Bredolab and Mega-D we witness active C&C during up to several months after the takedowns, none of these botnets manage to achieve active C&C communication in the long run. On the other hand, we have seen quite a few botnet families resurrect from takedowns. For example, researchers initiated a takedown of the Pushdo botnet in August 2010. However, even two years after the takedown, we still observe active executions of Pushdo. The Mariposa botnet is believed to have been taken down in December 2009, but we have seen active Mariposa command and control traffic ever since. Similarly, although the Nitol botnets have been taken down in September 2012, many Nitol binaries manage to successfully bootstrap and reach a viable C&C server, because they do not rely on the suspended domains such as 3322.org. In addition, the Tedroo botnet has been addressed in a takedown action in July, 2012. However, again, we observed active C&C communication of the same botnet family just within days after the takedown, continuing for at least three months. Thus, from an observational point of view, the challenge of botnet family takedowns lies in their sustain.

Some botnets even cease without a dedicated (publicly known) takedown of the C&C infrastructure. For example, the Miner botnet has not been addressed in a dedicated takedown operation of its peer-to-peer-based C&C, but its activity diminished significantly after October 2011. Similarly, the Renos botnet has ceased its operation, although possibly after removal signatures of the Renos binaries have been distributed by Microsoft as part of its Removal Tool MSRT. It is an open question as to whether the criminals behind these botnets just moved on to the next botnet. Most notably, the authors of Kelihos/Hlux (some consider Kelihos the successor of Waledac) stick to their botnet and change aspects such as the C&C encryption when faced with a takedown.

While many of the botnets mentioned above have been subject to takedown or sinkholing, it becomes obvious that a successful takedown is by far not an easy process. Bot masters distribute their infrastructure so that a takedown operation requires many different parties to cooperate — a challenging task.

Remarks
Finally, just a couple of remarks: Note that the monitoring time period has been interrupted by maintenance periods, from mid-February to mid-March 2011 as well as end-May to mid-July 2012. Furthermore, the per-family perspective does not always reflect all activity of the correspondings botnets; however, it can be considered a lower estimate. Especially since some families exhibit (lots of) distinct botnets, we certainly do not cover every unique botnet of that particular family. For example, in case of toolkit-based families such as Zeus and SpyEye, several distinct botnets may be formed. In our C&C activity tracking, we restrict ourselves to whole families instead of individual botnets on purpose.

Exploiting Visual Appearance to Cluster and Detect Rogue Software

nospam@example.com (Christian J. Dietrich) — Fri, 07 Dec 2012 13:37:00 +0100

While malware comes in many different flavors, e.g., spam bots, banking trojans or denial-of-service bots, one important monetization technique of recent years is rogue software, such as fake antivirus software (Fake A/V). In this case, the user is tricked into spending money for a rogue software which, in fact, does not aim at fulfilling the promised task. Instead, the rogue software is malicious, might not even have any legitimate functionality at all, and entices the user to pay. However, all rogue software has in common to provide a user interface, e.g., be it to scare the user, or in order to ask for banking credentials, or to carry out the payment process. The following figures show example screenshots of two typical rogue software flavors.

The first displays a Fake A/V user interface, mimicking a benign antivirus application, while the second exhibits a ransom screen (in German), asking the user to pay before the computer is unlocked (in fact the computer appears just visually locked). Especially the later category, ransomware, is considered an increasing threat with more than 120,000 new ransomware binaries in the second quarter of 2012. In addition, referring to the C&C tracking of Fake A/V and ransomware botnets, we observe a significant increase in activity since June 2011.

As rogue software is required to provide a user interface, we aim at exploiting its visual appearance in order to cluster and classify rogue software. We motivate our efforts by the relatively low A/V detection rates of such rogue software, and we aim to complement existing techniques to strive for better detection rates. In particular, we observed that the structure of the user interfaces of rogue software remains constant and can be used to recognize a rogue software family or campaign. Using a perceptual hash function and a hierarchical clustering approach, Christian Rossow and I, we propose a scalable and effective approach to cluster associated screenshot images of malware samples.
In short, the main contributions of our work are threefold:

We provide a scalable method to cluster and classify rogue software based on its user interface, an inherent property of rogue visual malware.

We applied our method to a corpus of more than 187,560 malware samples of more than 2,000 distinct families (based on Microsoft A/V labels) and revealed 25 distinct types of rogue software user interfaces. Our method successfully reduces the amount of more than 187,560 malware samples and their associated screenshot images down to a set of human-manageable size, which assists a human analyst in understanding and combating Fake A/V and ransomware.

We provide insights into Fake A/V and ransomware campaigns as well as their payment means. More specifically, we show a clear distinction of payment methods between Fake A/V and ransomware campaigns.

As an example and in order to underline the usefulness of our approach, we used the our visual clustering to enumerate the campaigns that can be attributed to the Winwebsec family. Note the visual similarity among the different campaigns, sometimes it is even difficult to spot the difference. Typically, the campaigns differ in names as well as logos.

I am delighted to announce that our paper was accepted for the security track of ACM's 28th Symposium On Applied Computing 2013. A preprint of our manuscript for ACM SAC 2013 is available here "Exploiting Visual Appearance to Cluster and Detect Rogue Software".

CoCoSpot - Recognizing Botnet C&C Channels using Traffic Analysis

nospam@example.com (Christian J. Dietrich) — Wed, 24 Oct 2012 15:48:22 +0200

A defining characteristic of a bot is its ability to be remote-controlled by way of command and control (C&C). Typically, a bot receives commands from its master, performs tasks and reports back on the execution results. All communication between a C&C server and a bot is performed using a specific C&C protocol over a certain C&C channel. Consequently, in order to instruct and control their bots, bot masters ‐ knowingly or not ‐ have to define and use a certain command and control protocol.

Plaintext C&C

Historically, bots used cleartext C&C protocols, such as plaintext messages transmitted using IRC or HTTP, as shown in the Rbot C&C example above. However, a C&C channel relying on a plaintext protocol can easily be detected. Methods such as payload byte signatures or heuristics on common C&C message elements such as IRC nicknames are examples for such detection techniques. To evade payload-based detection, botnets have evolved and often employ C&C protocols with obfuscated or encrypted messages as is the case with Waledac, Zeus, Hlux, TDSS/Alureon, Palevo, Renos, Virut and Feederbot, to name but a few. In fact, pretty much all recent botnets employ some kind of encryption in their C&C protocol. The following two images show an encrypted Virut C&C message and its decrypted plaintext. This reveals that the underlying carrier protocol is still IRC, or IRC-like. The encryption is basically a four-byte XOR with a random bot-chosen key.

Encrypted Virut C&C

Decrypted Virut C&C message

The change towards encrypted or obfuscated C&C messages effectively prevents detection approaches that rely on plaintext C&C message contents. Lately, we take a different approach to recognize C&C channels of botnets and fingerprint botnet C&C channels based on traffic analysis properties. The rationale behind our methodology is that for a variety of botnets, characteristics of their C&C protocol manifest in the C&C communication behavior. For this reason, our recognition approach is solely based on traffic analysis.

As an example, consider a C&C protocol that defines a specific handshake – e.g., for mutual authentication – to be performed in the beginning of each C&C connection. Each request and response exchanged during this handshake procedure conforms to a predefined structure and length, which in turn leads to a characteristic sequence of message lengths. In fact, we found that in the context of botnet C&C, the sequence of message lengths is a well-working example for traffic analysis features. The following figure shows the sequence of the first 8 messages in four Virut C&C flows and two Palevo/Rimecud/Pilleuz C&C flows. Whereas Virut exhibits similar message lengths for the first message (in the range 60-69) and a typical sequence of message lengths at positions five to eight, for Palevo, the first three message lengths provide a characteristic fingerprint.

Examples of message length sequences for Virut and Palevo C&C flows

Leveraging statistical protocol analysis and hierarchical clustering analysis, we develop CoCoSpot, a method to group similar botnet C&C channels and derive fingerprints of C&C channels based on the message length sequence, the underlying carrier protocol and encoding properties. The huge benefit of our approach is to be independent from payload byte signatures which enables the detection of C&C protocols with obfuscated and encrypted message contents. In addition, our C&C flow fingerprints complement existing detection approaches while allowing for finer granularity compared to IP address or domain blacklists. As a side-effect, our C&C flow clustering can be used to discover relationships between malware families, based on the distance of their C&C protocols. Experiments with more than 87,000 C&C flows as well as over 1.2 million Non-C&C flows have shown that our classification method can reliably detect C&C flows for a variety of recent botnets with very few false positives.

CoCoSpot classification evaluation results

The figure above shows the results of the CoCoSpot classification as a cumulative distribution function for all families that were included in both, true positive and false positive analysis. Note that the true positive rate values are given on the left y-axis, the false positive rate values on the right y-axis. More than half of all families have a true positive rate of over 95.6%. A small fraction of seven C&C families had true positives rates lower than 50%, which was caused by too specific cluster centroids. In most of these cases, we had too little training data to learn representative message length variations of a particular active C&C protocol, which could be improved by adding more training data for this family. For 88% of the families, the false positive rate is below 0.1%, and 23 cluster families do not exhibit any false positive at all. For the few families that cause false positives, we observed that the corresponding cluster centroids have high variation coefficients on many message length positions, effectively rendering the centroids being too generic and possibly matching random flow patterns.

I am happy to announce that the manuscript of our journal article on CoCoSpot has been accepted by Elsevier's Computer Networks journal in the special issue on Botnets. The published version of our manuscript is available from Sciencedirect.

Preventing ARP flux on Linux

nospam@example.com (Christian J. Dietrich) — Tue, 13 Mar 2012 09:05:11 +0100

ARP, the address resolution protocol, is used on an Ethernet network to map IP addresses to hardware (MAC) addresses. By default, a Linux box with several network interfaces will respond to ARP requests received on any interface for any of the IP addresses of its interfaces. Here is an example: Let's assume we have a box which is connected with two interfaces A (MAC 00:00:00:AA:AA:AA) and B (MAC 00:00:00:BB:BB:BB). Interface A is configured to the IP address 172.16.0.1 and B to 172.16.0.2. Thus, both interfaces point to the same segment.

We use arping to query for the hardware address of the IP address 172.16.0.1 and expect to get the MAC address 00:00:00:AA:AA:AA of interface A in return.



[root@nugger]# arping -I eth0 172.16.0.1

ARPING 172.16.0.1 from 172.16.0.99 eth0

Unicast reply from 172.16.0.1 [00:00:00:AA:AA:AA]  7.889ms

Unicast reply from 172.16.0.1 [00:00:00:BB:BB:BB]  8.014ms



[root@nugger]# arping -I eth0 172.16.0.2

ARPING 172.16.0.2 from 172.16.0.99 eth0

Unicast reply from 172.16.0.2 [00:00:00:AA:AA:AA]  6.612ms

Unicast reply from 172.16.0.2 [00:00:00:BB:BB:BB]  8.991ms

Instead, we get the MACs of A and B alternating. You can tune this behavior using arp_ignore and arp_announce sysctl properties:



arp_ignore - INTEGER

Define different modes for sending replies in response to

received ARP requests that resolve local target IP addresses:

0 - (default): reply for any local target IP address, configured

on any interface

1 - reply only if the target IP address is local address

configured on the incoming interface

2 - reply only if the target IP address is local address

configured on the incoming interface and both with the

sender's IP address are part from same subnet on this interface

3 - do not reply for local addresses configured with scope host,

only resolutions for global and link addresses are replied





arp_announce - INTEGER

Define different restriction levels for announcing the local

source IP address from IP packets in ARP requests sent on

interface:

0 - (default) Use any local address, configured on any interface

...

2 - Always use the best local address for this target.

In this mode we ignore the source address in the IP packet

and try to select local address that we prefer for talks with

the target host. Such local address is selected by looking

for primary IP addresses on all our subnets on the outgoing

interface that include the target IP address. If no suitable

local address is found we select the first local address

we have on the outgoing interface or on all other interfaces,

with the hope we will receive reply for our request and

even sometimes no matter the source IP address we announce.

Setting net.ipv4.conf.all.arp_ignore=1 and net.ipv4.conf.all.arp_announce=2 in /etc/sysctl.conf provides adequate settings. However, you should check whether these settings work in your network environment, especially if you depend on reaching an IP address from any other than the interface that it is configured on.



net.ipv4.conf.all.arp_ignore=1

net.ipv4.conf.all.arp_announce=2

Feederbot - a bot using DNS as carrier for its C&C

nospam@example.com (Christian J. Dietrich) — Fri, 02 Sep 2011 18:05:00 +0200

DNS as carrier for botnet C&C seems to be getting popular. Concerning its usage as botnet C&C, DNS has not been seen so far. Additionally, in typical network environments, DNS (at least when destined for the preconfigured DNS resolvers) is usually one of the few protocols – if not the only one – that is allowed to pass without further ado. Thus, botnets using DNS as C&C benefit from the fact that currently there is no specifically tailored detection mechanism, which in turn, raises the probability for the botnet to remain undetected.

During our work on covert communication of botnet command and control channels, we analyzed Feederbot in some detail and monitored it over the last year. In this post, I will provide some insight on the C&C.
Not only Feederbot, but also Morto seems to be using DNS as carrier for its command and control channel.

But let us focus on Feederbot for now. Feederbot uses valid DNS syntax for its DNS messages. Messages from the C&C server to the bot are transmitted in the rdata field of a TXT resource record. The DNS requests have the several different schemes for the question domain name (qname), similar to the following where [CHUNK-ID] is an int >= 0, incremented by 1:



[50 bytes].[CHUNK-ID].[qdparam].0.f2.[TLD].   IN   TXT

The DNS responses typically carry one TXT RR in the answer section (sometimes repeated in the authority section) with a 220 byte string that is base64 encoded. Here is an example:



xMtwHYRyZu/z4QbhBKZIVWvPBfiuGn+jb1WQxtZN7PR9Wf0sfnAqxDOJD9LgmwfFaU

Go6fdtgZ0lIQyAx1VWJw+vzdHdxMpHu6xfMRq8sVSfqwPvI9TEIV8pkXw4P4TCSH05

BAO1LGPMQ+XD+TYLY2woxM1j06mCMhrNjWzI8WbmCBlj2/dpR73KBnDl/DRmheKWMJ

x2dUTp4iFMH4N9kXjeOYis

Once base64 decoded, the messages are still no real plaintext, because they are encrypted with RC4. Feederbot uses a variety of different RC4 encryption keys and even stacks RC4 encryption. A specific part of the DNS query domain name is used to transmit parameters for key derivation. As an example, one such parametrized key derivation function takes as input a substring of the query domain name, denoted as 'qdparam' in the example above. The value of the substring 'qdparam' is then RC4-encrypted with the (constant) string “feedme” (hence the name of the bot) and the result is used to initialize the RC4 decryption of the actual C&C message chunks. The stream cipher is used in a stateful manner, so that if a message chunk gets lost, decryption of all subsequent message chunks will fail. In addition, Feederbot’s C&C message chunks make use of cyclic redundancy checks to verify the decryption result. The CRC32 checksum preceeds message chunk payload and is not encrypted.

The fact that CRC32 checksums are used makes it comfortable to know whether decryption works or not. Interestingly, we have seen ANY as resource record type in some of the queries, too. In order to perform the DNS requests, the bot relies on Windows DNSAPI.dll::DnsQuery_W.

The following figure shows an important part of the disassembled RC4 initialization routine:

Well, the drawback of encryption is that you need a key and you better choose one that is easy to remember, such as:

So, what is the lesson we learn from Feederbot? Watch your DNS traffic!

DNS as carrier for botnet C&C

nospam@example.com (Christian J. Dietrich) — Mon, 22 Aug 2011 17:49:00 +0200

Botnets have become one of the biggest security issues on the Internet imposing a variety of threats to Internet users. Advances in malware research have challenged botnet operators to improve the resilience of their C&C traffic. Partly, this has been achieved by moving towards decentralized structures (like P2P) or by otherwise obfuscating and even encrypting communication.

Recently, Christian Rossow and me, we looked into what we term covert communication, that is command and control communication which is hidden in what seems to be regular Internet traffic. We discovered and reverse engineered Feederbot, a botnet that uses DNS as carrier for its command and control. Using k-Means clustering and a Euclidean Distance based classifier, we correctly classified more than 14 million DNS transactions of 42,143 malware samples concerning DNS C&C usage. Interestingly, this analysis revealed yet another bot family with DNS C&C. In addition, we correctly detected DNS C&C in mixed office workstation network traffic.

Our paper dealing with DNS as carrier for botnet command and control channels got accepted at this year's EC2ND conference. I will be presenting the results at EC2ND which is going to take place in Gothenburg, Sweden, September 6-7 at Chalmers University.

Best practice: chrooted BIND on CentOS 5.6+ with DNSSEC aware resolution

nospam@example.com (Christian J. Dietrich) — Sat, 02 Jul 2011 21:50:00 +0200

BIND is the most prevalent DNS server software. Since CentOS 5.6, BIND is readily available in the more recent version 9.7.0 in the packages bind97*. Among others, a preconfigured chroot environment is provided. In order to use chrooted BIND, install the package bind97-chroot and make sure that ROOTDIR is correct in /etc/sysconfig/named:



[us@ns ~]# grep ROOTDIR /etc/sysconfig/named

ROOTDIR=/var/named/chroot

Note that a service named restart is required in case BIND was running beforehand.
In order to provide the chroot environment, certain files and directories are (re)mounted under /var/named/chroot



/etc/named on /var/named/chroot/etc/named type none (rw,bind)

/var/named on /var/named/chroot/var/named type none (rw,bind)

/etc/named.conf on /var/named/chroot/etc/named.conf type none (rw,bind)

/etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind)

/etc/rndc.conf on /var/named/chroot/etc/rndc.conf type none (rw,bind)

/etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind)

/usr/lib/bind on /var/named/chroot/usr/lib/bind type none (rw,bind)

/etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind)

/etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind)

Thus, for example /etc/named.conf is actually made available to the chrooted BIND and you as the admin just have to take care of one file. Previously, there used to be two named.confs, one inside the chroot environment and one outside. If you do not have a named.conf yet, I suggest you start using the named.conf template by Rob Thomas of Team Cymru.
Heading for DNSSEC validating resolution, the most important settings in named.conf are the following:



    // ****** DNSSEC relevant settings ****** //

    // Since 9.5 the default value is dnssec-enable yes;.

    // This statement may be used in a view or global options clause.

    dnssec-enable yes;

    // indicates that a resolver (a caching or caching-only name server)

    // will attempt to validate replies from DNSSEC enabled (signed) zones.

    // To perform this task the server also needs either a valid trusted-

    // keys clause (containing one or more trusted-anchors or a managed-keys

    // clause. Since 9.5 the default value is dnssec-validation yes;

    dnssec-validation yes;

    dnssec-lookaside auto;

    / Path to ISC DLV key /

    //bindkeys-file "/etc/named.iscdlv.key";

    / Path to root DNSSEC key /

    bindkeys-file "/etc/named.root.key";

As shown above, I changed the bindkeys-file statement to point to the root DNSSEC key instead of ISC's DLV root key. This is fine because by now there is a verifiable path to validate ISC's DLV root key (signed root, signed .ORG and signed isc.org and dlv.isc.org zones). Thus, ISC's DLV key does not need to be included any longer.

Please note that as of now (bind97-9.7.0-6.P2.el5_6.3), there is a bug in the init script of bind97 which has been acknowleged upstream. Basically, the root DNSSEC key is not mounted in the chroot environment. Until the bug will be fixed in the package, you should apply the fix (I also provided in the bug report):



# A possible fix is to include /etc/named.root.key in /etc/init.d/named, i.e.

# change the contents of the ROOTDIR_MOUNT variable in /etc/init.d/named from



ROOTDIR_MOUNT='/etc/named /etc/pki/dnssec-keys /var/named /etc/named.conf

/etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc.key

/usr/lib64/bind /usr/lib/bind /etc/named.iscdlv.key'



# to



ROOTDIR_MOUNT='/etc/named /etc/pki/dnssec-keys /var/named /etc/named.conf

/etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc.key

/usr/lib64/bind /usr/lib/bind /etc/named.iscdlv.key /etc/named.root.key'

Finally you should test with a domain that has authoritative DNSSEC information. The answer must contain the AD flag.



[us@ns ~]# dig +dnssec @127.0.0.1 gov. ns

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-6.P2.el5_6.2 <<>> +dnssec @127.0.0.1 gov. ns

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14572

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1



;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 4096

;; QUESTION SECTION:

;gov.                           IN      NS



;; ANSWER SECTION:

gov.                    172800  IN      NS      b.gov-servers.net.

gov.                    172800  IN      NS      a.gov-servers.net.

gov.                    172800  IN      RRSIG   NS 7 1 172800 20110609040023 

20110604040023 43879 gov. FnygljkPqlL9Q08CX5lixJ7O5bB6ysM...

Delegating IN-ADDR.ARPA domains for reverse DNS resolution (PTR: IP to hostname)

nospam@example.com (Christian J. Dietrich) — Wed, 01 Jun 2011 19:03:00 +0200

Part of a clean DNS configuration is to maintain a mapping from IP addresses to hostnames. Especially in email exchange, many mail servers require that the sender's IP address can be looked up in DNS and e.g. maps to a hostname. You can easily test this using the tool dig which is usually part of bind-utils:



$  dig  -x 80.67.18.126

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19989

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0



;; QUESTION SECTION:

;126.18.67.80.in-addr.arpa.     IN      PTR



;; ANSWER SECTION:

126.18.67.80.in-addr.arpa. 86400 IN     PTR     mxlb.ispgateway.de.

The listing shows the lookup for a PTR record of (one of) the mail server's IP address(es) of my domain. dig provides the -x flag which behind the scenes makes a query for 126.18.67.80.in-addr.arpa. of resource record type PTR. Equivalently, you can issue 'dig 126.18.67.80.in-addr.arpa. PTR'. As we can see from the output above, the IP address 80.67.18.126 maps to the hostname mxlb.ispgateway.de. (which in turn maps to 80.67.18.126 when querying for an A RR type).

In order to be able to provide reverse mappings for a set of IP addresses that have been assigned, there should be a delegation (or referral) from the authoritative entity which assigned the IP addresses. Usually you will want to have CIDR ranges of IPv4 addresses delegated. Thus, let's assume the upstream ISP takes care of the whole /24 network 1.2.3.0/24 (i.e. 1.2.3.0-1.2.3.255) and the subnet IP address range 1.2.3.32/27 (i.e. 1.2.3.32-1.2.3.63) should be delegated from the authoritative (upstream ISP) nameserver A to (your) nameserver B. The following configuration snippets provide an example configuration for BIND and illustrate the required steps.

Thus, A needs to be configured to delegate the DNS entries concerning the IP addresses 1.2.3.32/27 to the nameserver B as follows:



; depending on your style of zone files, you might not have an $ORIGIN in them at all

$ORIGIN 3.2.1.IN-ADDR.ARPA.

@            IN  SOA   ns1.A.com. dnsadmin.A.com. (

                              2011052501; serial number

                              1h             ; refresh after

                              1h             ; retry update after

                              2w             ; expire after

                              1h             ; negative caching TTL)

              IN  NS      ns1.A.com.

              IN  NS      ns2.A.com.



; here go PTR records for the IP address range 1.2.3.0-.31 which is not delegated to B

1            IN  PTR   some.absolute.hostname.example.com.

...

31           IN  PTR   note.that.relative.names.dont.make.sense.here.



; here goes the referral for the subnet 1.2.3.32/27 to B's name server(s)

32/27         IN  NS  ns1.B.com.

32/27         IN  NS  ns2.B.com.    ; in case B has a second NS



; Now comes an important part. the above statement does not suffice to refer queries to B's name server.

; In addition, we also have to define CNAMEs for ALL IP addresses in the subnet and map them to

; the referred domain 32/27.

32            IN  CNAME   32.32/27.3.2.1.IN-ADDR.ARPA.

; or alternatively

32            IN  CNAME   32.32/27

....

63            IN  CNAME   63.32/27  ; keep going from 32 to 63...

; ...or alternatively use the $GENERATE macro of BIND 8.2+

$GENERATE 32-63 $ CNAME $.32/27

Note that we could have chosen ANY arbitrary name instead of 32/27 for the CNAME targets as well as the referral (one could even refer outside the in-addr.arpa tree). However, RFC 2317 recommends the above scheme (for good reason).

On the "target" nameserver B, the zone looks similar to:



$ORIGIN 32/27.3.2.1.IN-ADDR.ARPA.

@            IN  SOA   ns1.B.com. dnsadmin.B.com. ( ... )

              IN  NS      ns1.B.com.

              IN  NS      ns2.B.com.



; provide the PTR mapping for the IP addresses 1.2.3.32-.63 (maybe omit first and 

; last as they are network and broadcast addresses).

32            IN  PTR   some-net.b.example.com.

33            IN  PTR   host33.b.example.com.

....

62            IN  PTR   web.example.com.

63            IN  PTR   host63.example.com.



; alternatively use the $GENERATE macro of BIND 8.2+

$GENERATE 32-63 $ PTR host$.b.example.com.

The configuration of the zone on the nameserver B is something like:



...

    zone "32/27.3.2.1.in-addr.arpa" in {

      type master;

      file "data/1.2.3.32_27.reverse.zone";

    };

...

Testing the configuration
Here are some commands using dig in order to test the configuration:



; query one of the PTRs at B's nameserver

dig +norecurse  @[nameserver-of-B]  33.32/27.3.2.1.in-addr.arpa  PTR



; query A's nameserver for the exact referral

dig +norecurse  @[nameserver-of-A]  32/27.3.2.1.in-addr.arpa  ANY



; query A's nameserver for one of the PTRs

dig +norecurse  @[nameserver-of-A]  33.32/27.3.2.1.in-addr.arpa  PTR

dig +norecurse  @[nameserver-of-A]  33.3.2.1.in-addr.arpa  PTR



; query one of the PTRs starting at the root

dig -x 1.2.3.33

dig +trace -x 1.2.3.33

Kryptotag - Transport Layer Security with RSA-PSK

nospam@example.com (Christian J. Dietrich) — Tue, 29 Mar 2011 21:35:00 +0200

Last week, Kryptotag and SPRING took place at HGI in Bochum. It turned out to be a very interesting event, although unfortunately, I could not stay very long. My talk dealt with how Transport Layer Security with RSA-secured Pre-Shared Keys is used in the eID Online Authentication of the new German ID card. I provided a short recap on the default RSA key exchange and the plain Pre-Shared Key variant before outlining the difference to the RSA-PSK variant. My slides are available here.

TLS-RSA-PSK Cipher Suites for OpenSSL

nospam@example.com (Christian J. Dietrich) — Fri, 25 Feb 2011 19:38:20 +0100

Since November 2010, the new German electronic ID card provides a facility to perform an online remote authentication of the ID card holder. This method is called eID online authentication and is defined in the Technical Guideline TR-03110 of the Federal Office for Information Security. As part of the eID online authentication, personal data can be transmitted from the electronic ID card to its counterpart, the eID server. All data transmitted between the eletronic ID card and the eID server is supposed to be subject to secure messaging.

As the eID online authentication is specifically tailored to be used in web applications, the secure messaging channel between the eID card and the eID server is mapped to the Security Assertion Markup Language (SAML) and uses several TLS channels (Transport Layer Security, RFC 5246). In order to prevent man-in-the-middle attacks, the TLS channels are intertwined with the Terminal Authentication. This binding is realized by two aspects, one of them being the fact that special cipher suites are used which combine X.509 certificate based peer authentication with pre-shared keys. These cipher suites are termed TLS-RSA-PSK and defined in RFC 4279.

I implemented one of the TLS-RSA-PSK cipher suites as a patch to openssl-1.0.0c. This patch is EXPERIMENTAL. Apply it like so:



tar xvzf openssl-1.0.0c.tar.gz

cd openssl-1.0.0c

patch -p1 -i ../openssl-1.0.0c.tls-rsa-psk.patch

IMPORTANT NOTE: This patch is provided "as is". See LICENSE.txt for details.

Testing TLS-RSA-PSK
You can test locally whether your openssl with TLS-RSA-PSK works as follows. Make sure that you actually call the currently generated openssl binary (in the apps directory):



# launching the server

openssl s_server \

    -psk c033f52671c61c8128f7f8a40be88038bcf2b07a6eb3095c36e3759f0cf40837 \

    -key privkey.pem \

    -cipher RSA-PSK-AES256-CBC-SHA \

    -debug -state



# launch the client

openssl s_client -connect localhost:4433 \

    -psk c033f52671c61c8128f7f8a40be88038bcf2b07a6eb3095c36e3759f0cf40837 \

    -cipher RSA-PSK-AES256-CBC-SHA \

    -debug -state

You should then be able to pass data back and forth between the server and the client. Additionally, I have provided transscripts of what it looks like if it works. There is a server log and a client log.

Expert Comments on Possible Web Fraud

nospam@example.com (Christian J. Dietrich) — Mon, 14 Feb 2011 16:19:00 +0100

I gave a short interview to Sat.1 today about the technical skills needed in order to implement a system for online bets. The interview was broadcast as part of a short report on a case where maybe online fraud was involved, though this is still to be clarified.

LaTeX Editing on Windows

nospam@example.com (Christian J. Dietrich) — Sat, 05 Feb 2011 15:09:00 +0100

Yes, Windows is far from being an enjoyable LaTeX editing base. However, every once in a while, you will find yourself urged to edit LaTeX under Windows. Thus, I compiled a few steps in order to have a somewhat usable LaTeX editing environment. I use MiKTEX in combination with Texmaker (both free). Texmaker has a builtin PDF viewer and an IDE-style builtin compile initiator. As often, it is the small details that make the difference. I dislike using an external program as PDF viewer that locks the .pdf-file and prevents from successful re-compilation. As a consequence you have to close the PDF viewer manually before each and every compile. Texmaker's builtin PDF viewer does not lock the pdf-file and thus re-compilation works like a charm. Furthermore, the -synctex=1 option to pdflatex enables the PDF viewer to jump to the right position in the LaTeX source upon a right-click. Even if you have your own special series of commands for compilation, you can recreate them in the options of Texmaker. I use the following user-defined quick build command in the options (remove line breaks, leave the pipes):



bibtex %|

pdflatex -synctex=1 -interaction=nonstopmode %.tex|

pdflatex -synctex=1 -interaction=nonstopmode %.tex|

"C:/Program Files/Adobe/Reader 9.0/Reader/AcroRd32.exe" %.pdf

Note that Texmaker uses the internal PDF viewer even though Acrobat's Reader is supposed to be called as last step (bug? feature?). All in all, in my eyes, Texmaker is a great LaTeX editor.

Compiling Gnuplot 4.4.2 on CentOS 5.5

nospam@example.com (Christian J. Dietrich) — Wed, 01 Dec 2010 19:25:00 +0100

CentOS is a really fine platform for professional Linux servers which is - among others - characterized by stable software releases. However, especially in a research environment every once in a while you need a recent version of a software. CentOS ships with Gnuplot 4.0.0 but I need Gnuplot >=4.4. In case others need this, too, here are my compile instructions:



# make sure your system is uptodate

yum clean all

yum check-update

yum update



# based on a minimal installation, you need some packages in order to compile, I suggest

yum install gcc gcc-c++ make libX11 xauth

yum install cairo-devel pango-devel freetype-devel gd-devel



cd /usr/local/src/

wget http://sourceforge.net/projects/gnuplot/files/gnuplot/4.4.2/gnuplot-4.4.2.tar.gz/download

tar xzf gnuplot-4.4.2.tar.gz 

cd gnuplot-4.4.2

less INSTALL



# start compiling. I usually install self-compiled stuff at /opt/[PKG-NAME]

./configure --prefix=/opt/gnuplot442

make

# make sure the shipped version of gnuplot is removed (this is probably not necessary but prevents version mix-up)

yum remove gnuplot

make install



# you might want to add a symlink

ln -s /opt/gnuplot442/bin/gnuplot /usr/bin/gnuplot

neuer Personalausweis (nPA) - analysis of remaining risks

nospam@example.com (Christian J. Dietrich) — Tue, 02 Nov 2010 22:22:00 +0100

As posted before, we have done an analysis of the remaining risks of the new German ID card (neuer Personalausweis, nPA) conducted by the German Federal Ministry of the Interior (Bundesinnenministerium). In mid October 2010, we published the summary of our study, presenting the key findings of the remaining risks (in German) when using the eID functionality via the Internet.

As the summary is only available in German, I will try to sum up the key findings in English here. First of all, we have to state that we analyzed the eID functionality only (neither the sovereign identification with biometry etc. nor the signature function). Thus, you may compare the target of the eID function to what usually is achieved using username and password authentication today. However, the eID function has mutual authentication builtin. This is one of the biggest advantages compared to "classic" username/password authentication where the server side is - if at all - only authenticated by its SSL/TLS certificate (ever heard of phishing?). Furthermore, the nPA requires a secret PIN before it can be used which effectively turns it into a two-factor-authentication mechanism. Thus, the security level of the eID function can be regarded much higher than classic username/password authentication.

There is always two faces of the same coin, so what ARE the remaining risks? We found that the card reader category B (Basisleser) poses a certain threat: Malware on the user's computer may - under certain circumstances - misuse the eID function of an nPA. As the secret PIN must be entered via the computer's keyboard when using Cat-B card readers, a keylogger may easily catch the PIN. Note that this only works with Cat-B card readers, not with the higher class card readers Cat-S (Standardleser) or Cat-K (Komfortleser). For more details, see our summary. A list of certified card readers is available online.