Watching the Big Three
After you patch, life with NetWare consists of being
careful about three environments that substantially affect your security:
·
Server environment—Server console and configuration
·
Client environment—Workstations, client software and
configuration
·
NDS (Novell Directory Services) environment
In what can be a hugely complex system, it's useful to
distill all your NetWare security concerns into these three groups. Not
every individual is responsible for each group, but every individual
suffers the consequences if these categories are not tended to. (If you're
"lucky" enough to be the only person in your shop who tends to
all three of these, pat yourself on the back and demand a raise.)
Accordingly, you'll want to figure out who's responsible
for what in your organization—it doesn't do any good for only one of these
subsystems to be locked down.
Server Environment
It's an understatement to say that, when an intruder is able to
access your server console, the battle is lost. If you're new to NetWare,
here's a basic, horrible fact about the OS:
There is no explicit login
to the console. The default access when you boot up amounts to "The
dude who's driving is large and in charge."
Huh? This sounds awfully weird, if you're used to UNIX or
(properly configured) NT. Why would the console offer supervisor privileges
to just anybody?
The answer is, it doesn't explicitly
offer these privileges. Many of NetWare's NLM (NetWare Loadable Module)
tools require authentication before they allow you to perform privileged
operations.
But, because NetWare in its default configuration allows
anybody who is driving the keyboard to load an NLM, it implicitly allows
the driver to perform any privileged
operation that is coded into that NLM.
For example, simply by loading an NLM (and without causing
undue suspicion—you don't have to reboot to do these things), you can
·
Set the administrative password (which would alert the real
administrator that
something's awry)
·
Add an additional administrative user to the system with a
password of your choice (which would not alert the administrator)
·
Snag the entire NDS database (if you're driving a server with
a replica on it) for offline decryption with publicly available tools
·
Commit other mayhem at will
Sound bad? It is. Again, merely by inserting the right
floppy diskette in the drive—or by loading an NLM from a user's directory
on the server—you can, as an untrusted user, be treated as a trusted user
at the console.
Novell offers a partial solution, the SECURE CONSOLE command.
It's a hard call: On the one hand, SECURE CONSOLE protects your servers
from a keyboard interloper who wants to
·
Load NLMs from anywhere but SYS:\SYSTEM
or C:\NWSERVER
·
Gain access to the NetWare debugger (right-shift+Alt+left
shift+ESC), and possibly hand-enter malicious code
·
Change the time to try to break security
On the other hand, SECURE
CONSOLE can be a real pain when you have to do maintenance. Even a
legitimate user (you) can't change the time to correct for clock drift, you
can't add a search path, and you cannot load NLMs from anywhere but the two
system locations. It would be a wonderful thing if you didn't have to reboot the system to disable it.
Unfortunately, using SECURE
CONSOLE is a must if your physical security is at all in
question—if there's even a possibility of an unauthorized person sitting
down at your server keyboard even for a moment.
Physical Security
Here's the obvious: Keep your consoles
(and backup tapes!) behind locked doors. But as with other operating
systems/routers/pieces of key infrastructure, there is usually some point
when your space gets shared, be it with the cleaning people, outside
consultants, or your own folks.
Note
I was once in an IT shop where an application consultant
was invited to set up his office in the computer room—there wasn't any
extra office space. That's Huge Problem #1. Then, the consultant started doing ad hoc
training for users of his application—right in the data center.
Huge Problem #2? He gave out the passcode to the data
center door, and the user was sitting at an NT console merrily playing
Solitaire when the consultant arrived. ("Oh, was that a server?")
Notwithstanding how trusted the consultant was, the user could have been
anybody. All of the data center's physical security was compromised the
instant the consultant was trusted in the data center.
A corollary: Any server that is not
physically secure must not be part
of your production NDS tree. Any machine that isn't
physically secure can't be considered trusted, and any untrusted console
can wreak havoc on your tree. This means new servers that are being set up
on an unsecured workbench; lab machines; test machines, and so on.
Naturally, any switches or hubs that your servers—or
administrative workstations—are connected to also need to be behind locked
doors, particularly in light of how easily NetWare's default remote control
encryption is
defeated. (See the section "RCONSOLE," later in the
chapter.)
Physical security can be a pretty large and ongoing task
(for more on physical security you can refer to Chapter 26, "Policies, Procedures, and
Enforcement)." After you've set up physical security for
your production servers, you need policies, procedures, and regular
checkups to make sure that your secured areas stay
secure.
Securing an Insecure Console
The best thing to do with an idle
console is to use a utility to lock down the keyboard, and only unlock it
if someone authenticates. NetWare 5 has just such a utility, scrsaver.nlm.
It's pretty easy to use; just type
scrsaver help
at the console prompt for on-the-fly directions.
I like to set up the screensaver to kick in and lock down
after four minutes of idle time. (You can see what this looks like in Figure 21.1) The screensaver is not a default action; you must load and configure
the screensaver each
time. You can do this by putting the following line in your AUTOEXEC.NCF:
Figure
21.1. It's a good idea to load scrsaver.nlm upon server startup, so that it
locks down the keyboard when the console has been idle.
scrsaver enable; delay=240
Some folks also like to start the screensaver up as the
last action of the AUTOEXEC.NCF. This way, even if someone does get access to one of the servers right after boot
time, they need to authenticate.
In this case, the last line of your AUTOEXEC.NCF should
look like this:
scrsaver enable; delay=360; activate
Note
Activating the screensaver at boot time is not a sure-fire
way of keeping someone out of your console; an intruder could, at
first-stage boot time, avoid execution of the AUTOEXEC.NCF by typing server -na from the DOS prompt.
NetWare 4 Console Lock
NetWare 4 doesn't have a cool
password-protected screensaver. Novell's considering making one available, and it might
be by the time you read this. Check out the status of
this enhancement request at
http://support.novell.com/cgi-bin/search/tidfinder.cgi?2952871
In the meantime, you can always use the MONITOR.NLM to
manually lock your console down when you're not using it (see Figure 21.2), or get a third-party tool (check the end
of this chapter for product listings).
Figure
21.2. Although NetWare 4's MONITOR.NLM has a lock function, it requires an
administrator to explicitly lock the server, rather than doing so after a
timeout.
RCONSOLE
RCONSOLE, the remote-control tool for
NetWare servers, can be a NetWare administrator's best friend.
Unfortunately, it's not exactly a very secure friend.
The first problem with RCONSOLE is that, by default, its
password is stored
in plain text. If you're an old-style CNE (Certified NetWare Engineer),
your AUTOEXEC.NCF might have a line like
LOAD REMOTE MYPASSWORD
in it. (If you use INETCFG.NLM to configure remote access,
the password is stored in plain text in SYS:ETC.)
Obviously, this is a Bad Thing. You don't want someone
printing out your AUTOEXEC.NCF for troubleshooting purposes, and then
accidentally leaving it around for the entire world to see. Furthermore,
because RCONSOLE sends screens over the network "in the clear,"
someone with a sniffer could watch you scroll through or edit your
configuration file and read your password.
What to do? NetWare has a method of "encrypting"
the REMOTE password (REMOTE ENCRYPT at the server console), but it is
worthless in terms of secure encryption. In less than a second, you can use
a DOS-based, publicly available tool, REMOTE.EXE, to break even the largest
passwords encrypted this way. Don't use REMOTE ENCRYPT; it will do nothing
but give you a false sense of security.
In short, using RCONSOLE over potentially untrusted
networks is a really bad idea. If you really must use it, make sure that
·
Your data link and network infrastructure is secured from
eavesdropping.
·
The two server-possible directories in which the password
might be stored are unreadable by anybody but Admin-equivalents
(directories such as SYS:SYSTEM
and SYS:ETC).
RCONJ, the "pure Java" version of RCONSOLE, has
similar problems, and should be treated with similar care. If you are
serious about secure remote control of the console—and you should be, if
you are responsible for an enterprise's security—see the end of this
chapter for third-party tools that are much more secure.
Network Computing's
October 16, 2000, issue has a detailed workshop by Kevin Novak that
discusses RCONSOLE and RCONJ, available at http://www.networkcomputing.com/1120/1120ws1.html.
UNIX-Compatibility Utilities
Speaking of plain-text remote control utilities, XCONSOLE, the Telnet server for
NetWare, is no safer than RCONSOLE. It uses plain-text Telnet for the
authentication, and either Telnet or the X protocol—both non-encrypted
protocols—for the session data. You should avoid XCONSOLE as well, unless you're
absolutely sure that your infrastructure is un-tappable.
The same goes for FTP. Although FTP is arguably less of a
risk than RCONSOLE if non- administrative users are ftping, FTP is just as
grave a risk as RCONSOLE if administrative users ftp in to the server. All
passwords for FTP are sent in the clear. Avoid, avoid, avoid.
As with any service, if you have no pressing business
reason for using the service, you should probably use UNICON.NLM to
deconfigure both of these tools(see Figure 21.3).
Figure
21.3. Use UNICON, NetWare's UNIX Services Configuration tool, to stop
unwanted UNIX-compatibility services from running.
WWW Services
In the past, NetWare 4.1 and IntranetWare shipped with the
NetWare Web Server—not the Netscape Enterprise Server. The Web server included
a PERL.NLM, that allowed
arbitrary execution of code on the server—a very bad thing indeed.
Although this hole has long been plugged in newer versions
of the Web server, we mention this because the Web server is not part of the NetWare 4 core OS and thus not
part of the OS's service pack. You need to go out and separately update it
(or, upgrade to NetWare 5).
Finally, as with any Web server, you'll want to
search-and-destroy any sample scripts. Leaving them there is simply asking
for trouble.
NETBASIC.NLM
Get rid of NETBASIC.NLM unless you
have a pressing need for it. There are several attacks involving NETBASIC.
This is particularly true of NetWare 4, which doesn't have NetWare 5's
SCRSAVER.NLM. Even if you've used the SECURE CONSOLE
command, NETBASIC.NLM allows someone who accesses the console to
·
Drop to a NETBASIC shell
·
Copy untrusted NLMs into the SYS:SYSTEM
directory
·
Copy the NDS files from the hidden SYS:SYSTEM\_NETWARE directory to arbitrary locations on the file
server
·
Perform trusted file operations that could potentially make
your life miserable
Again, if you've got NetWare 5 and SCRSAVER.NLM (or
NetWare 4 and a third-party utility), this isn't as
hot an issue, but it is still due diligence to remove this tool from the
server unless you need it.
TOOLBOX.NLM
Toolbox is one of the most useful
administrator tools available for NetWare. It even attempts to keep its
operations secure—you must authenticate to the tree before it will obey
your commands. However, Toolbox is frequently used in batch files, and
administrators tend to save authentication information to the Toolbox
database. (For example, many administrators use Toolbox to reboot the
server, purge limbo blocks from volumes, and so on.)
In a nutshell, an intruder who's familiar with Toolbox
will likely type
AUTH LOAD
at the console. If an administrator has previously done an
AUTH SAVE, then the intruder can use Toolbox's functions without
logging in.
Basically, if you're doing AUTH SAVEs, the same rules apply to Toolbox as were
previously described for NETBASIC. If a screensaver is unavailable, the
potential amount of damage is huge. If a screensaver is in use, AUTH SAVE has a more acceptable level of risk.
Server Environment Parameters
There are publicly available tools that can spoof NCP (NetWare Core Protocol) packets—thus
making hijacking a session a real possibility. To prevent this from
happening to your users, you'll want to set your server's NCP parameters to
include packet signature, packet length, and packet component checks.
For example, to get the highest level of NCP security,
you'd type
SET NCP Packet Signature Option = 3 SET Reject NCP Packets with bad components = ON SET Reject NCP Packets with bad lengths = ON
at the server console. (NetWare 4 users have to put these
in the AUTOEXEC.NCF as well.)
Note
You will definitely want to do tests in your environment
before you enable a packet signature level of 3. Level 3 means, "Don't
communicate with ANYBODY if they don't sign their packets." This might
be a bad thing if you haven't enabled your clients'packet signature
options. (Although, Novell's latest client defaults to "will-do,"
as discussed later in the
chapter.)
Furthermore, you will want to test your servers to see how
they'll hold up under the load with a signature level of 3. The amount of
processing dedicated to cryptographically signing packets is non-trivial.
Bindery Context
A bindery context is only
necessary on a server if its third-party software doesn't understand how to
communicate via NDS. Unfortunately, there are still NetWare utilities that
don't. Upgrade them, if you can, to utilities that are NDS savvy because
there are publicly available tools that attack based on bindery contexts.
(See the "Guest and Other No-Password Users"
section for an example of this.)
NetWare servers default to having a bindery context; get
rid of it by typing
set bindery context=
(That's right, there's nothing to the right of the equal
sign). The system will warn you that bindery services have been disabled.
If you don't need 'em, this is a good thing.
Client Environment
You'll want to stay native with your NetWare client—that
is, use Novell's client, not Microsoft's. Microsoft's client doesn't support
packet signing—neither advisory (Level 2) nor mandatory (Level 3).
The NetWare client defaults to the same thing that the
server does—Level 1: "Perform packet signatures only if the other side
requires it." So, if you're using the latest version of the NetWare
client, you won't have a problem setting the server to a mandatory
packet-signature level. Still, if you're serious about requiring packet
signing, you'll want to set your clients to Level 3.
Again, make sure to test
any parameter changes in your environment before rolling them out. As
advisories come out, you might find yourself changing a large number of
client workstations at a time. ZenWorks or other desktop management can
make this easier and quicker.
Windows: The Weakest Link
Without getting into operating system holy wars here,
let's just say that you need to pay special attention to Windows
workstations where administrative users log in. The PWL files (in Windows
9x) and the SAM (of Windows NT/2K workstations) are very easily cracked.
This is fine if you only log in at workstations that have
tight physical security. But what about when administrators need to log in
from the field? If you must do this, consider using some sort of encrypted
remote control, rather than using the desktop of the workstation that you
are working on (for example, Citrix, PCAnywhere, and so on). The last thing
you want to do is leave your administrative NDS password—and username—as a
dropping on the user's highly insecure workstation.
Also, check out Chapter 18, "Trojans," for
information on protecting your workstations from programs that can hijack
login information. Because it's likely that you're in a NetWare
environment, you might want to use ZENWorks to assign policies that lock
down your client workstations.
Finally, if you have public terminals, or a Citrix remote
login system, you will definitely want to disable the "Advanced"
function of the client. The browse functions of the Advanced tab provide
more information to an intruder than you want to disseminate. (If you do
this, you'll want to enable "context-less" login, unless you want your users typing .myname.mydepartment.mylocation.myorg as
their username.)
Novell Directory Services (NDS) Environment
Any directory service (DS) needs to be maintained from birth and throughout its life.
Neglect and oversight are the main reasons a DS fails—whether in the
security space, or simply from the functionality perspective.
A Good Start: Intruder Detection
Intruder detection is a way of making NDS count the number
of failed login attempts within a certain time frame—and lock the account
for a certain amount of time if the number of failed logins exceeds a
certain limit.
Let's look at an example. An intruder writes a program to
do a dictionary or brute-force attack on a given user's login, say, user
name "JOE," using the authentication calls that are available via
the NetWare API. If there is no intruder detection, the intruder can cycle
through thousands of possible passwords in a relatively short time.
If the admin has enabled Detect intruders, as shown in Figure 21.4, the following happens: Because the
intruder is trying more than seven passwords in a 30-minute period, the
account is locked for 15 minutes. All of a sudden, rather than being able
to cycle through thousands of passwords, the intruder can only cycle
through seven before the account gets locked. This is an extremely good protection
against systematic, online, real-time password cracking.
Figure
21.4. You'll want to use NWAdmin to enable intruder detection on each
organizational unit in your tree.
The bad news is intruder detection is not enabled by
default. You'll need to go into NWAdmin and enable it per OU
(organizational Unit) as part of your "new tree SOP (Standard
Operating Procedure)."
User Names: Admin
Admin is the first user created in a new NDS tree. The
first thing a lot of folks do after installing a new NDS tree is to rename
the Admin user to something nonobvious and put Admin into a nonobvious
container (like .GSmith.abc.myorg.)
This container should be stored separately from that of regular users.
This is a good measure, as far as attacks from outside
your organization go, but it's not
foolproof. As we've discussed elsewhere, lots of security problems come
from the inside. A temp worker—intern, air conditioning repair person, or
receptionist—might see an administrative user log in (like, um, YOU while
you log in to solve a problem for this person)—and thus gain information
about an administrative user's login name. Perhaps it's not THE Admin user,
but it's an Admin user—which is all
potential crackers are looking for. So, move the Admin user if you want,
but know that this is not a cure-all.
Naturally, you'll want to make sure that all administrative users have very good passwords. Use NWAdmin to make sure
that administrative users have policies in place to require a password of
sufficient length.
Guest and Other No-Password Users
Unless you have a need for a Guest account—and most
organizations do not—delete the Guest user. (NetWare 5, happily, does not
supply a Guest user by default when
you install a new NDS tree.)
If you're administrating an existing NDS tree, you will
want to check for users with no passwords on a fairly regular basis (or,
use NDS auditing software, discussed later in the chapter). Even if these
accounts have NO special privileges, they will allow an attacker to browse
the tree and gather an intruder's best friend, more information. If they
belong to a container that's been given special authority (a bad idea—see
the section "Unintended Consequences of Container
Rights" ), suddenly you've got a problem on your hands.
How do these no-password accounts "show up?"
There are tools (for example, backup, anti-virus, print servers) that
generate accounts so that the program can log in to the tree without
operator intervention. You'll want to make sure that these accounts do NOT
allow an interactive login—at least, not without requiring a password. Try
it; if the tool account allows you to log in, restrict the account to
certain network addresses only—the network addresses of the station that
runs the program, such as the anti-virus console, the print server, and so
on. (Some of these types of tools don't allow you to specify a password, so
changing the password won't fly.)
You—and an intruder—can find accounts with no passwords,
if you have a bindery context set (see why a bindery context isn't a good
thing?), with the freely-available CHKNULL program. A good NDS auditing
tool will also find these.
Note
There is literature out there that implies that you can
also use NLIST to find null password information. This is not the case.
NLIST will show you what the policies are for users—that is, if a null
password is allowed, and what the minimum password length is. These are
useful things to know (because you don't want a user to have too short of a
password, or to be allowed to blank it), but be aware of the difference.
Enforcing User Authentication Policies
NetWare has a bunch of good password management built into
NDS. Each site is different, but typically, enabling the password
management can greatly increase your
security. Using NWAdmin, you can set
·
Whether a user can change his password
·
Whether a password is required
·
The minimum password length
·
Whether periodic password changes are required, and how many
days are required between changes
·
The number of times the user can procrastinate a required
periodic password change before getting locked out (called grace logins)
·
Whether unique passwords are required
These policies are delegated per
user, not as part of a group. You'll want to use NWAdmin's Details
on Multiple Users feature (see Figure 21.5) if you want to change the policies of many
users at once.
Figure
21.5. If you are changing the password policies of a bunch of users at one
time, use NWAdmin's Details on Multiple Users options.
If your organization believes that passwords are too
easily compromised (by users writing them down, sharing them, and so on), you can investigate
alternative login methods, such as biometrics. The Novell Modular
Authentication System (NMAS) supports third-party authentication such as
fingerprinting, SecurID, and so on. You can read more about NMAS at
http://www.novell.com/products/nmas/details.html
Understanding and Applying NDS "Best
Practices"
The Novell Directory Service is the heart of your NetWare
network. Servers, accounts, file systems, certificates—everything—relies on
NDS being configured correctly. If you or your system administrators don't
fully grok NDS, or take short cuts, you are likely to make mistakes that
will leave you vulnerable to
attack.
Note
There is a huge body of work about NDS—most of it,
naturally, written by Novell. If you are shaky on your NDS understanding,
or want to make sure you fully understand it, a good place to start is the
Novell Research AppNote, "Learning and Applying the Rules of NDS
Security," found at http://developer.novell.com/research/appnotes/1997/august/02/index.htm.
Unintended Consequences of Container Rights
Container rights are one of the most convenient NDS
features—you apply rights to an organizational unit (OU), and the rights
flow down so that children containers and their objects inherit these
rights. Convenient—yet dangerous.
With many objects and subcontainers in a tree, it can be
difficult to visualize just what the
consequences of inherited rights can be.
One common—and bad—practice that some IT shops have is to
link administrative rights to an OU, for example, the "SysAdmins"
OU. They figure, "Anybody in this OU is an administrator, so what's
the harm?" The answer is, "It can be plenty of harm."
For example, a recently discovered problem (http://Feldman.org/zen)
with the ZenWorks workstation manager allowed any workstation
object to assume the rights of its
container—without a user being logged on. This made it easy for an
untrusted user to get sneaky and run programs with those rights. In the
case of a container that was assigned Admin rights, the workstation assumed the Admin rights—because it
was part of the container. All of a sudden, the intruder had admin rights,
too.
If the container had not
been given special rights, the damage of this exploit would have been
minimized. Lesson: Don't assign sensitive rights to a container, ever.
What are sensitive rights?
Some of them include
·
Security equivalencies to administrative users
·
Any rights to the root of any volume
·
Any rights to SYS:\etc
·
Any rights to SYS:\system
Use groups instead of containers to assign these types of
rights. This is a good administrative practice. Because a group is a
central point of administration, the potential for admin error is
decreased.
There's nothing inherently wrong with grouping; the
problem only has to do with inheritance—and
thus, containers. Although Novell (and other literature) will tell you that
problems with inheritance can be handled with an IRF (Inherited Rights
Filter), consider the previous problem. Would an IRF block rights to workstation objects in the same OU as the administrative users? No! An IRF
"flows down" through the tree. Objects in the same container get the same rights as the user in
the container.
In a nutshell, inheritance can be a tricky beast. Be careful.
NDS Auditing Tools
NDS can be a big and complex beast—the fact of the matter
is that any good directory service is. Your best bet if you are serious
about keeping an eye on NDS is to invest in third-party auditing software.
NWAdmin enables you to do searches on various NDS attributes (for example,
the "Security Equivalent to Me" search shown in Figure 21.6, which reveals all the users that other users
are equivalent to). However, search on every single property from NWAdmin
can be cumbersome and/or impossible. I do not recommend Novell's AUDITCON
for anything but a very small organization.
Figure
21.6. NWAdmin will enable you to do basic property searches, but isn't
sufficient for hardcore auditing.
It's beyond the scope of this chapter to review every
auditing tool available, but the following are a sampling of what's available.
AuditTrack
Manufacturer: WebTrends
URL: http://www.webtrends.com/products/adttrk/intro.htm
AuditTrack allows auditing and reporting of server access
and file manipulation activity.
Includes predefined audit rule sets; additional audit
instruction sets that define who and what to monitor can also be defined.
Options allow for the auditing of files, workstations, users, or user
groups. Alarms can be configured to notify the administrator if suspicious
file activity is taking place, or if a security breach occurs. AuditTrack
also has a custom reporting and graphing facility.
AuditWare for NDS
Manufacturer: Computer Associates
URL: http://www.computerassociate.com/products/auditware_nds.htm
A Windows-based advanced NDS reporting and security
analysis tool. Generates comparison,
analysis, security, and documentation reports.
Can locate potentially hazardous stealth users that cannot
be seen because the Browse privilege has been filtered out. Can also locate
"dangerous" users—those who have supervisor privileges but do not
meet minimum password requirements.
bv-Control for NDS
Manufacturer: BindView
URL: http://bindview.com/products/bv-Control/NDS/index.html
A tool to automate the analysis and documentation of
server and NDS configuration; it looks for improperly configured servers
and out-of-date or conflicting executables (including EXEs, NLMs, services,
and device drivers) that can cause your servers to perform poorly and
crash.
JRButils
URL: http://www.jrbsoftware.com
Command-line-based utilities for the rugged individualist
who lives for the CLI. Users can use these utilities to perform operations
on objects selected via wild cards, container,
membership of a group, or via a list in a file. When displaying
information, filters can be applied. Can be used for automation of
operations such as mass user creation, customization, deletion and for
performing security checks.
Kane Security Analyst
Manufacturer: Intrusion.com
URL: http://www.intrusion.com/Products/analystnt.shtml
An assessment tool that claims to provide centralized
audit data of key Windows NT and Novell NetWare security features. It
evaluates password strength, access control, user account restrictions, as
well as having a data monitoring facility. Provides report card summaries
and more verbose reports.
LT Auditor+
Manufacturer: Blue Lance
URL: http://www.bluelance.com/ltauditor/default.html
A Windows-based intrusion detection/audit trail security
software solution. LT Auditor+ supports NT and/or Novell networks. Alerts
can be configured to respond to specific events either system-wide or at
particular workstations; it also provides off-site paging and email alerts via an SNMP console.
Commercial Secure Remote Control Products
SecureConsole for NetWare
Manufacturer: Protocom Development Systems
URL: http://www.serversystems.com/frames/sc_cs.htm
A native Win32 application, which provides single sign-on
to a NetWare console. It does this by checking a user's current NDS
credentials and looking them up in the SecureConsole database. Standard NDS
security features such as secure password authentication, single sign-on
and intruder lock out are supported. Generates SNMP alerts to one or more
network management consoles when it detects attempted unauthorized access
or other abnormal server conditions.
Secure Remote Console
Manufacturer: AdRem Software
URL: http://www.adremsoft.com/arcon3/index.htm
Offers 128-bit encrypted remote console operations. Access
control is available that allows users and groups of users to be permitted
specific console commands and
server screens.
Useful Freeware
Most of the following is available from http://www.netwarefiles.com,
a repository of a bunch of free or shareware utilities.
BURGLAR.NLM
A venerable tool, Bart Mellink's BURGLAR.NLM creates a
supervisory user of your choice. You need access to the server console and
about five free nanoseconds to do this—reason #9,285 to secure your server
consoles from unauthorized personnel.
HOBJLOC.NLM
Novell Consulting's answer to crackers who create
"hidden" users, that is, users invisible even to administrative
users. Finds them so that you can root them out. (Commercial auditing tools
do this too, but this is free.)
Pandora
"The Leatherman" of NetWare cracking tools,
written by Simple Nomad and
friends. Runs under Linux as well as Win32. Includes offline NDS cracking
tools—so that you can audit your NDS passwords—as well as online denial of
service tools. You can find both Pandora and enough NetWare-related
documentation to feed a family of four for a month at http://www.nmrc.org.
As of this writing, the NMRC is probably your best bet for up-to-date
information and code from the underground.
REMOTE.EXE
Written by TheRuiner, Instantly
cracks even the longest of "encrypted" remote console passwords.
Want to see some fun? Type "remote encrypt" at the server
console, and enter the longest password you can. Then take the remotely
encrypted string, and feed it to REMOTE.EXE.
985FF510136420112F1D366A207616903FBEEDEBCDCDDCCCCDCCBDB4CCBCCDCD4BCDBB03
is instantly decrypted to
THEREISNOREMOTEPASSWORDSECURITY
It's a small and useful demo tool that turns even the most
doubting of Thomases into a true believer in REMOTE's lack of real encryption.
SETPWD.NLM
Developed at the University of Salford in the U.K., P.R.
Lees'SETPWD.NLM allows you to set anybody's password from the server console.
Is this reason #9,286?
|