Since when is SYS:ETC readable by everyone??? Not on my default NetWare
install! You might want to check your rights at the root of SYS or see if
some knucklehead gave read rights at the ETC directory.
The separate NCF idea is actually pretty good, seeing as how INETCFG can get
kind of stupid sometimes. For example, we're running ATM on the servers
using Novell's ATM stack, INETCFG reeks all kinds of havoc...we had to use a
separate NCF to load/bind the drivers/protocols. Novell is aware of this
issue (seems to be a problem with INETCFG not understanding how ATM works).
Don't know if this happens with NetWare 5 or not. BTW - being on an ATM
network (for us) makes it damn near impossible to sniff the wire. You have
to physically break the connection to get a trace.
I still go back to my original statement - RCONOSLE, although it appears
subject to compromise, it's still difficult to do. The data destruction
threat is more likely than the threat of the system being compromised for
inappropriate access. BTW - if you have a firewall, SPX won't work. If
you're running IP via XCONSOLE (included with NetWare/IP or the older
Flex/IP product), you can easily set up deny rules to prevent telnet
sessions to your NetWare servers. Also, truly truly paranoid people can put
a firewall between their internal net and the NetWare servers, if you're
interested in adding a hop (and some serious latency) into the network in
the name of security ;-).
As for the internal threat, that's easy to deal with from where I stand.
Scare someone into realizing his/her job is at stake and that it's a felony
to compromise computer data or systems, and you should be able to deter the
internal threat somewhat.
-- dcc --
-----Original Message-----
From: Chris Brenton [SMTP:cbrentonat_private]
Sent: Friday, October 09, 1998 11:07 AM
To: BUGTRAQat_private
Subject: More Rconsole stuff
Since we're on the subject of Rconsole and I did not find this in
the
archives...
As of NetWare 4.x, Novell recommends using the Inetcfg utility for
managing networking. If you have "load remote" in the autoexec.ncf,
Inetcfg will try to grab it and add it to Inetcfg's scripts.
The problem here is that Inetcfg saves the Rconsole password to
SYS:ETC
in a file named Netinfo.cfg. All users have full read access to this
directory so anyone with a valid account can view the Rconsole
password.
Given Simple Nomad's post, even if you cut and paste in order to
ensure
that the password is encrypted, it is still extremely vulnerable.
The patch would be to call remote from another NCF file which is
stored
in the SYS:SYSTEM directory. This will at least limit access to only
Admins. This will also prevent Inetcfg from trying to grab it. Of
course
the real fix would be to not use Rconsole. ;)
I've also noticed (with 4.1x anyway) that if you enable Telnet
access to
the server, remote sessions are not logged. Combine this with the
above
and any user can now whack away at the server console without
leaving an
audit trail.
Any known patches for the above would be most cool,
Chris
--
**************************************
cbrentonat_private
* Multiprotocol Network Design & Troubleshooting
http://www.amazon.com/exec/obidos/ISBN=0782120822/0740-8883012-887529
* Mastering Network Security
http://www.amazon.com/exec/obidos/ISBN%3D0782123430/002-0346046-8151850
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:19:11 PDT