This section contains info regarding logging and backdoors for Netware.
Once you are in, you want to leave a way back with supe equivalency. You can use SUPER.EXE, written for the express purpose of allowing the non-supe user to toggle on and off supe equivalency. If you use the cheesy way in (previous question), you turn on the toggle before the admin removes your supe equivalency. If you gain access to a supe equivalent account, give Guest supe equivalency and then login as Guest and toggle it on. Now get back in as the original supe account and remove the supe equivalency. Now Guest can toggle on supe equivalency whenever it's convenient.
Of course Guest doesn't have to be used, it could be another account, like an account used for e-mail administration or an e-mail router, a gateway's account, you get the idea.
Now SUPER.EXE is not completely clean. Running the Security utility or Bindfix will give away that an account has been altered at the bindery level, but the only way for an admin to clear the error is to delete and rebuild the account.
There are several. Here is a list with their location and their purposes:
File Server Error Log
- This log file is located at SYS:SYSTEM\SYS$ERR.LOG
and is typically written to by the operating system. It is an ascii text file, and can
be written to by anyone with read/write access to SYS:SYSTEM. It typically contains info
like bindery open and closes, certain NLMs writing info messages, and of interest to
hackers: intruder lockouts, remote console access attempts (failed or successful), and
other security-related console alerts. Hackers should edit this file if they have hacked
an account with access to SYS:SYSTEM.Volume Error Log
- This is a plain text file located on the root of every
volume and is named VOL$LOG.ERR. Hackers should not pay attention to it unless you are
mounting and unmounting volumes and don't want a record of it. Typically volume errors
are written here.Transaction Tracking Error Log
- Transaction Tracking is a method of
backing out data that was being written to the volume and the server suddenly stopped
writing this data (like a crash of the server). It is plain text, found on the root of
any Transaction Tracking defined volume, and is named TTS$LOG.ERR. Usually only the
SYS volume (and possibly a volume with a SQL database on it, Sybase comes to mind)
is set up for Transaction Tracking. If you're bouncing the server and wish to cover
your tracks, this along with the other logs needs to be looked at.Console Monitor Log
- If a server is running the CONLOG.NLM, everything
that rolls by on the main system console gets written to a log file. If you think your
activities might write info to the console (especially if you've RCONSOLE'd in and are
typing in commands). You may wish to edit this file. CONLOG.NLM will have to be unloaded
first, as it has an exclusive lock on the log file, located at SYS:SYSTEM\CONSOLE.LOG.Accounting
- If accounting has been turned on on a Netware 3.x server,
all logins and logouts will be time stamped into the SYS:SYSTEM\NET$ACCT.DAT file. For
details on accounting, see the next couple of questions.Auditing
- Auditing in Netware 4.x and greater writes its data to files
located in _NETWARE\*.CAF files. Normally found under SYS:, the _NETWARE directory is a
hidden directory, but it also exists on other volumes.Accounting is Novell's pain in the butt way to control and manage access to the server in a way that is "accountable". The admin set up charge rates for blocks read and written, service requests, connect time, and disk storage. The account "pays" for the service by being given some number, and the accounting server deduces for these items. How the account actually pays for these items (departmental billing, cash, whatever) you may or may not want to know about, but the fact that it could be installed could leave a footprint that you've been there.
Any valid account, including non-supe accounts, can check to see if Accounting is turned on. Simply run SYSCON and try to access Accounting, if you get a message that Accounting is not installed, then guess what?
Since it is a pain to administer, many sys admins will turn it on simply to time-stamp each login and logout, track intruders, and include the node address and account name of each of these items.
Turn it off. And spoof your node address. Here's the steps -
If you can't spoof the address (some LAN cards don't allow it or require extra drivers you may not have), just turn off Accounting and leave it off or delete the NET$ACCT.DAT file located in the SYS:SYSTEM directory.
It should be noted that to turn off and on Accounting you need supe equivalent, but you don't need supe equivalence to spoof the address.
Intruder Detection is Novell's way of tracking invalid password attempts. While this feature is turned off by default, most sites practicing any type of security will at minimum turn this feature on. There are several parameters to Intruder Detection. First, there is a setting for how long the server will remember a bad password attempt. Typically this is set to 30 minutes, but can be as short as 10 minutes of as long as 7 days. Then there is a setting for how many attempts will lockout the account. This is usually 3 attempts, but can be as short as 1 or as many as 7. Finally is the length the account is locked out. The default is 30 minutes but it can range from 10 minutes to 7 days.
When an Intruder Detection occurs, the server beeps and a time-stamped message is displayed on the System Console with the account name that is now locked out and the node address from where to attempt came from. This is also written to the File Server Error Log. A Supervisor or equivalent can unlock the account before it frees itself up, and the File Server Error Log can also be erased by a Supervisor or equivalent.
In a large shop, it is not unusual to see Intruder Lockouts even on a daily basis, and forgetting a password is a typical regular-user thing to do. Intruder Lockouts on Supervisor or equivalent account is usually noticed.
The easiest way to check for Intruder Detection is to play with a valid account that you know the password of. Try the wrong password several times. If Intruder Detection is on, the account will be locked out once you try to get back in with the correct password.
Time restrictions can be placed on an account to limit the times in which an account can be logged in. In the account is already logged in and the time changes to a restricted time, the account is logged out. The restriction can be per weekday down to the half hour. That means that if an admin wants to restrict an account from logging in except on Monday through Friday from 8-5, it can be done. Only Supervisor and equivalents can alter time restrictions. Altering the time at the workstation will not get you around time restrictions, only altering time at the server can change the ability to access.
Station restriction place a restriction on where an account can be used. Restrictions can be to a specific token ring or ethernet segment, and can be specific down to the MAC layer address, or node address. The only way around a station restriction at the node address is to spoof the address from a workstation on the same segment or ring as the address you are spoofing. Like time restrictions, only Supervisor and equivalents can alter station restrictions.
Of course you can remove station and time restrictions in SYSCON if you are a Supe equivalent.