Re: rlinetd security

[Jamie Heilman]

Ted Cabeen wrote:

> In other news, the maintainer of netbase is against removing the netbase 
> dependency on netkit-inetd, but I can't really seem to tell why.  I've looked 
> at his posts on debian-devel and in the BTS, but I haven't found a good 
> justification for the dependency yet.  If anyone does know Anthony's reasons, 
> I'd like to hear them.

I thought about asking why a few months ago, but after reading his responses
in the BTS I decided I'd save my breath.  There is no good reason afaik,
and I'd even go out on a limb and say there is no good reason *period* as
I've been running several machines without a working inetd for a year or so
now, simply don't have the need for it on most workstations in my situation.

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"You came all this way way without saying squat and now you're trying
 to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile?
 I liked you better when you weren't saying squat kid." -Buddy

Re: rlinetd security

[Jamie Heilman]

Ted Cabeen wrote:

> In other news, the maintainer of netbase is against removing the netbase 
> dependency on netkit-inetd, but I can't really seem to tell why.  I've looked 
> at his posts on debian-devel and in the BTS, but I haven't found a good 
> justification for the dependency yet.  If anyone does know Anthony's reasons, 
> I'd like to hear them.

I thought about asking why a few months ago, but after reading his responses
in the BTS I decided I'd save my breath.  There is no good reason afaik,
and I'd even go out on a limb and say there is no good reason *period* as
I've been running several machines without a working inetd for a year or so
now, simply don't have the need for it on most workstations in my situation.

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"You came all this way way without saying squat and now you're trying
 to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile?
 I liked you better when you weren't saying squat kid." -Buddy


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Hubert Chan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> "Hubert" == Hubert Chan <[EMAIL PROTECTED]> writes:

> "Dale" == Dale Southard <[EMAIL PROTECTED]> writes:
Dale> Is something like the IRIX or redhat (gasp) `chkconfig` system
Dale> worth considering?

Hubert> I don't have it installed, so I can't say for sure, but it seems
Hubert> like the file-rc package (from woody) does something like this.

Oops.  I guess I should have pasted a package description for the sake
of those who aren't using woody:

,
| [sixpack:~]# apt-cache show file-rc
| Package: file-rc
| Priority: extra
| Section: admin
| Installed-Size: 55
| Maintainer: Roland Rosenfeld <[EMAIL PROTECTED]>
| Architecture: all
| Version: 0.5.7
| Depends: sysvinit
| Conflicts: ash (<< 0.3.5-1)
| Filename: dists/woody/main/binary-all/admin/file-rc_0.5.7.deb
| Size: 17676
| MD5sum: f33837f77d63b10d78cf58b480a84784
| Description: Alternative one-configfile boot mechanism
|  This package provides an alternative mechanism to boot the system, to
|  shut it down and to change runlevels.  The /etc/rc?.d/* links will be
|  converted into one single configuration file /etc/runlevel.conf
|  instead, which is easier to administrate than symlinks, and is also
|  more flexible.
|  .
|  The package will automatically convert your existing symlinks into
|  the file method on installation, and convert the file back into
|  symlinks on removal.  Both mechanisms are compatible trough
|  /etc/init.d/rc, /etc/init.d/rcS and /usr/sbin/update-rc.d scripts.
`

- -- 
Hubert Chan <[EMAIL PROTECTED]> - http://www.geocities.com/hubertchan/
PGP/GnuPG key: 1024D/71FDA37F
Fingerprint: 6CC5 822D 2E55 494C 81DD  6F2C 6518 54DF 71FD A37F
Key available at wwwkeys.pgp.net.   Please encrypt *all* e-mail to me.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7L9YfZRhU33H9o38RAkLCAKDWj2NidH2jfPBQGZem+YvKIzubVwCgnxY9
w312lXElQCci4dfb9E27NDQ=
=wdbH
-END PGP SIGNATURE-

Re: rlinetd security

[Hubert Chan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> "Dale" == Dale Southard <[EMAIL PROTECTED]> writes:

Dale> Is something like the IRIX or redhat (gasp) `chkconfig` system
Dale> worth considering?

I don't have it installed, so I can't say for sure, but it seems like
the file-rc package (from woody) does something like this.

- -- 
Hubert Chan <[EMAIL PROTECTED]> - http://www.geocities.com/hubertchan/
PGP/GnuPG key: 1024D/71FDA37F
Fingerprint: 6CC5 822D 2E55 494C 81DD  6F2C 6518 54DF 71FD A37F
Key available at wwwkeys.pgp.net.   Please encrypt *all* e-mail to me.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7L9FBZRhU33H9o38RAkbgAJsE/6pAwA5EA5A/FX97g9D0NK8jywCgunR3
mhmUy+zmPHDi+jV9h4Js/7w=
=1U9N
-END PGP SIGNATURE-

Re: rlinetd security

[Joseph Pingenot]

>From Dale Southard on Tuesday, 19 June, 2001:
>Actually, your version is a little more complex than the IRIX version.
>Under IRIX there are seperate files for each service, rather than a
>single file with on/off entries for each service.  In other words
>`echo on > /etc/config/xdm` and `chkconfig xdm on` do exactly the same
>thing under IRIX.

Erm, seems like a waste of disk space to me.  1 block just to say "on"?
  Ah well.

>IRIX sometimes uses multiple chkconfig entries in tne same rc script,
>eg turning off `network' also prevents named, nfs, timed, routed, and
>lots of other services from starting.  All told there are about 50
>chkconfig flags on a normal IRIX install.

Hrm.  I suppose one could add ':depends' after the setting.  e.g.
  daemon=status:dependencies
if you wanted to do the same thing.  That would maybe make it a perl
  script (you could still do it as a sh-script, though).
  I suppose my script shouldn't have relied on perl, though.  Or grep/sed,
  although grep/sed are pretty small and should be included on minimal
  installs.
Then recursively walk through the dependencies, although you would then
  need some way to make sure you weren't going to loop back on yourself,
  causing an infinite loop.  Ah well.

>Also note that /etc/rc?.d isn't really guaranteed by anything other
>than convention.  I can easily write init.d scripts that do the wrong
>thing, and updating/reinstalling can put rc?.d symlinks back in (which
>is how we got on this subject to begin with).  Under IRIX, the
>chkconfig convention is entrenched and works quite well.  Wether or
>not it would be a useful addition to Debian is another question

Also true.  And you can always go back to /etc/inittab.  :)  I guess
  all these things need to be changed in order to keep security.  Maybe
  a quick little checsec script to do this?  :)

checksec /path/to/daemon

So many options, so much scripting that can be done.  :)

  -Joseph
-- 
[EMAIL PROTECTED]
"IBM were providing source code in the 1960's under similar terms. 
VMS source code was available under limited licenses to customers 
from the beginning. Microsoft are catching up with 1960."
   --Alan Cox,  http://www2.usermagnet.com/cox/index.html

Re: rlinetd security

[Dale Southard]

Actually, your version is a little more complex than the IRIX version.
Under IRIX there are seperate files for each service, rather than a
single file with on/off entries for each service.  In other words
`echo on > /etc/config/xdm` and `chkconfig xdm on` do exactly the same
thing under IRIX.

IRIX sometimes uses multiple chkconfig entries in tne same rc script,
eg turning off `network' also prevents named, nfs, timed, routed, and
lots of other services from starting.  All told there are about 50
chkconfig flags on a normal IRIX install.

Also note that /etc/rc?.d isn't really guaranteed by anything other
than convention.  I can easily write init.d scripts that do the wrong
thing, and updating/reinstalling can put rc?.d symlinks back in (which
is how we got on this subject to begin with).  Under IRIX, the
chkconfig convention is entrenched and works quite well.  Wether or
not it would be a useful addition to Debian is another question


Joseph Pingenot <[EMAIL PROTECTED]> writes:

> From Dale Southard on Tuesday, 19 June, 2001:
> Hrm.  That could be rather easy to implement.  The guaranteed
>   way to see if something's going to be started or not, though,
>   is still /etc/rc?.d
> 
> If you want to, you can replace them and create an easy
>   script, such as
> 
> --/sbin/chkdconfig--
> #!/bin/bash
> 
> #returns 1 if daemon is enabled, 0 otherwise.
> 
> if [ -z "$1" ]; then
>   echo "Error: No daemon process specified"
>   exit 0;
> fi
> 
> configfile=/etc/checkdconfig
> line=`grep -i "^$1=" $configfile 2>/dev/null | head -1`
> if [ $? -ne 0 ]; then
>   #No such line existed.  Return 0.
> fi
> 
> setting=`echo $line | sed 's/^.*=//'`;
> setting=`echo $setting | perl -we '$_ = ; s/\s+//g; print;'`
> case "$setting" in
>   'on'|'ON'|'On'|'oN'|'yes'|'YES'|'Yes'|'YEs'|'yEs'|'yES'|'yeS'|'1')
>  exit 1
>  ;;
>*)
>  exit 0
>  ;;
> esac
> exit 0
> --end chkdconfig--
> 
> please, no comments on my perl or bash-scripting (lack of) abilities.  ;)
> All that would then remain is to alter the rc scripts to check chkconfig
>   and to NOT populate it with daemon=value lines.  :)

-- 

/*  Dale Southard Jr.   [EMAIL PROTECTED]925-422-1463  */
/*  Computer Scientist, Accelerated Strategic Computing Initiative  */
/*  L-550,  Lawrence Livermore National Lab,  Livermore CA   94551  */
/*  AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving  */

Re: rlinetd security

[Joseph Pingenot]

>From Dale Southard on Tuesday, 19 June, 2001:
Hrm.  That could be rather easy to implement.  The guaranteed
  way to see if something's going to be started or not, though,
  is still /etc/rc?.d

If you want to, you can replace them and create an easy
  script, such as

--/sbin/chkdconfig--
#!/bin/bash

#returns 1 if daemon is enabled, 0 otherwise.

if [ -z "$1" ]; then
  echo "Error: No daemon process specified"
  exit 0;
fi

configfile=/etc/checkdconfig
line=`grep -i "^$1=" $configfile 2>/dev/null | head -1`
if [ $? -ne 0 ]; then
  #No such line existed.  Return 0.
fi

setting=`echo $line | sed 's/^.*=//'`;
setting=`echo $setting | perl -we '$_ = ; s/\s+//g; print;'`
case "$setting" in
  'on'|'ON'|'On'|'oN'|'yes'|'YES'|'Yes'|'YEs'|'yEs'|'yES'|'yeS'|'1')
 exit 1
 ;;
   *)
 exit 0
 ;;
esac
exit 0
--end chkdconfig--

please, no comments on my perl or bash-scripting (lack of) abilities.  ;)
All that would then remain is to alter the rc scripts to check chkconfig
  and to NOT populate it with daemon=value lines.  :)

  -Joseph
-- 
[EMAIL PROTECTED]
"IBM were providing source code in the 1960's under similar terms. 
VMS source code was available under limited licenses to customers 
from the beginning. Microsoft are catching up with 1960."
   --Alan Cox,  http://www2.usermagnet.com/cox/index.html

Re: rlinetd security

[Ted Cabeen]

In message <[EMAIL PROTECTED]>, Dale Southard writes:
>[EMAIL PROTECTED] (Sami J. Juvonen) writes:
>> What I would really like Debian to do when installing services is to *not*
>> start them by default. Just install all the files, but make init scripts 
>> not run unless edited.
>
>Is something like the IRIX or redhat (gasp) `chkconfig` system worth
>considering?

It's not a bad solution, but on fully-loaded systems, the number of chkconfig 
options might get a little out of hand. 

In other news, the maintainer of netbase is against removing the netbase 
dependency on netkit-inetd, but I can't really seem to tell why.  I've looked 
at his posts on debian-devel and in the BTS, but I haven't found a good 
justification for the dependency yet.  If anyone does know Anthony's reasons, 
I'd like to hear them.

--
Ted Cabeen   http://www.pobox.com/~secabeen [EMAIL PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2  [EMAIL PROTECTED]
"I have taken all knowledge to be my province." -F. Bacon  [EMAIL PROTECTED]
"Human kind cannot bear very much reality."-T.S.Eliot[EMAIL PROTECTED]




pgpdNmUce20hp.pgp
Description: PGP signature

Re: rlinetd security

[Jamie Heilman]

Tim Haynes wrote:

> FWIW I heard recently[i] that djbdns never needs TCP. Maybe this is by

Not exactly.

tinydns only uses port 53 udp
axfrdns only uses port 53 tcp - you run this if you a) need to allow zone
transfers to legacy systems, b) need to serve
large queries, otherwise, you don't need it
dnscache uses port 53 both tcp and udp - its the caching resolver

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"I was in love once -- a Sinclair ZX-81.  People said, "No, Holly, she's 
 not for you." She was cheap, she was stupid and she wouldn't load 
 -- well, not for me, anyway."  -Holly

Re: rlinetd security

[Dale Southard]

[EMAIL PROTECTED] (Sami J. Juvonen) writes:

> 
> What I would really like Debian to do when installing services is to *not*
> start them by default. Just install all the files, but make init scripts 
> not run unless edited.

Is something like the IRIX or redhat (gasp) `chkconfig` system worth
considering?

For those that haven't seen it, IRIX uses a program called
``chkconfig'' to control things started from /etc/init.d scripts.
Essentially chkconfig is a fairly simple program that does one of
three things depending on how it's called:

 1) `chkconfig` prints ``state'' (on or off) of every configuration
flag found in /var/config (the flags are just the string ``on''
or ``off'' stored in individual txt files in that directory).

 2) `chkconfig [-f] ` sets the flag to the desired state
(the -f option will create the flag if it doesn't exist)

 3) `chkconfig ` will check the status of the flag -- chkconfig
will exit with status 0 if it is on, 1 if it is off or
nonexistent.

How this works in practice:

Scripts in /etc/init.d all have a structure something like:

  case "$1" in
'start')
  if /etc/chkconfig myservice; then
...start myservice

So, in this example if if the /var/config/myservice file doesn't
contain ``on'' (or doesn't exist) the commands to start it won't be
run.  

As a whole the system works fairly well (and is easier for newbie
admins than the Red Hat chkconfig implementation or symlink
creation/deletion).  It's fairly simple to turn things on/off, and
there are few surprises during updates.


-- 

/*  Dale Southard Jr.   [EMAIL PROTECTED]925-422-1463  */
/*  Computer Scientist, Accelerated Strategic Computing Initiative  */
/*  L-550,  Lawrence Livermore National Lab,  Livermore CA   94551  */
/*  AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving  */

Re: rlinetd security

[Joseph Pingenot]

>From Pat Moffitt on Tuesday, 19 June, 2001:
>> -Original Message-
>> From: Joseph Pingenot [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, June 19, 2001 9:54 AM
>> To: debian-security@lists.debian.org
>> Subject: Re: rlinetd security
>[snip]
>> While we're at it, it'd be nice if the packages (on an update)
>> didn't re-enable
>>   themselves if I've disabled them.  Inetd should check each of
>> the runlevels to
>>   see if it's currently enabled (/etc/rc?.d).  If it's not, it
>> shouldn't make it
>>   so.  The same goes for all the other services in /etc/rc?.d.
>> Also, if it
>>   isn't listed in /etc/inetd.conf, the admin has probably removed
>> it, and it
>>   shouldn't add itself back in.
>> Just something that's annoyed me when updating daily.  :)
>The latest exim update got me on that one.  I have exim running all the
>time, don't want it in inetd.conf

Yup, me too.  that's why I wrote in.  :)  Maybe we can make inetd.conf
  ugo-r by default?  That'll help keep stuff from writing to it, and
  inexperienced sysadmins from letting stuff add to it.  *But* it should
  be empty first.  :)

  -Joseph

-- 
[EMAIL PROTECTED]
"IBM were providing source code in the 1960's under similar terms. 
VMS source code was available under limited licenses to customers 
from the beginning. Microsoft are catching up with 1960."
   --Alan Cox,  http://www2.usermagnet.com/cox/index.html

Re: rlinetd security

[Tim Haynes]

[EMAIL PROTECTED] (Sami J. Juvonen) writes:

> Tim Haynes <[EMAIL PROTECTED]> writes:
> 
> > "Noah L. Meyerhans" <[EMAIL PROTECTED]> writes:
> > 
> > And let's not forget that plenty enough people don't know all 3 obvious
> > commands for finding a process responsible for a given listener, or
> > don't have `head /etc/services` in short-term memory, or why 53/tcp is
> > a Bad Thing, etc...
> 
> Just a minor nit: 53/tcp is *not* inherently bad. Blocking it breaks some
> DNS functionality.

What's more likely, that you're going to want the world and his dog to xfer
your zones and return result sets >512 bytes, or that some schmuck is going
to scan you for the port and attempt to exploit it? Bear in mind that bind
in Debian does not get chrooted by default (IIRC it doesn't even -u, does
it?), so the "just install it from distro defaults and leave it dangling"
line makes for horrible insecurity.

FWIW I heard recently[i] that djbdns never needs TCP. Maybe this is by
implementing a subset of `DNS functionality' - quite possibly so; but if
so, non-TCP DNS is something with which I'm happy to live for the most
part. Obviously, if I'm setting up a nameserver, it's a different kettle of
fish - I know a little stuff there, and am content that others should have
to RTBdocs to get to the same stage, if it means there are fewer insecure
boxes out there attempting to crack me.

> > Yes. I've seen the question `should one aim for secure by default?' 
> > before and never made up my mind; there is a `false complacency'
> > argument to be wary of, of course, but I'm now pretty much decided that
> > one should aim for as secure as possible if only to stop things
> > spreading through people's incompetance.
> 
> I agree with this. Sysadmins should also be vary of legacy services that
> "have always been there" in Unix. A lot of that cruft follows us around
> just by tradition.

.

> What I would really like Debian to do when installing services is to
> *not* start them by default. Just install all the files, but make init
> scripts not run unless edited.

I dunno about `unless edited'; having a variety of ways to disable things
is obviously a blessing, but it's a bit perverse when you have update-rc.d
to do the job, to go around putting `exit 0' at the top of scripts for
folks to find, IMHO.

~Tim

Footnotes: 
[i]  For obvious reasons, I never expect to have to find out the hard way.

-- 
A big sky above me, |[EMAIL PROTECTED]
West winds blow.|http://spodzone.org.uk/

Re: rlinetd security

[Hubert Chan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> "Hubert" == Hubert Chan <[EMAIL PROTECTED]> writes:

> "Dale" == Dale Southard <[EMAIL PROTECTED]> writes:
Dale> Is something like the IRIX or redhat (gasp) `chkconfig` system
Dale> worth considering?

Hubert> I don't have it installed, so I can't say for sure, but it seems
Hubert> like the file-rc package (from woody) does something like this.

Oops.  I guess I should have pasted a package description for the sake
of those who aren't using woody:

,
| [sixpack:~]# apt-cache show file-rc
| Package: file-rc
| Priority: extra
| Section: admin
| Installed-Size: 55
| Maintainer: Roland Rosenfeld <[EMAIL PROTECTED]>
| Architecture: all
| Version: 0.5.7
| Depends: sysvinit
| Conflicts: ash (<< 0.3.5-1)
| Filename: dists/woody/main/binary-all/admin/file-rc_0.5.7.deb
| Size: 17676
| MD5sum: f33837f77d63b10d78cf58b480a84784
| Description: Alternative one-configfile boot mechanism
|  This package provides an alternative mechanism to boot the system, to
|  shut it down and to change runlevels.  The /etc/rc?.d/* links will be
|  converted into one single configuration file /etc/runlevel.conf
|  instead, which is easier to administrate than symlinks, and is also
|  more flexible.
|  .
|  The package will automatically convert your existing symlinks into
|  the file method on installation, and convert the file back into
|  symlinks on removal.  Both mechanisms are compatible trough
|  /etc/init.d/rc, /etc/init.d/rcS and /usr/sbin/update-rc.d scripts.
`

- -- 
Hubert Chan <[EMAIL PROTECTED]> - http://www.geocities.com/hubertchan/
PGP/GnuPG key: 1024D/71FDA37F
Fingerprint: 6CC5 822D 2E55 494C 81DD  6F2C 6518 54DF 71FD A37F
Key available at wwwkeys.pgp.net.   Please encrypt *all* e-mail to me.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7L9YfZRhU33H9o38RAkLCAKDWj2NidH2jfPBQGZem+YvKIzubVwCgnxY9
w312lXElQCci4dfb9E27NDQ=
=wdbH
-END PGP SIGNATURE-


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Hubert Chan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> "Dale" == Dale Southard <[EMAIL PROTECTED]> writes:

Dale> Is something like the IRIX or redhat (gasp) `chkconfig` system
Dale> worth considering?

I don't have it installed, so I can't say for sure, but it seems like
the file-rc package (from woody) does something like this.

- -- 
Hubert Chan <[EMAIL PROTECTED]> - http://www.geocities.com/hubertchan/
PGP/GnuPG key: 1024D/71FDA37F
Fingerprint: 6CC5 822D 2E55 494C 81DD  6F2C 6518 54DF 71FD A37F
Key available at wwwkeys.pgp.net.   Please encrypt *all* e-mail to me.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7L9FBZRhU33H9o38RAkbgAJsE/6pAwA5EA5A/FX97g9D0NK8jywCgunR3
mhmUy+zmPHDi+jV9h4Js/7w=
=1U9N
-END PGP SIGNATURE-


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Sami J. Juvonen]

Tim Haynes <[EMAIL PROTECTED]> writes:

> "Noah L. Meyerhans" <[EMAIL PROTECTED]> writes:
> 
> And let's not forget that plenty enough people don't know all 3 obvious
> commands for finding a process responsible for a given listener, or don't
> have `head /etc/services` in short-term memory, or why 53/tcp is a Bad
> Thing, etc...

Just a minor nit: 53/tcp is *not* inherently bad. Blocking it breaks some 
DNS functionality.

> Yes. I've seen the question `should one aim for secure by default?' before
> and never made up my mind; there is a `false complacency' argument to be
> wary of, of course, but I'm now pretty much decided that one should aim for
> as secure as possible if only to stop things spreading through people's
> incompetance. 

I agree with this. Sysadmins should also be vary of legacy services that 
"have always been there" in Unix. A lot of that cruft follows us around
just by tradition. 

What I would really like Debian to do when installing services is to *not*
start them by default. Just install all the files, but make init scripts 
not run unless edited.

-sami.

Re: rlinetd security

[Jamie Heilman]

> >Can't it just be removed with update-rc.d?
> 
> Sure, of course.  You just can't delete it from the system entirely, which is 
> what I would prefer.

Exactly, you can do all kinds of things to make sure it isn't enabled, (I
usually add exit 0 to the top of the init script) but not having the
software isntalled that you don't use is one of the biggest advantages to a
binary based distro like Debian.  Its the inability to do this at a
sufficiently granular level in *BSD that makes me want to punch through
walls sometimes.  One of the biggest reasons I still evangelize binary
distro's and linux.

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"I was in love once -- a Sinclair ZX-81.  People said, "No, Holly, she's 
 not for you." She was cheap, she was stupid and she wouldn't load 
 -- well, not for me, anyway."  -Holly

Re: rlinetd security

[Joseph Pingenot]

>From Dale Southard on Tuesday, 19 June, 2001:
>Actually, your version is a little more complex than the IRIX version.
>Under IRIX there are seperate files for each service, rather than a
>single file with on/off entries for each service.  In other words
>`echo on > /etc/config/xdm` and `chkconfig xdm on` do exactly the same
>thing under IRIX.

Erm, seems like a waste of disk space to me.  1 block just to say "on"?
  Ah well.

>IRIX sometimes uses multiple chkconfig entries in tne same rc script,
>eg turning off `network' also prevents named, nfs, timed, routed, and
>lots of other services from starting.  All told there are about 50
>chkconfig flags on a normal IRIX install.

Hrm.  I suppose one could add ':depends' after the setting.  e.g.
  daemon=status:dependencies
if you wanted to do the same thing.  That would maybe make it a perl
  script (you could still do it as a sh-script, though).
  I suppose my script shouldn't have relied on perl, though.  Or grep/sed,
  although grep/sed are pretty small and should be included on minimal
  installs.
Then recursively walk through the dependencies, although you would then
  need some way to make sure you weren't going to loop back on yourself,
  causing an infinite loop.  Ah well.

>Also note that /etc/rc?.d isn't really guaranteed by anything other
>than convention.  I can easily write init.d scripts that do the wrong
>thing, and updating/reinstalling can put rc?.d symlinks back in (which
>is how we got on this subject to begin with).  Under IRIX, the
>chkconfig convention is entrenched and works quite well.  Wether or
>not it would be a useful addition to Debian is another question

Also true.  And you can always go back to /etc/inittab.  :)  I guess
  all these things need to be changed in order to keep security.  Maybe
  a quick little checsec script to do this?  :)

checksec /path/to/daemon

So many options, so much scripting that can be done.  :)

  -Joseph
-- 
[EMAIL PROTECTED]
"IBM were providing source code in the 1960's under similar terms. 
VMS source code was available under limited licenses to customers 
from the beginning. Microsoft are catching up with 1960."
   --Alan Cox,  http://www2.usermagnet.com/cox/index.html


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Dale Southard]

Actually, your version is a little more complex than the IRIX version.
Under IRIX there are seperate files for each service, rather than a
single file with on/off entries for each service.  In other words
`echo on > /etc/config/xdm` and `chkconfig xdm on` do exactly the same
thing under IRIX.

IRIX sometimes uses multiple chkconfig entries in tne same rc script,
eg turning off `network' also prevents named, nfs, timed, routed, and
lots of other services from starting.  All told there are about 50
chkconfig flags on a normal IRIX install.

Also note that /etc/rc?.d isn't really guaranteed by anything other
than convention.  I can easily write init.d scripts that do the wrong
thing, and updating/reinstalling can put rc?.d symlinks back in (which
is how we got on this subject to begin with).  Under IRIX, the
chkconfig convention is entrenched and works quite well.  Wether or
not it would be a useful addition to Debian is another question


Joseph Pingenot <[EMAIL PROTECTED]> writes:

> From Dale Southard on Tuesday, 19 June, 2001:
> Hrm.  That could be rather easy to implement.  The guaranteed
>   way to see if something's going to be started or not, though,
>   is still /etc/rc?.d
> 
> If you want to, you can replace them and create an easy
>   script, such as
> 
> --/sbin/chkdconfig--
> #!/bin/bash
> 
> #returns 1 if daemon is enabled, 0 otherwise.
> 
> if [ -z "$1" ]; then
>   echo "Error: No daemon process specified"
>   exit 0;
> fi
> 
> configfile=/etc/checkdconfig
> line=`grep -i "^$1=" $configfile 2>/dev/null | head -1`
> if [ $? -ne 0 ]; then
>   #No such line existed.  Return 0.
> fi
> 
> setting=`echo $line | sed 's/^.*=//'`;
> setting=`echo $setting | perl -we '$_ = ; s/\s+//g; print;'`
> case "$setting" in
>   'on'|'ON'|'On'|'oN'|'yes'|'YES'|'Yes'|'YEs'|'yEs'|'yES'|'yeS'|'1')
>  exit 1
>  ;;
>*)
>  exit 0
>  ;;
> esac
> exit 0
> --end chkdconfig--
> 
> please, no comments on my perl or bash-scripting (lack of) abilities.  ;)
> All that would then remain is to alter the rc scripts to check chkconfig
>   and to NOT populate it with daemon=value lines.  :)

-- 

/*  Dale Southard Jr.   [EMAIL PROTECTED]925-422-1463  */
/*  Computer Scientist, Accelerated Strategic Computing Initiative  */
/*  L-550,  Lawrence Livermore National Lab,  Livermore CA   94551  */
/*  AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving  */


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Ted Cabeen]

In message <[EMAIL PROTECTED]>, Quietman writes:
>On Tue, Jun 19, 2001 at 01:25:17PM -0500, Ted Cabeen wrote:
>> >It's true that uninstalling it (in potato, anyway) is not worth all the
>> >effort.  But you can definitely disable it.  I have "K20inetd" links in
>> >all my /etc/rc?.d directories where I don't want to run inetd.
>>
>> Unfortunately, you can't do it in sid either without using equivs.  netbase
>> depends on netkit-inetd.  :(
>Can't it just be removed with update-rc.d?

Sure, of course.  You just can't delete it from the system entirely, which is 
what I would prefer.

--
Ted Cabeen   http://www.pobox.com/~secabeen [EMAIL PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2  [EMAIL PROTECTED]
"I have taken all knowledge to be my province." -F. Bacon  [EMAIL PROTECTED]
"Human kind cannot bear very much reality."-T.S.Eliot[EMAIL PROTECTED]




pgp0k0J8kMKO3.pgp
Description: PGP signature

Re: rlinetd security

[Quietman]

On Tue, Jun 19, 2001 at 01:25:17PM -0500, Ted Cabeen wrote:
> >It's true that uninstalling it (in potato, anyway) is not worth all the
> >effort.  But you can definitely disable it.  I have "K20inetd" links in
> >all my /etc/rc?.d directories where I don't want to run inetd.
> 
> Unfortunately, you can't do it in sid either without using equivs.  netbase 
> depends on netkit-inetd.  :(
Can't it just be removed with update-rc.d?

Cheers,
Tom


pgpP9GOEgSPf4.pgp
Description: PGP signature

Re: rlinetd security

[Ted Cabeen]

In message <[EMAIL PROTECTED]>, Dale Southard writes:
>[EMAIL PROTECTED] (Sami J. Juvonen) writes:
>> What I would really like Debian to do when installing services is to *not*
>> start them by default. Just install all the files, but make init scripts 
>> not run unless edited.
>
>Is something like the IRIX or redhat (gasp) `chkconfig` system worth
>considering?

It's not a bad solution, but on fully-loaded systems, the number of chkconfig 
options might get a little out of hand. 

In other news, the maintainer of netbase is against removing the netbase 
dependency on netkit-inetd, but I can't really seem to tell why.  I've looked 
at his posts on debian-devel and in the BTS, but I haven't found a good 
justification for the dependency yet.  If anyone does know Anthony's reasons, 
I'd like to hear them.

--
Ted Cabeen   http://www.pobox.com/~secabeen [EMAIL PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2  [EMAIL PROTECTED]
"I have taken all knowledge to be my province." -F. Bacon  [EMAIL PROTECTED]
"Human kind cannot bear very much reality."-T.S.Eliot[EMAIL PROTECTED]



 PGP signature

Re: rlinetd security

[Jamie Heilman]

Tim Haynes wrote:

> FWIW I heard recently[i] that djbdns never needs TCP. Maybe this is by

Not exactly.

tinydns only uses port 53 udp
axfrdns only uses port 53 tcp - you run this if you a) need to allow zone
transfers to legacy systems, b) need to serve
large queries, otherwise, you don't need it
dnscache uses port 53 both tcp and udp - its the caching resolver

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"I was in love once -- a Sinclair ZX-81.  People said, "No, Holly, she's 
 not for you." She was cheap, she was stupid and she wouldn't load 
 -- well, not for me, anyway."  -Holly


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Dale Southard]

[EMAIL PROTECTED] (Sami J. Juvonen) writes:

> 
> What I would really like Debian to do when installing services is to *not*
> start them by default. Just install all the files, but make init scripts 
> not run unless edited.

Is something like the IRIX or redhat (gasp) `chkconfig` system worth
considering?

For those that haven't seen it, IRIX uses a program called
``chkconfig'' to control things started from /etc/init.d scripts.
Essentially chkconfig is a fairly simple program that does one of
three things depending on how it's called:

 1) `chkconfig` prints ``state'' (on or off) of every configuration
flag found in /var/config (the flags are just the string ``on''
or ``off'' stored in individual txt files in that directory).

 2) `chkconfig [-f] ` sets the flag to the desired state
(the -f option will create the flag if it doesn't exist)

 3) `chkconfig ` will check the status of the flag -- chkconfig
will exit with status 0 if it is on, 1 if it is off or
nonexistent.

How this works in practice:

Scripts in /etc/init.d all have a structure something like:

  case "$1" in
'start')
  if /etc/chkconfig myservice; then
...start myservice

So, in this example if if the /var/config/myservice file doesn't
contain ``on'' (or doesn't exist) the commands to start it won't be
run.  

As a whole the system works fairly well (and is easier for newbie
admins than the Red Hat chkconfig implementation or symlink
creation/deletion).  It's fairly simple to turn things on/off, and
there are few surprises during updates.


-- 

/*  Dale Southard Jr.   [EMAIL PROTECTED]925-422-1463  */
/*  Computer Scientist, Accelerated Strategic Computing Initiative  */
/*  L-550,  Lawrence Livermore National Lab,  Livermore CA   94551  */
/*  AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving  */


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Joseph Pingenot]

>From Pat Moffitt on Tuesday, 19 June, 2001:
>> -Original Message-
>> From: Joseph Pingenot [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, June 19, 2001 9:54 AM
>> To: [EMAIL PROTECTED]
>> Subject: Re: rlinetd security
>[snip]
>> While we're at it, it'd be nice if the packages (on an update)
>> didn't re-enable
>>   themselves if I've disabled them.  Inetd should check each of
>> the runlevels to
>>   see if it's currently enabled (/etc/rc?.d).  If it's not, it
>> shouldn't make it
>>   so.  The same goes for all the other services in /etc/rc?.d.
>> Also, if it
>>   isn't listed in /etc/inetd.conf, the admin has probably removed
>> it, and it
>>   shouldn't add itself back in.
>> Just something that's annoyed me when updating daily.  :)
>The latest exim update got me on that one.  I have exim running all the
>time, don't want it in inetd.conf

Yup, me too.  that's why I wrote in.  :)  Maybe we can make inetd.conf
  ugo-r by default?  That'll help keep stuff from writing to it, and
  inexperienced sysadmins from letting stuff add to it.  *But* it should
  be empty first.  :)

  -Joseph

-- 
[EMAIL PROTECTED]
"IBM were providing source code in the 1960's under similar terms. 
VMS source code was available under limited licenses to customers 
from the beginning. Microsoft are catching up with 1960."
   --Alan Cox,  http://www2.usermagnet.com/cox/index.html


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Ted Cabeen]

In message <[EMAIL PROTECTED]>, "Noah L. Meyerhans" writes:
>On Tue, Jun 19, 2001 at 10:47:47AM -0700, Jamie Heilman wrote:
>> No, you can't if you're plan is to uninstall inetd, the package structure is
>> broken and won't allow it due to $@)!ed up dependancies.  I've been trying
>> to do it for ages.  Then, when I found equivs I danced a jig.  Its pretty
>> much impossible to do in potato, I think you can pull it off in sid/woody
>> though with the help of equivs - I haven't tried as my only unstable box
>> actually needed inetd, and was only accessible from an internal network so
>> I wasn't worried about inetd's underlying flaws wrt DoSability and lack of
>> concurency limiting.  If you use inetd on untrusted interface you are
>> asking for pain, I thought that was fairly well understood by now.
>
>It's true that uninstalling it (in potato, anyway) is not worth all the
>effort.  But you can definitely disable it.  I have "K20inetd" links in
>all my /etc/rc?.d directories where I don't want to run inetd.

Unfortunately, you can't do it in sid either without using equivs.  netbase 
depends on netkit-inetd.  :(

--
Ted Cabeen   http://www.pobox.com/~secabeen [EMAIL PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2  [EMAIL PROTECTED]
"I have taken all knowledge to be my province." -F. Bacon  [EMAIL PROTECTED]
"Human kind cannot bear very much reality."-T.S.Eliot[EMAIL PROTECTED]




pgpUfS739r39t.pgp
Description: PGP signature

Re: rlinetd security

[Tim Haynes]

[EMAIL PROTECTED] (Sami J. Juvonen) writes:

> Tim Haynes <[EMAIL PROTECTED]> writes:
> 
> > "Noah L. Meyerhans" <[EMAIL PROTECTED]> writes:
> > 
> > And let's not forget that plenty enough people don't know all 3 obvious
> > commands for finding a process responsible for a given listener, or
> > don't have `head /etc/services` in short-term memory, or why 53/tcp is
> > a Bad Thing, etc...
> 
> Just a minor nit: 53/tcp is *not* inherently bad. Blocking it breaks some
> DNS functionality.

What's more likely, that you're going to want the world and his dog to xfer
your zones and return result sets >512 bytes, or that some schmuck is going
to scan you for the port and attempt to exploit it? Bear in mind that bind
in Debian does not get chrooted by default (IIRC it doesn't even -u, does
it?), so the "just install it from distro defaults and leave it dangling"
line makes for horrible insecurity.

FWIW I heard recently[i] that djbdns never needs TCP. Maybe this is by
implementing a subset of `DNS functionality' - quite possibly so; but if
so, non-TCP DNS is something with which I'm happy to live for the most
part. Obviously, if I'm setting up a nameserver, it's a different kettle of
fish - I know a little stuff there, and am content that others should have
to RTBdocs to get to the same stage, if it means there are fewer insecure
boxes out there attempting to crack me.

> > Yes. I've seen the question `should one aim for secure by default?' 
> > before and never made up my mind; there is a `false complacency'
> > argument to be wary of, of course, but I'm now pretty much decided that
> > one should aim for as secure as possible if only to stop things
> > spreading through people's incompetance.
> 
> I agree with this. Sysadmins should also be vary of legacy services that
> "have always been there" in Unix. A lot of that cruft follows us around
> just by tradition.

.

> What I would really like Debian to do when installing services is to
> *not* start them by default. Just install all the files, but make init
> scripts not run unless edited.

I dunno about `unless edited'; having a variety of ways to disable things
is obviously a blessing, but it's a bit perverse when you have update-rc.d
to do the job, to go around putting `exit 0' at the top of scripts for
folks to find, IMHO.

~Tim

Footnotes: 
[i]  For obvious reasons, I never expect to have to find out the hard way.

-- 
A big sky above me, |[EMAIL PROTECTED]
West winds blow.|http://spodzone.org.uk/


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Noah L. Meyerhans]

On Tue, Jun 19, 2001 at 10:47:47AM -0700, Jamie Heilman wrote:
> No, you can't if you're plan is to uninstall inetd, the package structure is
> broken and won't allow it due to $@)!ed up dependancies.  I've been trying
> to do it for ages.  Then, when I found equivs I danced a jig.  Its pretty
> much impossible to do in potato, I think you can pull it off in sid/woody
> though with the help of equivs - I haven't tried as my only unstable box
> actually needed inetd, and was only accessible from an internal network so
> I wasn't worried about inetd's underlying flaws wrt DoSability and lack of
> concurency limiting.  If you use inetd on untrusted interface you are
> asking for pain, I thought that was fairly well understood by now.

It's true that uninstalling it (in potato, anyway) is not worth all the
effort.  But you can definitely disable it.  I have "K20inetd" links in
all my /etc/rc?.d directories where I don't want to run inetd.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 



pgphwRc8OsXOw.pgp
Description: PGP signature

Re: rlinetd security

[Jamie Heilman]

> > I do care.  I often disable inetd completely, if the server in question
> > doesn't need any of what it offers.
> 
> Interesting thought...  I wonder if I can get away with that easily?

No, you can't if you're plan is to uninstall inetd, the package structure is
broken and won't allow it due to $@)!ed up dependancies.  I've been trying
to do it for ages.  Then, when I found equivs I danced a jig.  Its pretty
much impossible to do in potato, I think you can pull it off in sid/woody
though with the help of equivs - I haven't tried as my only unstable box
actually needed inetd, and was only accessible from an internal network so
I wasn't worried about inetd's underlying flaws wrt DoSability and lack of
concurency limiting.  If you use inetd on untrusted interface you are
asking for pain, I thought that was fairly well understood by now.

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"I was in love once -- a Sinclair ZX-81.  People said, "No, Holly, she's 
 not for you." She was cheap, she was stupid and she wouldn't load 
 -- well, not for me, anyway."  -Holly

Re: rlinetd security

[Noah L. Meyerhans]

On Tue, Jun 19, 2001 at 09:30:56AM -0700, Pat Moffitt wrote:
> My real concern is for people like me.  I know a lot about computers (over
> 20 years of experience).  But, I don't have much experience with security.
> I don't know a lot about many of the packages in Linux.

That's partly why I don't like the argument that, for example, if you
don't want rpc.statd running, just uninstall nfs-common.  I work in an
environment where there are hundreds of Linux installations directly
connected to the Internet.  There is no firewall, and, in general, no
ports are filtered by the routers.  Andybody is free to install their
own system and do with it pretty much as they please.  The problem is
that most of the time they don't really know what's running on their
system.  They don't know about editing inetd.conf, they don't know about
portmap and NFS, and some of them are only just now leaning (the
hard way) why 'xhost +' is bad.

These people will install Apache on their machine, see that it works,
and start using it as a production web server.  There is nothing to
force them to turn off unnecessary services.  It might make my life more
difficult if they came to me every time they installed a new system and
asked why Apache wasn't working, but I'd prefer that to having them come
complain when I shut their access off due to their machine being cracked
via rpc.statd, which they've never even heard of.

I am certainly not claiming that these people are competant sysadmins,
or that a sysadmin would experience the difficulties that they do, but I
am claiming that the majority of Linux installations are run by people
with this level of expertise.  As it gets easier and easier to install
Linux, we're going to be seeing less and less competant people doing it.
They're going to get in trouble.

> As I write this it becomes a little clearer to me that we need to protect
> the net and ourselves.  This may make it harder for the newbie to learn (and
> more work for us when we install).  I would have to recommend that the "off
> by default" would be the safer policy.  (But then again, who am I?)

Well, maybe off by default is not the way to go, but "not installed by
default" is.  If somebody needs NFS, they know it, and with that
knowledge can easily search dselect for appropriate packages.  If they
don't need NFS, they don't necessarily know it, and don't necessarily
know that they need to disable or uninstall packages to get rid of it.
I think this is really a better way to go.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 



pgpxi8FtT9lqe.pgp
Description: PGP signature

Re: rlinetd security

[Ted Cabeen]

In message <[EMAIL PROTECTED]>, Joseph Pingenot writes:
>While we're at it, it'd be nice if the packages (on an update) didn't re-enable
>themselves if I've disabled them.  Inetd should check each of the runlevels to
>see if it's currently enabled (/etc/rc?.d).  If it's not, it shouldn't make it
>so.  The same goes for all the other services in /etc/rc?.d.  Also, if it
>isn't listed in /etc/inetd.conf, the admin has probably removed it, and it
>shouldn't add itself back in.
>Just something that's annoyed me when updating daily.  :)

They don't.  If you leave any /etc/rc?.d links in place (I use a harmless K??
link), then any upgrade of that package will never re-enable the service.
Check out the man page for update-rc.d for more information.  I think 
update-inetd has a similar functionality.

--
Ted Cabeen   http://www.pobox.com/~secabeen [EMAIL PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2  [EMAIL PROTECTED]
"I have taken all knowledge to be my province." -F. Bacon  [EMAIL PROTECTED]
"Human kind cannot bear very much reality."-T.S.Eliot[EMAIL PROTECTED]




pgpu8Kd3kADtj.pgp
Description: PGP signature

Re: rlinetd security

[Joseph Pingenot]

>From Pat Moffitt on Tuesday, 19 June, 2001:
>> -Original Message-
>> From: Noah L. Meyerhans [mailto:[EMAIL PROTECTED]
>Doesn't it really depend on the use of the machine and the competency of the
>admin?  Can (should) options be made for say Firewall, Personal System,
>Default or by experience level?  This is starting to sound too much like
>Microsoft:).

Heh..  It's not Mc$oft in that a) the functionality isn't disabled in such
  a way as to prevent usage (you just have to go in and activate it and
  it's *not* illegal to do so. also, you can just download the packages and
  install them) and b) you aren't charged any more for
  one than the other (in fact, you aren't charged anything :).

I'd argue that, out of the box, *nothing* should be listening in on *any* port.
  For one, that'd give admins time to patch before they set the box out (helping
  limit the window of vulnerability) For another thing, disabling services
  makes the admin actually set up the machine themselves, something they ought
  to do anyway.  For example, if they want FTP, they'd better configure it 
before
  they set it out.  I guess you could just throw in an "I know this is dumb, 
but I'd
  like to have stuff up and running out-of-box" for those who would go 
elsewhere if
  they had to set it up themselves.

>My real concern is for people like me.  I know a lot about computers (over
>20 years of experience).  But, I don't have much experience with security.
>I don't know a lot about many of the packages in Linux.

This is a very good argument for not having your box be running every service
  known to man out of the box.  If you don't know, it *can* hurt you (and
  *others* as well).  You should learn about things before you go running
  them.  You should have to read the manual in order to get FTP up and running.

>The next problem, and you mention it in the incompetent admins, is there is
>a large group of people that are installing Linux as firewalls to their home
>intranets to a DSL or Cable connection.  These people have no clue what they
>are getting into.  (I still don't believe how often the firewall gets port

This is a good argument for a "firewall" installation.  An absolutely minimum 
  install that has firewall software up and running, with a reasonable ruleset, 
  so that they are at least *partly* covered when the box comes up the first 
time.

>As I write this it becomes a little clearer to me that we need to protect
>the net and ourselves.  This may make it harder for the newbie to learn (and
>more work for us when we install).  I would have to recommend that the "off
>by default" would be the safer policy.  (But then again, who am I?)

Sounds good.  I've not followed the thread very religiously, but I'd suggest
  a setup system for the next release that has the following options:
 a) personal system (no server components are even installed on the box)
 b) firewall system (only a very minimal install, with firewall software
  and a reasonable default ruleset up and running when the box comes
  on line)
 c) server (Have the user choose exactly *which* services they want running.
  Nothing should be started until the administrator explicitly enables
  them.  The user should be told of this when they finish the install)
 d) custom (use dselect)


While we're at it, it'd be nice if the packages (on an update) didn't re-enable
  themselves if I've disabled them.  Inetd should check each of the runlevels to
  see if it's currently enabled (/etc/rc?.d).  If it's not, it shouldn't make it
  so.  The same goes for all the other services in /etc/rc?.d.  Also, if it
  isn't listed in /etc/inetd.conf, the admin has probably removed it, and it
  shouldn't add itself back in.
Just something that's annoyed me when updating daily.  :)

  -Joseph
-- 
[EMAIL PROTECTED]
"IBM were providing source code in the 1960's under similar terms. 
VMS source code was available under limited licenses to customers 
from the beginning. Microsoft are catching up with 1960."
   --Alan Cox,  http://www2.usermagnet.com/cox/index.html

Re: rlinetd security

[Ted Cabeen]

In message <[EMAIL PROTECTED]>, Quietman writes:
>On Tue, Jun 19, 2001 at 01:25:17PM -0500, Ted Cabeen wrote:
>> >It's true that uninstalling it (in potato, anyway) is not worth all the
>> >effort.  But you can definitely disable it.  I have "K20inetd" links in
>> >all my /etc/rc?.d directories where I don't want to run inetd.
>>
>> Unfortunately, you can't do it in sid either without using equivs.  netbase
>> depends on netkit-inetd.  :(
>Can't it just be removed with update-rc.d?

Sure, of course.  You just can't delete it from the system entirely, which is 
what I would prefer.

--
Ted Cabeen   http://www.pobox.com/~secabeen [EMAIL PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2  [EMAIL PROTECTED]
"I have taken all knowledge to be my province." -F. Bacon  [EMAIL PROTECTED]
"Human kind cannot bear very much reality."-T.S.Eliot[EMAIL PROTECTED]



 PGP signature

Re: rlinetd security

[Quietman]

On Tue, Jun 19, 2001 at 01:25:17PM -0500, Ted Cabeen wrote:
> >It's true that uninstalling it (in potato, anyway) is not worth all the
> >effort.  But you can definitely disable it.  I have "K20inetd" links in
> >all my /etc/rc?.d directories where I don't want to run inetd.
> 
> Unfortunately, you can't do it in sid either without using equivs.  netbase 
> depends on netkit-inetd.  :(
Can't it just be removed with update-rc.d?

Cheers,
Tom

 PGP signature

RE: rlinetd security

[Pat Moffitt]

Hello Noah

> -Original Message-
> From: Noah L. Meyerhans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 19, 2001 7:59 AM
> To: Debian Security List
> Subject: Re: rlinetd security
[snip]
>
> I do care.  I often disable inetd completely, if the server in question
> doesn't need any of what it offers.
[snip]

Interesting thought...  I wonder if I can get away with that easily?

> I do think it's worth discussing whether the policy should be "on by
> default" of "off by default".  Not just for the simple services, but for
> all services that get installed.  Which option leaves more work to be
> done by the admin?  In the current "on by default" state, you install a
> new system and go throught /etc/rc?.d/ and /etc/inetd.conf and turn off
> things that you don't need, or uninstall them completely.  Is that
> less time consuming for the admin than requiring them to go over the
> same directories and files and explicitly enable the services they want?
> I am not sure, but I expect it might not be.  And I know it would be
> safer to leave services off by default.  There are a lot of incompetant
> admins out there, and while "off by default" might generate a bit more
> traffic on -user, it is likely to save some of them some major grief.

Doesn't it really depend on the use of the machine and the competency of the
admin?  Can (should) options be made for say Firewall, Personal System,
Default or by experience level?  This is starting to sound too much like
Microsoft:).

My real concern is for people like me.  I know a lot about computers (over
20 years of experience).  But, I don't have much experience with security.
I don't know a lot about many of the packages in Linux.

When I first loaded Linux on a machine, I wanted it to be at least
functional (whatever that means).  So there should be a base install that
does that.  For this the policy of "on by default" works best.

Then there is the last install I performed, a firewall.  This should be very
minimal and I should have to chose what to put on the box or add it in
later.  Yes, the assumption that I know what I am doing (mostly) is
reasonable.  Here the policy should be 'off by default'.

The next problem, and you mention it in the incompetent admins, is there is
a large group of people that are installing Linux as firewalls to their home
intranets to a DSL or Cable connection.  These people have no clue what they
are getting into.  (I still don't believe how often the firewall gets port
scanned and hit with attempted compromises.)  What do we want their machines
to do?  (They won't know enough at first to deal with security.)  I am sure
that some of you feel they shouldn't do this if the don't know what they are
doing, but the reality is they don't care what you think.  I don't want to
deal with these machines getting compromised and then attacking us.

As I write this it becomes a little clearer to me that we need to protect
the net and ourselves.  This may make it harder for the newbie to learn (and
more work for us when we install).  I would have to recommend that the "off
by default" would be the safer policy.  (But then again, who am I?)

Pat Moffitt
MIS Administrator
Western Recreational Vehicles, Inc.

Re: rlinetd security

[Ted Cabeen]

In message <[EMAIL PROTECTED]>, "Noah L. Meyerhans" writes:
>On Tue, Jun 19, 2001 at 10:47:47AM -0700, Jamie Heilman wrote:
>> No, you can't if you're plan is to uninstall inetd, the package structure is
>> broken and won't allow it due to $@)!ed up dependancies.  I've been trying
>> to do it for ages.  Then, when I found equivs I danced a jig.  Its pretty
>> much impossible to do in potato, I think you can pull it off in sid/woody
>> though with the help of equivs - I haven't tried as my only unstable box
>> actually needed inetd, and was only accessible from an internal network so
>> I wasn't worried about inetd's underlying flaws wrt DoSability and lack of
>> concurency limiting.  If you use inetd on untrusted interface you are
>> asking for pain, I thought that was fairly well understood by now.
>
>It's true that uninstalling it (in potato, anyway) is not worth all the
>effort.  But you can definitely disable it.  I have "K20inetd" links in
>all my /etc/rc?.d directories where I don't want to run inetd.

Unfortunately, you can't do it in sid either without using equivs.  netbase 
depends on netkit-inetd.  :(

--
Ted Cabeen   http://www.pobox.com/~secabeen [EMAIL PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2  [EMAIL PROTECTED]
"I have taken all knowledge to be my province." -F. Bacon  [EMAIL PROTECTED]
"Human kind cannot bear very much reality."-T.S.Eliot[EMAIL PROTECTED]



 PGP signature

Re: rlinetd security

[Noah L. Meyerhans]

On Tue, Jun 19, 2001 at 10:47:47AM -0700, Jamie Heilman wrote:
> No, you can't if you're plan is to uninstall inetd, the package structure is
> broken and won't allow it due to $@)!ed up dependancies.  I've been trying
> to do it for ages.  Then, when I found equivs I danced a jig.  Its pretty
> much impossible to do in potato, I think you can pull it off in sid/woody
> though with the help of equivs - I haven't tried as my only unstable box
> actually needed inetd, and was only accessible from an internal network so
> I wasn't worried about inetd's underlying flaws wrt DoSability and lack of
> concurency limiting.  If you use inetd on untrusted interface you are
> asking for pain, I thought that was fairly well understood by now.

It's true that uninstalling it (in potato, anyway) is not worth all the
effort.  But you can definitely disable it.  I have "K20inetd" links in
all my /etc/rc?.d directories where I don't want to run inetd.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


 PGP signature

Re: rlinetd security

[Ted Cabeen]

In message <[EMAIL PROTECTED]>, "Noah L. Meyerhans" writes:
>I do think it's worth discussing whether the policy should be "on by
>default" of "off by default".  Not just for the simple services, but for
>all services that get installed.  Which option leaves more work to be
>done by the admin?  In the current "on by default" state, you install a
>new system and go through /etc/rc?.d/ and /etc/inetd.conf and turn off
>things that you don't need, or uninstall them completely.  Is that
>less time consuming for the admin than requiring them to go over the
>same directories and files and explicitly enable the services they want?
>I am not sure, but I expect it might not be.  And I know it would be
>safer to leave services off by default.  There are a lot of incompetent
>admins out there, and while "off by default" might generate a bit more
>traffic on -user, it is likely to save some of them some major grief.

IMHO, I like the default-on setup in debian.  The main reason that I like it
is that it maintains the linkage between installation of a package and that
package working.  I like knowing that if I apt-get a new package, it will
work, and I won't have to do additional munging to get it to work.  Especially
for complex packages, this is invaluable.  Without the default-on policy,
installing new packages will be a horrible nightmare.  Imagine trying to
install konqueror on a kde-free machine with a default-off policy.  Although
many packages would install cleanly, there would be hundreds of packages that
would require hassle to install.  I think the solution to the problem above is
package removal.  If you don't want NFS client support, just remove
nfs-common.  Don't want portmap?  Remove it.  Same with inetd.  In unstable
both inetd and portmap are their own packages now.  I know that this wasn't
the case in the past, but in a release or two, stable will have the same
functionality.  I think that we should continue with this strategy of package
proliferation rather than have a drastic change to policy.  This combination
of ease-of-use with the eternal vigilance of the security team is what gives
debian the enviable reputation of security and ease-of-use that it has today.

--
Ted Cabeen   http://www.pobox.com/~secabeen [EMAIL PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2  [EMAIL PROTECTED]
"I have taken all knowledge to be my province." -F. Bacon  [EMAIL PROTECTED]
"Human kind cannot bear very much reality."-T.S.Eliot[EMAIL PROTECTED]





pgpuL3x1DocTS.pgp
Description: PGP signature

Re: rlinetd security

[Jamie Heilman]

> > I do care.  I often disable inetd completely, if the server in question
> > doesn't need any of what it offers.
> 
> Interesting thought...  I wonder if I can get away with that easily?

No, you can't if you're plan is to uninstall inetd, the package structure is
broken and won't allow it due to $@)!ed up dependancies.  I've been trying
to do it for ages.  Then, when I found equivs I danced a jig.  Its pretty
much impossible to do in potato, I think you can pull it off in sid/woody
though with the help of equivs - I haven't tried as my only unstable box
actually needed inetd, and was only accessible from an internal network so
I wasn't worried about inetd's underlying flaws wrt DoSability and lack of
concurency limiting.  If you use inetd on untrusted interface you are
asking for pain, I thought that was fairly well understood by now.

-- 
Jamie Heilman   http://audible.transient.net/~jamie/
"I was in love once -- a Sinclair ZX-81.  People said, "No, Holly, she's 
 not for you." She was cheap, she was stupid and she wouldn't load 
 -- well, not for me, anyway."  -Holly


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Tim Haynes]

"Noah L. Meyerhans" <[EMAIL PROTECTED]> writes:

[snip]
> Personally, I don't care if something is turned on by default or not. If
> I need it, and it's on by default, I'll leave it on. If it's not on, I'll
> turn it on. If I don't need it I'll turn it off.

That's if you remember to check for these things and have the ability to
track down what starts such ports as are on.

You should see the number of posts we get on c.o.l.s. asking `how do I find
out what's listening on this port?' and suchlike questions.

Now ask how Ramen, 1i0n, adore and friends all spread and what would be a
*really* good way to reduce such things' chances of spreading later.

> I do think it's worth discussing whether the policy should be "on by
> default" of "off by default". Not just for the simple services, but for
> all services that get installed. Which option leaves more work to be done
> by the admin? 

The amount of work to be done is neither here nor there. Any competant
admin will have a pattern and preferably a set of scripts to tweak things
the way they want. Compared to the security risk, I think it pales into
insignificance.

> In the current "on by default" state, you install a new system and go
> throught /etc/rc?.d/ and /etc/inetd.conf and turn off things that you
> don't need, or uninstall them completely. Is that less time consuming for
> the admin than requiring them to go over the same directories and files
> and explicitly enable the services they want?

I think it might well be harder work.

Datapoint: my colo server box has a very few listeners, and uses xinetd to
control what interfaces they're bound to. Whenever I dist-upgraded before I
took portmapper out altogether, I had to check what was listening where,
and there was a lot of stuff that needed disabled.
Compared to changing a few `disable=yes' into `no' lines in xinetd.conf,
the process of tracking down & disabling several things all over the place
was an unnecessary PITA.

And let's not forget that plenty enough people don't know all 3 obvious
commands for finding a process responsible for a given listener, or don't
have `head /etc/services` in short-term memory, or why 53/tcp is a Bad
Thing, etc...

> I am not sure, but I expect it might not be. And I know it would be safer
> to leave services off by default. There are a lot of incompetant admins
> out there, and while "off by default" might generate a bit more traffic
> on -user, it is likely to save some of them some major grief.

Yes. I've seen the question `should one aim for secure by default?' before
and never made up my mind; there is a `false complacency' argument to be
wary of, of course, but I'm now pretty much decided that one should aim for
as secure as possible if only to stop things spreading through people's
incompetance. 

~Tim
-- 
   16:02:53 up 4 days, 20:06, 11 users,  load average: 0.02, 0.09, 0.04
[EMAIL PROTECTED] |And your radiance shines
http://piglet.is.dreaming.org |Like the moon of all innocent grace

Re: rlinetd security

[Noah L. Meyerhans]

On Tue, Jun 19, 2001 at 08:56:51AM -0400, Stuart Krivis wrote:
> > Why not?  You've not given any reason at all.  Do you know of any
> > malicious behavior that is made possible by leaving the services turned
> > on?  The potential exists to use the chargen feature as a part of a DoS
> 
> 
> That's completely the wrong way to look at it. You should be saying, "Do I 
> need this for anything?" If you don't need it, then turn it off.

Sure, but my original post was in response to us having the simple
services turned on *by default* on new installations.  If we're going to
leave stuff like portmap and the NFS client daemons on by default then
we're already comitting a worse crime than leaving the simple services
on.

> > Really I'm just playing devil's advocate here.  I don't care if they're
> > turned off or not.  I've just never seen any evidence that there's any
> > reason for concern over them.
> 
> You should care. If it isn't running, you have one less thing to worry 
> about.

I do care.  I often disable inetd completely, if the server in question
doesn't need any of what it offers.  But again, what I was talking about
previously was the installation defaults.  Tim Haynes was saying that he
certainly hoped that the simple services were not turned on by default
in unstable.  I wasn't recommending to anybody to *leave* them on if
they don't need them.  But by default we've always left everything
turned on unless there was some major configuration or whatever that
needed to be done in order for the service to be used at all.

Personally, I don't care if something is turned on by default or not.
If I need it, and it's on by default, I'll leave it on.  If it's not on,
I'll turn it on.  If I don't need it I'll turn it off.

I do think it's worth discussing whether the policy should be "on by
default" of "off by default".  Not just for the simple services, but for
all services that get installed.  Which option leaves more work to be
done by the admin?  In the current "on by default" state, you install a
new system and go throught /etc/rc?.d/ and /etc/inetd.conf and turn off
things that you don't need, or uninstall them completely.  Is that
less time consuming for the admin than requiring them to go over the
same directories and files and explicitly enable the services they want?
I am not sure, but I expect it might not be.  And I know it would be
safer to leave services off by default.  There are a lot of incompetant
admins out there, and while "off by default" might generate a bit more
traffic on -user, it is likely to save some of them some major grief.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 



pgpcZfkWlVY6O.pgp
Description: PGP signature

Re: rlinetd security

[Noah L. Meyerhans]

On Tue, Jun 19, 2001 at 09:30:56AM -0700, Pat Moffitt wrote:
> My real concern is for people like me.  I know a lot about computers (over
> 20 years of experience).  But, I don't have much experience with security.
> I don't know a lot about many of the packages in Linux.

That's partly why I don't like the argument that, for example, if you
don't want rpc.statd running, just uninstall nfs-common.  I work in an
environment where there are hundreds of Linux installations directly
connected to the Internet.  There is no firewall, and, in general, no
ports are filtered by the routers.  Andybody is free to install their
own system and do with it pretty much as they please.  The problem is
that most of the time they don't really know what's running on their
system.  They don't know about editing inetd.conf, they don't know about
portmap and NFS, and some of them are only just now leaning (the
hard way) why 'xhost +' is bad.

These people will install Apache on their machine, see that it works,
and start using it as a production web server.  There is nothing to
force them to turn off unnecessary services.  It might make my life more
difficult if they came to me every time they installed a new system and
asked why Apache wasn't working, but I'd prefer that to having them come
complain when I shut their access off due to their machine being cracked
via rpc.statd, which they've never even heard of.

I am certainly not claiming that these people are competant sysadmins,
or that a sysadmin would experience the difficulties that they do, but I
am claiming that the majority of Linux installations are run by people
with this level of expertise.  As it gets easier and easier to install
Linux, we're going to be seeing less and less competant people doing it.
They're going to get in trouble.

> As I write this it becomes a little clearer to me that we need to protect
> the net and ourselves.  This may make it harder for the newbie to learn (and
> more work for us when we install).  I would have to recommend that the "off
> by default" would be the safer policy.  (But then again, who am I?)

Well, maybe off by default is not the way to go, but "not installed by
default" is.  If somebody needs NFS, they know it, and with that
knowledge can easily search dselect for appropriate packages.  If they
don't need NFS, they don't necessarily know it, and don't necessarily
know that they need to disable or uninstall packages to get rid of it.
I think this is really a better way to go.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


 PGP signature

Re: rlinetd security

[Ted Cabeen]

In message <[EMAIL PROTECTED]>, Joseph Pingenot writes:
>While we're at it, it'd be nice if the packages (on an update) didn't re-enable
>themselves if I've disabled them.  Inetd should check each of the runlevels to
>see if it's currently enabled (/etc/rc?.d).  If it's not, it shouldn't make it
>so.  The same goes for all the other services in /etc/rc?.d.  Also, if it
>isn't listed in /etc/inetd.conf, the admin has probably removed it, and it
>shouldn't add itself back in.
>Just something that's annoyed me when updating daily.  :)

They don't.  If you leave any /etc/rc?.d links in place (I use a harmless K??
link), then any upgrade of that package will never re-enable the service.
Check out the man page for update-rc.d for more information.  I think 
update-inetd has a similar functionality.

--
Ted Cabeen   http://www.pobox.com/~secabeen [EMAIL PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2  [EMAIL PROTECTED]
"I have taken all knowledge to be my province." -F. Bacon  [EMAIL PROTECTED]
"Human kind cannot bear very much reality."-T.S.Eliot[EMAIL PROTECTED]



 PGP signature

Re: rlinetd security

[Joseph Pingenot]

>From Pat Moffitt on Tuesday, 19 June, 2001:
>> -Original Message-
>> From: Noah L. Meyerhans [mailto:[EMAIL PROTECTED]]
>Doesn't it really depend on the use of the machine and the competency of the
>admin?  Can (should) options be made for say Firewall, Personal System,
>Default or by experience level?  This is starting to sound too much like
>Microsoft:).

Heh..  It's not Mc$oft in that a) the functionality isn't disabled in such
  a way as to prevent usage (you just have to go in and activate it and
  it's *not* illegal to do so. also, you can just download the packages and
  install them) and b) you aren't charged any more for
  one than the other (in fact, you aren't charged anything :).

I'd argue that, out of the box, *nothing* should be listening in on *any* port.
  For one, that'd give admins time to patch before they set the box out (helping
  limit the window of vulnerability) For another thing, disabling services
  makes the admin actually set up the machine themselves, something they ought
  to do anyway.  For example, if they want FTP, they'd better configure it before
  they set it out.  I guess you could just throw in an "I know this is dumb, but I'd
  like to have stuff up and running out-of-box" for those who would go elsewhere if
  they had to set it up themselves.

>My real concern is for people like me.  I know a lot about computers (over
>20 years of experience).  But, I don't have much experience with security.
>I don't know a lot about many of the packages in Linux.

This is a very good argument for not having your box be running every service
  known to man out of the box.  If you don't know, it *can* hurt you (and
  *others* as well).  You should learn about things before you go running
  them.  You should have to read the manual in order to get FTP up and running.

>The next problem, and you mention it in the incompetent admins, is there is
>a large group of people that are installing Linux as firewalls to their home
>intranets to a DSL or Cable connection.  These people have no clue what they
>are getting into.  (I still don't believe how often the firewall gets port

This is a good argument for a "firewall" installation.  An absolutely minimum 
  install that has firewall software up and running, with a reasonable ruleset, 
  so that they are at least *partly* covered when the box comes up the first time.

>As I write this it becomes a little clearer to me that we need to protect
>the net and ourselves.  This may make it harder for the newbie to learn (and
>more work for us when we install).  I would have to recommend that the "off
>by default" would be the safer policy.  (But then again, who am I?)

Sounds good.  I've not followed the thread very religiously, but I'd suggest
  a setup system for the next release that has the following options:
 a) personal system (no server components are even installed on the box)
 b) firewall system (only a very minimal install, with firewall software
  and a reasonable default ruleset up and running when the box comes
  on line)
 c) server (Have the user choose exactly *which* services they want running.
  Nothing should be started until the administrator explicitly enables
  them.  The user should be told of this when they finish the install)
 d) custom (use dselect)


While we're at it, it'd be nice if the packages (on an update) didn't re-enable
  themselves if I've disabled them.  Inetd should check each of the runlevels to
  see if it's currently enabled (/etc/rc?.d).  If it's not, it shouldn't make it
  so.  The same goes for all the other services in /etc/rc?.d.  Also, if it
  isn't listed in /etc/inetd.conf, the admin has probably removed it, and it
  shouldn't add itself back in.
Just something that's annoyed me when updating daily.  :)

  -Joseph
-- 
[EMAIL PROTECTED]
"IBM were providing source code in the 1960's under similar terms. 
VMS source code was available under limited licenses to customers 
from the beginning. Microsoft are catching up with 1960."
   --Alan Cox,  http://www2.usermagnet.com/cox/index.html


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: rlinetd security

[Pat Moffitt]

Hello Noah

> -Original Message-
> From: Noah L. Meyerhans [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 19, 2001 7:59 AM
> To: Debian Security List
> Subject: Re: rlinetd security
[snip]
>
> I do care.  I often disable inetd completely, if the server in question
> doesn't need any of what it offers.
[snip]

Interesting thought...  I wonder if I can get away with that easily?

> I do think it's worth discussing whether the policy should be "on by
> default" of "off by default".  Not just for the simple services, but for
> all services that get installed.  Which option leaves more work to be
> done by the admin?  In the current "on by default" state, you install a
> new system and go throught /etc/rc?.d/ and /etc/inetd.conf and turn off
> things that you don't need, or uninstall them completely.  Is that
> less time consuming for the admin than requiring them to go over the
> same directories and files and explicitly enable the services they want?
> I am not sure, but I expect it might not be.  And I know it would be
> safer to leave services off by default.  There are a lot of incompetant
> admins out there, and while "off by default" might generate a bit more
> traffic on -user, it is likely to save some of them some major grief.

Doesn't it really depend on the use of the machine and the competency of the
admin?  Can (should) options be made for say Firewall, Personal System,
Default or by experience level?  This is starting to sound too much like
Microsoft:).

My real concern is for people like me.  I know a lot about computers (over
20 years of experience).  But, I don't have much experience with security.
I don't know a lot about many of the packages in Linux.

When I first loaded Linux on a machine, I wanted it to be at least
functional (whatever that means).  So there should be a base install that
does that.  For this the policy of "on by default" works best.

Then there is the last install I performed, a firewall.  This should be very
minimal and I should have to chose what to put on the box or add it in
later.  Yes, the assumption that I know what I am doing (mostly) is
reasonable.  Here the policy should be 'off by default'.

The next problem, and you mention it in the incompetent admins, is there is
a large group of people that are installing Linux as firewalls to their home
intranets to a DSL or Cable connection.  These people have no clue what they
are getting into.  (I still don't believe how often the firewall gets port
scanned and hit with attempted compromises.)  What do we want their machines
to do?  (They won't know enough at first to deal with security.)  I am sure
that some of you feel they shouldn't do this if the don't know what they are
doing, but the reality is they don't care what you think.  I don't want to
deal with these machines getting compromised and then attacking us.

As I write this it becomes a little clearer to me that we need to protect
the net and ourselves.  This may make it harder for the newbie to learn (and
more work for us when we install).  I would have to recommend that the "off
by default" would be the safer policy.  (But then again, who am I?)

Pat Moffitt
MIS Administrator
Western Recreational Vehicles, Inc.



--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Ted Cabeen]

In message <[EMAIL PROTECTED]>, "Noah L. Meyerhans" writes:
>I do think it's worth discussing whether the policy should be "on by
>default" of "off by default".  Not just for the simple services, but for
>all services that get installed.  Which option leaves more work to be
>done by the admin?  In the current "on by default" state, you install a
>new system and go through /etc/rc?.d/ and /etc/inetd.conf and turn off
>things that you don't need, or uninstall them completely.  Is that
>less time consuming for the admin than requiring them to go over the
>same directories and files and explicitly enable the services they want?
>I am not sure, but I expect it might not be.  And I know it would be
>safer to leave services off by default.  There are a lot of incompetent
>admins out there, and while "off by default" might generate a bit more
>traffic on -user, it is likely to save some of them some major grief.

IMHO, I like the default-on setup in debian.  The main reason that I like it
is that it maintains the linkage between installation of a package and that
package working.  I like knowing that if I apt-get a new package, it will
work, and I won't have to do additional munging to get it to work.  Especially
for complex packages, this is invaluable.  Without the default-on policy,
installing new packages will be a horrible nightmare.  Imagine trying to
install konqueror on a kde-free machine with a default-off policy.  Although
many packages would install cleanly, there would be hundreds of packages that
would require hassle to install.  I think the solution to the problem above is
package removal.  If you don't want NFS client support, just remove
nfs-common.  Don't want portmap?  Remove it.  Same with inetd.  In unstable
both inetd and portmap are their own packages now.  I know that this wasn't
the case in the past, but in a release or two, stable will have the same
functionality.  I think that we should continue with this strategy of package
proliferation rather than have a drastic change to policy.  This combination
of ease-of-use with the eternal vigilance of the security team is what gives
debian the enviable reputation of security and ease-of-use that it has today.

--
Ted Cabeen   http://www.pobox.com/~secabeen [EMAIL PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2  [EMAIL PROTECTED]
"I have taken all knowledge to be my province." -F. Bacon  [EMAIL PROTECTED]
"Human kind cannot bear very much reality."-T.S.Eliot[EMAIL PROTECTED]




 PGP signature

Re: rlinetd security

[Stuart Krivis]

--On Monday, June 18, 2001 13:48:50 -0400 Noah Meyerhans <[EMAIL PROTECTED]> 
wrote:



Why not?  You've not given any reason at all.  Do you know of any
malicious behavior that is made possible by leaving the services turned
on?  The potential exists to use the chargen feature as a part of a DoS



That's completely the wrong way to look at it. You should be saying, "Do I 
need this for anything?" If you don't need it, then turn it off.


When you _do_ turn something on, then you need to look into the security 
risks involved in doing so.


Just because something is there is not a valid reason for running it. 
You'll save yourself a lot of grief if keep what you have running to a 
minimum.


If nothing else, a future breakin might be easier to handle if you have 
fewer things open. You'll be able to zero in on the hole more quickly in 
most cases.


It's just sound practice to control everything that you can. There will be 
plenty of things that you will need to leave open without adding more. :-)




Really I'm just playing devil's advocate here.  I don't care if they're
turned off or not.  I've just never seen any evidence that there's any
reason for concern over them.


You should care. If it isn't running, you have one less thing to worry 
about.

Re: rlinetd security

[Tim Haynes]

"Noah L. Meyerhans" <[EMAIL PROTECTED]> writes:

[snip]
> Personally, I don't care if something is turned on by default or not. If
> I need it, and it's on by default, I'll leave it on. If it's not on, I'll
> turn it on. If I don't need it I'll turn it off.

That's if you remember to check for these things and have the ability to
track down what starts such ports as are on.

You should see the number of posts we get on c.o.l.s. asking `how do I find
out what's listening on this port?' and suchlike questions.

Now ask how Ramen, 1i0n, adore and friends all spread and what would be a
*really* good way to reduce such things' chances of spreading later.

> I do think it's worth discussing whether the policy should be "on by
> default" of "off by default". Not just for the simple services, but for
> all services that get installed. Which option leaves more work to be done
> by the admin? 

The amount of work to be done is neither here nor there. Any competant
admin will have a pattern and preferably a set of scripts to tweak things
the way they want. Compared to the security risk, I think it pales into
insignificance.

> In the current "on by default" state, you install a new system and go
> throught /etc/rc?.d/ and /etc/inetd.conf and turn off things that you
> don't need, or uninstall them completely. Is that less time consuming for
> the admin than requiring them to go over the same directories and files
> and explicitly enable the services they want?

I think it might well be harder work.

Datapoint: my colo server box has a very few listeners, and uses xinetd to
control what interfaces they're bound to. Whenever I dist-upgraded before I
took portmapper out altogether, I had to check what was listening where,
and there was a lot of stuff that needed disabled.
Compared to changing a few `disable=yes' into `no' lines in xinetd.conf,
the process of tracking down & disabling several things all over the place
was an unnecessary PITA.

And let's not forget that plenty enough people don't know all 3 obvious
commands for finding a process responsible for a given listener, or don't
have `head /etc/services` in short-term memory, or why 53/tcp is a Bad
Thing, etc...

> I am not sure, but I expect it might not be. And I know it would be safer
> to leave services off by default. There are a lot of incompetant admins
> out there, and while "off by default" might generate a bit more traffic
> on -user, it is likely to save some of them some major grief.

Yes. I've seen the question `should one aim for secure by default?' before
and never made up my mind; there is a `false complacency' argument to be
wary of, of course, but I'm now pretty much decided that one should aim for
as secure as possible if only to stop things spreading through people's
incompetance. 

~Tim
-- 
   16:02:53 up 4 days, 20:06, 11 users,  load average: 0.02, 0.09, 0.04
[EMAIL PROTECTED] |And your radiance shines
http://piglet.is.dreaming.org |Like the moon of all innocent grace


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Stuart Krivis]

--On Monday, June 18, 2001 13:48:50 -0400 Noah Meyerhans <[EMAIL PROTECTED]> 
wrote:

> Why not?  You've not given any reason at all.  Do you know of any
> malicious behavior that is made possible by leaving the services turned
> on?  The potential exists to use the chargen feature as a part of a DoS


That's completely the wrong way to look at it. You should be saying, "Do I 
need this for anything?" If you don't need it, then turn it off.

When you _do_ turn something on, then you need to look into the security 
risks involved in doing so.

Just because something is there is not a valid reason for running it. 
You'll save yourself a lot of grief if keep what you have running to a 
minimum.

If nothing else, a future breakin might be easier to handle if you have 
fewer things open. You'll be able to zero in on the hole more quickly in 
most cases.

It's just sound practice to control everything that you can. There will be 
plenty of things that you will need to leave open without adding more. :-)


> Really I'm just playing devil's advocate here.  I don't care if they're
> turned off or not.  I've just never seen any evidence that there's any
> reason for concern over them.

You should care. If it isn't running, you have one less thing to worry 
about.




--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Colin Phipps]

On Mon, Jun 18, 2001 at 04:22:15PM -0800, Ethan Benson wrote:
> On Mon, Jun 18, 2001 at 01:48:50PM -0400, Noah Meyerhans wrote:
> > 
> > Why not?  You've not given any reason at all.  Do you know of any
> > malicious behavior that is made possible by leaving the services turned
> > on?  The potential exists to use the chargen feature as a part of a DoS
> > attack, but I've not heard of it ever being used as it's not
> > particularly effective unless you have many many machines available, and
> > even then there are much more effective weapons.  And what about the
> > rest of the ports?  How are they dangerous?  I've never heard of an
> > exploit involving any of them.
> 
> play a spoofing trick to attach the victims chargen port to its echo
> port.  
> 
> i don't know if that is still possible, in the olden days it was, had
> quite ammusing result too.  

The UDP versions only are affected by this, and yes it's still possible (it's
fundamental to the lack of design of these "protocols" that they have no defense
vs packet loops).

The TCP versions OTOH are pretty safe, assuming you use suitable concurrency
limiting on connections, but disabling them remains easier and safer.

-- 
Colin Phipps PGP 0x689E463E http://www.netcraft.com/

Re: rlinetd security

[Colin Phipps]

On Mon, Jun 18, 2001 at 04:22:15PM -0800, Ethan Benson wrote:
> On Mon, Jun 18, 2001 at 01:48:50PM -0400, Noah Meyerhans wrote:
> > 
> > Why not?  You've not given any reason at all.  Do you know of any
> > malicious behavior that is made possible by leaving the services turned
> > on?  The potential exists to use the chargen feature as a part of a DoS
> > attack, but I've not heard of it ever being used as it's not
> > particularly effective unless you have many many machines available, and
> > even then there are much more effective weapons.  And what about the
> > rest of the ports?  How are they dangerous?  I've never heard of an
> > exploit involving any of them.
> 
> play a spoofing trick to attach the victims chargen port to its echo
> port.  
> 
> i don't know if that is still possible, in the olden days it was, had
> quite ammusing result too.  

The UDP versions only are affected by this, and yes it's still possible (it's
fundamental to the lack of design of these "protocols" that they have no defense
vs packet loops).

The TCP versions OTOH are pretty safe, assuming you use suitable concurrency
limiting on connections, but disabling them remains easier and safer.

-- 
Colin Phipps PGP 0x689E463E http://www.netcraft.com/


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Peter Cordes]

On Mon, Jun 18, 2001 at 07:15:55PM +0200, Sebastiaan wrote:
> I know you are right, but I have become curious now: if everyone says that
> you do not need them, then where are they used for? And why are they still
> installed by default?

 All those internal services are for testing/debugging, except for the
"time" service, which is used by rdate.  If you don't run around
playing with netcat, you _don't_ need them.

 The "turn it off if you don't need it" rule applies to services you
don't know about.  If you don't know if something will break if you
turn it off, turn it off and see if something breaks.  If nothing
breaks, leave it off.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X([EMAIL PROTECTED] , ns.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE

Re: rlinetd security

[Peter Cordes]

On Mon, Jun 18, 2001 at 07:15:55PM +0200, Sebastiaan wrote:
> I know you are right, but I have become curious now: if everyone says that
> you do not need them, then where are they used for? And why are they still
> installed by default?

 All those internal services are for testing/debugging, except for the
"time" service, which is used by rdate.  If you don't run around
playing with netcat, you _don't_ need them.

 The "turn it off if you don't need it" rule applies to services you
don't know about.  If you don't know if something will break if you
turn it off, turn it off and see if something breaks.  If nothing
breaks, leave it off.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X([EMAIL PROTECTED] , ns.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Ethan Benson]

On Mon, Jun 18, 2001 at 01:48:50PM -0400, Noah Meyerhans wrote:
> 
> Why not?  You've not given any reason at all.  Do you know of any
> malicious behavior that is made possible by leaving the services turned
> on?  The potential exists to use the chargen feature as a part of a DoS
> attack, but I've not heard of it ever being used as it's not
> particularly effective unless you have many many machines available, and
> even then there are much more effective weapons.  And what about the
> rest of the ports?  How are they dangerous?  I've never heard of an
> exploit involving any of them.

play a spoofing trick to attach the victims chargen port to its echo
port.  

i don't know if that is still possible, in the olden days it was, had
quite ammusing result too.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgphaIXBvdnPp.pgp
Description: PGP signature

Re: rlinetd security

[Ethan Benson]

On Mon, Jun 18, 2001 at 09:06:07AM -0700, Pat Moffitt wrote:
> That makes a lot of assumptions about my (or anyone else) understanding of
> the system.  For example, I have no clue what discard is used for.  So, how
> do I know if I have a package installed that will not work properly if I
> disable that port.  Yes, I should go and research the issue but I only have
> some much time in the day.

if you don't understand such issues you have no business with the root
password.  

> Therefor, many of us are forced to make the same assumptions (valid or not)
> such as Sebastiaan's.

only if you insist on remaining ignorant.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpakFannjKd9.pgp
Description: PGP signature

Re: rlinetd security

[Ethan Benson]

On Mon, Jun 18, 2001 at 01:48:50PM -0400, Noah Meyerhans wrote:
> 
> Why not?  You've not given any reason at all.  Do you know of any
> malicious behavior that is made possible by leaving the services turned
> on?  The potential exists to use the chargen feature as a part of a DoS
> attack, but I've not heard of it ever being used as it's not
> particularly effective unless you have many many machines available, and
> even then there are much more effective weapons.  And what about the
> rest of the ports?  How are they dangerous?  I've never heard of an
> exploit involving any of them.

play a spoofing trick to attach the victims chargen port to its echo
port.  

i don't know if that is still possible, in the olden days it was, had
quite ammusing result too.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

 PGP signature

Re: rlinetd security

[Ethan Benson]

On Mon, Jun 18, 2001 at 09:06:07AM -0700, Pat Moffitt wrote:
> That makes a lot of assumptions about my (or anyone else) understanding of
> the system.  For example, I have no clue what discard is used for.  So, how
> do I know if I have a package installed that will not work properly if I
> disable that port.  Yes, I should go and research the issue but I only have
> some much time in the day.

if you don't understand such issues you have no business with the root
password.  

> Therefor, many of us are forced to make the same assumptions (valid or not)
> such as Sebastiaan's.

only if you insist on remaining ignorant.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

 PGP signature

Re: rlinetd security

[Tim Haynes]

[EMAIL PROTECTED] (Martin Maney) writes:

> On Mon, Jun 18, 2001 at 08:34:11PM +0100, Tim Haynes wrote:
>
> > Well, it depends. You can never tidy up a rooted box; the same
> > mentality sort of applies all the way down - if you're setting up a
> > box, why worry about installing this and uninstalling that, when your
> > original installation shouldn't have had anything enabled in the first
> > place? (And yes, you can push that back into the distro, too.)
> 
> Sure, you can have a distro that doens't install any services. Heck,
> consider local exploits and you may decide that "login considered
> harmful" isn't too great a stretch... :-)

Well, smiley noted, but the list of users who have what kind of access to
the box has to be considered.

> I have to take issue with your attempt to draw a aparallel to a rooted
> box. It *is* possible to cleanup the newly installed box because you can
> reasonably assume that it hasn't been maliciously setup to resist the
> cleanup.

Well, if you can assume that, sure. But the parallel really comes in saying
you half-way don't know what to look for, or might miss something. That's
why I'm in favour of pushing some things into the distro
installation-default area.

> > Surely software you install on production machines has its requirements
> > either satisfied by the wonder that is apt-get, or documented properly? 
> > You can, and should, start from blank and add things as you need.
> 
> Could I agree with the minimalist sentiment while yet observing that
> apt-get, wonderful as it is, cannot satisfy requirements that come not
> from packages installed on this machine, but from other machines -
> possibly ones that aren't even using Debian?

Sure; that's where `or documented properly' comes in.

> At the same time, I would like to agree with the sentiment that has been
> expressed a few times. "If you don't know what it's for, shut it off." I
> think the unstated part that some may have overlooked is that if you need
> something but don't know it, then you owe it to yourself (and your
> employers, if that's the sort of situation it is) to find out what's
> there.

It's been mentioned very en-passant, as has `but I don't have the time to
investigate everything', which makes my caffeine^Wblood boil.

>  This is how sysadmins lose their hair!

Tell me about it. 

My take on the whole thing is that you're building a test box internally
first *anyway*, if you don't know exactly how to set up a live machine;
then you investigate, kill off everything your reading of the manuals
allows you to, on the simple grounds that you don't want it to turn around
& bite you later on, and you're on a test box so any breaks won't matter
and you'll learn in the process.
Leaving stuff open because `there aren't any known holes at the moment
doesn't really wash here :( .

~Tim
-- 
But mountains are holy places,  |[EMAIL PROTECTED]
And beauty is free / We can still walk  |http://spodzone.org.uk/
Through the garden  |
Our earth was once green|

Re: rlinetd security

[Martin Maney]

On Mon, Jun 18, 2001 at 08:34:11PM +0100, Tim Haynes wrote:
> Well, it depends. You can never tidy up a rooted box; the same mentality
> sort of applies all the way down - if you're setting up a box, why worry
> about installing this and uninstalling that, when your original
> installation shouldn't have had anything enabled in the first place? (And
> yes, you can push that back into the distro, too.)

Sure, you can have a distro that doens't install any services.  Heck,
consider local exploits and you may decide that "login considered harmful"
isn't too great a stretch...  :-)

I have to take issue with your attempt to draw a aparallel to a rooted box. 
It *is* possible to cleanup the newly installed box because you can
reasonably assume that it hasn't been maliciously setup to resist the
cleanup.

> Surely software you install on production machines has its requirements
> either satisfied by the wonder that is apt-get, or documented properly? You
> can, and should, start from blank and add things as you need.

Could I agree with the minimalist sentiment while yet observing that
apt-get, wonderful as it is, cannot satisfy requirements that come not from
packages installed on this machine, but from other machines - possibly ones
that aren't even using Debian?

At the same time, I would like to agree with the sentiment that has been
expressed a few times.  "If you don't know what it's for, shut it off."  I
think the unstated part that some may have overlooked is that if you need
something but don't know it, then you owe it to yourself (and your
employers, if that's the sort of situation it is) to find out what's there. 
This is how sysadmins lose their hair!

-- 
There has grown up in the minds of certain groups in this country
the notion that because a man or corporation has made a profit
out of the public for a number of years, the government and the courts
are charged with the duty of guaranteeing such profit in the future,
even in the face of changing circumstances and contrary public interest.
This strange doctrine is not supported by statute nor common law.  -- RAH

Re: rlinetd security

[Tim Haynes]

"Pat Moffitt" <[EMAIL PROTECTED]> writes:

[snip]
> Now that answers some questions. Much better. At least when I turn them
> off I will have a clue about what might break.
> 
> BTW, my philosophy on disabling unknown services/ports has been to
> disable it and see if anything breaks. If something breaks, then figure
> out what to do about it. 

Well, it depends. You can never tidy up a rooted box; the same mentality
sort of applies all the way down - if you're setting up a box, why worry
about installing this and uninstalling that, when your original
installation shouldn't have had anything enabled in the first place? (And
yes, you can push that back into the distro, too.)

> But, this can be a tough philosophy on production machines. (No, I don't
> have machines that I can test with here. Nor do I have the time to set
> them up.)

Surely software you install on production machines has its requirements
either satisfied by the wonder that is apt-get, or documented properly? You
can, and should, start from blank and add things as you need.

> The concept of 'if you don't know why your running them you don't need
> them.' may be good advice but doesn't help those of use that are trying
> to understand Security.

It's a useful approach to take while you ask questions about it :)

~Tim
-- 
   20:31:49 up 4 days, 35 min, 11 users,  load average: 0.04, 0.03, 0.00
[EMAIL PROTECTED] |Ideologies come, ideologies go
http://piglet.is.dreaming.org |A waste of words, and endless flow

Re: rlinetd security

[Tim Haynes]

"Noah L. Meyerhans" <[EMAIL PROTECTED]> writes:

[snip]
> > , btw. Why bother
> > hooking /dev/{zero,null} onto the net with netcat when you can cause a fair
> > bit of traffic with standard services that do much the same thing?
> 
> Yes, but you know what? 'ping -f' works just as good, if not better. Do
> you have ICMP filtered at your router?

Some, yes. 

I also worry about who's going to be able to execute `ping -f' on *my*
machines, should they make it through, and try to make it as hard as
possible.

Leaving ports open because you don't know better does not constitute making
nasty people's life harder.

~Tim
-- 
   20:12:08 up 4 days, 16 min, 17 users,  load average: 0.02, 0.04, 0.00
[EMAIL PROTECTED] |Windows 98 is year 2000-ready
http://piglet.is.dreaming.org |(seen during a recent, >y2000, installation)

Re: rlinetd security

[Tim Haynes]

"Noah L. Meyerhans" <[EMAIL PROTECTED]> writes:

> On Mon, Jun 18, 2001 at 11:08:49AM -0700, Vineet Kumar wrote:
>
> > The argument below is pretty bad. Have you ever heard of anybody
> > actually getting impaled by holding a sword poised at his belly and
> > walking into grand central station at 5:00pm going "'scuse me, pardon
> > me, 'scuse me, pardon *GGUAGHGH!*"? I sure haven't. So why not do it? 
> > Our hypothetical late friend didn't need to be doing it, and he
> > shouldn't have been doing it.
> 
> Huh? You've acknowledged that there may be legitimate uses for the simple
> services that you may be ignorant of. I don't think there is any
> legitimate gain to be had be running around a crowded area with a blade
> against your belly.

The point is that these things can be used for good or evil. If you're not
going to use it for good, whether someone else can or not, a nasty chap can
still use it for evil.

You realise rpc.statd has its uses, as does ftpd? Is that some reason to
enable them `just in case somebody wants to use them for legitimate
reasons'?
 
> > "the standard inetd services including discard, echo, sysstat, netstat
> > et al all *have* *had* their known vulnerabilities before now. All
> > long-since patched, but that's not to say there won't be another
> > tomorrow."
> 
> Have you looked at their code?  I can assure you that there is no
> potential for remote exploit in 
> void
> discard_stream(int s, struct servtab *sep)
[snip]

> These services are so simple that any moderately knowledgeable coder can
> ensure that there is no risk to leaving the services turned on.

There isn't? What about in your choice of C-library, then, have you audited
that? 
While you're here, what tweaks are going to be made to these functions next
week?

The principle is still the same. It's not enough to ask whether you need it
or not and assume something can be left on if you don't know any better; if
another vulnerability comes out you have to check one more thing to see
whether it's relevant or not, which is a waste of time, at best, and an
omitted necessary update to an unused service (unused, until someone scans
you for it, that is) at worst.

Incidentally, in your dismissal of exploits for these things, you're
neglecting another scenario: black-hat *does* manage to crack another box
in the organization, and points multiple netcats from the exploited box at
someone with echo: you'll end up with enough network traffic & load to
cause a slow-down, and the traffic may possibly help him mask very nasty
activities in the noise.

~Tim
-- 
All I see, All I know   |[EMAIL PROTECTED]
Is touching the sacred earth|http://spodzone.org.uk/
And warming the hallowed ground |

RE: rlinetd security

[Pat Moffitt]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> Of Tim Haynes
> Sent: Monday, June 18, 2001 10:35 AM
> To: Sebastiaan
> Cc: Tim Haynes; [EMAIL PROTECTED]; debian-security@lists.debian.org
> Subject: Re: rlinetd security
>
>
> Sebastiaan <[EMAIL PROTECTED]> writes:
>
> [snip]
> > > Again, if you don't know why you need it, you don't need it.
> >
> > I know you are right, but I have become curious now: if everyone says
> > that you do not need them, then where are they used for? And
> why are they
> > still installed by default?
>
> Good questions.
>
> a) echo is just there to duplicate everything you send back at you.
>discard is just there to dump everything in the sink.
>chargen is to give a continual stream of output, eg bandwidth testing
>daytime is to give another box a snapshot of the time on here - a crude
>& ancient & horrible way to sync boxes
>netstat is to give a view of `netstat' over the 'net - remote admin?
[snip]

Now that answers some questions.  Much better.  At least when I turn them
off I will have a clue about what might break.

BTW, my philosophy on disabling unknown services/ports has been to disable
it and see if anything breaks.  If something breaks, then figure out what to
do about it.  But, this can be a tough philosophy on production machines.
(No, I don't have machines that I can test with here.  Nor do I have the
time to set them up.)

The concept of 'if you don't know why your running them you don't need
them.' may be good advice but doesn't help those of use that are trying to
understand Security.

Pat Moffitt
MIS Administrator
Western Recreational Vehicles, Inc.

Re: rlinetd security

[Noah L. Meyerhans]

On Mon, Jun 18, 2001 at 07:25:37PM +0100, Tim Haynes wrote:
> But that said, I gather leaking one's timestamp is not a good thing
> (leaking *anything* is not really any good). I'm no Kerberos user, but I
> heard you can do time-dependent auth in that a given ticket is good until
> . I wouldn't want someone to know exactly what time my boxes
> thought it was.

So I assume you stay very clear of any kind of time synchronization
(ntpd and the like).  In order for things like Kerberos to work (BTW, I
am a kerberos user) the client machines have to be very closely
synchronized with the authentication server.  NTP is how this is done.
Giving out your time via either the daytime or time simple service is
not giving out any info that's not already available to anybody who
cares to look.

> > The potential exists to use the chargen feature as a part of a DoS
> > attack, but I've not heard of it ever being used as it's not particularly
> > effective unless you have many many machines available, and even then
> > there are much more effective weapons.
> 
> , btw. Why bother
> hooking /dev/{zero,null} onto the net with netcat when you can cause a fair
> bit of traffic with standard services that do much the same thing?

Yes, but you know what?  'ping -f' works just as good, if not better.
Do you have ICMP filtered at your router?


-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 



pgpHBQyrZ4Pyt.pgp
Description: PGP signature

Re: rlinetd security

[Noah L. Meyerhans]

On Mon, Jun 18, 2001 at 11:08:49AM -0700, Vineet Kumar wrote:
> The argument below is pretty bad. Have you ever heard of anybody
> actually getting impaled by holding a sword poised at his belly and
> walking into grand central station at 5:00pm going "'scuse me, pardon
> me, 'scuse me, pardon *GGUAGHGH!*"? I sure haven't. So why not do it?
> Our hypothetical late friend didn't need to be doing it, and he
> shouldn't have been doing it. 

Huh?  You've acknowledged that there may be legitimate uses for the
simple services that you may be ignorant of.  I don't think there is any
legitimate gain to be had be running around a crowded area with a blade
against your belly.

> "the standard inetd services including discard, echo, sysstat,
> netstat et al all *have* *had* their known vulnerabilities before now.
> All long-since patched, but that's not to say there won't be another
> tomorrow."
> 

Have you looked at their code?  I can assure you that there is no
potential for remote exploit in 
void
discard_stream(int s, struct servtab *sep)
{
char buffer[BUFSIZE];

setproctitle(sep->se_service, s);
while ((errno = 0, read(s, buffer, sizeof(buffer)) > 0) ||
errno == EINTR)
;
exit(0);
}

Or how 'bout this:
/* Return human-readable time of day */
void
daytime_stream(int s, struct servtab *sep)
{
char buffer[256];
time_t clocc;

(void)sep;

clocc = time(NULL);
snprintf(buffer, sizeof(buffer), "%.24s\r\n", ctime(&clocc));
write(s, buffer, strlen(buffer));
}

These services are so simple that any moderately knowledgeable coder can
ensure that there is no risk to leaving the services turned on.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 



pgp4hkG0LGaVt.pgp
Description: PGP signature

Re: rlinetd security

[Tim Haynes]

Noah Meyerhans <[EMAIL PROTECTED]> writes:

> On Mon, Jun 18, 2001 at 06:35:03PM +0100, Tim Haynes wrote:
> > b) they shouldn't be. You'll have to check if they still appear by
> > default
[snip]
> 
> Why not? You've not given any reason at all. Do you know of any malicious
> behavior that is made possible by leaving the services turned on? 

I don't need to, as my point earlier included `you don't know there won't
be a vulnerability tomorrow'.

But that said, I gather leaking one's timestamp is not a good thing
(leaking *anything* is not really any good). I'm no Kerberos user, but I
heard you can do time-dependent auth in that a given ticket is good until
. I wouldn't want someone to know exactly what time my boxes
thought it was.

> The potential exists to use the chargen feature as a part of a DoS
> attack, but I've not heard of it ever being used as it's not particularly
> effective unless you have many many machines available, and even then
> there are much more effective weapons.

, btw. Why bother
hooking /dev/{zero,null} onto the net with netcat when you can cause a fair
bit of traffic with standard services that do much the same thing?

> Really I'm just playing devil's advocate here. I don't care if they're
> turned off or not. I've just never seen any evidence that there's any
> reason for concern over them.

There doesn't have to be a reason for concern for you to not want them
available. I don't want anyone so much as fingerprinting my box (given that
nmap relies mostly on TCP responses to guage OS), let alone doing anything
really interesting with it.

~Tim
-- 
The light of the world keeps shining,   |[EMAIL PROTECTED]
Bright in the primal glow   |http://spodzone.org.uk/

Re: rlinetd security

[Tim Haynes]

[EMAIL PROTECTED] (Martin Maney) writes:

> On Mon, Jun 18, 2001 at 08:34:11PM +0100, Tim Haynes wrote:
>
> > Well, it depends. You can never tidy up a rooted box; the same
> > mentality sort of applies all the way down - if you're setting up a
> > box, why worry about installing this and uninstalling that, when your
> > original installation shouldn't have had anything enabled in the first
> > place? (And yes, you can push that back into the distro, too.)
> 
> Sure, you can have a distro that doens't install any services. Heck,
> consider local exploits and you may decide that "login considered
> harmful" isn't too great a stretch... :-)

Well, smiley noted, but the list of users who have what kind of access to
the box has to be considered.

> I have to take issue with your attempt to draw a aparallel to a rooted
> box. It *is* possible to cleanup the newly installed box because you can
> reasonably assume that it hasn't been maliciously setup to resist the
> cleanup.

Well, if you can assume that, sure. But the parallel really comes in saying
you half-way don't know what to look for, or might miss something. That's
why I'm in favour of pushing some things into the distro
installation-default area.

> > Surely software you install on production machines has its requirements
> > either satisfied by the wonder that is apt-get, or documented properly? 
> > You can, and should, start from blank and add things as you need.
> 
> Could I agree with the minimalist sentiment while yet observing that
> apt-get, wonderful as it is, cannot satisfy requirements that come not
> from packages installed on this machine, but from other machines -
> possibly ones that aren't even using Debian?

Sure; that's where `or documented properly' comes in.

> At the same time, I would like to agree with the sentiment that has been
> expressed a few times. "If you don't know what it's for, shut it off." I
> think the unstated part that some may have overlooked is that if you need
> something but don't know it, then you owe it to yourself (and your
> employers, if that's the sort of situation it is) to find out what's
> there.

It's been mentioned very en-passant, as has `but I don't have the time to
investigate everything', which makes my caffeine^Wblood boil.

>  This is how sysadmins lose their hair!

Tell me about it. 

My take on the whole thing is that you're building a test box internally
first *anyway*, if you don't know exactly how to set up a live machine;
then you investigate, kill off everything your reading of the manuals
allows you to, on the simple grounds that you don't want it to turn around
& bite you later on, and you're on a test box so any breaks won't matter
and you'll learn in the process.
Leaving stuff open because `there aren't any known holes at the moment
doesn't really wash here :( .

~Tim
-- 
But mountains are holy places,  |[EMAIL PROTECTED]
And beauty is free / We can still walk  |http://spodzone.org.uk/
Through the garden  |
Our earth was once green|


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Martin Maney]

On Mon, Jun 18, 2001 at 08:34:11PM +0100, Tim Haynes wrote:
> Well, it depends. You can never tidy up a rooted box; the same mentality
> sort of applies all the way down - if you're setting up a box, why worry
> about installing this and uninstalling that, when your original
> installation shouldn't have had anything enabled in the first place? (And
> yes, you can push that back into the distro, too.)

Sure, you can have a distro that doens't install any services.  Heck,
consider local exploits and you may decide that "login considered harmful"
isn't too great a stretch...  :-)

I have to take issue with your attempt to draw a aparallel to a rooted box. 
It *is* possible to cleanup the newly installed box because you can
reasonably assume that it hasn't been maliciously setup to resist the
cleanup.

> Surely software you install on production machines has its requirements
> either satisfied by the wonder that is apt-get, or documented properly? You
> can, and should, start from blank and add things as you need.

Could I agree with the minimalist sentiment while yet observing that
apt-get, wonderful as it is, cannot satisfy requirements that come not from
packages installed on this machine, but from other machines - possibly ones
that aren't even using Debian?

At the same time, I would like to agree with the sentiment that has been
expressed a few times.  "If you don't know what it's for, shut it off."  I
think the unstated part that some may have overlooked is that if you need
something but don't know it, then you owe it to yourself (and your
employers, if that's the sort of situation it is) to find out what's there. 
This is how sysadmins lose their hair!

-- 
There has grown up in the minds of certain groups in this country
the notion that because a man or corporation has made a profit
out of the public for a number of years, the government and the courts
are charged with the duty of guaranteeing such profit in the future,
even in the face of changing circumstances and contrary public interest.
This strange doctrine is not supported by statute nor common law.  -- RAH


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Vineet Kumar]

I'm not adding anything new to this thread, only reiterating for those
who seem to have missed previous reiterations:

'The more ports you leave open, the greater chance you have of being
cracked.'

'If you don't know why you need it, you don't need it.'

It seems reasonable that the default installation should try to make
itself useful to the average target user. Now, by a show of hands
(rather than a string of replies), how many of us have sat down at our
newly-installed machines and said "All right, time to get my discard
service on! Let's follow that up with a little chargen, while we're at
it!" They may be legitimate services with legitimate uses, but are not
needed in the normal case, and as such, should not be activated in the
default case.

The argument below is pretty bad. Have you ever heard of anybody
actually getting impaled by holding a sword poised at his belly and
walking into grand central station at 5:00pm going "'scuse me, pardon
me, 'scuse me, pardon *GGUAGHGH!*"? I sure haven't. So why not do it?
Our hypothetical late friend didn't need to be doing it, and he
shouldn't have been doing it. 

...which brings me to my next point: just because I've never heard of
such a ridiculous demise actually occuring doesn't rule out the
possibility that it has. And just because you haven't heard of
exploits involving these services doesn't mean they haven't been
around. Again, a reiteration of wiser words earlier in the thread:

"the standard inetd services including discard, echo, sysstat,
netstat et al all *have* *had* their known vulnerabilities before now.
All long-since patched, but that's not to say there won't be another
tomorrow."

Vineet

* Noah Meyerhans ([EMAIL PROTECTED]) [010618 10:51]:
> Why not?  You've not given any reason at all.  Do you know of any
> malicious behavior that is made possible by leaving the services turned
> on?  The potential exists to use the chargen feature as a part of a DoS
> attack, but I've not heard of it ever being used as it's not
> particularly effective unless you have many many machines available, and
> even then there are much more effective weapons.  And what about the
> rest of the ports?  How are they dangerous?  I've never heard of an
> exploit involving any of them.
> 
> Really I'm just playing devil's advocate here.  I don't care if they're
> turned off or not.  I've just never seen any evidence that there's any
> reason for concern over them.
> 
> noah
> 
> -- 
>  ___
> | Web: http://web.morgul.net/~frodo/
> | PGP Public Key: http://web.morgul.net/~frodo/mail.html 
> 




pgpo1zzoxfxVx.pgp
Description: PGP signature

Re: rlinetd security

[Noah Meyerhans]

On Mon, Jun 18, 2001 at 06:35:03PM +0100, Tim Haynes wrote:
> b) they shouldn't be. You'll have to check if they still appear by default
> in unstable; I should hope they don't. (There's been discussion of this
> before if you trawl some archives somewhere.) It's possible to use them all
> legitimately - e.g. the daytime thing might be if someone has a legacy
> setup on their LAN and relied on it for time sync, the chargen/echo/discard
> things could well be useful for getting streams of data and network
> monitoring, etc. However, they really shouldn't be enabled by default.

Why not?  You've not given any reason at all.  Do you know of any
malicious behavior that is made possible by leaving the services turned
on?  The potential exists to use the chargen feature as a part of a DoS
attack, but I've not heard of it ever being used as it's not
particularly effective unless you have many many machines available, and
even then there are much more effective weapons.  And what about the
rest of the ports?  How are they dangerous?  I've never heard of an
exploit involving any of them.

Really I'm just playing devil's advocate here.  I don't care if they're
turned off or not.  I've just never seen any evidence that there's any
reason for concern over them.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 



pgp1434Zdbbvy.pgp
Description: PGP signature

Re: rlinetd security

[Tim Haynes]

Sebastiaan <[EMAIL PROTECTED]> writes:

[snip]
> > Again, if you don't know why you need it, you don't need it.
>
> I know you are right, but I have become curious now: if everyone says
> that you do not need them, then where are they used for? And why are they
> still installed by default?

Good questions.

a) echo is just there to duplicate everything you send back at you.
   discard is just there to dump everything in the sink.
   chargen is to give a continual stream of output, eg bandwidth testing
   daytime is to give another box a snapshot of the time on here - a crude
   & ancient & horrible way to sync boxes
   netstat is to give a view of `netstat' over the 'net - remote admin?

b) they shouldn't be. You'll have to check if they still appear by default
in unstable; I should hope they don't. (There's been discussion of this
before if you trawl some archives somewhere.) It's possible to use them all
legitimately - e.g. the daytime thing might be if someone has a legacy
setup on their LAN and relied on it for time sync, the chargen/echo/discard
things could well be useful for getting streams of data and network
monitoring, etc. However, they really shouldn't be enabled by default.

~Tim
-- 
All I see, All I know   |[EMAIL PROTECTED]
Is touching the sacred earth|http://spodzone.org.uk/
And warming the hallowed ground |

Re: rlinetd security

[Tim Haynes]

"Noah L. Meyerhans" <[EMAIL PROTECTED]> writes:

[snip]
> > , btw. Why bother
> > hooking /dev/{zero,null} onto the net with netcat when you can cause a fair
> > bit of traffic with standard services that do much the same thing?
> 
> Yes, but you know what? 'ping -f' works just as good, if not better. Do
> you have ICMP filtered at your router?

Some, yes. 

I also worry about who's going to be able to execute `ping -f' on *my*
machines, should they make it through, and try to make it as hard as
possible.

Leaving ports open because you don't know better does not constitute making
nasty people's life harder.

~Tim
-- 
   20:12:08 up 4 days, 16 min, 17 users,  load average: 0.02, 0.04, 0.00
[EMAIL PROTECTED] |Windows 98 is year 2000-ready
http://piglet.is.dreaming.org |(seen during a recent, >y2000, installation)


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Sebastiaan]

On 18 Jun 2001, Tim Haynes wrote:

> "Pat Moffitt" <[EMAIL PROTECTED]> writes:
> 
> > That makes a lot of assumptions about my (or anyone else) understanding
> > of the system. For example, I have no clue what discard is used for. So,
> > how do I know if I have a package installed that will not work properly
> > if I disable that port. Yes, I should go and research the issue but I
> > only have some much time in the day.
> > 
> > Therefor, many of us are forced to make the same assumptions (valid or
> > not) such as Sebastiaan's.
> 
> Ethan is correct. 
> 
> Start from `the more ports you leave open, the greater chance you have of
> being cracked' and work up.
> 
> ISTR the standard inetd services including discard, echo, sysstat, netstat
> et all *have* *had* their known vulnerabilities before now. All long-since
> patched, but that's not to say there won't be another tomorrow.
> 
> Again, if you don't know why you need it, you don't need it.
> 
I know you are right, but I have become curious now: if everyone says that
you do not need them, then where are they used for? And why are they still
installed by default?

Thanks,
Sebastiaan

Re: rlinetd security

[Tim Haynes]

"Noah L. Meyerhans" <[EMAIL PROTECTED]> writes:

> On Mon, Jun 18, 2001 at 11:08:49AM -0700, Vineet Kumar wrote:
>
> > The argument below is pretty bad. Have you ever heard of anybody
> > actually getting impaled by holding a sword poised at his belly and
> > walking into grand central station at 5:00pm going "'scuse me, pardon
> > me, 'scuse me, pardon *GGUAGHGH!*"? I sure haven't. So why not do it? 
> > Our hypothetical late friend didn't need to be doing it, and he
> > shouldn't have been doing it.
> 
> Huh? You've acknowledged that there may be legitimate uses for the simple
> services that you may be ignorant of. I don't think there is any
> legitimate gain to be had be running around a crowded area with a blade
> against your belly.

The point is that these things can be used for good or evil. If you're not
going to use it for good, whether someone else can or not, a nasty chap can
still use it for evil.

You realise rpc.statd has its uses, as does ftpd? Is that some reason to
enable them `just in case somebody wants to use them for legitimate
reasons'?
 
> > "the standard inetd services including discard, echo, sysstat, netstat
> > et al all *have* *had* their known vulnerabilities before now. All
> > long-since patched, but that's not to say there won't be another
> > tomorrow."
> 
> Have you looked at their code?  I can assure you that there is no
> potential for remote exploit in 
> void
> discard_stream(int s, struct servtab *sep)
[snip]

> These services are so simple that any moderately knowledgeable coder can
> ensure that there is no risk to leaving the services turned on.

There isn't? What about in your choice of C-library, then, have you audited
that? 
While you're here, what tweaks are going to be made to these functions next
week?

The principle is still the same. It's not enough to ask whether you need it
or not and assume something can be left on if you don't know any better; if
another vulnerability comes out you have to check one more thing to see
whether it's relevant or not, which is a waste of time, at best, and an
omitted necessary update to an unused service (unused, until someone scans
you for it, that is) at worst.

Incidentally, in your dismissal of exploits for these things, you're
neglecting another scenario: black-hat *does* manage to crack another box
in the organization, and points multiple netcats from the exploited box at
someone with echo: you'll end up with enough network traffic & load to
cause a slow-down, and the traffic may possibly help him mask very nasty
activities in the noise.

~Tim
-- 
All I see, All I know   |[EMAIL PROTECTED]
Is touching the sacred earth|http://spodzone.org.uk/
And warming the hallowed ground |


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: rlinetd security

[Pat Moffitt]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Tim Haynes
> Sent: Monday, June 18, 2001 10:35 AM
> To: Sebastiaan
> Cc: Tim Haynes; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: rlinetd security
>
>
> Sebastiaan <[EMAIL PROTECTED]> writes:
>
> [snip]
> > > Again, if you don't know why you need it, you don't need it.
> >
> > I know you are right, but I have become curious now: if everyone says
> > that you do not need them, then where are they used for? And
> why are they
> > still installed by default?
>
> Good questions.
>
> a) echo is just there to duplicate everything you send back at you.
>discard is just there to dump everything in the sink.
>chargen is to give a continual stream of output, eg bandwidth testing
>daytime is to give another box a snapshot of the time on here - a crude
>& ancient & horrible way to sync boxes
>netstat is to give a view of `netstat' over the 'net - remote admin?
[snip]

Now that answers some questions.  Much better.  At least when I turn them
off I will have a clue about what might break.

BTW, my philosophy on disabling unknown services/ports has been to disable
it and see if anything breaks.  If something breaks, then figure out what to
do about it.  But, this can be a tough philosophy on production machines.
(No, I don't have machines that I can test with here.  Nor do I have the
time to set them up.)

The concept of 'if you don't know why your running them you don't need
them.' may be good advice but doesn't help those of use that are trying to
understand Security.

Pat Moffitt
MIS Administrator
Western Recreational Vehicles, Inc.



--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Noah L. Meyerhans]

On Mon, Jun 18, 2001 at 07:25:37PM +0100, Tim Haynes wrote:
> But that said, I gather leaking one's timestamp is not a good thing
> (leaking *anything* is not really any good). I'm no Kerberos user, but I
> heard you can do time-dependent auth in that a given ticket is good until
> . I wouldn't want someone to know exactly what time my boxes
> thought it was.

So I assume you stay very clear of any kind of time synchronization
(ntpd and the like).  In order for things like Kerberos to work (BTW, I
am a kerberos user) the client machines have to be very closely
synchronized with the authentication server.  NTP is how this is done.
Giving out your time via either the daytime or time simple service is
not giving out any info that's not already available to anybody who
cares to look.

> > The potential exists to use the chargen feature as a part of a DoS
> > attack, but I've not heard of it ever being used as it's not particularly
> > effective unless you have many many machines available, and even then
> > there are much more effective weapons.
> 
> , btw. Why bother
> hooking /dev/{zero,null} onto the net with netcat when you can cause a fair
> bit of traffic with standard services that do much the same thing?

Yes, but you know what?  'ping -f' works just as good, if not better.
Do you have ICMP filtered at your router?


-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


 PGP signature

Re: rlinetd security

[Noah L. Meyerhans]

On Mon, Jun 18, 2001 at 11:08:49AM -0700, Vineet Kumar wrote:
> The argument below is pretty bad. Have you ever heard of anybody
> actually getting impaled by holding a sword poised at his belly and
> walking into grand central station at 5:00pm going "'scuse me, pardon
> me, 'scuse me, pardon *GGUAGHGH!*"? I sure haven't. So why not do it?
> Our hypothetical late friend didn't need to be doing it, and he
> shouldn't have been doing it. 

Huh?  You've acknowledged that there may be legitimate uses for the
simple services that you may be ignorant of.  I don't think there is any
legitimate gain to be had be running around a crowded area with a blade
against your belly.

> "the standard inetd services including discard, echo, sysstat,
> netstat et al all *have* *had* their known vulnerabilities before now.
> All long-since patched, but that's not to say there won't be another
> tomorrow."
> 

Have you looked at their code?  I can assure you that there is no
potential for remote exploit in 
void
discard_stream(int s, struct servtab *sep)
{
char buffer[BUFSIZE];

setproctitle(sep->se_service, s);
while ((errno = 0, read(s, buffer, sizeof(buffer)) > 0) ||
errno == EINTR)
;
exit(0);
}

Or how 'bout this:
/* Return human-readable time of day */
void
daytime_stream(int s, struct servtab *sep)
{
char buffer[256];
time_t clocc;

(void)sep;

clocc = time(NULL);
snprintf(buffer, sizeof(buffer), "%.24s\r\n", ctime(&clocc));
write(s, buffer, strlen(buffer));
}

These services are so simple that any moderately knowledgeable coder can
ensure that there is no risk to leaving the services turned on.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


 PGP signature

Re: rlinetd security

[Tim Haynes]

"Pat Moffitt" <[EMAIL PROTECTED]> writes:

> That makes a lot of assumptions about my (or anyone else) understanding
> of the system. For example, I have no clue what discard is used for. So,
> how do I know if I have a package installed that will not work properly
> if I disable that port. Yes, I should go and research the issue but I
> only have some much time in the day.
> 
> Therefor, many of us are forced to make the same assumptions (valid or
> not) such as Sebastiaan's.

Ethan is correct. 

Start from `the more ports you leave open, the greater chance you have of
being cracked' and work up.

ISTR the standard inetd services including discard, echo, sysstat, netstat
et all *have* *had* their known vulnerabilities before now. All long-since
patched, but that's not to say there won't be another tomorrow.

Again, if you don't know why you need it, you don't need it.

~Tim
-- 
   17:16:07 up 3 days, 21:20, 16 users,  load average: 0.13, 0.09, 0.02
[EMAIL PROTECTED] |Sometimes you're the pigeon,
http://piglet.is.dreaming.org |Sometimes you're the statue.

Re: rlinetd security

[Tim Haynes]

Noah Meyerhans <[EMAIL PROTECTED]> writes:

> On Mon, Jun 18, 2001 at 06:35:03PM +0100, Tim Haynes wrote:
> > b) they shouldn't be. You'll have to check if they still appear by
> > default
[snip]
> 
> Why not? You've not given any reason at all. Do you know of any malicious
> behavior that is made possible by leaving the services turned on? 

I don't need to, as my point earlier included `you don't know there won't
be a vulnerability tomorrow'.

But that said, I gather leaking one's timestamp is not a good thing
(leaking *anything* is not really any good). I'm no Kerberos user, but I
heard you can do time-dependent auth in that a given ticket is good until
. I wouldn't want someone to know exactly what time my boxes
thought it was.

> The potential exists to use the chargen feature as a part of a DoS
> attack, but I've not heard of it ever being used as it's not particularly
> effective unless you have many many machines available, and even then
> there are much more effective weapons.

, btw. Why bother
hooking /dev/{zero,null} onto the net with netcat when you can cause a fair
bit of traffic with standard services that do much the same thing?

> Really I'm just playing devil's advocate here. I don't care if they're
> turned off or not. I've just never seen any evidence that there's any
> reason for concern over them.

There doesn't have to be a reason for concern for you to not want them
available. I don't want anyone so much as fingerprinting my box (given that
nmap relies mostly on TCP responses to guage OS), let alone doing anything
really interesting with it.

~Tim
-- 
The light of the world keeps shining,   |[EMAIL PROTECTED]
Bright in the primal glow   |http://spodzone.org.uk/


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: rlinetd security

[Pat Moffitt]

That makes a lot of assumptions about my (or anyone else) understanding of
the system.  For example, I have no clue what discard is used for.  So, how
do I know if I have a package installed that will not work properly if I
disable that port.  Yes, I should go and research the issue but I only have
some much time in the day.

Therefor, many of us are forced to make the same assumptions (valid or not)
such as Sebastiaan's.

Pat Moffitt
MIS Administrator
Western Recreational Vehicles, Inc.


> -Original Message-
> From: Ethan Benson [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 18, 2001 1:57 AM
> To: debian-security@lists.debian.org
> Subject: Re: rlinetd security
>
>
> On Mon, Jun 18, 2001 at 10:53:06AM +0200, Sebastiaan wrote:
> > Yes, that is a good question. I do not know where most of them are used
> > for, but because they are always installed, I assumed that these are
> > needed for correct system operation. But even if I would disable these
> > ports, I still want to use ftp, smtp and telnet only for my
> local network.
>
> if you don't know why your running them you don't need them.  simple
> as that.

Re: rlinetd security

[Vineet Kumar]

I'm not adding anything new to this thread, only reiterating for those
who seem to have missed previous reiterations:

'The more ports you leave open, the greater chance you have of being
cracked.'

'If you don't know why you need it, you don't need it.'

It seems reasonable that the default installation should try to make
itself useful to the average target user. Now, by a show of hands
(rather than a string of replies), how many of us have sat down at our
newly-installed machines and said "All right, time to get my discard
service on! Let's follow that up with a little chargen, while we're at
it!" They may be legitimate services with legitimate uses, but are not
needed in the normal case, and as such, should not be activated in the
default case.

The argument below is pretty bad. Have you ever heard of anybody
actually getting impaled by holding a sword poised at his belly and
walking into grand central station at 5:00pm going "'scuse me, pardon
me, 'scuse me, pardon *GGUAGHGH!*"? I sure haven't. So why not do it?
Our hypothetical late friend didn't need to be doing it, and he
shouldn't have been doing it. 

...which brings me to my next point: just because I've never heard of
such a ridiculous demise actually occuring doesn't rule out the
possibility that it has. And just because you haven't heard of
exploits involving these services doesn't mean they haven't been
around. Again, a reiteration of wiser words earlier in the thread:

"the standard inetd services including discard, echo, sysstat,
netstat et al all *have* *had* their known vulnerabilities before now.
All long-since patched, but that's not to say there won't be another
tomorrow."

Vineet

* Noah Meyerhans ([EMAIL PROTECTED]) [010618 10:51]:
> Why not?  You've not given any reason at all.  Do you know of any
> malicious behavior that is made possible by leaving the services turned
> on?  The potential exists to use the chargen feature as a part of a DoS
> attack, but I've not heard of it ever being used as it's not
> particularly effective unless you have many many machines available, and
> even then there are much more effective weapons.  And what about the
> rest of the ports?  How are they dangerous?  I've never heard of an
> exploit involving any of them.
> 
> Really I'm just playing devil's advocate here.  I don't care if they're
> turned off or not.  I've just never seen any evidence that there's any
> reason for concern over them.
> 
> noah
> 
> -- 
>  ___
> | Web: http://web.morgul.net/~frodo/
> | PGP Public Key: http://web.morgul.net/~frodo/mail.html 
> 



 PGP signature

Re: rlinetd security

[Noah Meyerhans]

On Mon, Jun 18, 2001 at 06:35:03PM +0100, Tim Haynes wrote:
> b) they shouldn't be. You'll have to check if they still appear by default
> in unstable; I should hope they don't. (There's been discussion of this
> before if you trawl some archives somewhere.) It's possible to use them all
> legitimately - e.g. the daytime thing might be if someone has a legacy
> setup on their LAN and relied on it for time sync, the chargen/echo/discard
> things could well be useful for getting streams of data and network
> monitoring, etc. However, they really shouldn't be enabled by default.

Why not?  You've not given any reason at all.  Do you know of any
malicious behavior that is made possible by leaving the services turned
on?  The potential exists to use the chargen feature as a part of a DoS
attack, but I've not heard of it ever being used as it's not
particularly effective unless you have many many machines available, and
even then there are much more effective weapons.  And what about the
rest of the ports?  How are they dangerous?  I've never heard of an
exploit involving any of them.

Really I'm just playing devil's advocate here.  I don't care if they're
turned off or not.  I've just never seen any evidence that there's any
reason for concern over them.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


 PGP signature

Re: rlinetd security

[Tim Haynes]

Sebastiaan <[EMAIL PROTECTED]> writes:

[snip]
> > Again, if you don't know why you need it, you don't need it.
>
> I know you are right, but I have become curious now: if everyone says
> that you do not need them, then where are they used for? And why are they
> still installed by default?

Good questions.

a) echo is just there to duplicate everything you send back at you.
   discard is just there to dump everything in the sink.
   chargen is to give a continual stream of output, eg bandwidth testing
   daytime is to give another box a snapshot of the time on here - a crude
   & ancient & horrible way to sync boxes
   netstat is to give a view of `netstat' over the 'net - remote admin?

b) they shouldn't be. You'll have to check if they still appear by default
in unstable; I should hope they don't. (There's been discussion of this
before if you trawl some archives somewhere.) It's possible to use them all
legitimately - e.g. the daytime thing might be if someone has a legacy
setup on their LAN and relied on it for time sync, the chargen/echo/discard
things could well be useful for getting streams of data and network
monitoring, etc. However, they really shouldn't be enabled by default.

~Tim
-- 
All I see, All I know   |[EMAIL PROTECTED]
Is touching the sacred earth|http://spodzone.org.uk/
And warming the hallowed ground |


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Sebastiaan]

On 18 Jun 2001, Tim Haynes wrote:

> "Pat Moffitt" <[EMAIL PROTECTED]> writes:
> 
> > That makes a lot of assumptions about my (or anyone else) understanding
> > of the system. For example, I have no clue what discard is used for. So,
> > how do I know if I have a package installed that will not work properly
> > if I disable that port. Yes, I should go and research the issue but I
> > only have some much time in the day.
> > 
> > Therefor, many of us are forced to make the same assumptions (valid or
> > not) such as Sebastiaan's.
> 
> Ethan is correct. 
> 
> Start from `the more ports you leave open, the greater chance you have of
> being cracked' and work up.
> 
> ISTR the standard inetd services including discard, echo, sysstat, netstat
> et all *have* *had* their known vulnerabilities before now. All long-since
> patched, but that's not to say there won't be another tomorrow.
> 
> Again, if you don't know why you need it, you don't need it.
> 
I know you are right, but I have become curious now: if everyone says that
you do not need them, then where are they used for? And why are they still
installed by default?

Thanks,
Sebastiaan



--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Tim Haynes]

"Pat Moffitt" <[EMAIL PROTECTED]> writes:

> That makes a lot of assumptions about my (or anyone else) understanding
> of the system. For example, I have no clue what discard is used for. So,
> how do I know if I have a package installed that will not work properly
> if I disable that port. Yes, I should go and research the issue but I
> only have some much time in the day.
> 
> Therefor, many of us are forced to make the same assumptions (valid or
> not) such as Sebastiaan's.

Ethan is correct. 

Start from `the more ports you leave open, the greater chance you have of
being cracked' and work up.

ISTR the standard inetd services including discard, echo, sysstat, netstat
et all *have* *had* their known vulnerabilities before now. All long-since
patched, but that's not to say there won't be another tomorrow.

Again, if you don't know why you need it, you don't need it.

~Tim
-- 
   17:16:07 up 3 days, 21:20, 16 users,  load average: 0.13, 0.09, 0.02
[EMAIL PROTECTED] |Sometimes you're the pigeon,
http://piglet.is.dreaming.org |Sometimes you're the statue.


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: rlinetd security

[Pat Moffitt]

That makes a lot of assumptions about my (or anyone else) understanding of
the system.  For example, I have no clue what discard is used for.  So, how
do I know if I have a package installed that will not work properly if I
disable that port.  Yes, I should go and research the issue but I only have
some much time in the day.

Therefor, many of us are forced to make the same assumptions (valid or not)
such as Sebastiaan's.

Pat Moffitt
MIS Administrator
Western Recreational Vehicles, Inc.


> -Original Message-
> From: Ethan Benson [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 1:57 AM
> To: [EMAIL PROTECTED]
> Subject: Re: rlinetd security
>
>
> On Mon, Jun 18, 2001 at 10:53:06AM +0200, Sebastiaan wrote:
> > Yes, that is a good question. I do not know where most of them are used
> > for, but because they are always installed, I assumed that these are
> > needed for correct system operation. But even if I would disable these
> > ports, I still want to use ftp, smtp and telnet only for my
> local network.
>
> if you don't know why your running them you don't need them.  simple
> as that.


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Tim Haynes]

Ethan Benson <[EMAIL PROTECTED]> writes:

> On Mon, Jun 18, 2001 at 10:53:06AM +0200, Sebastiaan wrote:
> > Yes, that is a good question. I do not know where most of them are used
> > for, but because they are always installed, I assumed that these are
> > needed for correct system operation. But even if I would disable these
> > ports, I still want to use ftp, smtp and telnet only for my local network.
> 
> if you don't know why your running them you don't need them.  simple
> as that.  

Word of warning to Sebastian: I've missed the start of this thread,
obviously, but how much do you trust your LAN? If it's a home affair, don't
worry so much; if it's a corporate LAN, you'll always have *insiders*
sniffing networks, remembering your passwords, being sacked and feeling
disenchanted with you.
Avoid ftp & telnet, and any other plain-text protocol, as much as humanly
possible. (We don't run them in-house here, on the grounds that we find ssh
& scp & rsync *more convenient* anyway. Maybe that's just us... ;)

~Tim
-- 
   10:08:32 up 3 days, 14:12, 11 users,  load average: 0.04, 0.03, 0.00
[EMAIL PROTECTED] |Roobarb and Custard let fly
http://piglet.is.dreaming.org |with their secret weapon.

Re: rlinetd security

[Ethan Benson]

On Mon, Jun 18, 2001 at 10:53:06AM +0200, Sebastiaan wrote:
> Yes, that is a good question. I do not know where most of them are used
> for, but because they are always installed, I assumed that these are
> needed for correct system operation. But even if I would disable these
> ports, I still want to use ftp, smtp and telnet only for my local network.

if you don't know why your running them you don't need them.  simple
as that.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgp5Z9Fm0eHOU.pgp
Description: PGP signature

Re: rlinetd security

[Sebastiaan]

On Mon, 18 Jun 2001, Ethan Benson wrote:

> On Mon, Jun 18, 2001 at 09:21:56AM +0200, Sebastiaan wrote:
> > Hello,
> > 
> > I found out that rlinetd seems like a great replacement for inetd, because
> > it lets you choose which services may be available for the outside world
> > and which only for the inner network. So, standard services like echo,
> > daytime, chargen, ftp, etc. are only available for the LAN, while it is
> > not possible to connect to these ports from the internet.
> > 
> > But, how secure is this? Is it really what it seems? 
> 
> first you should ask yourself why you even need echo, daytime,
> discard, chargen and such.  i don't think ive ever found anyone who
> actually did need all of those. 
> 
Yes, that is a good question. I do not know where most of them are used
for, but because they are always installed, I assumed that these are
needed for correct system operation. But even if I would disable these
ports, I still want to use ftp, smtp and telnet only for my local network.

Thanks,
Sebastiaan

Re: rlinetd security

[Ethan Benson]

On Mon, Jun 18, 2001 at 09:21:56AM +0200, Sebastiaan wrote:
> Hello,
> 
> I found out that rlinetd seems like a great replacement for inetd, because
> it lets you choose which services may be available for the outside world
> and which only for the inner network. So, standard services like echo,
> daytime, chargen, ftp, etc. are only available for the LAN, while it is
> not possible to connect to these ports from the internet.
> 
> But, how secure is this? Is it really what it seems? 

first you should ask yourself why you even need echo, daytime,
discard, chargen and such.  i don't think ive ever found anyone who
actually did need all of those. 

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpEVAZUCzbSk.pgp
Description: PGP signature

Re: rlinetd security

[Tim Haynes]

Jason Thomas <[EMAIL PROTECTED]> writes upside-down:

> this stuff can also be controlled using hosts.deny and hosts.allow. so
> then any inetd prog will do!

No it can't. There's a difference between not listening on the interface at
all, and filtering it out by allowing them to connect to the port first and
only later saying `I don't like the look of your IP#'.

If nothing else, you *should* use rlinetd or xinetd or similar to control
the binding *as well as* tightening down hosts.{allow,deny}.

~Tim
-- 
   09:43:56 up 3 days, 13:48, 16 users,  load average: 0.00, 0.00, 0.00
[EMAIL PROTECTED] |Ideologies come, ideologies go
http://piglet.is.dreaming.org |A waste of words, and endless flow

Re: rlinetd security

[Jason Thomas]

this stuff can also be controlled using hosts.deny and hosts.allow. so
then any inetd prog will do!

On Mon, Jun 18, 2001 at 09:21:56AM +0200, Sebastiaan wrote:
> Hello,
> 
> I found out that rlinetd seems like a great replacement for inetd, because
> it lets you choose which services may be available for the outside world
> and which only for the inner network. So, standard services like echo,
> daytime, chargen, ftp, etc. are only available for the LAN, while it is
> not possible to connect to these ports from the internet.
> 
> But, how secure is this? Is it really what it seems? 
> 
> Thanks in advance,
> Sebastiaan
> 
> 
> 
> --
>   NT is the OS of the future. The main engine is the 16-bit Subsystem
>   (also called MS-DOS Subsystem). Above that, there is the windoze 95/98
>   16-bit Subsystem. Anyone can see that 16+16=32, so windoze NT is a 
>   *real* 32-bit system.
> 
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
Jason Thomas   Phone:  +61 2 6257 7111
System Administrator  -  UID 0 Fax:+61 2 6257 7311
tSA Consulting Group Pty. Ltd. Mobile: 0418 29 66 81
1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/


pgpacqYephpWx.pgp
Description: PGP signature

Re: rlinetd security

[Tim Haynes]

Ethan Benson <[EMAIL PROTECTED]> writes:

> On Mon, Jun 18, 2001 at 10:53:06AM +0200, Sebastiaan wrote:
> > Yes, that is a good question. I do not know where most of them are used
> > for, but because they are always installed, I assumed that these are
> > needed for correct system operation. But even if I would disable these
> > ports, I still want to use ftp, smtp and telnet only for my local network.
> 
> if you don't know why your running them you don't need them.  simple
> as that.  

Word of warning to Sebastian: I've missed the start of this thread,
obviously, but how much do you trust your LAN? If it's a home affair, don't
worry so much; if it's a corporate LAN, you'll always have *insiders*
sniffing networks, remembering your passwords, being sacked and feeling
disenchanted with you.
Avoid ftp & telnet, and any other plain-text protocol, as much as humanly
possible. (We don't run them in-house here, on the grounds that we find ssh
& scp & rsync *more convenient* anyway. Maybe that's just us... ;)

~Tim
-- 
   10:08:32 up 3 days, 14:12, 11 users,  load average: 0.04, 0.03, 0.00
[EMAIL PROTECTED] |Roobarb and Custard let fly
http://piglet.is.dreaming.org |with their secret weapon.


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Ethan Benson]

On Mon, Jun 18, 2001 at 10:53:06AM +0200, Sebastiaan wrote:
> Yes, that is a good question. I do not know where most of them are used
> for, but because they are always installed, I assumed that these are
> needed for correct system operation. But even if I would disable these
> ports, I still want to use ftp, smtp and telnet only for my local network.

if you don't know why your running them you don't need them.  simple
as that.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

 PGP signature

Re: rlinetd security

[Sebastiaan]

On Mon, 18 Jun 2001, Ethan Benson wrote:

> On Mon, Jun 18, 2001 at 09:21:56AM +0200, Sebastiaan wrote:
> > Hello,
> > 
> > I found out that rlinetd seems like a great replacement for inetd, because
> > it lets you choose which services may be available for the outside world
> > and which only for the inner network. So, standard services like echo,
> > daytime, chargen, ftp, etc. are only available for the LAN, while it is
> > not possible to connect to these ports from the internet.
> > 
> > But, how secure is this? Is it really what it seems? 
> 
> first you should ask yourself why you even need echo, daytime,
> discard, chargen and such.  i don't think ive ever found anyone who
> actually did need all of those. 
> 
Yes, that is a good question. I do not know where most of them are used
for, but because they are always installed, I assumed that these are
needed for correct system operation. But even if I would disable these
ports, I still want to use ftp, smtp and telnet only for my local network.

Thanks,
Sebastiaan



--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Ethan Benson]

On Mon, Jun 18, 2001 at 09:21:56AM +0200, Sebastiaan wrote:
> Hello,
> 
> I found out that rlinetd seems like a great replacement for inetd, because
> it lets you choose which services may be available for the outside world
> and which only for the inner network. So, standard services like echo,
> daytime, chargen, ftp, etc. are only available for the LAN, while it is
> not possible to connect to these ports from the internet.
> 
> But, how secure is this? Is it really what it seems? 

first you should ask yourself why you even need echo, daytime,
discard, chargen and such.  i don't think ive ever found anyone who
actually did need all of those. 

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

 PGP signature

Re: rlinetd security

[Tim Haynes]

Jason Thomas <[EMAIL PROTECTED]> writes upside-down:

> this stuff can also be controlled using hosts.deny and hosts.allow. so
> then any inetd prog will do!

No it can't. There's a difference between not listening on the interface at
all, and filtering it out by allowing them to connect to the port first and
only later saying `I don't like the look of your IP#'.

If nothing else, you *should* use rlinetd or xinetd or similar to control
the binding *as well as* tightening down hosts.{allow,deny}.

~Tim
-- 
   09:43:56 up 3 days, 13:48, 16 users,  load average: 0.00, 0.00, 0.00
[EMAIL PROTECTED] |Ideologies come, ideologies go
http://piglet.is.dreaming.org |A waste of words, and endless flow


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rlinetd security

[Jason Thomas]

this stuff can also be controlled using hosts.deny and hosts.allow. so
then any inetd prog will do!

On Mon, Jun 18, 2001 at 09:21:56AM +0200, Sebastiaan wrote:
> Hello,
> 
> I found out that rlinetd seems like a great replacement for inetd, because
> it lets you choose which services may be available for the outside world
> and which only for the inner network. So, standard services like echo,
> daytime, chargen, ftp, etc. are only available for the LAN, while it is
> not possible to connect to these ports from the internet.
> 
> But, how secure is this? Is it really what it seems? 
> 
> Thanks in advance,
> Sebastiaan
> 
> 
> 
> --
>   NT is the OS of the future. The main engine is the 16-bit Subsystem
>   (also called MS-DOS Subsystem). Above that, there is the windoze 95/98
>   16-bit Subsystem. Anyone can see that 16+16=32, so windoze NT is a 
>   *real* 32-bit system.
> 
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
Jason Thomas   Phone:  +61 2 6257 7111
System Administrator  -  UID 0 Fax:+61 2 6257 7311
tSA Consulting Group Pty. Ltd. Mobile: 0418 29 66 81
1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/

 PGP signature