NSEC and ldns-walk

In my previous blog post, I discussed the weakness of NSEC in DNSSEC which causes zone walking by means of trying alphabetical combinations in domain names. Actually, for those who have installed the ldns DNS tool, they need not try alphabetcial combinations for zone-walking. Just invoke "ldns-walk ripe.net" will give all sub-domain names under ripe.net and the associated NSEC records.

Use fail2ban to protect dovecot against brute force attacks

From time to time, I find brute force attacks on pop and imap in addition to ftp and ssh. The fail2ban version I have can offer brute force protection for ftpd and sshd but not dovecot. In order to achieve the same for dovecot, the following files must be added under the fail2ban folder:

/etc/fail2ban/filter.d/dovecot.conf

[Definition]
failregex = dovecot-auth: pam_unix\(dovecot:auth\):
authentication failure; .* rhost=(?:\s+user=\S*)?\s*$
ignoreregex =

/etc/fail2ban/jail.conf

[dovecot-iptables]

enabled = true
filter = dovecot
action = iptables-multiport[name=Dovecot, port="pop3,pop3s,imap,imaps", protocol=tcp]
sendmail-whois[name=Dovecot, dest=you at mail.com]
logpath = /var/log/secure
maxretry = 5
bantime = 1800
ignoreip = 127.0.0.1

This works quite well. No more worry on unlimited meaningless break-in trials on port 110 and port 143.

Reverse lookup in Postfix

I recalled that once I successfully amended the config file of postfix (/etc/postfix/main.cf) to require mandatory reverse lookup of connecting IP addresses and if no hostname could be returned, then the connections would be rejected. The directive for this is :

reject_unknown_reverse_client_hostname,

There is yet another more stringent settting

reject_unknown_client_hostname,

which requires not only that the address->name and name->address mappings exist, but also that the two mappings must reproduce the same client IP address. This one must be used with care. My experience is that not many SMTP servers can satisfy the requirements.

Weakness of NSEC in DNSSEC

Some zone administrators might have heard that an obstacle to DNSSEC implementation is that the early design of DNSSEC provided the resource record of NSEC (next secure record) which tells interrogating resolvers that the domain names they are asking do not exist at all. When a zone file is signed, all the original resource records will be arranged in alphabetical order and the NSEC records are properly inserted indicating which domain name to be followed after each other. This is a huge vulnerability giving rise to zone walking and a bad guy can dig out all domain records. The illustrations are below:

[Please click on the link to see the second screen dump]


In the screen dump above, I tried to find the a record of "a.ripe.net" and the query was dnssec-enabled. The remote side just told me that this one did not exist and the next available record which best matches my query is "adder.ripe.net". Please note that I have already installed the the public key of ripe.net so all data returned are tagged with "ad" which means "authenticated data".

Next, I tried to find the a record of "ooo.ripe.net" and the result told me that the next available was "openpgp.ripe.net" as below:

[Please click on the link to see the second screen dump]


By trying different alphabetical combinations, thanks to NSEC, I can find out all domain names in a zone. NSEC is now replaced by NSEC3 for zone signing. It is quite new indeed and Windows 2008 Server R2 and Bind 9.6 or above can support it.

The IETF has recommended that all early implementations of DNSSEC signed zones must be resigned with NSEC3 for security reason.

DNSSEC-enabled name hosting service

I guess no ISPs in Hong Kong right now has the capability to provide domain name hosting service with DNSSEC. I find one in Germany which is Exanemes (http://exanames.com/)

The standard rate is 5€ per month per domain. It is really not expensive if you consider the heavy workload of signing and resigning zones. key rollovers and publish the KSK to parent zone.

I am not going to use it as I have decided to do all the DNSSEC config by myself.

HKNET is testing out IPv6

My IPv6 email autoreply facility (autoreply@v6-mail.com) has received test emails from HKNET Network Operation Center (noc@ipv6-test.hknet.com) and the v6 addresses in use are:

2001:2e0:4::5
2001:2e0:4::6

From the mail transaction tests, I visualize that IPv6 paths of HKNET are already well-established. It is just a matter of time for HKNET to offer to corporate customers.


In fact, HKNET was the first ISP to get IPv6 address block dated back to year 2001.

IPv6 Reverse DNS Zone Builder for BIND 8/9

For those who need help in configuring IPv6 reverse lookup information, they may use “IPv6 Reverse DNS Zone Builder for BIND 8 & 9” available at:

http://www.fpsn.net/index.cgi?pg=tools&tool=ipv6-inaddr

This tool is a quick and easy way of creating BIND 8, and BIND 9 named.conf configuration entries, along with creating a zone file with the correct syntax for domain name mapping to IPv6 addresses. Users just need to input the file name, assigned IPv6 Block (e.g. 2002:ca51:1234::/48), zone managers E-mail address, primary Domain server, secondary Domain server(s) and the forward lookup records.

I have never found any websites that offer similar function.

XPS Viewer

Bind 9.7makes DNSSEC human touchable

BIND 9.7 promises to make DNSSEC much easier, much more human. From ISC website, it says the improvements are :

- support NSEC3;
- easier to resign zone;
- automated trust anchor management;
- support DLV;and
- support dynamic DNS configuration.

I am not sure I will be impressed by these additional features BIND 9.7. I have decided to use “Unbound” as the recursive validator and “NSD” as the DNSSEC-enabled authoritative server.

Rescue Windows XP

One XP box in my home failed to boot. Boot into last known configuration or safe mode also crashed.

I used the XP CD to boot up and then gained access to the System Recovery Console. failure.Next I used bootcfg /list, /scan, or /rebuild, all failed and the Recovery Console prompted me that no bootable Windows partition is found. At this point, I had the feeling that boot.ini might have corrupted. I did fixboot to try my luck. It worked.

This process of finding ways to rescue XP was really a great pain. I decided to crone another disk for emergency purpose.

Configure BIND as a recursive validator with Domain Lookaside Validator

I made pretty good progress in DNSSEC. I have changed BIND from a plain resolver to a recursive validator with the aid of domain lookaside validator (DLV) of ISC. DLV is an interim solution for providing an entry point (besides the root zone) from which to obtain DNSSEC validation information. Without DLV, in the absence of a fully signed path from the root to a zone, zone administrators must configure and maintain all trusted keys into their configurations.

The following lines are the additional requirements in named.conf to enable DLV :

----------------------------------------
[enable dnssec in BIND ]

dnssec-enable yes;
dnssec-validation yes;

[use dlv.isc.org as secure entry point ]

dnssec-lookaside "." trust-anchor "dlv.isc.org.";

[Permit detail logging ]
logging {
channel dnssec_log {
file "/var/log/dnssec.log" size 20m;
print-time yes;
print-category yes;
print-severity yes;
severity debug 3; };
category dnssec { dnssec_log; };
};

[add the KSK of dlv.isc.org]

trusted-keys {
dlv.isc.org. 257 3 5
"BEAAA..........................."};

---------------------------------------------
After these entries, tests need to be conducted to verify AD (authenticated data) flag is set when querying resource records that are signed.

[root@i3way etc]# dig +dnssec www.dnssec.se a
; <<>> DiG 9.5.2-RedHat-9.5.2-1.fc10 <<>> +dnssec www.dnssec.se mx
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16411
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1

Now that I have an recursive validator in place, the next tasks are to sign my zones and publish the keys to dlv.isc.org.

Journalists in China said their Yahoo email accounts were hacked

Some journalists in China said their Yahoo email accounts were hacked, see the URL:

http://news.yahoo.com/s/ap/20100330/ap_on_hi_te/as_china_internet

My advice is that they should give up Yahoo email service which lacks HTTPS encryption in the web session. In Sept 2005, a Chinese journalist named Shi Tao was sentenced to 10 years' imprisonment because of talking June 4 in Yahoo email which was intercepted by the China Great Firewall.

By all means and for avoding being caught because of reporting sensitive matters, they should use Gmail which is fully encrypted.