------------------------------------------------------------------- SECURTY2.DOC -- 19980114 -- Email thread on NetWare Security Issues ------------------------------------------------------------------- Feel free to add or edit this document and then email it back to faq@jelyon.com Date: Tue, 20 Aug 1996 21:49:50 -0700 From: Bill Subject: Re: Disabling the debugger Password protecting the monitor console has no effect on the debugger. You can, however, issue the "SECURE CONSOLE" command, which will not only prevent the debugger from being used, but will also prevent NLM's being loaded from anywhere other than SYS:SYSTEM. It also removes DOS, thus preventing anyone from exiting out to DOS after issuing a DOWN command. The only way to "un-secure" the console after doing this is to down the server and reset or power off. Placing "SECURE CONSOLE" at the end of the AUTOEXEC.NCF will go a long way in keeping people from screwing around with your server. I must stress that this is no substitute for physiical security of the box, along with a well communicated policy of termination and prosecution for violators. ------------------------------ Date: Thu, 22 Aug 1996 13:48:43 EST From: hal katzen Subject: >I am a security officer and auditor, i am looking for good audit >tools for novell v3.11. You may want to consider Bindview or Audittrak also, The following are for Netware, but much of the audit programs included can be used generically to audit any LAN. I have used the one for Netware 3.x, and thought it was very helpful. The chapters on auditing include sections on - audit procedures and overview, technlogy controls, operating system, system access, system operations, backup and recovery, and more. NetWare Security: Configuring and Auditing a Trusted Environment (3.x) #164-000030-015 Novell Research, In USA - 800.377.4136 cost me $15.00 (this was well worth the money) Building and Auditing a Trusted Network Environment with Netware 4.x. This one can currently be found on-line on Novells experimental on-line press site. http://occam.sjf.novell.com:8080/nw410.english/trustenu ------------------------------ Date: Wed, 2 Oct 1996 08:23:05 EST From: Sam Martin Subject: NW Hack Attack and NCP packet signatures Here is a post which I found interesting , ... not exactly the footprints of a gigantic hound,... but still not entirely devoid of interest, suspect there are others out there who might agree. I preface it w/a discussion of NCP Packet Signatures. What is an NCP Packet Signature: A security enhancement to protect a client by preventing packet forging. How do I turn it on: At the server console and autoexec.ncf SET NCP PACKET SIGNATURE OPTION = <0,1,2,3> At the workstation net.cfg dos requester signature level=<0,1,2,3> Options: Number Results 0 Client does not sign packets 1 Client signs packets only if server requests it (server option is 2 or higher) 2 Client signs packets if server is capable of signing (server option is 2 or higher) 3 Client signs packets and requires the server to sign packets Signature levels for client and server combine to determine an effective packet signature level. There is a performance hit for some combinations. Client Server = WS 0 1 2 3 0 No sig no sig no sig no login 1 no sig no sig packet sig packet sig 2 no sig packet sig packet sig packet sig 3 no login packet sig packet sig packet sig (Hope this space delimited table makes it thru our mailer) >>>FORWARDED MESSAGE >From owner-bugtraq@NETSPACE.ORG Sat Sep 28 00:20:01 1996 Date: Sat, 28 Sep 1996 03:13:13 GMT From: Greg Miller Subject: An attack against the NetWare login protocol. To: Multiple recipients of list BUGTRAQ I have successfully implemented this attack against a 3.12 server, the exploit is available on my web page in the Novell section. A breif explanation of the attack follows: An Explanation of NOCRYPT.EXE Greg Miller September 26, 1996 The NetWare login protocol consists of three packet exchanges between the server and the client. First the client sends a request for a login key, the server generates a random eight byte value and sends it to the client. Then the client sends a request for for the user ID of the user loging in, the server looks up the user ID in the bindery and sends it to the client. Finally, the client computes X=hash(UID,password) and Y=hash(X,login key) and sends the result to the server. The server retrieves X'=hash(UID,password) stored in the bindery and computes Y'=hash(X',login key). If Y=Y', the client is granted access as the user. If both the client and server agree to use packet signatures, both parties then compute Z=hash(X,c) (where c is some constant value) which they will use as a shared secret for authentication. The following chart gives a graphical representation of the protocol: CLIENT SERVER Request Login Key -----------------------------> <----------------------------- Login Key Request User ID -----------------------------> <----------------------------- UID of client Compute Compute X=hash(UID,password) X'=hash(UID,password) Compute Compute Y=hash(X,login key) Y'=hash(X,login key) Request Authentication -----------------------------> If Y=Y', Access granted Compute Z=hash(X,c) Compute Z=hash(X,c) When a user Alice logs in, an attacker Bob can interrupt this protocol sequence and gain access as Alice without knowing her password. In order for the procedure to work, Bob must be on a network where he can observe the traffic between Alice and the server, and Bob must be able to respond to Alice's requests faster than the server. First Bob sends a request to the server to login, and the server sends Bob a login key R". Then Alice requests a login key from the server, Bob sees the request and spoofs a reply as the server which sends Alice R" as her login key. The server receives Alice's request and sends her R as her login key, when Alice receives R she will discard it as a duplicate. Alice requests her UID from the server, and the server responds with her UID. Alice computes X=hash(UID,password) and Y=hash(X,R") and sends the result to the server. The server computes Y'=hash(X,R), since Y' is not equal to Y, Alice is denied access. Meanwhile, Bob saw Alice's Y submitted to the server, he retrieves this value from the network and sends it to the server for authentication as Alice. The server computes Y"=hash(X,R"), since Y = Y" Bob is granted access as Alice. Bob requests not to sign packets, if the server does not require all clients to sign packets, then Bob is allowed to masqurade as Alice. Alice Bob Server Requests Login Key R" -> <- Sends R" to Bob Requests Login Key R --------------------------------> <---- Sends R" to Alice <-------------------------------- Sends R to Alice Receives R" first Discards R as a duplicate Requests UID for Alice --------------------------------> <-------------------------------- Sends UID of Alice Computes X=hash(UID,password) Computes Y=hash(X,R") Sends Y to the server --------------------------------> Computes Y'=hash(X,R) Sees Y and retrieves it. Y != Y', access is denied Sends Y to authenticate -> Computes Y"=hash(X,R") Y"=Y, access is granted Refuses to sign packets If all clients are not REQUIRED to sign packets, access is granted. There may be a second attacker, Joe, waiting for Alice to log in without using packet signatures. As a result, Joe can highjack Bob's connection as Alice. ------------------------------ Date: Fri, 25 Oct 1996 09:35:08 -0400 From: Dick Cook Subject: Re: Hiding REMOTE.NLM password in autoexec.ncf >I vaguely remember reading somewhere about how to write your >autoexec.ncf such that the RCONSOLE password is not visible. You can encrypt the password in NW 4.1. Using: load REMOTE ENCRYPT password this returns an encrypted password (long string of alpha-numerics) that you would use in the .NCF file. Eg: load REMOTE -e "new encrypted password" There is a TID on this at Novell's website http://support.novell.com/cgi-bin/search/tidfinder.cgi?1001567 I though that the docs said something about the encrypted password being unique per machine (ie if you used "billgates" as your password on different servers, each would return a different string of nonsense) ------------------------------ Date: Tue, 26 Nov 1996 16:34:17 -0600 From: Joe Doupnik Subject: Re: Rconsole >Yes you can, and the encryption scheme used on the password sent over the >wire is a simple substitution cipher, so if someone can capture your >packet stream while you establish a RConsole session, it takes VERY little >effort to work out the console password. And the contents of the server >console are sent back to the workstation uncompressed and unencrypted, so >don't edit your autoexec.ncf (if that's where Rconsole is loaded from) >over the wire, if you have the least suspicion that your cable can be >tapped. > >Remote Encrypt would be a step in the right direction, if it would work >with INetCfg, but until Novell or someone else comes out with a Rconsole >version that's secure (and Novell Rconsole isn't) use it sparingly or not >at all. > >It should be using the same password encryption scheme as login does, and >the across the wire stuff should be compressed at least. Novell's last >comment I heard on the subject was "It's under advisement" > >So it should be. ----------- Adding two cents: 1) I delete xconsole.nlm as a tragedy waiting to happen out of my control. 2) Fortunately ODI is designed to permit loading series (en passant) encryption/decryption while handling packets. Not much has been done in this area, but it is untrue that nothing has been done (English is wonderful). Facts of life are encrypting packets in software is horribly expensive and causes headaches from PC Magazine articles reviewing server performance. Joe D. ------------------------------ Date: Tue, 10 Dec 1996 09:09:49 -0600 From: Joe Doupnik Subject: Re: Special access attributes of PUBLIC under 4.1 >I decided that I would like to keep the students out of the public >directory, and give them a stupub directory with just the applications >I wanted them to have access to. > >I have taken the Public object out of the trustee list for the SYS:\PUBLIC >directory, students still have access. I specifically took all access to >the directory away from the group STUDENT, they still have access. I used >grant to take away access from the files within the folder, students still >see them! I even got bold and used an inherited rights filter for the >group student on the Public folder but students still can see the files. > >So I give up. Does anyone have any information on what is special about >sys:\public and how to change it? > >What is the implication of ROOT and my O.OU being trustees? -------- I dunno. While I remove most .exe files from sys:public to keep tiny fingers away from matches I otherwise leave the directory in a normal state. It's much easier to upgrade and maintain that way. You seem to be fixating on rights to specific items such as users and groups. I suggest you step back and look at rights from the tree root on down, the inherited stuff, particularly rights granted to the container object. Joe D. ------------------------------ Date: Mon, 30 Dec 1996 17:28:31 -0600 From: Joe Doupnik Subject: Re: Securing against hackers Those interested in network security, including how NW 3 and 4 approach the problem, and who aren't intimitated by some math symbols on pages, might be interested in obtaining a copy of the book "Network Security, PRIVATE Communication in a PUBLIC World," by Kaufman, Perlman, and Speciner, Prentice Hall, 1995, ISBN 0-13- 061466-1, around US$45. Ms Perlman is also known to dabble in things like routing, NLSP in particular, when working for Novell. This book gets rather technical while pretending it's all just good fun. This is a "what and reasons why" technical discussion of encryption and authentication written for the non-specialist, but not about how to configure a server (it's from Prentice Hall not Novell Press). Joe D. ------------------------------ Date: Fri, 3 Jan 1997 09:13:38 -0600 From: Joe Doupnik Subject: Re: Bind Question >Anyway, I was looking at their autoexec.ncf files and noticed that they >have 802.3 and ethernet_II being loaded. At my last job, I brought up 40 >different servers using only ethernet_II for ipx and ip. Had no problems. >I know that the 802.3 is not needed because ethernet_II will handle ipx and >ip. >load tcpip You forgot to explicitly load snmp with private passwords, and hence tcpip autoloaded it. Your system is open to inspection by the world. ------------------------------ Date: Mon, 13 Jan 1997 09:43:53 GMT+10 From: TONY OAKLEY Subject: Security on NW3.11 >>It's not easy for me to change 200 pc's net.cfg that have there >>hard drive locked with pcLockout. > >I'd like to know more about this "PCLockOut". Does it write-protect >the HDD? Yes, check out http://www.widewest.com.au/aspa/html/soft025.htm or email:pcplus@pcplus.com.au ------------------------------ Date: Sat, 8 Mar 1997 10:43:15 -0600 From: "Mike Avery" To: netw4-l@ecnet.net Subject: Re: Internet fire blocks >I know this is off the 4.1 subject a bit, but we are looking into >setting up an ip firewall and web server DMZ zone type architecture. >Has anybody heard about the PIX system? No, but I've become more interested in this sort of product of late, so I'd be interested in what information you could provide. Here are some alternate products. Ukiah Software http://www.ukiahsoft.com has a NLM based firewall that also does network address conversion and ip/ipx gateway functions. It's not bad at all. FTP Software has one also. http://www.ftp.com BSDI software has a Unix based system that can act as a firewall, router, ip/ipx gateway, and act as a ftp server and www server, dns host, and so on. Microtest has a possible product also, depending on your needs. Look on their home page http://www.microtest.com/webetc Also, Gauntlet has a free Linux version, with source code, of it's firewall. More information can be had from the comp.security.firewalls ------------------------------ Date: Mon, 17 Mar 1997 18:59:36 -0600 From: Joe Doupnik Subject: Re: Novell server as "firewall" using IPX >At our University, we have set up the 2 separate networks, ie Admin >and Academic and both partitioned off at the routers. > >What had happen with the TCP/IP network is that if the Academic users >want to access the Admin network, they have to log into a Linux box >and if the login is OK, then the Linux box would allow the user to >access the Admin systems. > >We want to do the same thing using IPX. Could a Novell server handle >this, ie log into Novell server and if OK, then allow the access to >the Admin network. --------------- I'm not clear on what you think you are defending against. Certainly that Linux box is a security risk rather than enhancement, and what's worse is passwords over regular telnet are plaintext on the wire. Novell has a far better scheme. Allow logins from only certain users and if desired from only certain networks and/or stations. The traffic on logins is encrypted both ways. Once logged in NetWare security is effective in keeping people away from areas they ought not be in. Unix security of this kind is a joke. There is no precondition login via IPX such as you summarize. Each server is independent of the other for that work. NDS is spread over the top so a secure login permits access to and from only the places the manager has allowed. That means NDS imposes the conditions at all times, not by trusting one piece of the network. NDS is not aware of routing pathways, so electrical connectivity must exist before NDS can deal with requests. I suggest the high level managers be clear about what they mean by security and isolation, and dig into the manner by which it is ensured. That should include your real routers as well. Joe D. ------------------------------ Date: Wed, 19 Mar 1997 10:26:58 -0600 From: Joe Doupnik Subject: Re: One Time Password and NetWare >Our university is looking at implementing an OTP (one time password) >system for various servers/users. A search on the FAQ and on the Web has >brought up very little with regard to Netware. > >I would appreciate any pointers/information on solutions in the Netware >3.1x and 4.1x environments. ------------ You are discussing an entirely different cryptographic methodology than NetWare provides for authentication. NW does not have provision for third party authentication procedures. Joe D. --------- Date: Wed, 19 Mar 1997 17:29:44 +0000 From: Richard Letts Subject: Re: One Time Password and Netware >Our university is looking at implementing an OTP (one time password) >system for various servers/users. A search on the FAQ and on the Web has >brought up very little with regard to Netware. > >I would appreciate any pointers/information on solutions in the Netware >3.1x and 4.1x environments. OTP systems are useful if you're logging into the network using an unencrypted username/password. Since 3.1x and 4.x all use encrypted passwords you don't need a OTP system for this. --------- Date: Wed, 19 Mar 1997 13:32:41 -0700 From: Jason Green Subject: One Time Password and Netware -Reply There is a new firewall product from Ukiah Software called NetRoad Firewall that runs on a NW 3.X or 4.x server that supports OTP using MD4 or MD5 authentication. You can download an evaluation copy or find info at their web site: www.ukiahsoft.com ------------------------------ Date: Tue, 25 Mar 1997 11:24:02 +0000 From: Richard Letts Subject: Re: Can Firewalls be set up?? >>You want to learn about TCP/IP firewalls, go to NEWS and investigate >>the existing groups dealing with that topic, or consider hiring a >>consultant. There is no "firewall" NLM for NW and NW isn't designed to >>do that job. Firewalls are not a single object but rather a whole body >>of software and management techniques, ranging from simple to very >>elaborate. As such they are outside the pervue of the list's topics. > >Thanks, Joe! I'll investigate that option. > >But what about my other question... Is there a nice, neat way to filter >people from using the internet in NW 3.12 (ex. SAP filtering ala NW 4.1x)? Setting up a firewall is NOT for the faint of heart and people who have little interest in picky details (as it's these which hackers exploit) If people are interested in books on the topic, then I reccomend the "Building Internet Firewalls" by Brent Chapman. This has some good diagrams on protocols, their characteristics and how to block/filter/proxy them ------------------------------ Date: Wed, 26 Mar 1997 09:09:06 +0000 From: Richard Letts Subject: NetWare: New Border Services Product Outlined (fwd) I've just read the following announcement, which might be of interest to NDS sites. I've not looked at the product and can't comment on it's security / features, this is just a press-release Richard Letts >>>>> ---------- Forwarded message ---------- FOR IMMEDIATE RELEASE March 25, 1997 Novell Extends Corporate Networks to the Internet, Outlines New Border Services Product Novell's Border Services to Focus on Security, Manageability and Performance and the *Border* Between the Intranet and the Internet OREM, Utah, -- March 25, 1997 -- Novell*, Inc. today announced key network solutions for business intranets and the Internet. This year, Novell will deliver a new *border services* product to enable businesses to extend their private corporate networks across the public Internet while retaining the security, manageability and performance of their current network. Novell also outlined additional solutions to be delivered over the next twelve months including Novell Distributed Print Services* (NDPS*), Novell Replication Services* (NRS), Java Application Environment for IntranetWare (JAE), and Moab, the next major release of IntranetWare*. *Novell is focused on delivering the products its customers need more now than at any time in the company's history,* said Mike Hicks, systems engineer for the City of Tucson, Arizona. *We're in the process of upgrading each of the city's over 300 servers to IntranetWare and have been very pleased with the results so far. We're also are confident that Novell--with its planned release of border services and other IntranetWare solutions--will continue to deliver the products we'll need to stay competitive and to provide a high level of customer service.* *Novell is committed to delivering IntranetWare technology to customers in the most timely and efficient manner possible,* said Coleman Barney, vice president of the IntranetWare Product Group. *The solutions we are outlining today reflect Novell's focus on intranets and the increased need customers have to secure their data over the Internet.* Border Services Novell's new product, currently referred to as border services, will provide customers with security, manageability and performance within the intranet and at the border between the corporate network and the Internet. The product includes firewall security, proxy/cache, circuit gateways, Virtual Private Networking (VPN), routing and remote access capabilities and a runtime version of IntranetWare as the server operating system. *Novell is squarely positioned in the Internet space by providing customers with solutions like border services that offer security, manageability and directory integration for connecting an intranet to the Internet* said Lee Doyle, vice president, Worldwide LAN and Data Communication, International Data Corporation. *Novell knows how to deliver secure, high performance networking solutions and is uniquely positioned to help customers meet the new challenges of leveraging intranets and the Internet to help run their businesses.* Novell's border services product, now being distributed in a Brainshare special edition Early Access CD, delivers: improved security for information sharing across the Internet; access management and control for securing and managing user access; proxy serving for enhanced performance of data look up on the intranet and Internet; reduced cost of operation through single point of administration and leveraging Internet infrastructure. Security: The new product delivers an NDS*-based security solution more comprehensive than simple firewalls, enabling organizations to secure the corporate network, to monitor and manage both inbound and outbound access, and to leverage the information and power of the Internet. VPN: VPN technology allows businesses to leverage the Internet backbone for securely connecting with remote sites, customers and partners through site-to-site encryption, eliminating the need for costly dedicated lines. Proxy: Novell's border services proxy provides acceleration technology to offset performance disparities between the Internet and corporate networks by intelligently caching Internet or intranet information closer to the users who need it. Novell Directory Service* (NDS) Integration: Novell's solutions offers the unique ability to easily manage Internet access to the individual user level through NDS - all from a single point of administration across the enterprise. The integrated administration and comprehensive approach to all aspects of the border space will reduce the overall cost of managing corporate intranets and Internet connectivity. <<<<< ------------------------------ Date: Thu, 27 Mar 1997 12:23:45 -0600 From: Joe Doupnik Subject: Re: screen lock Paraphrasing from pp 434-436 of the book "Network Security" by Kaufman, Perlman, and Speciner, Prentice Hall, 1995, the password process for NW 4 goes about like this. Alice is the innocent user in crypto-speak: Server holds in NDS Alice's username hash(salt, password) = X public RSA key encrypted private RSA key Alice sends to the workstation Alice, pwd but not as one unit (below, time runs down the screen) Workstation Server Sends Alice Alice--> Lookups up Alice in NDS to obtain as plaintext X = hash(password, salt) public RSA key encrypted private RSA key Picks a random number R, sends R and salt <--R,salt to workstation as plaintext Gets plaintext password from Alice Computes X' = hash(password, salt) Y' = hash(X', R) Password memory is erased. X' memory is erased. Picks random number R2. Retrieves public key of NDS if not cached. Sends {Y', R2} encrypted with NDS public key. {Y', R2}NDS--> Computes Y = hash(X, R) Verifies Y' = Y. This is the pwd check. Sends (private RSA key XOR R2) encrypted by Y (equals Y'). <--{encrypted private key XOR R2}Y Now have private key. Does not have password. Does not have password. Does not have encrypted Does not have encrypted password. password. Does not have hash of encrypted password. Does have hash X of encrypted password. The plaintext password never leaves the workstation, is solicited after the server's initial response, and is erased immediately after the Y' encryption step. The encrypted password itself does not leave the workstation in bare form; it is super-enciphered with the NDS public key on the wire (only the server knows the matching decryption key, the NDS private key). Wire snooping will not reveal items which can be "replayed" by an intruder. There's a little more to this to prevent nasty guys from slipping in packets but the above scenario is the basic flow of information. One needs to be convinced that password handling programs do not store items on disk files and that the memory areas involved are erased immediately after use (and that's sticky if a program is aborted) and that plaintext or encrypted passwords exist for only minimum time in memory, and that includes DOS' typeahead buffer. Joe D. --------- Date: Fri, 28 Mar 1997 07:34:22 -0500 From: Brian Dunworth Subject: Re: NOVELL Digest - 27 Mar 1997 - Special issue >If a program like SETPASS can verify my password before it lets me >change it, I would imagine that a screen saver or mail program could >verify it too, the same way. Right. >To try to find out how, I ran SETPASS. [snip] >It looks to me like there's a function to verify a password based on the >public key (and, perhaps, a private key that is local?). If SETPASS can >do it, why can't anyone? Anyone can. In the Netware API, there is this call: NWVerifyObjectPassword Verifies the password of a bindery object on the specified NetWare server NetWare Server: 2.2, 3.11, 3.12, 4.x NetWare for UNIX Server: 3.11, 3.12, 4.02, 4.1 Platform: DOS, Mac OS, NT, OS/2, UNIX, Win Syntax #include or #include NWCCODE N_API NWVerifyObjectPassword (NWCONN_HANDLE conn, pnstr8 objName, nuint16 objType, pnstr8 password); Pascal Structure #include Function NWVerifyObjectPassword (conn : NWCONN_HANDLE; objName : pnstr8; objType : nuint16; password : pnstr8 ) : NWCCODE; Parameters conn (IN) Specifies the NetWare server connection handle whose password is to be verified. objName (IN) Points to the name of the object whose password is to be verified. objType (IN) Specifies the type of object. password (IN) Points to the password to be verified. Return Values These are common return values; see "Return Values Section" in the Preface for more information. 0x0000 SUCCESSFUL 0x89F0 WILD_CARD_NOT_ALLOWED 0x89FB INVALID_PARAMETERS 0x89FC NO_SUCH_OBJECT 0x89FF NO_SUCH_OBJECT_OR_BAD_PASSWORD Remarks The requesting workstation does not have to be logged in to the NetWare server to call NWVerifyObjectPassword. If the server supports encrypted passwords, the password is encrypted. If the server does not support encryption, password verification is attempted without encryption. objName and objType must uniquely identify the bindery object and cannot contain wildcards. A bindery object without a PASSWORD is different from a bindery object with a PASSWORD having no value. A workstation is not allowed to log in to a NetWare server as a bindery object that does not have a PASSWORD. However, a workstation can log in without a password if the bindery object has been given a PASSWORD containing no value. --------- Date: Mon, 31 Mar 1997 12:37:22 -0500 From: "Brien K. Meehan" Subject: Re: Screen Lock I've hacked around a bit, and found something interesting. I've got my standard Windows 95 screen saver (Flying Through Space) asking me for my Netware password. I accomplished this amazing feat by tweaking the registry. Here's a disclaimer: Don't teak your registry! You can render your machine useless very easily! I've found that there's a section in HKEY_LOCAL_MACHINE\System\CurrentControlSet\control called PwdProvider. It's a repository for password handler related stuff. There are several keys under that, two of which are NWPASSWD and SCRSAVE. Each of these keys has values that define a description of the password provider, the path to a DLL of related password functions (ProviderPath), the name of a DLL function that performs a "GetPasswordStatus" operation, and the name of a DLL function that performs a "ChangePassword" operation. (Disclaimer: You would have to be an IDIOT to try the following!) I found that if I change the SCRSAVE values to match those of the NWPASSWD values, the screen savers that use the SCRSAVE password provider settings will thereafter use the Netware functions to check the password. I also ran a packet trace, and found that the client does NOT ask the server to verify the Netware password! So, the password is cached on the workstation - yikes! (I haven't tried chaning the Netware password while the screen is locked, or trying to guess the password too many times...) So, that answers two issues: 1) A screen saver can use the Netware password in Windows 95; 2) It is done in a security-unfriendly (or unconscious) way. Remember, manual registry changes are not advised by me, Microsoft, or anyone sane. Also, I will not provide more details than I described above, either here or by direct e-mail. ------------------------------ Date: Tue, 8 Apr 1997 03:25:07 +0200 From: "Arthur B." Subject: Re: security >I am running Netware 3.11 and think I might have a hacker giving >themselves Supervisor rights. Does anyone know of a way to list all >users who have equivalence to a certain group or user without going >through each one? ( I have several hundred users) In SYS:SYSTEM there's a utility called SECURITY.EXE. Execute: SECURITY > CHECK.TXT and make use of EDIT or something to search for "SUPERVISOR" and "[S". Then use SYSCON to straighten things out. For hackerstools you may browse the Internet and query some search-engines and learn how they did it. Another thing. Current patches from Novell prevent any results from most known user-friendly hacking tools (SEC*.* files???). ------------------------------ Date: Wed, 9 Apr 1997 15:43:49 -0400 From: Debbie Becker Subject: Re: Netware 4.1 Security >I am running 9 Novell 4.1 servers over a WAN with container >administrators in each state. How can I check users security, >i.e. who has supervisor access etc. at both the NDS and file levels. > >I am aware of a utility that came with Netware 3 called SECURITY. >I don't have a copy of this and am not sure if it would be of any >use if I did have it. I would assume it would only work within a >bindery context and wouldn't know about NDS rights. > >I have used RIGHTS /S /T from the [root] context. Is this the only way? >or is there a another? I use RIGHTS VOLUMENAME: /T /S to get trustee assignments for all directories/files on a volume. Usually port this off to a file for easier evaluation. For NDS rights, I CX to the [Root] of the tree and type: NLIST * SHOW ACL This will show you the Access Control List (a.k.a. Object Trustees List) for all objects in the [Root] context ([Root], Country, Organization) with trustees and all Object and Property rights granted shown. I then run this for any object I want to check trustees for (i.e., NLIST "ORGANIZATIONAL UNIT" SHOW ACL /S). Usually run it for Organizational Units and Server objects. (Sometimes for volumes as well, since people seem to feel that granting NDS rights to volume objects will somehow translate into file system rights). Last thing I do is to run NLIST USER SHOW "SECURITY EQUAL TO" /S for a listing of all security equivalences (groups, org.roles, other users, servers, etc.) ------------------------------ Date: Mon, 14 Apr 1997 21:03:59 -0400 From: Greg Small Subject: Re: SECURITY_EQUALS Bindery Property & NW 3.12 >"This user's SECURITY_EQUALS property has group stored >beyond the maximum of 32, so the group is not considered when >determining Security Equivalences, Trustee Directory, and FIle >rights. The group membership is ineffective and should be deleted." There is a 3rd party utility called OVER32.ZIP which I have used to determine who was near, at or over 32 entries in the table. I believe this will also allow some kind of bindery change to make the entries over 32 work as expected. If you cannot find it EMAIL me at gsmall@spar.ca tomorrow and I'll ship it off to you. IMPORTANT NOTE -- FOR THOSE USING NW 4.1 and PROBABLY 4.11 -- the equivalent problem shows up when either 57, 58 or 59 entries (I forget exactly which) are reached. I only used to see the OVER32 in 3.1 and now the "over5?" in 4.1 when I was testing a lot of new apps and had all sorts of groups enabled. The users never reached this limitation -- that Novell obviosuly never expected ANYONE to reach. --------- Date: Tue, 15 Apr 1997 10:23:55 GMT From: Roger Kresge Subject: Re: SECURITY_EQUALS Bindery Property & NW 3.12 >I recently upgraded from NW 3.11 to 3.12. The NW 3.11 server was >called DLAN and the NW 3.12 server was called NEW-DLAN. The object >was to move the user's personal files (in DLAN/USER:) and the >workgroup files (in DLAN/GROUP:) to the analogous directory on the >NEW-DLAN server. The further object was to have the user's mail IDs >and passwords remain the same. All of this was accomplished with a >combination of BINDFIX and JRB Utilities (netcopy). > >The problem arose on Monday morning when users began logging into the >new server (which had been renamed from NEW-DLAN to DLAN; the former >DLAN is now OLD-DLAN and will be kept around until we're sure we >don't need anything from it). Some users could no longer get into >applications and directories they had access to before the change. >This smelled like a trustee rights issue. WHen I went into SYSCON to >check out the users, I would receive the following message: > >"This user's SECURITY_EQUALS property has group stored >beyond the maximum of 32, so the group is not considered when >determining Security Equivalences, Trustee Directory, and FIle >rights. The group membership is ineffective and should be deleted." I studied Novell's available technical documents that seem to match up with this, and conclude that you may have had a hacker attack your network by running a utility that increases a user's security equivalence. Try running BINDIFX *twice* from the 3.11 server, then take the *.OLD files to your NW 3.12 server and BINDREST again. FWIW, Novell didn't change the binderies from NW 3.11 to 3.12, but they *did* change the APIs to close some security holes; perhaps the JRB utilities tried to mess around with the binderies on the NW 3.12 server. If that doesn't fix it, run BINDFIX *again* on the NW 3.12 server, which may fix the problem. Oh, the problem manifests itself as a trustee issue, but it appears to be a bindery issue. >The problem here is that we never saw this message before in NW 3.11. >It's also quite strange in that one user will be able to get to an >application while the adjoining user will not. I believe this is >because the bindery stored trustee rights in the order they're >assigned so that the 33rd one, regardless of what it is, will not be >available. > >Is there any way to get around this short of actually editing that >property with a bindery editor? Would running BINDFIX help? Hinder? >Make no difference? ------------------------------ Date: Wed, 16 Apr 1997 14:01:52 -0400 From: "Brien K. Meehan" Subject: Re: Admin User Corrupted >My NW4.11 server crashed during a Backup Exec backup. Upon rebooting >the NDS system was out of whack, I ran DSREPAIR and all is fine >*except* that user ADMIN is now an "Unknown" object (as opposed to >being a user object), I cannot login as ADMIN, unfortunatly I did not >grant another user supervisor equivelency so when I run netadmin.exe >as a regular user I don't have the privilege of deleting and >re-creating the Admin object. I can login as SUPERVISOR in bindery mode, >but I can't run netadmin.exe without NDS login. There is no utility (as far as I understand) for adding Admin-like rights to an object in a tree. If there is one with rights to [Root], you need to call Novell, and ask their expert hackers to add or fix the Admin account, using their special magical tools. For future reference, making an object security-eqivalent to Admin wouldn't fix the problem, because if Admin goes away, the other account becomes security-equivalent to no one! You need another account with rights to [Root], not just equivalence, to cover that base. --------- Date: Wed, 16 Apr 1997 14:33:01 -0600 From: Steve Miller Subject: Re: Admin User Corrupted >My NW4.11 server crashed during a Backup Exec backup. Upon rebooting >the NDS system was out of whack, I ran DSREPAIR and all is fine >*except* that user ADMIN is now an "Unknown" object (as opposed to >being a user object), I cannot login as ADMIN, unfortunatly I did not >grant another user supervisor equivelency so when I run netadmin.exe >as a regular user I don't have the privilage of deleteing and >re-creating the Admin object. I can login as SUPERVISOR in bindery >mode, but I can't run netadmin.exe without NDS login. There is a third party utility called MakeSU to make a new Admin object from the console. This utility is licensed to your tree. A demo and more info at at: ftp://ftp.netcent.com/makesu.zip. I have not tried this program, but I like the other utilities put out by this company, DreamLAN Network Consulting. ˙They make a toolkit (called NDS Toolkit) that includes this utility or you can buy it by itself. The last I knew the entire toolkit only cost $500 to $600. I think the MakeSU utility by itself might only be $100, and the guy at DreamLAN can probably mail it to you. Thats how we got our DSLogin utility from them. ------------------------------ Date: Mon, 21 Apr 1997 14:27:41 +0100 From: Richard Letts Subject: Re: Compromise of a single NDS server >Is it true that in Netware v.4.x, if a single server is compromised the >whole NDS network could be compromised? To ellaborate: > >Say I get a rconsole password for a single 4.x server >Can I create/access accounts on other servers in the tree (using commonly >available hacking utilities like setpwd.nlm or burglar.nlm) No, not the whole tree, but you would be able to modify the password for any account that server held a RW/master Areplica for in the same way as you can any account on a NW3.x server you have the passoerd for. On our servers the rconsole passord bear not relationship to the ADMIN or SUPERVISOR passwords, gaining rconsole access to the server leaves the monitor lock-screen hurdle [we leave our console locked by default, even in the machine room]. Security requires thought, not questions. /please/ no knee-jerkreactions here. NT security is worse. I don't doubt for a moment you're an IS Security Auditor -- your question was simplistic; I know the kind since I'm getting atleast one dumb questionaire a week from our Auditors on network security. ------------------------------ Date: Tue, 22 Apr 1997 10:31:22 -0400 From: "Brien K. Meehan" Subject: Re: ? Admin password >Does anyone know how to recover an ADMIN password >on a Novell 4.1 network; without reloading. I'm assuming the problem is that you don't have an object with Supervisor rights to [Root], right? There are two things you can do: 1) Call Novell's technical support, and they can dial in to your network and create an object with rights to [Root]. $200, quality work. 2) Have a look at http://ourworld.compuserve.com/homepages/dreamlan/toolkit.htm. "NDS Toolkit" is produced by DreamLAN Consulting Ltd. (The president of this company is Peter Kuo, author of one of my "must have" books, "NDS Troubleshooting.") There's a utility called MakeSU that creates a user object as described. I tried the demo (after the last time someone asked this), and it really does create an object with Supervisor rights to the [Root]. But, the Demo assigns the object a password and doesn't tell you what it is, so it's essentially non-functional. ------------------------------ Date: Fri, 9 May 1997 13:33:26 -0600 From: Joe Doupnik Subject: Re: NDS tree surgery >I've got an annoying NDS problem that I've been researching with no >success. I taught a NetWare 4.x class and created a container where >students could run amok with full rights. Now I've got several >containers with an IRF that blocks everything except Browse. This >makes cleanup "challenging" since there's no way to delete the >containers or the objects therein. I've checked and the accounts >used to create the containers are locked out as well. > >If there's a next time, I'll bring up a disposable tree for students >to frolick in. For now, I just want to lop off a branch of my NDS tree. ---------- Here's an object (sic) lesson for your students and staff: always create a safe administrative account on each server so that you can always get in and override anything others have done. Do not use "equivalent to." Here's another: never put play servers in the same NDS domain as production equipment. And the corrollary is never trust a server which has been tinkered with by less than expert hands: clean the drives and make fresh installations. Joe D. ------------------------------ Date: Tue, 13 May 1997 08:42:27 +0100 From: Chris van Oorspronk Subject: Re: rconsole >Try setting this us in INETCFG. Under "Manage Configuration" select >"Configure Remote Access to this Server". Enable Remote access, and >set the password. You are done! Don't use this. This tool creates a file NETINFO.CFG in SYS:ETC. Everyone who can reads this file can read the rconsole password. Type this at the console: remote encrypt (you will now be ask for a password) Then type your password (you will not see it) and press . Then there will be created a file LDREMOTE.NCF. This file contains your password (encrypted). Put this command (ldremote) in your autoexec.ncf. >I installed a Netware 4.11 server and am trying to get rconsole to >load in the autoexec.ncf so that the server can be downed and >restarted remotely. I put "LOAD REMOTE PASSWORD" AND "LOAD RSPX" in >the autoexec.ncf and when the server is downed and brought back up it >still asks for the password before continuing to load and connect to >our tree. Is there something else that I am missing? I have even >made another NCF file and put a call from autoexec.ncf and it still >asks for the password. This is currently how we have our 3.12 servers >set up. ------------------------------ Date: Tue, 3 Jun 1997 17:16:05 -0600 From: Joe Doupnik Subject: Re: Anonymous E-mail through Groupwise >Has anybody noticed that the Groupwise mail server does not keep track >of full headers? All one person needs to do is telnet to that server and >then you can send anonymous email. Are there not logs to keep track of >who telnets in and sends mail? There needs to be because if you route >email through a groupwise server it is totally anonymous... --------- How do you propose to distinguish a remote email system from a person telneting to TCP port 25 and typing by hand when they both say the same thing (follow the rules)? It's all text mode stuff, what you see is all there is. Faking mail this way is as old as email. It's also how email programs work. Joe D. --------- Date: Tue, 3 Jun 1997 22:02:28 -0400 From: Larry Hansford Subject: Re: Anonymous E-mail through Groupwise >Has anybody noticed that the Groupwise mail server does not keep track >of full headers? All one person needs to do is telnet to that server and >then you can send anonymous email. Are there not logs to keep track of >who telnets in and sends mail? There needs to be because if you route >email through a groupwise server it is totally anonymous... Groupwise isn't the only e-mail that allows that -- it is standard way of doing business. Read the news on the ISP's trying to get a grip on people (not subscribers) using their e-mail system for spamming. I don't allow Telnetting into my mail servers -- Groupwise or Otherwise.... --------- Date: Wed, 4 Jun 1997 17:56:41 -0600 From: Joe Doupnik Subject: Re: anonymous email >>>Has anybody noticed that the Groupwise mail server does not keep track >>>of full headers? All one person needs to do is telnet to that server >>>and then you can send anonymous email. Are there not logs to keep track >>>of who telnets in and sends mail? There needs to be because if you route >>>email through a groupwise server it is totally anonymous... >>--------- >> How do you propose to distinguish a remote email system from a >>person telneting to TCP port 25 and typing by hand when they both say >>the same thing (follow the rules)? It's all text mode stuff, what you >>see is all there is. Faking mail this way is as old as email. It's also >>how email programs work. >> Joe D. > >You are obvioulsy confused. Of course you can telnet to port 25 of any >isp and type in the headers manually but this does not make it totally >anonymous. If you send mail to yourself using this method and look at >the full headers you will see that it may say it is from >yourmom@aol.com when it is really from hrd@cc.usu.edu but it also logs >where the call came from. In my case, sending mail through my isp's port >25 can change the "from:" to anything I want it to but in the header it >will read the IP number I had when I telneted in and where I came from, >citrine.cyberstation.net for example. On the other hand if you telnet to >port25 of mail.amnat.com and send mail to yourself you will see this: ----------- Yes, I know about the envelope, and how to launder connections so the envelope is from another place. Stopping laundering is a bit of a problem actually, on many systems (on yours too perhaps)? And if one looks carefully, a very large fraction of sites have messed up DNS records such that the apparent IP name is not the one supplied otherwise, ptr records and cnames being what they are. And you are believing the remote DNS server, and so on. If I rejected such connections to my machines ftp and web service would slow to a trickle. Needless to say, folks create convincing fake mailgrams all the time, and often the envelope material is not seen or even visible. My points are: Email travels as plain text which anyone can type, to port 25, and there is no way of discerning that the person is using Telnet or whatever to create those bytes. Expecting a machine to validate a remote email user just isn't in the cards at this time. Validation involves a shared secret or public/private keys, PGP signatures being commonly used today, but done right and not as merely a digital signature. Joe D. ------------------------------ Date: Mon, 9 Jun 1997 08:03:30 -0400 From: Dennis Large Subject: Re: Additional Security for Netware 4.11 >Is anyone aware of a shareware or commercial software package >which allows you to provided added security to netware directories. I >am looking for extra password protection, folder locking, etc. I am aware >that NetWare is a very secure networking environment, but our H.R. >dept. is paranoid. Any help would be greatly appreciated. Technically, no, at least none that I know of, but I'll offer some related comments. 1) The shrinkwrapped netware package has been given a C2 security rating which is quite an honor for NW, in my mind. One of the manuals deals specifically with the security issues, and may be worth some reading time. See where your operation is in reference to the optimum dreamworld described, and make any changes you deem appropriate. Prepare appropriate info from all this to share with HR. 2) Many applications have the ability to password individual documents, databases, etc. Though this has no central control, you may want to give this as an option, but claim absolutely no responsibility for forgotten passwords in such a case. 3) Enable auditing on the appropriate areas, and show them some samples of information that you track and monitor. If you do not have specific personnel handling security and auditing issues, perhaps it's time to consider such. You may want to supplement the native auditing features with some 3rd party tools which do a much better/easier job of reporting the data.(bindview, etc). Maybe they'd be willing to pay for some of it. ------------------------------ Date: Thu, 12 Jun 1997 17:30:53 GMT From: Herb Axilrod Subject: Re: Screen-saver Win95 - NW 4.11 >We are upgrading our workstations to run Windows 95. To enforce >security on workstations, we are looking for a product that >can enforce screen-saver activation after a predefined period. > >Ideally it should not be possible for the users to de-select >the screen-saver, it should follow the user and authenticate >to NW i.e., use same password as NW. Birch Grove Software offers such a screen saver product. Key features: * Unlocks with user's or the administrator's password. * NDS aware. * Distributable and configurable from Login script * Option to prevent user from disabling. * Displays bouncing bitmap or uses any *.scr display. * 2nd level timeout logs users off of network. * Available for Win 3.x, Win 95, or Win NT. * US or German language versions. Demos are available from http://www.bgrove.com/bgrove ------------------------------ Date: Mon, 16 Jun 1997 15:35:10 +0100 From: Richan Postmus Subject: Re: way to load remote without passwd on 3.1X? >There is a command you can type at the console which encrypts >the password you set on the server. It then load the rconsole: > >load remote 20570982 > >The 20570982 will be the encrypted password that Novell churns out, it >then keeps another hidden file with your real password. The commands are: LOAD REMOTE (With unencrypted password) REMOTE ENCRYPT The system prompts for a password to encrypt. You type the password and press . By default the commands are written to LDREMOTE.NCF in the system directory. Add LDREMOTE to your AUTOEXEC.NCF and ready you are. ------------------------------ Date: Sat, 26 Jul 1997 17:28:54 +1200 From: "Baird, John" Subject: Re: Require Unique Passwords >>We have this setting turned on as a system default. Does anybody know >>how many old passwords Netware remembers? Surely it doesn't >>remember every password for the life of the user ID. > >Last I heard, version 4.1 remembers 20 passwords. > >Debbie Becker I thought the answer was still 8 so I ran a test. After 40 different passwords (under NW 4.11) I still could not reuse the original. I then tried reusing the 39th and it worked. Further testing shows that the first 25 passwords had been retained, and I could freely change between the 26th through 40th password. This indicates that Novell have re-introduced the system where there is a time-delay (24 hours?) before a password can be re-used. I would be interested to hear if these results apply to 4.10 - I don't have access to a 4.10 server any more. ------------------------------ Date: Mon, 28 Jul 1997 16:05:16 +0100 From: Graeme Findlay Subject: Re: Password Change Date >I am running NW 3.12, 250 users. The server is patched up to date. >Users must change their password every 120 days. My problem is, the >date field doesn't calculate right. It should reset itself to be 120 >days from the date the account is setup (atleast that's what I was >thinking should happen). What am I missing here? The date always goes >back to January 1, 1985. That is correct behaviour. The 120 days is from the date that the password was last changed, not when the account was created. This means that all new accounts default to asking for a password to be setup by the user the first time they logon and then takes the 120 days from that point. The Jan 1,1985 is basically a NULL date, so any date is later than that as far as running Netware. So Netware looks at the date. If it is earlier than (or the same as) today then the user is asked to change the password when they login. ------------------------------ Date: Wed, 13 Aug 1997 18:19:47 +0200 From: Svetlin Petrov Subject: Re: Making Novell Password Security better >I am looking for an add on package to my Novell 4.1x environment that >will put tougher requirements on the types of password user's use. >I am looking for something that has a dictionary of common words, >etc... so my users do not use passwords such as names or common >words. Does anyone know of such a product that works in a Novell >Netware 4.1x environment??? Look here: http://www.intrusion.com/ and here http://www.egsoftware.com/ ------------------------------ Date: Tue, 2 Sep 1997 16:59:15 -0600 From: Joe Doupnik Subject: Re: Ethernet frames -Reply >>I use just Ethernet_II on my networks, because I run both IPX >>and IP. >> >>But I've seen a server (I was told to look at it), where was >>bound Eth_802.2 AND Eth_802.3 on one NIC. The LAN I talk >>about is realy small, about 10 stations, just a bussines LAN for >>some accounting aplication. >> >>When I look at monitor.nlm/LAN, I saw that all the communication >>is done twice - both interfaces have the same Send_packet_number, >>Receive_packet_number and so on. The clients have also used >>all the frames. >> >>I would like to know, if I'm right that all the communication >>goes twice, or if its just some trick and the configuration >>described above has some use (all the client's NICs are some >>3c5x9, so they can use all the frames). >> >>I would also like to hear your opinion about using frame >>types - if there's some reason not to use Eth_II frame type >>(when all the NIC's can use it) > >>I'll say it in case JD is taking some time off: >>Go to ftp://netlab2.usu.edu/sys/anonftp/misc/ and read ethernet.txt >>amongstothers. > >I just wanted to elaborate a little more. Yes, most likely the 802.3 is there >for legacy purposes, at one time they may have been running the older >packet drivers or something. >The stats you see are not per protocol, rather per NIC. The packets in >and packets out are counted for that particular NIC, I can't think of a place >to find out how much traffic each individual frame type uses. >George Taylor --------- Time off? How does one spell that? Here's another aspect to keep in mind when looking for useless traffic. If your IPX traffic traverses an FDDI link then it is quite possible for the FDDI to Ethernet converter box to be puzzled about recreating the proper Ethernet frame (FDDI does not preserve them, normally). I had just that situation this weekend, where the converter was instructed to send a copy of each three times (three different frames). That made the RIP/SAP bursts gigantic. The cure was to tell the converter please use Ethernet_II. And on the useless traffic topic but a change of protocols, to IP. Many of you know that Ping (ICMP/IP) can be used to create denial of service attacks. The idea is to send a Ping Request with a destination IP address of 255.255.255.255, and often with a MAC address of broadcast (all 1's). Then all stations hearing it are tempted to do a Ping Reply (to 255.255.255.255 or whereever). The attack can be manifold. The simple step is the source IP address is local, and the idea is to get many machines generating a Ping Reply surge. The nastier one is to put a foreign IP address in the Request packets such that the foreign address gets all the replies (and your WAN link saturates). One would think that in this day and age machines would discard Ping requests which involve an IP broadcast address. Ha! Not only do many machines reply, but (take careful note) most HP Jetdirect boards do too if not configured properly, and many managed hubs do also. The HP JD boards in unconfigured state do an ARP for the destination IP rather than a formal Ping Response. Hubs can do either too, for the same reason. The sneaky bad guys find a way of slipping such Ping Request packets onto the wiring. They should not be conveyed by the full Internet because broadcast addresses should be filtered out, but then... The defense is to chat with your router people to filter out such packets. Don't let in IP traffic with broadcast addresses (for either src or destination) and don't send them outside either. This does not stop the local wackos from generating the probes, but we can, with much work, track down the originating machinery. What applies for in/outside the site applies equally to each side of routed links within the site. A handy rule of thumb is to reject packets whose source IP address is not appropriate to that wire (subnet masks considered). Joe D. ------------------------------ Date: Sat, 13 Sep 1997 19:55:00 -0700 From: Hansang Bae Subject: Re: TFTPD Server >>Is there any way to make an IntraNetware server a TFTP Server? > >FTP Services for IW, the 4th CD in the set has a TFTP server component. >After install, look at sys:etc/inetd.cfg, and see that the corresponding >line is commented out by default. Remove the semicolon, and go! You >don't have any other management options to play with. Keep in mind that tftp (trivial ftp) can be a BIG security hole. As no passwords or usernames are required. It's typically used to download bootstrap code or new firmwares. So make sure you know what you are doing before implementing tftpd. ------------------------------ Date: Thu, 18 Sep 1997 21:24:17 -0400 From: Dave Wineman Subject: Client 32 Security Hole Does anyone know of a way to plug a Client 32 security hole upon startup with policies in place and forced login before access to the computer for the following scenario: I found another security/program glitch with win95/Client32. You know that if your at the Novell Client32 logon screen and press CTRL+ESC you get the task manager. And that you can enter a program to run. If you enter CONTROL and press enter it DOESN'T bring up the control panel like you would think, it skips the logon (leaves the logon box there) and takes you into windows. It appears that you get the local start menu (including MS-DOS Prompt, Explorer, Etc). Try it and see if it does the same with the old win95. This is at HB with the Win95B machines Any ideas on how to force the login without bypassing to windows (not connected to the network?)? ------------------------------ Date: Fri, 19 Sep 1997 06:32:10 -0400 From: Desmond Irvine Subject: Re: Client 32 Security Hole >Does anyone know of a way to plug a Client 32 security hole upon >startup with policies in place and forced login before access to the >computer for the following scenario: > >I found another security/program glitch with win95/Client32. You know >that if your at the Novell Client32 logon screen and press CTRL+ESC you >get the task manager. And that you can enter a program to run. If you >enter CONTROL and press enter it DOESN'T bring up the control panel like >you would think, it skips the logon (leaves the logon box there) and >takes you into windows. It appears that you get the local start menu >(including MS-DOS Prompt, Explorer, Etc). Try it and see if it does the >same with the old win95. This is at HB with the Win95B machines Delete or rename TASKMAN.EXE and the CTRL+ESC trick will no longer work. ------------------------------ Date: Thu, 13 Nov 1997 12:10:00 -0600 From: Joe Doupnik Subject: Re: How do the workstation login, attach ? >I wonder if anybody knows how does a workstation connect (login, attach) >to a server NetWare 4.1, I mean what kind of packets are sent between the >file server and the workstation or if there is a place where I can see this >information. ----------- Use a wire monitor. Novell's Lanalyzer for Windows is a good tool for NetWare work. Also you may wish to dig deeply into the security exchanges, and this is summarised conveniently in the book "Network Security, PRIVATE Communication in a PUBLIC world" by Kaufman, Perlman, and Speciner, Prentice Hall publisher. Joe D. ------------------------------ Date: Thu, 27 Nov 1997 20:19:53 -0600 From: Joe Doupnik Subject: Re: Rights to Applications NOT to Users >The problem I am facing is when the worker accesses DOS they also have >access to the files allowing then to copy, delete, or change the status >of the file. > >I NEED A PROGRAM THAT GIVE ACCESS TO APPLICATION, NOT FOR A USER OR >GROUP !!! ----------- Let's stop and think for a moment. A user can't give him/herself more rights than he/she already has. To give them would be a fundamental security flaw. NW does not know how a user makes requests on a server, though some TSRs try to make guesses by trapping DOS. The app is running on the user's machine, not in the server, and thus the app is essentially the user. Consequently the app is merely one of many ways the same requests can be made on the server by that user. The solution is to have an agent running on the server which has necessary rights and can be commanded by the user through a second matching agent to assign them. Naturally, the weakness is how the commands are validated, and a second is knowing when to rescind them. A third is restricting the command set to particular operating conditions and sequences. And a final weakness is knowing the user agent is not being mimiced. And so on along the twisty pathway of security. In the database world the pair of agents is often called a frontend and backend program, and the user is not allowed to see the data as such. Joe D. ------------------------------ Date: Tue, 9 Dec 1997 08:53:47 -0600 From: Joe Doupnik Subject: Re: TCPIP messages >>Any news about a patch to the recent LAND Attack on INW4.11, it >>will cause 100% CPU usage. > >Yes i saw that too but what i allso saw that the utiization wil dropped a >while and the server can still be accessed while being under attack. >I tried the same on an NT server that was unreachable for about 60 seconds... > >Joe D. said >>Best to talk with your IP router >>people now and get the attack blocked as it enters the site. SYN is TCP >>start of data stream, and the SYN attack is to continually open such >>connections and never responsd to the local side's complment to the open. >>Thus the target system crashes from overallocation of buffer resources. >>Port 25 is SMTP mail. This is an old adolescent game. Block at your site's >>router. Thank Novell for their software trying to survive the attack >>automatically. Joe D. > >but as one of my novell servers acts as an incoming mail server and the >other one as a web server it seems to mee that blocking means cutting me out >on the rest of the world, or am i wrong joe ? -------- Let's face reality on the net. There are many bad guys and stupid people on the Internet who can and do perform disruptive things to any machine they can reach. It will not get better, it is getting worse. The normal first line of defense is the router separating the site from the world. Whoever is in charge of it needs to be familiar with ways of blocking the bad guys while letting normal work proceed, as much as is possible. This is TCP/IP material rather than local IPX. In addition, individual machines on site should be protected and configured to not be inviting targets or security holes. This is a system manager's responsibility, working with the router people. The normal strong defense is constructing a firewall system. This is complicated, costly, and not a single unit that is plugged in and magically provides protection. People have to configure the system. There are NEWS discussions groups on firewalls, books on such matters, and so on. In depth knowledge of TCP/IP is a requirement to intelligent defense. Joe D. ------------------------------ Date: Wed, 17 Dec 1997 11:03:40 -0600 From: Joe Doupnik Subject: Re: Teardrop TCP/IP attack >I just searched Novell's Knowledge Base for Teardrop and there seems to >be no information about it > >Some implementations of the TCP/IP IP fragmentation re-assembly code >do not properly handle overlapping IP fragments. Teardrop is a widely >available attack tool that exploits this vulnerability. ------- It is a malicious attack. Let's see why. TCP or UDP or ICMP generates a request to send to IP and an IP decides the request must go out in fragments. Or, equivalently, a large IP datagram arrives at a router and needs to be fragmented to fit a smaller outgoing pipe. These fragments are contiguous, not overlapping. Suppose the datagram implies a response and the response never appears. The high levels can initial a retransmission. The retransmission creates a new IP datagram, one with a different IP ident in its header. The pieces can be fragmented differently that before. These fragments are considered a completely independent datagram than the first case, because the IP ident field is different; no overlap is possible. Networks rarely make copies of datagrams in transit. Thus the same datagram is extremely unlikely to arrive by two different paths, each fragmented differently. Now you can see that overlapping fragments mean the same IP datagram must be copied and fragmented differently. This implies bad guys are trying to destroy machines. There are many ways of violating common sense operating conditions to create trouble and we will never be free of such opportunities for mayhem. For the standard IP frag reassembly algorithm see RFC815.TXT. It is kind and does not explicitly defend against the crazy people inciting riot. If you catch any of your people with destruction tools you may wish to contact your legal people right away. In addition, in cases of serious attack from outside put up a good firewall. Joe D. ------------------------------ Date: Sun, 21 Dec 1997 10:34:06 -0500 From: Steve Kurz Subject: Re: RCONSOLE >I have two servers, a 4.11 and a 3.12. The AUTOECEX.NCF loads >REMOTE.NLM with the password, and I use that same password to lock the >server with MONITOR.NLM. Yes it is different from the supervisors >password. Remote = Password "A" Monitor = Password "B" Supervisor = Password "C" >Client 32 v2.2 is on the clients. > >When I attempt to access the servers using RCONSOLE via DOS, I must >enter two different passwords (So far so good). One to access the >sever, and another to unlock the server as locked with the MONITOR.NLM. >The problem is that they are two different passwords and I believe the >two passwords should be the same. Is this correct? I have downed the >server and brought it back up with the same results. Rconsole = Password "A" Monitor = Passwords "B" or "C" No matter what password you use to lock the console, the supervisor's password always works. I usually use a sweep of my finger over the keyboard to lock the console and the supervisor's password to umlock it. --------- Date: Tue, 23 Dec 1997 09:12:36 +0200 From: Patrick Medhurst Subject: Re: RCONSOLE >It's been my observation that the Admin password will not unlock the 4.1 >Console unless it is the original password from when the server was >installed. If user Admin has had a password change - the new one will not >unlock the console. The original server setup password is assigned to the >user Supervisor and cannot be changed in this regard. >CraigE... It can be changed if you change that server's bindery emulated Supervisor user. You need a bindery context set on the server to do that, however. As a matter of interest, in Moab (NetWare 5) the lock feature has been removed from MONITOR.NLM. There is a separate SCRSAVE.NLM which does the snake and locks the console. The console is unlocked by authenticating to NDS as Admin (or equivalent). This will solve the confusion that has been caused by the MONITOR lock password, but will bring a worse problem (in my opinion) in that how will you unlock the console if the replica on the server does not contain an Admin user, and the server is currently unable to synchronise with a replica that does (because of a WAN link down, etc.)? I am sure we will figure out the best way around this, but who needs the headache? ------------------------------ Date: Tue, 6 Jan 1998 11:45:35 -0600 From: Marius Swart Subject: New: Firewall-l - Computer network security & Technology FIREWALL-L on LISTSERV@LISTSERV.NANOTEQ.COM FIREWALL-L is a mailing list for discussions on computer network firewalls, network security and related technology, concepts and techniques. To subscribe, send a message to listserv@listserv.nanoteq.com containing a single line in the body of the message: SUBSCRIBE firewall-l Yourname Yoursurname Owner: owner-firewall-l@listserv.nanoteq.com ------------------------------ Date: Tue, 6 Jan 1998 10:40:38 -0700 From: Joe Doupnik Subject: Re: Office 97 running on a server? >Joe has a point of course. > >In my personal view, and after enough time using this software called >office, I can't think of any reason not to install disks in WS's other >than a monetary one. These programs are getting too large and too >cumbersome for diskless WS's......whethere they work on them or not. > >And there is no problem installing disks and no diskettes. --------- Ok, let me add the context in which I have to work. It is a student open lab, a very public arena with thousands of users going through it daily, seven days per week. I have requirements that each user gets a clean machine upon every boot, with no leftovers from the previous user, and the machine configuration is the same every time, and the time to get the machine ready for them is about a minute or less. Real life shows that there is no way of keeping a local hard disk intact in this environment. Not with DOS nor Win3.1/95 nor with NT. Remaking a hard disks takes at least 20 minutes using the best of today's tools, and that is 20 times too long for a public place. The solution is diskless booting, with a local floppy drive for carry-aways. Each station is given an individual scratch area on the server, shown to users as drive D:, which is cleaned absolutely during login (takes a few seconds at worst). Collectively the drive D:'s share an 800MB volume, but a user cannot see another user's drive D: no matter what they try. As you can see, this public arena is very different from dealing with one-person-per-machine desktop situations. On MS Office 97 slowness. There are two principle slow items: the interactive spelling checker in Word (so turn off that option) and searching vast ClipArt collections. Of the two the first is the most noticable. In my environment we don't have a bandwidth problem, using 100Mbps Ethernet by design, nor a swap file problem (using 32MB clients, by design, with swap on the server in a per-station scratch area). Bloated programs have become a fact of life and we arrange the net to accomodate most of them. Joe D. --------- Date: Thu, 8 Jan 1998 09:31:02 -0500 From: Bob Dopher Subject: Re: Office 97 running on a server >>> It is a student open lab, a very public arena with thousands of >>>users going through it daily, seven days per week. I have requirements >>>that each user gets a clean machine upon every boot, with no leftovers >>>from the previous user, and the machine configuration is the same every >>>time, and the time to get the machine ready for them is about a minute or >>>less. >>> Real life shows that there is no way of keeping a local hard disk >>>intact in this environment. Not with DOS nor Win3.1/95 nor with NT. Remaking >>>a hard disks takes at least 20 minutes using the best of today's tools, and >>>that is 20 times too long for a public place. >> >>Have you tried PC-Rdist? >> >>It works great at in a lab of 190 computers on campus. All the >>machines have Windows 95 and Office 97 installed locally, along with >>other software. The typical log off and rebuild process takes no more >>than a minute, with severe cases taking longer. It cleans the drive >>throughly right down to the bookmarks in Netscape. >> >>Kris S. >-------- > Down to bookmarks in Netscape is a looooong way from cleaning a disk, >Kris. As mentioned, I've looked at these tools (including Ghost). One must >start with a repartition operation. Now measure the time to rebuild. > Joe D. I've been following this thread for the past couple of days & just thought I'd throw in my 2 cents worth. We run about 50 public win95 machines from the local hard disks very successfully, without having to reconfigure back to the basic setup each time. We use a combination hardware/software locking system to prevent user reconfiguration of the local harddrive so that a reboot always brings the machine back to its original configuration. From our point of view this has a couple of advantages: 1. The initial boot of the machine is local, thereby reducing the network traffic ( or more properly, the load on the server). When one gets an instructor telling 30 students " now push the reset button" that becomes important as far as the boot time is concerned. 2. Swap space is kept off of the file server; an important consideration to us as we observed considerable thrashing of the file server when swap space was allocated for the user on the file server itself. We still run our applications, such as Office 97, from the file server; and this neither overloads the server at any given time nor does it consume any significant bandwidth beyond normal bursts. We do make use of Ghost, but it's only needed when we build a new image for our machines. Other than that the machines run for extended periods with no reconfiguration necessary. --------- Date: Fri, 9 Jan 1998 10:00:43 -0500 From: Jim Pretty Subject: Re: Office 97 running on a server? > "Real life shows that there is no way of keeping a local hard >disk intact in this environment. Not with DOS nor Win3.1/95 nor with NT. > Joe D. I definitely agree with the Win3.1 part and agree that it is a real bear under Win95, although there are some 3rd party utilities which make it a lot easier, but am confused about why you don't think it is possible (even relativly easy) to keep a disk intact under NT. Granted the way rights work under NT are quite different if you are used to the Novell paradigm, but one should be able to lock down an NT workstation very tight. --------- Date: Fri, 9 Jan 1998 09:47:06 -0700 From: Joe Doupnik Subject: Re: Office 97 running on a server? Because a) writable space must exist locally to run the login script b) anyone with a floppy disk can become administrator via common hacker tools on the net. No intelligence needed. c) anyone with a floppy disk can consume a hard drive. No intelligence needed. Joe D. --------- Date: Fri, 9 Jan 1998 10:37:20 +0000 From: Randy Richardson Subject: Re: Office 97 running on a server? >>> "Real life shows that there is no way of keeping a local hard >>>disk intact in this environment. Not with DOS, Win3.1/95 nor NT." >> >>I definitely agree with the Win3.1 part and agree that it is a real bear >>under Win95, although there are some 3rd party utilities which make it a >>lot easier, but am confused about why you don't think it is possible >>(even relativly easy) to keep a disk intact under NT. >> >>Granted the way rights work under NT are quite different if you are used >>to the Novell paradigm, but one should be able to lock down an NT >>workstation very tight. >-------------- > No, because > a) writable space must exist locally to run the login script > b) anyone with a floppy disk can become administrator via common >hacker tools on the net. No intelligence needed. > c) anyone with a floppy disk can consume a hard drive. No intelligence >needed. > Joe D. d) A Linux boot disk will grant the user full access to the NTFS partitions. --------- Date: Mon, 12 Jan 1998 09:58:14 -0700 From: Joe Doupnik Subject: Re: Office 97 running on a server? >> No, because >> a) writable space must exist locally to run the login script >OK, but can not a small part be left so that the login script be run? >> b) anyone with a floppy disk can become administrator via common >>hacker tools on the net. No intelligence needed. >Do they not need some idea of the administrator password? >> c) anyone with a floppy disk can consume a hard drive. No >>intelligence needed. > >Can you elaborate on this one. > >We are in the process of upgrading to NT (from Win31) at the moment >and trying to glean as much 'additional' information as possible. --------- You are at a Univ. I suggest asking the scruffiest students you can find to come in and "play" with your machinery. Within about 20 minutes they will have reduced it to rubble, in the CS sense. That's too bad because the last time I visited Sheffield it was a nice Univ. Try FDISK, or get any Linux user to arrive with a boot floppy to take out NTFS material. Try boot sector viruses, partition table viruses. Try Norton's Utilities. There are tools circulating on the net which let anyone with them on a floppy to become Administrator. Clearly, they don't need to know the password. Your system is now toast. MS has commented upon these tools, and at last reading there is no defense. There are no space quotas on NT, so any opening means all available disk space. It's part of the job to know about such things, alas. I too find it repellant and a waste of energy, but it is necessary. Please read NT groups in NEWS for more information. Joe D. --------- Date: Mon, 12 Jan 1998 11:52:39 -0700 From: Joe Doupnik Subject: Re: Office 97 running on a server? >> There are tools circulating on the net which let anyone with them >>on a floppy to become Administrator. Clearly, they don't need to know >>the password. Your system is now toast. MS has commented upon these tools, >>and at last reading there is no defense. >> Joe D. > >But what if the stations cannot boot up from a floppy via the CMOS >setup, and users are denied the right to run or copy anything from a >floppy? --------- A fair question: basically no floppy. That means users have difficulty taking data to or from the machine, unless one provides remote data access across the network. In my situation (public access labs) users carry their data on floppies and there is no public remote access data storage. One may also imagine individual usernames and private storage associated with them, but I can't support that nice concept. I think the break-in tools (become Administrator) work even without a floppy, and thus remote data access permits them to be run. But I am not expert in the fine points of those tools. Removing the floppy drive and remote data access tends to create a totally inward looking system, and that's not worth much in a University. Joe D. --------- Date: Mon, 12 Jan 1998 14:30:30 -0800 From: Michael Kessler Subject: Re: Office 97 running on a server? >Removing the floppy drive and remote data access tends to create a >totally inward looking system, and that's not worth much in a University. > Joe D. Users can save their data on floppies, but can't run any executables from the floppies. The station boots off the C: drive, and we use FoolProof to define how the station may be used. --------- Date: Tue, 13 Jan 1998 07:58:47 +0200 From: Mike Glassman - Admin Subject: Re: Office 97 running on a server? >> There are tools circulating on the net which let anyone with >them on a floppy to become Administrator. Clearly, they don't need >>to know the password. Your system is now toast. MS has commented >>upon these tools, and at last reading there is no defense. > Joe D. > >But what if the stations cannot boot up from a floppy via the CMOS >setup, and users are denied the right to run or copy anything from a >floppy? On the issue of security hacks, we all know that someone who is determined to bring a system to it's knees can and will no matter how many options we disable in our end users Pc's, and no matter how many sniffers and other such we have running. There is only one way to abolish this sort of issue from an organization, and that is to make sure that if anyone is caught attempting this sort of thing, whether as "fun" or any other, is simply to punish. And I mean punish in large capitol letters - and make sure it gets published. Obviously this is easier in an organization like mine, and much harder in schools and such, but the option to do so is available everywhere. In my org, the rules have been published and are re-published once a year at least, stating that any such atempts will be severely dealt with. In the short time I have been here, I have been instrumental in catching 2 such "fun" hackers....both no longer work here, and I doubt if either of them will ever work in any similar place again, not to forget the very large sums of money they are paying for damages that they may have caused. There are some things that one simply has to be firm with. On security issues, I have no mercy, I'm the devil incarnate. And I couldn't care less if it was a kid or an adult. I have no doubts there will be many replies as to the inability to punish children at schools.....but then, if you have no way of causing people not to "want" to hack your system, you'll get hit one way or another. --------- Date: Tue, 13 Jan 1998 00:49:34 -0700 From: The Abundant One Subject: Re: Office97 on Server Like Joe says, its pretty easy to beat NT security. For anyone who isn't in the know, there are at least 3 different hacks freely avalible on the net that will allow a person to bypass NT security. Method #1 is to use a Linux boot disk and simply mount the NTFS drive as a Linux volume. Method #2 is to boot to DOS from a floppy and use something like NTFS4DOS to gain access to the NTFS partion. Method #3 is to install a new copy of NT into a different directory, and boot that version of NT and you have full access to the NTFS partition. Method #1 and #2 require a *bootable* floppy so going into the bios and changing the boot order from C->A rather then A->C and then password protecting the bios can do a pretty good job of protecting you from this one. Method #3 doesn't require a floppy, you could place the install files on a FTP server then FTP them to the machine you want to hack, or even boot from the CD (if you have bootable CD drives) There is also a program called getadmin that gives you admin privs on a NT box, but the hole this program exploits I think was dealt with in SP3 so I don't think its much of a concern anymore, but if you have an unpatched box you are open to that hack as well. --------- Date: Tue, 13 Jan 1998 17:19:46 +0200 From: Cris Subject: Re: Office97 on Server >Method #1 is to use a Linux boot disk and simply mount the NTFS drive >as a Linux volume. Method #2 is to boot to DOS from a floppy and use >a something like NTFS4DOS to gain access to the NTFS partion. Method >#3 is to install a new copy of NT into a different directory, and >boot that version of NT and you have full access to the NTFS partition. > >Method #1 and #2 require a *bootable* floppy so going into the bios and >changing the boot order from C->A rather then A->C and then password >protecting the bios can do a pretty good job of protecting you from this >one. With debug.exe (DOS) is very easy to "crash" CMOS in only two line ;) --------- Date: Thu, 15 Jan 1998 10:41:35 GMT0BST From: Liz Jarman Subject: Re: Office 97 running on a server? >On the issue of security hacks, we all know that someone who is >determined to bring a system to it's knees can and will no matter how >many options we disable in our end users Pc's, and no matter how many >sniffers and other such we have running. And they do. >Obviously this is easier in an organization like mine, and much harder >in schools and such, but the option to do so is available everywhere. In >my org, the rules have been published and are re-published once a year >at least, stating that any such atempts will be severely dealt with. In >the short time I have been here, I have been instrumental in catching 2 >such "fun" hackers....both no longer work here, and I doubt if either of >them will ever work in any symilar place again, not to forget the very >large sums of money they are paying for damages that they may have >caused. Like Joe we have 'Open Access' rooms. This means that the rooms are meant for student use, but we have an open building policy that allows members of the public to use the campus (we have a couple of cafes that we enourage the public to use). We have a very large adult student population and can never know whether the user is a proper student or not. The PCs are only for educational use, but without going round and checking each user which is time consuming we find that occasionally a non student will use the PCs. Our Internet access is controlled by login codes so we don't provide free inetnet access to every Tom, Dick or Harry. >There are some things that one simply has to be firm with. On security >issues, I have no mercy, I'm the devil incarnate. And I couldn't care >less if it was a kid or an adult. I have no doubts there will be many >replies as to the inability to punish children at schools.....but then, >if you have no way of causing people not to "want" to hack your system, >you'll get hit one way or another. Students mean cash, even in the UK were education was seen to be free. If a student is found causing damage the redress isn't immediate as there are various stages to go through. We are aware that there is a problem and have to work on the basis that we can recover a machine quick enough to not cause a problem for the true users. ------------------------------ Date: Tue, 13 Jan 1998 22:20:13 -600 From: Steven Thompson Subject: Re: MAC address tracking >I have a MAC address of a machine that tripped the intruder lockout >for my 'Admin' account. Is there anything out there that can alert >me when that address connects to the network or something that can >list by MAC address. I'm just looking for a way to know when that >machine is connected so I can see the user ID and track that person >down. Try this... IF "%P_STATION" ="Put-The MAC-Address-Here" THEN #COMMAND /C SEND "Intruder Alert!! - Check the console" server/user END Check the syntax for SEND for your version, NDS and bindery are a little different. Make sure the user you send the alert to is *you* Then just rconsole in and look for the address ------------------------------ Date: Wed, 14 Jan 1998 11:07:51 -0800 From: Jeff Groetsema Subject: Re: Office97 on Server I have seen sites with many, many more NT hacks. And on the issue of the getadmin hack, there are already updates to get around the service packs. At a generic OS hack site, there was information on many hacks to an NT system and only two for NetWare (add on stuff - FTP and Perl). So what does this tell you? --------- Date: Wed, 14 Jan 1998 12:39:20 -0700 From: Joe Doupnik Subject: Re: Office97 on Server...Again >Floppy disks are important, but so is providing a small chunk of >network hard drive space for students. > >Why not purchase an additional hard drive (if you're low on space), >and extra RAM since the prices have been crashing down for quite some >time now? > >With NetWare (version 3.x, 4.x, and later) you can restrict the >amount of disk space available to a particular subdirectory (which >applies to all its subdirectories automatically). When you do this, >the amount of free disk space reported from this directory will be >different than the root directory. > >For example, if you had 1000 students, all you would need to do is >add 2 GBs of disk space and restrict each student's directory (not >the user account) to 2 MBs each. If the student fills it up, too >bad, they'll just have to resort to floppy disks or clean up their >files. --------- I'm afraid that this introduces larger issues. They start with personal logins and the maintenance associated therewith. Then 2MB is small and will be pressured to be much larger. 2MB won't hold even a Windows swap file. I put all stations on volume USER: and share the space amongst all without quotas. Each station's scratch directory there is independent of that of the other stations. Each scratch directory is cleaned absolutely upon machine boot, and I provide a count-down menu choice to save files there or not (default is not save) to accomodate rebooting after a crash. Volume User: has 800MB capacity and thus each user has much elasticity but all share the capacity. Sharing makes far better use of common resources, with the known danger of a hog consuming all. Takeaway/permanent storage is via floppy disks. Joe D. --------- Date: Wed, 14 Jan 1998 11:47:46 +0000 From: Randy Richardson Subject: Re: Office97 on Server...Again [Above message snipped] This solution definitely reduces the user whining, and simplifies the administrator's job. In most situations, I think this would work very well. When you get a network hog, that's where you add a directory space "throttle." 2 MBs is enough in an elementary school setting, and even for many high schools. I keep forgetting that you run Windows from the network, and have to deal with large swap files. ------------------------------ Date: Wed, 14 Jan 1998 16:33:00 -0400 From: "BURTT, PETER (AEL)" Subject: security info > -Second prob is with my latest job task. >My boss wants me to get all the security bugs that Novell servers have >(all sorts of). And all the resources i've seen are not very useful for >me, cause they contain hacking binaries, and what i need is a short >describtion on what, how and solution. Is there a good Info on the >net or has anybody done this before? A good place to start is the Simple Nomad Novell hack site, http://www.fastlane.net/~thegnome/faqs/netware/index.html This isn't your typical hack site, the information is well organized and explains exactly what conditions you need to have in order to break in using such and such a tactic. Of course that gives the admin a nice, well organized list of conditions that had better not be possible on his LAN. In general though, off the top of my head... 1) Secure physical access to the server 2) Keep client and server software up to date. Well known security holes are usually (often??? sometimes???) patched. 3) Don't load RCONSOLE. There are lots of things to worry about, but those 3 things will foil most attacks. ------------------------------