From owner-dns-security@portal.ex.tis.com Fri Dec 18 16:26:42 1998 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09380 for ; Fri, 18 Dec 1998 16:26:41 -0500 (EST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA02607 for dns-security-outgoing; Fri, 18 Dec 1998 14:43:35 -0500 (EST) Message-ID: <19981218200236.10628.qmail@hotmail.com> X-Originating-IP: [170.248.3.3] From: "Ricardo González" To: dns-security@tis.com Subject: Hiding BIND version number Date: Fri, 18 Dec 1998 12:02:36 PST Mime-Version: 1.0 Content-Type: text/plain X-MIME-Autoconverted: from 8bit to quoted-printable by clipper.hq.tis.com id PAA25407 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id OAA02604 Sender: owner-dns-security@ex.tis.com Precedence: bulk Content-Transfer-Encoding: 8bit Can you tell me what do I have to do to avoid BIND giving its version number to anybody? We used a Scanning tool against our network, in order to give it a higher security level. One of the vulnerabilities it found was: > Vuln: BIND VERSION > Desc: BIND running on this host has returned information that may > be useful in an attack. > FIX: Configure BIND so that it does not return version number. For > more information, see Internet Software Consortium at > http:\\www.isc.org. We went there, but still don´t know how to do this configuration. We have the version 8.2 of BIND, which comes with LINUX. Thank you very much. Ricardo González. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-dns-security@portal.ex.tis.com Fri Dec 18 17:03:29 1998 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09762 for ; Fri, 18 Dec 1998 17:03:28 -0500 (EST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA02872 for dns-security-outgoing; Fri, 18 Dec 1998 15:50:36 -0500 (EST) X-Authentication-Warning: spiral.hq.tis.com: bwelling owned process doing -bs Date: Fri, 18 Dec 1998 16:09:29 -0500 (EST) From: Brian Wellington X-Sender: bwelling@spiral.hq.tis.com To: =?X-UNKNOWN?Q?Ricardo_Gonz=E1lez?= cc: dns-security@tis.com Subject: Re: Hiding BIND version number In-Reply-To: <19981218200236.10628.qmail@hotmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-MIME-Autoconverted: from 8bit to quoted-printable by clipper.hq.tis.com id QAA29376 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA02869 Sender: owner-dns-security@ex.tis.com Precedence: bulk Content-Transfer-Encoding: 8bit On Fri, 18 Dec 1998, Ricardo González wrote: > Can you tell me what do I have to do to avoid BIND giving its version > number to anybody? > We used a Scanning tool against our network, in order to give it a > higher security level. One of the vulnerabilities it found was: > > Vuln: BIND VERSION > > Desc: BIND running on this host has returned information that may > > be useful in an attack. > > FIX: Configure BIND so that it does not return version number. For > > more information, see Internet Software Consortium at > > http:\\www.isc.org. > > We went there, but still don´t know how to do this configuration. > Try the BIND users mailing list at bind-users@isc.org. This mailing list is for discussions dealing with DNS security (DNSSEC), not specific products. As for your question, I believe it is possible with various hacks, but there's no simple way to do it. > We have the version 8.2 of BIND, which comes with LINUX. I assume you mean 8.1.2, since 8.2 hasn't been released yet. Brian From owner-dns-security@portal.ex.tis.com Fri Dec 18 17:48:29 1998 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10360 for ; Fri, 18 Dec 1998 17:48:29 -0500 (EST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA02957 for dns-security-outgoing; Fri, 18 Dec 1998 16:25:36 -0500 (EST) Message-Id: <199812182143.NAA10863@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Ricardo Gonz lez" cc: dns-security@tis.com, gnu@toad.com Subject: Re: Hiding BIND version number In-reply-to: <19981218200236.10628.qmail@hotmail.com> Date: Fri, 18 Dec 1998 13:43:25 -0800 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk The people who wrote your security scanner are idiots. Ignore this warning. Knowing the version number is only of minor help in exploiting bugs; the usual way to exploit a bug in BIND is to simply try to exploit it. If you succeed, it was the right version; if not, it was a fixed version. John Gilmore From owner-dns-security@portal.ex.tis.com Sun Dec 20 10:47:01 1998 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02791 for ; Sun, 20 Dec 1998 10:47:01 -0500 (EST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA06683 for dns-security-outgoing; Sun, 20 Dec 1998 09:18:42 -0500 (EST) Date: Sun, 20 Dec 1998 09:38:33 -0500 (EST) From: Stefan Jon Silverman Message-Id: <199812201438.JAA05648@sunthing.sjsinc.com> To: dns-security@tis.com Subject: Re: Hiding BIND version number Cc: gnu@toad.com Sender: owner-dns-security@ex.tis.com Precedence: bulk > From: John Gilmore > > The people who wrote your security scanner are idiots. Ignore this > warning. Knowing the version number is only of minor help in exploiting > bugs; the usual way to exploit a bug in BIND is to simply try to exploit > it. If you succeed, it was the right version; if not, it was a fixed > version. > > John Gilmore > Amen to this thought -- first bit of "security sanity" that I have seen in a very long time...If you follow the right lists, you know when to upgrade -- if you don't, you should probably find another line of work... Security through obscurity has never been one of my favored methods of protecting anything... Regards, b c++'ing u, %-) sjs PS: I am my own employer, therefore: "all opinions are twice spoken for;" and they do, in fact, scare the hell out of said employer!!! ------------------------------------------------------------------------------- Stefan Jon Silverman - President SJS Associates, N.A., Inc. Suite 15-B Inter-/Intra-Net Architecture, Implementation & Security 698 West End Avenue New York, NY 10025 E-mail: sjs@sjsinc.com Phone: 212 662 9450 Website: http://www.sjsinc.com Fax: 212 662 9461 Text-Page: sjs-page@sjsinc.com Cell: 917 929 1668 ------------------------------------------------------------------------------- Weebles wobble, but they don't fall down!!! ------------------------------------------------------------------------------- From owner-dns-security@portal.ex.tis.com Mon Dec 21 10:47:01 1998 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03627 for ; Mon, 21 Dec 1998 10:47:01 -0500 (EST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA09636 for dns-security-outgoing; Mon, 21 Dec 1998 09:03:37 -0500 (EST) Message-Id: <199812182249.RAA03546@maury.arl.psu.edu> X-Mailer: exmh version 2.0.2 2/24/98 From: Jim Duncan To: John Gilmore Cc: dns-security@tis.com Subject: Re: Hiding BIND version number In-reply-to: Your message of "Fri, 18 Dec 1998 13:43:25 PST." <199812182143.NAA10863@toad.com> Date: Fri, 18 Dec 1998 17:49:10 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk John Gilmore writes: > The people who wrote your security scanner are idiots. Ignore this > warning. Knowing the version number is only of minor help in exploiting > bugs; the usual way to exploit a bug in BIND is to simply try to exploit > it. If you succeed, it was the right version; if not, it was a fixed > version. You're right, and I feel obligated to point out that their logic is altogether too typical. It's simply a misdirected attempt to improve their security by fixing the wrong problem. Here's the statement of the problem: Our scanner determined that the name server is insecure because it revealed a version number that is vulnerable. Here's the solution: Fix the name server so it doesn't reveal the version number. Years ago I submitted a bug report to Sun regarding a problem with ldconfig. If any of the directories given as arguments to ldconfig did not exist, then the dynamic library cache would be damaged and the system would crash with what appeared to be a hardware error. Somehow the bug got submitted as "Bogus first arg to ldconfig trashes cache." When I got back the patched ldconfig from Sun and ran it, sure enough a bogus first arg, e.g., "ldconfig /foo /usr/local/lib /usr/lib /lib" would generate a warning message and skip over the non-existent directory. But *two* bogus arguments, e.g., "ldconfig /foo /foo ..." and down it went. Something's wrong when folks continue to treat the symptoms rather than the illness. How much trouble could it have been to check all of the directories instead of just the first one? I'm sorry to have bored the whole list with this. Please consider it an endorsement of your valuable work, especially when you contemplate the bizarre logic that is competing against us outside this list. Jim -- Jim.Duncan@psu.edu | Manager, Network & Information Systems | Member, PSU CERT Computing Systems & Networking Group, Applied Research Lab, Penn State Univ. "Objects in calendar are closer than they appear." From owner-dns-security@portal.ex.tis.com Mon Dec 28 12:07:22 1998 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23874 for ; Mon, 28 Dec 1998 12:07:22 -0500 (EST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA29356 for dns-security-outgoing; Mon, 28 Dec 1998 10:45:01 -0500 (EST) Message-Id: <199812241607.LAA01713@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-certs-04.txt Date: Thu, 24 Dec 1998 11:07:19 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Storing Certificates in the Domain Name System (DNS) Author(s) : D. Eastlake, O. Gudmundsson Filename : draft-ietf-dnssec-certs-04.txt Pages : 10 Date : 23-Dec-98 Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnssec-certs-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-certs-04.txt". Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-certs-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981223122445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-certs-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-certs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981223122445.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security@portal.ex.tis.com Mon Dec 28 12:08:38 1998 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23949 for ; Mon, 28 Dec 1998 12:08:38 -0500 (EST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA29545 for dns-security-outgoing; Mon, 28 Dec 1998 11:03:00 -0500 (EST) Message-Id: <199812241618.LAA02339@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-secext2-07.txt Date: Thu, 24 Dec 1998 11:18:41 -0500 Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake Filename : draft-ietf-dnssec-secext2-07.txt Pages : 49 Date : 23-Dec-98 Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can also be provided through non-security aware DNS servers in some cases. The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests. This document incorporates feedback on RFC 2065 from early implementers and potential users. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnssec-secext2-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext2-07.txt". Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext2-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981223104932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext2-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext2-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981223104932.I-D@ietf.org> --OtherAccess-- --NextPart--