linux security - Jun 1998 - Named update for RH 4.2 exploitable?

Someone I was speaking with this evening claimed they have installed the
latest named rpms yet they are still getting exploited daily and being
hacked.  Do the latest rpm''s for the named 4.9.x stuff fix all the root
exploits or is this person just an idiot who probably has holes elsewhere in
the system?

Hello,

I traditionally have always run BIND in a chroot() environment and always
recommend admins do the same because this program is rather complicated in
it''s functionality. This can provide a high degree of protection from a
lot of nonsense that a person may wish to throw at you.

To facilitate setting up BIND in a chroot() environment for other admins,
I typed up a document last week to detail how to do it under OpenBSD
(because that is what my SMTP/DNS/WWW servers run [no flames please]).

Since I also use Linux for many applications and the majority of my
development, I''ve done a quick re-write to apply the same information
for
RedHat Linux and what I suspect to be most variants.

The documents only apply to version 8.1.x because I feel that people
should migrate to this version. Also 8.1.x has a not-so-well-documented
feature where you can tell it to run under a differenty UID/GID and
chroot() to the directory after it initializes. These options are:

-u <UID>
-g <GID>
-t <chroot dir>

This means that named will be able to bind as root and then quickly drop
privilege and contain operations to a safe directory free of pesky
binaries such as /bin/sh. Much better than the default
run-everything-as-root configuration.

There are a few small hurdles to cross to get it to work under Linux, but
nothing extraordinary. Please check out the documents here:

http://www.psionic.com/papers/dns.html

This document is largely based off of Adam Shostack''s orginal paper
that
detailed setting up BIND under chroot() on Solaris. This document can be
had from:

http://www.homeport.org/~adam/dns.html


PLEASE NOTE: I have limited experience running BIND under Linux in a
chroot() fashion. The document expresses this and I''m encouraging
people
who have a problem in following the information to please write me
directly so I can change/update. Full credit will be given to
all suggestions used.

I''ll also be following this up with a document to describe how to run
Apache under chroot(). Another thing that many sites should probably do.


Thanks,


-- Craig

Jiva DeVoe enscribed thusly:
> Someone I was speaking with this evening claimed they have installed the
> latest named rpms yet they are still getting exploited daily and being
> hacked.  Do the latest rpm''s for the named 4.9.x stuff fix all the
root
> exploits or is this person just an idiot who probably has holes elsewhere
in
> the system?
	Ahhhhh!!!!  If the latest RPM''s are STILL using 4.9.x instead of
the latest 8.1.x, people should be really upset.  Bind 8.1.1 has been out
for quite some time and, unless you have turned on those assinine fake INVQ
inverse queries, it is not vulnerable to the remote root hack.  It was still
vulnerable to several DoS attacks and everyone should now be using 8.1.2.
I don''t know what''s in the RPM''s simply because I
build straight from Paul
Vixie''s sources up at www.isc.com.  I know of no reasons to be sitting
on the 4.9.x stuff any more unless you are in love with or need some
compatibility with /etc/named.boot (8.1.x uses the newer, more flexible
/etc/named.conf).

	Mike
--
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

I don''t know if the new rpm''s fix all the problems but I would
ask your friend several questions (forgive me if these are obvious)

1) did your friend reload RH from the CD?
2) did they apply all the new rpms?
3) are they sure that there are no security flaws in their cgi-bin
directories?
4) What makes them believe they are being hacked by the named problem?

When I was hacked the first time the person had the nerve/insight while
someone was talking to him over IRC to change /bin/login
to accept a static password for root.  Once you have been hacked
there is very few alternatives to most Linux mortals than to reloading the
os if you would like to avoid future hacks.

At 01:27 AM 6/6/98 -0700, you wrote:
>Someone I was speaking with this evening claimed they have installed the
>latest named rpms yet they are still getting exploited daily and being
>hacked.  Do the latest rpm''s for the named 4.9.x stuff fix all the
root
>exploits or is this person just an idiot who probably has holes elsewhere in
>the system?
>
>--
>----------------------------------------------------------------------
>Please refer to the information about this list as well as general
>information about Linux security at http://www.aoy.com/Linux/Security.
>----------------------------------------------------------------------
>
>To unsubscribe:
>  mail -s unsubscribe linux-security-request@redhat.com < /dev/null
>

On Sat, 6 Jun 1998, Michael H. Warfield wrote:
> Vixie''s sources up at www.isc.com.  I know of no reasons to be
sitting
> on the 4.9.x stuff any more unless you are in love with or need some
> compatibility with /etc/named.boot (8.1.x uses the newer, more flexible
> /etc/named.conf).
Making sure that there won''t be library problems with all the SRPMs and
normal source packages which haven''t been upgraded is my guess, as 8.x
moved things.  For something like RH, where you''ll end up with a large
number
of not-so-literate administrators, this is probably an overriding factor,
followed by the lack of 3rd party documentation for named.conf.  Maybe
we''ll see a GUI config tool for the next release of RH,
they''re certainly
trying to lower the bar to entry.

The RH folks made both BIND4 and BIND8 RPMs available with the first set
of patches to the BIND sources prior to the 8.1.2 release, which fixed
the inverse query problem.  They were up as soon as was possible.

Given named-bootconf.pl, config file formats aren''t likely to be a
major
force of staying with BIND4 for anyone who can write scripts, and
doesn''t
want to spend the time "fixing" their current generation process.

The other major factor in sticking with BIND4 is the ability to use a database
backend, which is important for some sites, and doesn''t look to be
easily
done on the BIND8 sources according to the maintainers of such packages.

As we''ve seen with the patches, 8.1.1 wasn''t exactly great out
of the
box, so not adopting early wasn''t that ill-thought of a move after all.
Most vendors don''t rush right on to newer versions, and I doubt that RH
is
any different in that regard.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts@clark.net      which may have no basis whatsoever in fact."
                                                                     PSB#9280

"Michael H. Warfield" <mhw@wittsend.com>
wrote:
> 	Ahhhhh!!!!  If the latest RPM''s are STILL using 4.9.x instead of
> the latest 8.1.x, people should be really upset.  Bind 8.1.1 has been out
> for quite some time and, unless you have turned on those assinine fake INVQ
> inverse queries, it is not vulnerable to the remote root hack.  It was
still
> vulnerable to several DoS attacks and everyone should now be using 8.1.2.
> I don''t know what''s in the RPM''s simply because
I build straight from Paul
> Vixie''s sources up at www.isc.com.  I know of no reasons to be
sitting
> on the 4.9.x stuff any more unless you are in love with or need some
> compatibility with /etc/named.boot (8.1.x uses the newer, more flexible
> /etc/named.conf).
	The versions secured against INVQ buffer overflow are:
		4.9.7
		8.1.2
	Specifically 4.9.6 AND 8.1.1 ARE VULNERABLE!
	(Well, in 8.* you can disable INVQ support via option section,
	 but in 4.* you must to it by compiling..(has the RH 5.1 been
	 equiped with 4.9.6 configure this way, I don''t know.))
> 	Mike
>  Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
>   (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
/Matti Aarnio <matti.aarnio@sonera.fi>

On Sat, Jun 06, 1998 at 05:10:21PM -0400, Michael H. Warfield wrote:
> 	Ahhhhh!!!!  If the latest RPM''s are STILL using 4.9.x instead of
> the latest 8.1.x, people should be really upset.  Bind 8.1.1 has been out
> for quite some time and, unless you have turned on those assinine fake INVQ
> inverse queries, it is not vulnerable to the remote root hack.  It was
still
> vulnerable to several DoS attacks and everyone should now be using 8.1.2.
> I don''t know what''s in the RPM''s simply because
I build straight from Paul
> Vixie''s sources up at www.isc.com.  I know of no reasons to be
sitting
> on the 4.9.x stuff any more unless you are in love with or need some
> compatibility with /etc/named.boot (8.1.x uses the newer, more flexible
> /etc/named.conf).
I use RHS 5.0 .. bind-4.9.6-7 was built with INVQ #define''d.  I found
this out
because I got ahold of the ADMw0rm thing, and all that the `testvuln''
program
does is see if INVQ is set.  So, I hacked the patch in the SRPM and rebuilt
without INVQ.  End of that story.

''kay bye.
Yakko [who really should see about going to BIND8]
--
\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\
\ A!JW22 WAR+++i^ P&B++ RI++ I++++ \  `888888P"   \    Geek since 1985,
\
\ Dai T428 $++++dmvap SL++i^       \     J8L      \    and proud of it.   \
\ Vr++m++ Xpackage E70a H5         \    """""     \    
whois: CE334     \
\     Christopher A. Eslinger - yakko@{yallp.com,wtower.com,idt.net}      \
\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\\////\\\


[mod: The URL for BIND sources that was recently mentioned should be:
http://www.isc.org/ . Thanks to Dick Balaska (dick@buckosoft.com) for
noticing this. -- REW]

1) The RPMs at ftp.redhat.com in the updates directory are for 4.9.x,
   but 8.1.2 is in the contrib directory.  I went looking the other day.
> When I was hacked the first time the person had the nerve/insight while
> someone was talking to him over IRC to change /bin/login
> to accept a static password for root.  Once you have been hacked
> there is very few alternatives to most Linux mortals than to reloading the
> os if you would like to avoid future hacks.
2) One of my machines was hacked - apparently via Samba.  (I had turned
   it off, but the other sysadmin turned it back on to do something and
   apparently never removed it.)  However, the hacker was remarkably
   dumb... yes, they replaced /bin/login and a few other things with
   trojans, but they didn''t bother to touch them back, nor did they
   bother to check the system terribly well.  My tripwire programs
   (including ''tripwire'' itself) quite happily reported to me
every
   file he altered and everything he did.

   From what I''ve heard from other sysadmins, hackers are often very
   blind to tripwire programs.  I''m also doubly careful, and store
   my checksum data and whatnot on remote systems.  I HIGHLY recommend
   people use tripwire systems like ''tripwire''.  There are
also custom
   kernel modifications out there which provide additional - much harder
   to notice, since it''s in the kernel - security.  Better to run these
   and find problems quickly and be able to recover easily, than to
   avoid the hassle of setting them up, only to be hacked. :)

--Jeremy

On Sat, 6 Jun 1998, Michael H. Warfield wrote:
> Jiva DeVoe enscribed thusly:
>
> > Someone I was speaking with this evening claimed they have installed
the
> > latest named rpms yet they are still getting exploited daily and being
> > hacked.  Do the latest rpm''s for the named 4.9.x stuff fix
all the root
> > exploits or is this person just an idiot who probably has holes
elsewhere in
> > the system?
>
> 	Ahhhhh!!!!  If the latest RPM''s are STILL using 4.9.x instead of
> the latest 8.1.x, people should be really upset.  Bind 8.1.1 has been out
> for quite some time and, unless you have turned on those assinine fake INVQ
> inverse queries, it is not vulnerable to the remote root hack.  It was
still
> vulnerable to several DoS attacks and everyone should now be using 8.1.2.
> I don''t know what''s in the RPM''s simply because
I build straight from Paul
> Vixie''s sources up at www.isc.com.  I know of no reasons to be
sitting
> on the 4.9.x stuff any more unless you are in love with or need some
> compatibility with /etc/named.boot (8.1.x uses the newer, more flexible
> /etc/named.conf).
8.1 claims about twice as much memory as 4.9.x while adding no usefull
features to me.

So there is an argument in favor.

Hugo.

	+------------------------+------------------------------+
	| Hugo van der Kooij     | Hugo.van.der.Kooij@caiw.nl   |
	| Oranje Nassaustraat 16 | http://www.caiw.nl/~hvdkooij |
	| 3155 VJ  Maasland      | (De man met de rode hoed)    |
	+------------------------+------------------------------+
    "Computers let you make more mistakes faster than any other invention
in
      human history, with the possible exception of handguns and tequila."
		(Mitch Radcliffe)

On Sat, 6 Jun 1998 01:27:51 -0700, <jiva@devware.com>
wrote:
> Someone I was speaking with this evening claimed they have installed the
> latest named rpms yet they are still getting exploited daily and being
> hacked.  Do the latest rpm''s for the named 4.9.x stuff fix all the
root
> exploits or is this person just an idiot who probably has holes elsewhere
in
> the system?
This person is a twit. I have presonally tested all of the updates on several
different versions of Red Hat and none of them are still exploitable.

It is true that fake-iquery is still defined, but this in and of itself is not
a problem.

Make sure that this person has restarted named once they applied the updates.

Note: if they didn''t do this and were hacked then there is no telling
what
else is now vulnerable on the system.


[mod: The official Red Hat fixes are called "4.9.6-..." because the
same fix that went into the official 4.9.7 was applied by Red Hat onto
the then-current 4.9.6. Bryan, Eric, you''re scaring people by having
them run a 4.9.6 named, while it is known to be vulnerable.... -- REW]

--

                Bryan C. Andregg * <bandregg@redhat.com> * Red Hat
Software

"So hang the brand-name ego at the door and think about what I''m
saying" -
	Peter Da Silva

On Sat, 6 Jun 1998 17:10:21 -0400 (EDT), <mhw@wittsend.com>
wrote:
> 	Ahhhhh!!!!  If the latest RPM''s are STILL using 4.9.x instead of
> the latest 8.1.x, people should be really upset.  Bind 8.1.1 has been out
> for quite some time and, unless you have turned on those assinine fake INVQ
> inverse queries, it is not vulnerable to the remote root hack.  It was
still
> vulnerable to several DoS attacks and everyone should now be using 8.1.2.
> I don''t know what''s in the RPM''s simply because
I build straight from Paul
> Vixie''s sources up at www.isc.com.  I know of no reasons to be
sitting
> on the 4.9.x stuff any more unless you are in love with or need some
> compatibility with /etc/named.boot (8.1.x uses the newer, more flexible
> /etc/named.conf).
The latest RPMs are still 4.9.x because as of the pressing of 5.1
BIND-8.1.2-TR3 was all that was available and still suffered from serious
memory problems.

Typically we try to avoid major upgrades (BIND 4.9.x -> BIND 8.1.2) during a
release cycle because of support reasons. We are working on a way to solve
this for this case though.

--

                Bryan C. Andregg * <bandregg@redhat.com> * Red Hat
Software

"So hang the brand-name ego at the door and think about what I''m
saying" -
	Peter Da Silva

On Sat, 6 Jun 1998, Paul D. Robertson wrote:
> The other major factor in sticking with BIND4 is the ability to use a
> database backend, which is important for some sites, and doesn''t
look to
> be easily done on the BIND8 sources according to the maintainers of such
> packages.
I have had no trouble getting my database to work with BIND8.  It was
certainly easier than the same hacks to BIND4.  NOTIFY is pretty easy to
code and provides a much cleaner interface between the database and BIND
than the hacks into BIND4.  I''ve upgrade through several iterations of
BIND8 without difficulty.  This is a lot easier than having to muck with
Makefiles and patches every time there''s a bug or hole in BIND.

</chris>
--
It is bad luck to be superstitious. -Andrew Mathis

At 05:24 PM 6/6/98 -0700, you wrote:
>   From what I''ve heard from other sysadmins, hackers are often
very
>   blind to tripwire programs.  I''m also doubly careful, and store
>   my checksum data and whatnot on remote systems.  I HIGHLY recommend
>   people use tripwire systems like ''tripwire''...
Next logical question:  Has anyone worked out rpms for tripwire, COPS, etc?
and why aren''t these necessary security applications a standard part of
ALL
distributions?

Later...
Mike

> Next logical question:  Has anyone worked out rpms for tripwire, COPS, etc?
> and why aren''t these necessary security applications a standard
part of ALL
> distributions?
I would LOVE for StackGuard to become part of a standard distribution.

Background:  StackGuard is a gcc hack that makes programs largely
immune to stack smashing.  I presented a paper on it at USENIX Security
in January.

My lab is currently doing a complete re-build of everything setuid root
in the RH 5.0 distribution using StackGuard.  Just for yucks, we tried
the latest X exploit, and while a stock RH 5.0 machine was vulnerable,
the same distribution protected with StackGuard was not.

We''re pushing all these builds back into rpm''s, along with the
StackGuard compiler, and we''re going to burn a few CDs for selected
distribution.  We''ll also make as much of this stuff available via the
web as possible.

For general interest, I''ll be submitting a paper on the build
experience to LISA.

I would just LOVE for RedHat to take up using this tool.  Even if the
compiler RH ships is not the StackGuard version, IMHO
StackGuard-protected binaries would make a great deal of sense for a
distribution.

Disclaimer:  Yes, I''m plugging my project.  No, I''m not
"selling"
anything.  StackGuard is a product of an academic research project.
Since it''s a gcc patch, StackGuard is copylefted.

Crispin
-----
 Crispin Cowan, Research Assistant Professor of Computer Science, OGI
    StackGuard: protect your software against Stack Smashing Attack
       http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/

		 Support Justice:  Boycott Windows 98

On Sun, 7 Jun 1998, Mike Carpenter wrote:
> Next logical question:  Has anyone worked out rpms for tripwire, COPS, etc?
> and why aren''t these necessary security applications a standard
part of ALL
> distributions?
For RedHat, tripwire would be relatively redundant.  If you keep a copy of
your rpm database on some sort of removable, remote, or read-only media,
you can use rpm -V to look for things that are out of sync as far as
permissions or md5sum go.

If you do want it though, it''s been in the contrib dir at
ftp.redhat.com
for quite some time:

-rw-r--r--   1 root     root       368029 Feb  7  1997 tripwire-1.2-1.i386.rpm


BTW...for an unmoderated linux-specific security discussion list, send an
empty email to lsd-request@dhp.com with a subject of subscribe.

------------------------------------------------------------------
 Jon Lewis <jlewis@fdt.net>  |  Spammers will be winnuked or
 Network Administrator       |  drawn and quartered...whichever
 Florida Digital Turnpike    |  is more convenient.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

On Sun, 7 Jun 1998, Jon Lewis wrote:
> > Next logical question:  Has anyone worked out rpms for tripwire, COPS,
etc?
> > and why aren''t these necessary security applications a
standard part of ALL
> > distributions?
>
> For RedHat, tripwire would be relatively redundant.  If you keep a copy of
> your rpm database on some sort of removable, remote, or read-only media,
> you can use rpm -V to look for things that are out of sync as far as
> permissions or md5sum go.
My only concerns with running rpm -v is that it only checks files that are
-IN- the RPM database, while Tripwire can alert you to new binaries that
have been installed.

--
      President of New Age Consulting Service, Inc.  Cleveland Ohio
           http://www.nacs.net   info@nacs.net   (216)-619-2000
         An athletic supporter of the Cleveland Linux User Group
                        http://cleveland.lug.net

My site is up now. The ISP I use had a hiccup and I had to jump
through several incompetent bureaucratic hurdles to resolve the issue
after being down more than 24 hours.  

The page again:

http://www.psionic.com/papers/dns.html



Thanks,

-- Craig



On Tue, 9 Jun 1998 seifried@seifried.org wrote:
> > Hello,
> > 
> > I traditionally have always run BIND in a chroot() environment and
always
> > recommend admins do the same because this program is rather
complicated in
> > it''s functionality. This can provide a high degree of
protection from a
> > lot of nonsense that a person may wish to throw at you.
> 
> psionics was not responding <at least for me> so I wrote a set of
> instructions on how to setup BIND for a chrooted environment in RedHat
> 5.X.
> 
> http://www.seifried.org/dns/index.html
> 
> Pretty much step by step instructions, it''s what I have been using
for
> a while. 
> 
> -seifried
> 
> P.S. feedback/constructive criticism is appreciated, I am considering
> writing a series of ''articles'' on securing RedHat
servers, if you are
> interested please encourage me ;)
> 
> -- 
> ----------------------------------------------------------------------
> Please refer to the information about this list as well as general
> information about Linux security at http://www.aoy.com/Linux/Security.
> ----------------------------------------------------------------------
> 
> To unsubscribe:
>   mail -s unsubscribe linux-security-request@redhat.com < /dev/null
>

> Hello,
>
> I traditionally have always run BIND in a chroot() environment and always
> recommend admins do the same because this program is rather complicated in
> it''s functionality. This can provide a high degree of protection
from a
> lot of nonsense that a person may wish to throw at you.
psionics was not responding <at least for me> so I wrote a set of
instructions on how to setup BIND for a chrooted environment in RedHat
5.X.

http://www.seifried.org/dns/index.html

Pretty much step by step instructions, it''s what I have been using for
a while.

-seifried

P.S. feedback/constructive criticism is appreciated, I am considering
writing a series of ''articles'' on securing RedHat servers, if
you are
interested please encourage me ;)

Hello,

It''s been barely a week since DNS exploits were made public and
already people are scanning blocks of addresses looking for DNS version
numbers! 

So I wrote a simple patch that would disable this feature and write a log
notice out of the host that perpetrated the act. Because of the BIND
discussions that have been going on here I though I''d share it with
you.
This is only for version 8.1.2 of BIND, although the mildly saavy can
figure it out for other versions (do a search on "version.bind" in
ns_req.c in the sources).


To apply: 

cd src/bin/named
patch < patchfile.name
re-compile and run (preferably chrooted())

(See http://www.psionic.com/papers/dns.html for more information)


Test using command:

dig @127.0.0.1 version.bind chaos txt

You should see "Go away." come back instead of the BIND version number
and
your log should have an "attackalert" message in it with the IP of the
perpetrator. This can be grep''d for if you use an automated logfile
auditing tool like swatch or <ahem> logcheck, which already looks for
this keyword:

http://www.psionic.com/abacus/abacus_logcheck.html

;) 

While I don''t suspect this will break anything, I would like to hear if
it
does. I''ve been running the patch without incident, but no guarantees
as
usual.


Thanks,

-- Craig







*** ns_req.c	Tue Jun  9 21:56:26 1998
--- ns_req.new	Tue Jun  9 21:46:58 1998
***************
*** 665,673 ****
  		PUTLONG(0, *cpp);		/* TTL */
  		tp = *cpp;			/* Temp RdLength */
  		PUTSHORT(0, *cpp);
! 		copyCharString(cpp, ShortVersion);
  		PUTSHORT((*cpp) - (tp + INT16SZ), tp);	/* Real RdLength */
  		*msglenp = *cpp - msg;		/* Total message length */
  		return (Finish);
  	}
  
--- 665,674 ----
  		PUTLONG(0, *cpp);		/* TTL */
  		tp = *cpp;			/* Temp RdLength */
  		PUTSHORT(0, *cpp);
! 		copyCharString(cpp, "Go away.");
  		PUTSHORT((*cpp) - (tp + INT16SZ), tp);	/* Real RdLength */
  		*msglenp = *cpp - msg;		/* Total message length */
+ 		ns_info(ns_log_security, "attackalert: BIND version query from
%s", sin_ntoa(from));
  		return (Finish);
  	}

On Tue, 9 Jun 1998, Craig H. Rowland wrote:
> Hello,
> 
> It''s been barely a week since DNS exploits were made public and
> already people are scanning blocks of addresses looking for DNS version
> numbers! 
A few things on some comments received:

1) Several people have taken my original post to mean I endorse security
through obscurity by removing the version number from BIND. This is not
true, I changed the version number returned more as a "Hello, I know
you''re there" than as a security measure of any type. An attacker,
unable
to obtain version information, is going to try their attack *anyway*. Why?
Because it''s the only tool they have and they were going to use it
regardless of a patched version or not. This is just how a lot of the
intruders running scripts work. They fish around with their bag-o-tricks
until one works and they often don''t care if you are seemingly patched
against the hole or not.

Most burglaries of homes are stopped not with the sound of a siren, but
with the stickers on the windows notifying the intruder of the prescence
of an alarm. I like to apply the same principle when securing hosts to let
a person know that the admin is watching and will probably be alerted to
their actions. Maybe the person will get the message and move on somewhere
else (or maybe they''ll try harder to get in :) ). 

2) Other points raised include the usefulness of returning the version
information for debugging DNS issues. This is a very valid reason, however
as an admin of a DNS server I would rather have you *write me* to ask
about problems you are having with my DNS service so I can assist rather
than you start poking around remotely. IMHO

3) Some have mentioned that querying DNS version numbers is frequently
done and is not suspicious. I disagree with this for a couple of reasons:

	- Times have changed. If someone was querying DNS version
information a few months ago, I would have found it suspicious, but would
probably have let it slide (well not quite, I would have been watching for
them to return). As new attacks have emerged to target vulnerable DNS
servers though, I believe that admins will find these queries are going
to skyrocket. I''ll venture to guess most of these queries will not be
for
debugging anything except: a) shell code or b) to find vulnerable boxes
without trying exploits on large lists of addresses.

	- It was once true that features like VRFY and EXPN in SMTP were
useful for debugging mail connections too and were completely innocent.
This of course is no longer the case as people abuse these tools to pull
valuable recon information from target hosts. The same goes for other
features in protocols like mail relaying, FTP port redirection ("FTP
bounce"), Finger, etc. Once potentially useful features are now
increasingly dangerous holes "in today''s increasingly imbecile
Internet"[1].

4) Whenever a human is directly interacting with a network daemon in a
non-typical fashion the administrators of the remote site needs to know
about it. This is always a very suspicious event when the majority of a
network daemon''s traffic is server -> server/client operations as it
is
with BIND.

5) Other suspicious events in BIND are written to logs (i.e. denied zone
transfers), I think that version requests should fall into the same
category.

6) LaMont Jones posted to Bugtraq a solution which appears to be a lot
cleaner than patching the sources:
>Date: Fri, 12 Jun 1998 15:28:39 -0600
>From: LaMont Jones <lamont@CRANSTON.FC.HP.COM>
>To: BUGTRAQ@NETSPACE.ORG
>Subject: Re: Silly patch to report version.bind requests
>
>> I wrote this patch for BIND 8.1.2 that will change the version number
>> returned and (most importantly) write to your logs that a person
>> attempted to do so.
>
>Rather than hacking on the source, just do the following with the stock
>distribution:
>
>in named.conf:
>zone "bind" chaos { allow-query {localhost; }; type master; file
>"pri/bind"; };
>
>and in pri/bind:
>$ORIGIN bind.
>@       1D CHAOS SOA    localhost. root.localhost. (
>                        1               ; serial
>                        3H              ; refresh
>                        1H              ; retry
>                        1W              ; expiry
>                        1D )            ; minimum
>        CHAOS NS        localhost.
>
>Presto - log messages for denied queries, and no changes to the code.
>
>lamont
7) Administrators should be provided with as much useful information from
their computer systems as possible so they can decide what to ignore and
what to pay heed to. This was the main point of the patch.

-- Craig


[1] From majordomo.cf file when describing the virtue of running a list
with confirmation turned on after the non-confirmation feature was
presumably abused by mail-bomb scripts.

On Sat, 13 Jun 1998, Craig H. Rowland wrote:
> cleaner than patching the sources:
> 
> >Date: Fri, 12 Jun 1998 15:28:39 -0600
> >From: LaMont Jones <lamont@CRANSTON.FC.HP.COM>
> >To: BUGTRAQ@NETSPACE.ORG
> >Subject: Re: Silly patch to report version.bind requests
> >
> >> I wrote this patch for BIND 8.1.2 that will change the version
number
> >> returned and (most importantly) write to your logs that a person
> >> attempted to do so.
> >
> >Rather than hacking on the source, just do the following with the stock
> >distribution:
> >
> >in named.conf:
> >zone "bind" chaos { allow-query {localhost; }; type master;
file
> >"pri/bind"; };
> >
> >and in pri/bind:
> >$ORIGIN bind.
> >@       1D CHAOS SOA    localhost. root.localhost. (
> >                        1               ; serial
> >                        3H              ; refresh
> >                        1H              ; retry
> >                        1W              ; expiry
> >                        1D )            ; minimum
> >        CHAOS NS        localhost.
> >
This applies to the newer 8.? bind. RedHat does not ship with this
configuration. Could someone translate the above to work with a named.boot
configuration.

             +--------------------------------------------------+
             | David Gale                    Technical Director |
             |           datApex Network Systems, INC.          |
             |            2441 Bellevue Ave, Suite A            |
             |             Daytona Beach, FL 32114              |
             |             http://www.datapex.com               |
             | Phone 904 257-2500 EXT 609     FAX 904 947-5358  |
             +--------------------------------------------------+

On Mon, Jun 15, 1998 at 09:08:51AM -0400, David Gale wrote:

[ description of how to limit access to version.bind deleted ]
> This applies to the newer 8.? bind. RedHat does not ship with this
> configuration. Could someone translate the above to work with a named.boot
> configuration.
It is not possible for bind-4.x.  We at the LUGA (the Austrian Linux User
Group) have built bind-8 RPMs for RHL5.0 and RHL4.2.  The links are:

	RHL5.0:	http://www.luga.or.at/software/bind-8.1.2-3.i386.rpm
		http://www.luga.or.at/software/bind-utils-8.1.2-3.i386.rpm
		http://www.luga.or.at/software/bind-8.1.2-3.src.rpm

	RHL4.2:	http://www.luga.or.at/software/bind-8.1.2-1rh4.i386.rpm
		http://www.luga.or.at/software/bind-utils-8.1.2-1rh4.i386.rpm
		http://www.luga.or.at/software/bind-8.1.2-1rh4.src.rpm

Enclosed in the packages you find a program in /var/named which will make
the transition very easy.  Just convert your named.boot to named.conf by
cd''ing into /var/named and typing:

	./named-bootconf.pl < /etc/named.boot > /etc/named.conf

I use the RHL5.0 packages for more than 3 weeks now without any problems.

-GünthER
-- 
GünthER H. Leber, Adcon Telemetry GmbH
PGP Public Key: https://www.luga.or.at/pgppubkeys/921B6241.asc
PGP KeyID: 1024/921B6241
PGP Fingerprint: E4 59 2D 9C FD C4 41 4E  66 0D E2 E9 B9 34 3A C3