This morning I checked my email and found a phishing message purporting to be from Amazon. The link appeared as
http://www.amazon.com/exec/obidos/flex-sign-in/
but really pointed to
http://bvs.ucsg.edu.ec/lildbi/manual/.amazon/index.html
Immediately I thought of this as a good opportunity to "blackhole" the domain using our DMZ name servers.
But first a little background. Recently we reconfigured all of our internal resolvers to forward through our DMZ name servers, which in turn forward through their upstream (ISP) nameservers, which are either Internap or Qwest depending on location. By using a controlled packet flow we can be assured of knowing where our questions and answers (queries and replies) are going.
It also provides an opportunity to override DNS resolution as needed for specific domains. Today, that domain is bvs.ucsg.edu.ec.
Enter our blackhole.zone file...
$TTL 1h
@ IN SOA @ root (
2005060601 ; serial
1H ; refresh
15M ; retry
4W ; expiry
5M ) ; negativeTTL
1D IN NS ns1.example.org.
1D IN NS ns2.example.org.
1D IN A 127.0.0.2
* 1D IN A 127.0.0.2
The zone file above ensures that queries for any name below the domain name, including the domain name itself, are answered with an A record for 127.0.0.2. By returning this address we circumvent any follow-on traffic, since the asking host will simply start talking to itself (localhost) and should, in virtually all cases, receive a connection refused.
There are other strategies, such as using a defined internal IP address of a tracking webserver which will return a "Sorry, the web address you are trying to reach has been banned for security purposes, now get back to work!" message. In the meantime, the URL they tried to get to is logged. This provides a neat, centralized location for auditing purposes to get an idea of just how many suckers following the phisher's link.
Back to present. So I add the blackhole zone clause to named.conf and restart it.
zone "bvs.ucsg.edu.ec" {
type master;
file "master/blackhole.zone";
};
# /etc/init.d/named restartAfter loading the zone, some quick checking with dig reveals the zone has in fact been loaded and our server is giving out the "correct" address.
; <<>> DiG 9.2.4 <<>> @10.10.1.2 bvs.ucsg.edu.ec a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52090
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;bvs.ucsg.edu.ec. IN A
;; ANSWER SECTION:
bvs.ucsg.edu.ec. 86400 IN A 127.0.0.2
;; AUTHORITY SECTION:
bvs.ucsg.edu.ec. 86400 IN NS ns1.example.org.
bvs.ucsg.edu.ec. 86400 IN NS ns2.example.org.
;; ADDITIONAL SECTION:
ns1.example.org. 10800 IN A 10.10.1.2
ns2.example.org. 10800 IN A 10.11.3.4
;; Query time: 0 msec
;; SERVER: 10.10.1.2#53(10.10.1.2)
;; WHEN: Tue Nov 22 08:36:20 2005
;; MSG SIZE rcvd: 178
Labels: DNS, Security
Mastering FreeBSD and OpenBSD Security by Yanek Korff
