Slashdot Mirror

Let see this page sets the limit for distribution, and this page has a discussion on Bernstein's thoughts on licenses.

Or if you are to lazy to go to the link of the last one, let me quote:
What does all this mean for the free software world? Once you've legally downloaded a program, you can compile it. You can run it. You can modify it. You can distribute your patches for other people to use. If you think you need a license from the copyright holder, you've been bamboozled by Microsoft. As long as you're not distributing the software, you have nothing to worry about.

Wanna try again?

Let see this page sets the limit for distribution, and this page has a discussion on Bernstein's thoughts on licenses.

Or if you are to lazy to go to the link of the last one, let me quote:
What does all this mean for the free software world? Once you've legally downloaded a program, you can compile it. You can run it. You can modify it. You can distribute your patches for other people to use. If you think you need a license from the copyright holder, you've been bamboozled by Microsoft. As long as you're not distributing the software, you have nothing to worry about.

Wanna try again?

I don't mean this as a troll, but it seems that BIND has more security vulnerabilities than any other piece of software. I know someone brings this up on every DNS related post, but I think more people should try djbdns, with which I have been very impressed since I started using it about six months ago. I have heard that BIND 9 is supposed to be an improvement, but with BIND's history of security problems I'm not sure if I would trust even this new improved version. I think it is better to go with software that has already demonstrated its good security, like djbdns has.
---------------------------
"The people. Could you patent the sun?"

I switched to djbdns a few months ago because I just KNEW something like this would happen. Now I am glad I did! Bind is such a clusterf*ck. :(

http://cr.yp.to/djbdns.html

I can't help but think that it would be better code if it noted the flaws in the standard routines and either avoided them or wrapped them instead of replacing them outright.

If you were in his position, how much effort would you want to spend keeping track of which routines were safe in which versions of which OSs -- particularly the closed-source Unix varieties? And if an upgrade to an OS introduces a security flaw in a routine that was previously safe, would you want to drop everything to get out a patch for that OS's users?

In this case, having a whole package of reimplemented routines that you know are safe strikes me as the lesser evil.
--

I can't help but think that it would be better code if it noted the flaws in the standard routines and either avoided them or wrapped them instead of replacing them outright.

If you were in his position, how much effort would you want to spend keeping track of which routines were safe in which versions of which OSs -- particularly the closed-source Unix varieties? And if an upgrade to an OS introduces a security flaw in a routine that was previously safe, would you want to drop everything to get out a patch for that OS's users?

In this case, having a whole package of reimplemented routines that you know are safe strikes me as the lesser evil.
--

I can't help but think that it would be better code if it noted the flaws in the standard routines and either avoided them or wrapped them instead of replacing them outright.

If you were in his position, how much effort would you want to spend keeping track of which routines were safe in which versions of which OSs -- particularly the closed-source Unix varieties? And if an upgrade to an OS introduces a security flaw in a routine that was previously safe, would you want to drop everything to get out a patch for that OS's users?

In this case, having a whole package of reimplemented routines that you know are safe strikes me as the lesser evil.
--

People seem to be mentioning the obvious targets: Knuth, BSD etc. but I notice nobody has mentioned Dan Bernstein's projects, notably qmail. This guy basically didn't trust the standard C library routines for security and wrote his own string handling, file processing etc. based on a few system calls. He also splits up his programs into separate binaries as much as possible and is very, very minimalist in other ways too. The code seems quite impenetrable at first, I'm not sure beautiful is the right word, but it's certainly an education.

Also worth a read is Sam Latinga's C++ port of the classic Mac game Maelstrom. The actual code of the game is surprisingly small and very well-written.

Oh, and while I think about it, the InfoZip sources are a real surprise too-- I mean this code is one of the most portable pieces of code you'll ever see; they're a very good example of the sort of lengths you'll need to go to in order to achieve this kind of portability, and it's still elegant in my opinion.

I wholeheartedly disagree. There are a lot of people around who sing the same song about "it's all about the comments..." I feel strange whenever I hear such claims.

First of all, if someone is supposed to maintain a piece of code, he or she has to read the code (not the comments!) and understand it. Period. In most of the cases, its even better to just forget about the comments at all. Comments won't be translated into machine code... but the source code will, and that's what's going to run in the end. It's unlikely that a programmer will adjust all the comments (if there are changes in the code) to be completely consistent all the time. You simply can't trust comments.

Thus, the more comments a code has, the more I try to ignore them.

Now, I'm not saying good code has no comments, I just disagree with your your claim:
The best code has lots of comments.

Comments won't guarantee you good code, (and of course the lack of them won't guarantee you anything either.) There is good code around with plenty of comments, but there is also great code that is nearly comment free. You can find excellent examples at Dan Bernstein as an example.

SecureDNS (available in bind 9) allows you to sign your zone, so this kind of DNS cache poisoning can not happen.

1. This wasn't DNS cache poisoning. The nameservers just weren't reachable.

2. DNS cache poisoning is easily solved: just use good resolvers that don't automatically trust all answers. Try dnscache, and the mydomain.com incident wouldn't have affected you.

I don't want to trust them to handle their TLD's and ICANN's TLD's.

No one but ICANN handles delegations for the legacy TLDs. The dot-com zone is still resolved through the ICANN roots. The delegation to the NS for dot-com is given by whichever roots you're using. Once your cache has the glue for dot-com cached, it never has to consult the roots (any roots) again for resolution of a dot-com domain - until the glue expires, of course. A typical client cache with good uptime hits the roots only a few times a week to refresh the glue for the TLDs its clients are making queries for. With glue in cache, recursion all the way to the roots is unnecessary; to resolve a dot-com domain, the cache goes directly to the dot-com servers for which it already has records.

You can also slave an augmented root file to your own client nameserver, instead of installing a root.cache file. This permits you to see first hand what the root zone is delegating to, so you can easily verify its correctness yourself. Your cache won't ever hit the roots, since the root zone loads all the glue it needs.

Then get yourself an alternative root zone from the SuperRoot Consortium and let your local nameserver use that one instead. For dnscache users this is as simple as replacing the contents of the .../root/servers/@ file with:

199.166.24.1
195.117.6.10
199.166.24.3
199.166.31.250
199.166.31.3
199.5.157.128
204.57.55.100
204.80.125.130
205.189.73.10
205.189.73.102
207.126.103.16
216.13.76.2
216.196.48.66

Now, the new root servers provide the same service as the old ones -- i.e., they will resolve names in the .com, .org, .net, etc. TLDs, plus they will provide access to a whole bunch of alternative TLDs like, e.g., .ocean (try www.atlantic.ocean), .wine and so on. This system is plugin-compatible with the old ICANN't system (well, there's now a conflict with the .biz TLD, but who cares?).

Go try it -- you'll like it! :-)

// Klaus
--

Then get yourself an alternative root zone from the SuperRoot Consortium and let your local nameserver use that one instead. For dnscache users this is as simple as replacing the contents of the .../root/servers/@ file with:

199.166.24.1
195.117.6.10
199.166.24.3
199.166.31.250
199.166.31.3
199.5.157.128
204.57.55.100
204.80.125.130
205.189.73.10
205.189.73.102
207.126.103.16
216.13.76.2
216.196.48.66

Now, the new root servers provide the same service as the old ones -- i.e., they will resolve names in the .com, .org, .net, etc. TLDs, plus they will provide access to a whole bunch of alternative TLDs like, e.g., .ocean (try www.atlantic.ocean), .wine and so on. This system is plugin-compatible with the old ICANN't system (well, there's now a conflict with the .biz TLD, but who cares?).

Go try it -- you'll like it! :-)

// Klaus
--

I don't subscribe to the notion that these are in opposition to one another. That OpenBSD is not always the answer is very true. But all good things have their purposes. In fact, I use them both in my segmented, handy-man-special, home network:

OpenBSD for Mac68K (all these were bought for a pittance on eBay):
2 Quadra 700s: transparent firewall (ipf) and 3-legged NAT (ipnat)
Quadra 610: mail server (qmail)
Centris 610 (w/68040): dns server (djbdns)

LinuxPPC: (Bastille'd by using the Sparc trick on the FAQ)
2 7300s: apache and MySQL (soon to be PostgreSQL?)
9500/G3: mol / streaming with videod, icecast (Better choices are welcome.)
Pismo PowerBook: dual boot

I haven't had as many years using Linux (only 2) as you have. And aside from that my computer experience amounts to a few mid-'80s semesters of VAXen and the entire life of the Mac platform -- and around 4 months of NetBSD and OpenBSD. But I have to say it (adding BSD to the mix) hasn't been that hard at all. There are many similarities with Linux. Much of your current knowledge will transfer. For anyone who has learned guitar and then tried bass, or ukulele, you've experienced this before.

-B...

I don't subscribe to the notion that these are in opposition to one another. That OpenBSD is not always the answer is very true. But all good things have their purposes. In fact, I use them both in my segmented, handy-man-special, home network:

OpenBSD for Mac68K (all these were bought for a pittance on eBay):
2 Quadra 700s: transparent firewall (ipf) and 3-legged NAT (ipnat)
Quadra 610: mail server (qmail)
Centris 610 (w/68040): dns server (djbdns)

LinuxPPC: (Bastille'd by using the Sparc trick on the FAQ)
2 7300s: apache and MySQL (soon to be PostgreSQL?)
9500/G3: mol / streaming with videod, icecast (Better choices are welcome.)
Pismo PowerBook: dual boot

I haven't had as many years using Linux (only 2) as you have. And aside from that my computer experience amounts to a few mid-'80s semesters of VAXen and the entire life of the Mac platform -- and around 4 months of NetBSD and OpenBSD. But I have to say it (adding BSD to the mix) hasn't been that hard at all. There are many similarities with Linux. Much of your current knowledge will transfer. For anyone who has learned guitar and then tried bass, or ukulele, you've experienced this before.

-B...

I'm no Linux/Unix admin but shouldn't Linux Syn Cookies prevent DoS attacks. Syn Cookies

Qmail is NOT open source software, by any definition of the term. The author has never accepted patches that I know of, explicitly forbids the distribution of modified versions, and will never, ever permit a fork.

And frankly, that's probably a good thing, as it's the reason why qmail is not the horrid mess that sendmail is and that postfix seems hell-bent on becoming.

While adding another set of root nameservers to the standard root.cache sounds like a good idea on its face (and should be technically feasible, unless I'm missing something in my memory of how BIND 8 deals with cache), it won't work.

Why?

A fair portion of the Internet doesn't use BIND. Even on Unix systems, there are BIND replacements, just as there are sendmail replacements. But even ignoring the Unix world, what about Windows 2k, etctera? I mean, sure, they're making plenty of modifications to what's Right on their own (domains segments beginning in "_", for instance), but the chances of Microsoft not going along with ICANN (especially if NSI shuffles some money behind MS stock) are awfully low.

While adding another set of root nameservers to the standard root.cache sounds like a good idea on its face (and should be technically feasible, unless I'm missing something in my memory of how BIND 8 deals with cache), it won't work.

Why?

A fair portion of the Internet doesn't use BIND. Even on Unix systems, there are BIND replacements, just as there are sendmail replacements. But even ignoring the Unix world, what about Windows 2k, etctera? I mean, sure, they're making plenty of modifications to what's Right on their own (domains segments beginning in "_", for instance), but the chances of Microsoft not going along with ICANN (especially if NSI shuffles some money behind MS stock) are awfully low.

Or use just use qmail, and let the world know you are using a secure MTA :-)

Relevant URLs:
Dan Bernstein's page. Home of Qmail and djbdns.
The OpenBSD and OpenSSH home pages are full of useful information.
PuTTY, a free Windows SSH client Great for on road trips, internet cafe's, consulting, etc.
Mutt, the One True mail client. Takes some getting used to, a good .muttrc doesn't hurt either.

People seem to overlook qmail when setting up a reliable, secure system. Having dealt with Sendmail and Qmail, I would suggest the latter to anyone who cares about security or performance. The same logic applies to BIND vs. djbdns.

In my department we allow Linux systems, but people who intend to install it must notify a computing committee, and they are expected to run only ssh, and possibly smtp and a small, secure, non-cgi capable httpd like djb's publicfile (intended to serve a Java ssh client or test pages, not as a production server). We had a box rooted before this went into place; the user of the box was running an old version of Redhat, and the box was running a buggy, absolutely unneeded amd daemon. The attacker transferred a rootkit and a sniffer using ftp-- the ftp daemon had not been used for anything else in that box, ever...

Since some people don't like clicking links for some reason, here's DJB's comments on DNSSEC (a few of them at least):

DNSSEC is a project to have a central company, Network Solutions, sign all the .com DNS records. Here's the idea, proposed in 1993:

• Network Solutions creates and publishes a key.
• Each *.com creates a key and signs its own DNS records. Yahoo, for example, creates a key and signs the yahoo.com DNS records under that key.
• Network Solutions signs each *.com key. Yahoo, for example, gives its key to Network Solutions through some secure channel, and Network Solutions signs a document identifying that key as the yahoo.com key.
• Computers around the Internet are given the Network Solutions key, and begin rejecting DNS records that aren't accompanied by the appropriate signatures.

  However, as of February 2000, Network Solutions simply isn't doing this. There is no Network Solutions key. There are no Network Solutions signatures. There is no secure channel---in fact, no mechanism at all---for Network Solutions to collect *.com keys in the first place.

  DNSSEC is often falsely advertised as a software feature that you can install to protect your computer against DNS forgeries. In fact, installing DNSSEC does nothing to protect you, and it will continue to do nothing for the foreseeable future. I'm not going to bother implementing DNSSEC until I hear a detailed, concrete, credible plan for central DNSSEC deployment.

  Even if DNSSEC is someday put into place, it will continue to allow attacks through Network Solutions itself. What happens if a Network Solutions employee is bribed? Are the Network Solutions computers secure? An attacker who breaks into one critical Network Solutions computer will have control over the entire Internet.

Read the rest of that page for his idea for a quick-fix.

Dan (the maker of djdns) sure makes secure code, but at anno domini 2000 it is totally unnaceptable to have the following restrictions for distribution. this definetly not a open source license.

If I wanted to Improve djdns and distribute it, i couldn't. Same applies to qmail. Only sysadmins with unlimited time install Dan's software, as no distribution can accept Dan's restrictions and distribute precompiled versions.

Dan Bernstein (the guy who wrote qmail) has an interesting commentary on struggling to implement a secure replacement for BIND.

namedroppers

And whose fault is it that it's not implemented? clicky.

Oops, i was too hasteful on my judgement... He adresses that at the end of his paper - "Acknowledgement of previous work". He also points to an alternative location for description of syncookies.
GENESIS is a similar idea to syncookies, thus giving robust SYN flood protection to Windows platform.
It doesn't, however, eliminate the idea of Distributed Denial Of Service attacks.

BTW, we should rather call them Distributed Internet Load Denial Of Service attacks, that would make all those sensational news headlines much more funny (imagine a "www.hotgrits.com was taken down by DILDOS attack?" headline?)

Discussion of this idea has been taking place on the news.grc.com forums

The similarity to SYN cookies has been pointed out to Steve Gibson.

michael

The whole reason you don't want to use an array like you describe is that it requires that the server dedicate resources -- an array entry -- to a connection before the client's location is verified by the three-way handshake. This is exactly why syn floods work, by filling up the queue with bogus connection requests that never complete.

Dan Bernstein also has an old old web page in which he describes this idea in the context of IPV4:

http://cr.yp.to/syncookies.html

... but I still think Phil Karn is the real inventor.

This guy's "innovations" aren't new; IPV4 SYN cookies were invented by Eric Schenk and Dan Bernstein back in 1996. Not only that, but GRC's solution (as described on that page) doesn't address MSS or even discuss TCP options. See http://cr.yp.to/syncookies.html for a much better discussion of TCP cookies.

You don't need to pay any attention to a EULA unless you're in a UCITA state. http://cr.yp.to/softwarelaw.html

Qmail works best with DJB's tcpserver. Much better performance, and easy to set up.

> > djbdns turns of TCP queries by default.

> No it doesn't.

What about this FAQ: How do I answer TCP queries? Why does tinydns answer only UDP queries?

It sure looks like it is off by default according to the author.

You are wrong about AXFR. See

• axfrdns
• axfr-get

You are wrong about AXFR. See

• axfrdns
• axfr-get

I recently changed from BIND (the Buggy Internet Name Daemon) to D. J. Bernstein's DJBDNS. It's a very modular, robust and not to mention secure replacement for BIND. He's got a security guarantee as well. He offers $500 to the first person who reports a verifiable security hole.

So instead of worrying about the next serious security hole in BIND, replace it with DJBDNS and make your server a lot more secure.

Homepage: http://cr.yp.to/djbdns.html

For OpenBSD users: cd /usr/ports/net/djbdns; make; make install

I'm hoping BIND9 is a complete, utter rewrite, with no code from BIND8 still remaining.

If it isn't, then it's way way too late - switch to Dan Bernstein's djbdns instead. Read the security guarantee and weep in relief. Notice the exceedingly small memory footprint. The lack of core dumps. That you can get rid of AXFR completely and just use rsync+ssh to transfer to your secondaries.

Check out tinydns.org which has migration tools from BIND which im playing with atm.

I'm hoping BIND9 is a complete, utter rewrite, with no code from BIND8 still remaining.

If it isn't, then it's way way too late - switch to Dan Bernstein's djbdns instead. Read the security guarantee and weep in relief. Notice the exceedingly small memory footprint. The lack of core dumps. That you can get rid of AXFR completely and just use rsync+ssh to transfer to your secondaries.

Check out tinydns.org which has migration tools from BIND which im playing with atm.

I gave up on bind a while ago. Certainly some folks need its features, but for most of us, DJB's dns package should be powerful enough, plus its faster and more secure.

publicfile is a fabulous package that should really get much more recognition and use. It can do 90% of what most people want from httpd/ftpd servers in a faster and far more secure manner.

However, one stumbling block for a lot of people is Dan Bernstein's exclusive use of his EPLF format for LIST and NLST requests. This format is a great idea but still isn't very widely implemented by ftp clients including most web browsers; this is why you'll usually just see the raw eplf output on most clients when you do a dir or ls (example eplf output).

I wrote a patch to publicfile that will cause it to use the more widely accepted /bin/ls format. This will allow it to display properly in most ftp clients and web browsers (example of patched publicfile ftpd, over 65k modem BTW).

The patch is at ftp://ftp.essc.psu.ed u/pub/emsei/woods/publicfile_no_eplf.patch. I don't believe it compromises the security of the package in any way. Please let me know if you find it useful, or have any suggestsions.

-- Scott

publicfile is a fabulous package that should really get much more recognition and use. It can do 90% of what most people want from httpd/ftpd servers in a faster and far more secure manner.

However, one stumbling block for a lot of people is Dan Bernstein's exclusive use of his EPLF format for LIST and NLST requests. This format is a great idea but still isn't very widely implemented by ftp clients including most web browsers; this is why you'll usually just see the raw eplf output on most clients when you do a dir or ls (example eplf output).

I wrote a patch to publicfile that will cause it to use the more widely accepted /bin/ls format. This will allow it to display properly in most ftp clients and web browsers (example of patched publicfile ftpd, over 65k modem BTW).

The patch is at ftp://ftp.essc.psu.ed u/pub/emsei/woods/publicfile_no_eplf.patch. I don't believe it compromises the security of the package in any way. Please let me know if you find it useful, or have any suggestsions.

-- Scott

Anybody know if this works when your local DNS server is running djbdns (a.k.a. dnscache)?

If so, wonder how long it is before DJB re-codes his server so that it won't. That guy is a paranoid fanatic when it comes to security.

Anybody know if this works when your local DNS server is running djbdns (a.k.a. dnscache)?

If so, wonder how long it is before DJB re-codes his server so that it won't. That guy is a paranoid fanatic when it comes to security.

I've seen endless amounts of complaining on slashdot about the 'click here to agree' licenses that come with most commercial software. Some say they aren't binding and shouldn't be taken seriously. Why, then, should anybody take a license included with an open-source package seriously?

Shrinkwrap licenses attempt to tell you what you can do with a work, and draw their force from... er... nowhere in particular.

Here is some DNS server software that supports 8-bit data, no problem. Finding a compliant client resolver library is another matter, however...

Whether you believe it or not, there are some things I dont use Linux for. Especially in the server area. There are much more secure and easier to use DNS Servers for MacOS. BIND and named are fine, but, ease of use is not something that springs to mind when you think of them.

Speaking of DNS servers for linux, have you looked at djbdns? It is arguably more robust than BIND, and quite easy to use.

qmail is an excellent choice for securely replacing sendmail.

DJBDNS may be of some help.

ipchains is your friend...

I just this afternoon noticed that they were not using qmail as they normally do.

This was in the header of a message I received from a Hotmail user:

Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 1 Aug 2000 20:45:31 -0700
Received: from 202.14.100.58 by lw7fd.law7.hotmail.m sn.com with HTTP; Wed, 02 Aug 2000 GMT

Another from the same Hotmail user is using qmail.

Not really. Distribution is only allowed in as the original tarball. See the website.
--

And fixing the verification problem with a properly built mailing list program is easy if you're using something like MajorDomo, it's the default setting once you properly install it.

In Majordomo 1, the confirmation feature is at best useless, and at worst it provides a false sense of security. Daniel J. Bernstein has this to say about it (under the section ``Subscription cookie prediction'').

I've had a look at the cookie generation code in Majordomo 1.94.5 (the current version 1 release) and it's quite trivial, given a cookie and the email address you used to get that cookie, to make a cookie for any other email address. So if the list actually allows public subscription (e.g., open+confirm), be prepared to subscribe anyone.

This claim is substantiated; there is, for example, a working implementation.

Some people argue that the cookie algorithm can be changed; however this is no longer the ``default setting'' that you were referring to.

In my quick perusal of the Majordomo 2 code, they have got it ``right'', in the sense that you can't just spoof the ``confirmation tokens'' (as they're called in the code), which are randomly generated (using the standard Perl rand()---I don't know how secure or insecure this is).