This section contains info regarding Netware Denial of Service.
These are per itsme:
If you have console access, try this:
Another thing to try, with console access, is LOAD RARPSERV.NLM quickly followed by UNLOAD RARPSERV.NLM which will abend a Netware 4.11 server (tested with Service Pack 4 loaded). If RESTART AFTER ABEND is set (which is the default) the server will reboot. Using UNICON to UNLOAD RARPSERV.NLM and it should unload cleanly.
There are several flaws regarding NCP that can allow for interesting Denial of Service that will crash a server. One utility, Havoc, was released with Pandora, and a couple more (Burn and Yang) are available in our projects list.
By default Windows 95 shipped with long file names (LFN) and Packet Burst enabled, which created a unique problem -- if the server didn't have long name space loaded (OS/2 name space) it caused problems with files and occassionally crashed the server. But the worse one was Packet Burst. Unless you had at least a 3.11 server with the PBURST.NLM up and running, along with drivers for the server's network capable of handling Packet Burst, the buffer space used for network connections and/or the buffer space on the network card created problems ranging from lockups to timeouts to abends.
There were a couple of different fixes you could do, like updating the server for long name space and Packet Burst (sorry Netware 2.x users), or you could update the clients' SYSTEM.INI file with the following entries:
Alternately, a frame type (802.3) that doesn't support Packet Burst could be used, and you could enforce no LFNs via system policies.
If File & Print Sharing for Netware is configured and you have non-Windows 95 users, there could be serious network problems. How does this happen? Here is a very simplified explanation -
The way Netware advertises its file and print services is via Netware's proprietary (but widely documented) Service Advertising Protocol (SAP). How to get to these resources is communicated via Routing Information Protocol (RIP) packets. Both SAP and RIP info are transmitted broadcast style. Netware servers and even intelligent networking equipment that conform to the SAP and RIP protocol scheme (like routers) share this info dynamically between each other.
The problem is when Windows 95 is set up with File & Print Sharing for Netware, because the Windows 95 workstation does a lousy job of implementing and interacting with the SAP and RIP info. As any LAN/WAN specialist will tell you, extra SAPs can quickly waste bandwidth, causing timeouts and broadcast storms. And that is exactly what Windows 95 does. Netware 3.x and 4.x have released patches, but the easiest thing to do is simply NOT use File & Print Sharing under Windows 95 -- use Netware's file and print services like they're supposed to be used, or use Client/FPS for Microsoft networks instead.
Can hackers take advantage of this? Here's the theory how:
What could prevent this? Well, in a WAN environment a router could be configured to only allow SAPs to come from certain segments, or every one of the workstations are running Windows 95 (which is probably Microsoft's solution). And even though I have heard from a dozen people stating that this could be done, no one has said they've done it (the alternate LOGIN directory and trojan LOGIN.EXE).
Top | Next: Netware Logging and Backdoors | Previous: Netware Client Attacks | Table of Contents