techblog 

Recently we have seen a marked increase in the number of .uk domain names being used for phishing purposes. One phishing syndicate seems to be particularly prolific. They register 40-60 domains at a time to run phishing sites.

Real individuals with genuine addresses were listed as the registrant and administrative contact. Based on past activity, it would appear that the registrant listed is the victim of identity theft.

Please make sure you have malware protection installed before you investigate one of these sites. These are highly sophisticated phishing sites and have been known to embed malware in them.

They are targeting more than just banking information. For example, we have seen them phish for accounts of a well known online auction service. They set up a site that checked in with this auction service to ensure the victim has entered valid username and password. If a valid user and password are entered, it will log the victim into the real auction service. The phishing victim would have no idea that they did not visit a legitimate log-in page for the online auction service.

They do not target domains with keywords that you may expect to see with phishing. Here is a sample list of domains that have been used:
loltech.co.uk
loltech.me.uk
loltech1.co.uk
loltech1.me.uk
loltech2.co.uk
loltech2.me.uk
loltech3.co.uk
loltech3.me.uk
modeisp.co.uk
modeisp.me.uk
modeisp.org.uk

The only pattern we have been able to identify to help you establish whether this group is attempting to register a domain with your company is the IP addresses behind the name servers. During registration, they will provide their own name server to host the domain on. The host name used will be random, but the host will resolve to one of the following four IP addresses:
81.16.131.40
88.16.131.40
200.72.139.67
202.44.71.149

We have been advised that these IP address will eventually change, but may be used for up to 3 months.

Recently I had a weird problem on my laptop. Web browsing was slow and certain lookups failed altogether. The failures were exclusively associated with nominet.org.uk domain names, specifically connections to our office network. When the problems first started my mail client failed to work unless the VPN was activated, which is not the way our security policy mandates it should work. After a while the mail client failed even after activating the VPN. I was effectively locked out of my email unless I visited the office!

The error messages from the mail client suggested that the DNS lookup for the mail server was timing out. Using wireshark on the wireless interface I noticed that there were no DNS lookups for nominet.org.uk, though other search domains were being appended. Everything in System Preferences looked fine, /etc/resolv.conf had no surprises. However, I did find a suspect file: /etc/resolver/vpn-resolver-662638-0 which contained:

domain nominet.org.uk
nameserver 213.248.199.17
timeout 3

This file dated from early 2006, which seemed odd as the laptop was only installed in March 2008! I presume it was copied over from my previous laptop by the Migration Assistant. Removal of this file fixed the problem, but where did it come from?

Our present VPN solution is based on OpenVPN and I use the Tunnelblick client to connect. My first thoughts were to blame this combination. There have been some stability problems with Tunnelblick on Leopard, apparently. But, before we used this system we used an SSL VPN solution terminating on a Netscreen firewall. I used the VPN Tracker client from Equinux to connect. I now believe the rogue resolver file was left behind by VPN Tracker after it was deleted. I am still at a loss to explain why it took so long to start affecting the laptop, or why it appeared to degrade in stages, rather than just fail.

For a number of years I’ve been running Firefox (FF) with advert blocking extensions to make the whole web experience more pleasant.  Originally this was using AdBlock but for the last couple of years it has been with AdBlock Plus (ABP) and Filterset G.

However I recently got a bit fed up with the speed of FF to restart with 30 tabs open and so decided to investigate a bit.  Firstly I got to the bottom of the difference between AdBlock and ABP.  The former has been dead for a long time whilst the latter is live and apparently better developed.  No problem there I was already using the right one.

Then I discovered that the authors of ABP specifically caution you not  to use Filterset G because it will slow down FF and uses a different subscription mechanism.  Instead they recommend that you use a filterset from a recommended list, so I thought I would give it a try.

First though I had to remove Filterset G, which was not quite straightforward.  First you have to remove the FF add-on, easy enough.  But the last set of data it drew down is still present.  So then I de-installed and re-installed ABP but this kept the same data somewhere, so then I manually had to delete the filters added by Filterset G.

The next step was to add another add-on that ABP recommends, the element hider.  Again a simple FF add-on installation.  Finally I subscribed to some new filters, namely EasyList, EasyElement and ABP Tracking Filter, all accessed from the recommended list.

The end result is all the same ads blocked (it may even be better), a much faster FF and fewer of those obvious white spaces where ads used to be.  Altogether a good result.

Today, NLnet Labs released Unbound. A high performance, validating caching resolver implementation. It is fully DNSSEC-aware, up to the very latest standards such as NSEC3 and Opt-Out. Even if you don’t use DNSSEC, it is highly resilient to forgeries. It is the natural counterpart of NSD, NLnet Labs’ authoritative server.

The architectural concept behind unbound was developed in 2004. The modular design came from a wish to constrain complexity to very small modules. David Blacka implemented a prototype in Java, and Matt larson and others helped to make it fully featured. By the end of 2006, the prototype was done, and has been used in many standardization efforts in the IETF.

By that time, NLnet Labs became interested in building a validating caching resolver. Though inspired by early prototype, the C version is completely built from scratch. If you’ve ever used NSD, and appreciate the clarity, quality and robustness of the source code, then Unbound should not surprise you.

Unbound is very, very fast. It easily outperforms other DNS resolvers like PowerDNS or BIND. It runs on Linux, *BSD, Solaris, MacOSX. We expect Unbound to find its way to ISPs and other production level environments. NLnet Labs is committed to support Unbound. Any changes to that support will be notified two years in advance.

I found after I upgraded Toad for Oracle from 8.6.1 to 9.6.1, I could no longer read comments in PL/SQL code. They appeared as illegible, nonsense, unreadable text.

This is actually a problem with displaying the comments as italics. To avoid this, change the displaying of comments to be non-italicised as described below.

From the menu select:
View –> Toad Options –> Editor –> Behavior

In the Languages box, ensure PL/SQL is present in the drop down list, then select “Syntax highlighting”.

On the Highlighting tab, select “Comment” from the Styles list. Untick “Italic” in the Font style box and then press the Apply button.

PL/SQL comments should now be displayed legibly.

This is a follow up to my previous article, DomainKeys signing for nominet.org.uk e-mails… not just yet, which I wrote a month ago. Since then all I did was reading RFC4871 forsaking all my other duties, losing sleep and appetite.
After this I came up with the following findings:

• DomainKeys (rfc4870) is an obsolete standard for signing messages but still widely used (compared to DKIM)
• DKIM (rfc4871) is a current standard for signing messages
• DomainKeys defines signing policies but is vague about policies for subdomains
• DKIM doesn’t define policies. Policies, or rather Author Signing Practices(Sender Signing Practices), are separated from DKIM into a different standard which is still a draft and quite frequently revised: draft-ietf-dkim-ssp-03.txt
• If policies (practices) are not explicitly defined, Verifiers in both DomainKeys and DKIM assume that a Signing domain MAY sign messages and Verifiers should treat unsigned messages as if the domain supports neither DomainKeys nor DKIM.

After considering all this I came up with the following plan for rolling out of e-mails signing:

• Upgrade our mail servers to a version which supports both DomainKeys and DKIM signing
• Create DKIM and DomainKeys signing profiles on our mail servers
• Publish DKIM and DomainKeys selectors with public keys in nominet.org.uk zone
• Publish neither DomainKeys policies nor DKIM Author Signing Practices in nominet.org.uk zone effectively telling to Verifiers that Nominet messages MAY be signed
• Work out a correct Author Signing Practices (or whatever it’ll be called by that time) when it becomes a standard.

Having the plan I just followed it and as of today all outgoing @nominet.org.uk messages are signed both with DKIM and DomainKeys (subdomains originated messages, e.g. @lists.nominet.org.uk are not at the moment). One note though: for now we decided to publish the selectors with a “test mode” flag set but I think it’ll be removed very soon.

My appetite is back until I need to read another RFC.

In order to investigate a performance problem in our Oracle database, I needed to trace one of our batch PL/SQL procedures, which has been submitted via the dbms_job package to execute every morning. I had traced the procedure successfully when executing it manually from a SQL*Plus session: a SQL trace file was produced in the directory defined by the database parameter user_dump_dest. Below is a description of how I then went on to trace the procedure when it was executing as a job submitted via dbms_job.

Assume a job has been submitted to execute every morning at 9am:

variable job_num number
exec dbms_job.submit (:job_num, my_procedure, sysdate, '(trunc(sysdate + 1) + 9/24)');
commit;

From a SQL*Plus session examine dba_jobs_running, to verify that the job has started and obtain its session identifier (sid):

select * from dba_jobs_running;

 SID  JOB FAILURES LAST_DATE LAST_SEC THIS_DATE           THIS_SEC INSTANCE
---- ---- -------- --------- -------- ------------------- -------- --------
 356  467                             02/05/2008 14:37:35 14:37:35        0

Obtain the Oracle serial number (serial#) for this database session:

select sid, serial# from v$session where sid = 356;

SID SERIAL#
--- -------
356     701

Use the dbms_monitor.session_trace_enable procedure to start SQL tracing for this session:

exec dbms_monitor.session_trace_enable (356, 701);

A SQL trace file will be produced in the directory defined by the database parameter background_dump_dest. I was originally mistakenly looking for the file in the user_dump_dest directory, but background_dump_dest is the correct one, as it is an Oracle background process being traced here.

Once the job has completed use the tkprof utility to convert the output to a summarised, readable format:

tkprof livedb_j000_1850.trc sql_trace.txt sys=no explain=username/password

We have been using puppet, for all new server installs here at nominet for a few months now. The idea of course is to simplify the system administration, making us more agile and able to install a particular server with a particular specification far quicker.

It is also designed to give us repeatability, meaning each server “type” we install should be configured in an identical way with the only differences being the uniquely identifying configuration files, which also are controlled via puppet.

It is a paradigm shift I think, and it takes some while to get up to speed with administering a system via puppet rather than traditional methods. However, there are two techniques for testing and debugging your configuration that I have found invaluable. We are using subversion to provide a repository for all our puppet configuration.

Once I have made a change to the configuration and before I have checked this back into subversion I have found the following very useful to run:

puppetmasterd --parseonly --confdir=/var/home/jason/trunk --debug

The parses my configuration that I have checked out to trunk and if it encounters a syntax error in any of the files gives me a file name and line number so I can go debug the issue.

Next up, is when I run the config on the server, it is useful to use the following:

puppetd --debug --test

Somewhat contradictory, this will actually apply the configuration to the system, but runs puppetd just once (rather than every 30 minutes) and provides copious quantities of output so you can spot if your configuration has actually managed to accomplish what you had intended.

I think when you are first getting to grips with puppet, these options can be really useful