Wi-Fi

From the trenches: Troubleshooting and securing SonicWall

Consultant Bob Eisenhardt recounts a recent experience working with a small office's SonicWall V200. If you've ever tangled with one of these devices, these tips might help.

Recently, I found a real challenge in a new account at a small medical office. A SonicWall V200 was abandoned half-way through a proper configuration by the departed consultant and thus left in a very damaged state. Otherwise, the network seemed straightforward with a Windows 2003 SBS server and about eight stations and no Exchange server running. I said I could manage it without any problems at all...but I was wrong.

I have since learned that a SonicWall is UNLIKE any "router" in the world: the menu interface LOOKS nice at opening page but going deeper is like an archeological dig. There are literally hundreds of pre-set objects and controls. These multiple objects are visual distractions and should be ignored at first glance. Enabling port-forwarding was my first problem. I performed it remotely through DYNDNS and, after some trial and error, I found it under the DDNS listing, and was able to crack it through to the server. Only much later did I learn that remote control DESTROYS insurance form overlays and I had to disable it!!

After resolving a backup issue, the really big problem was that the public area Wi-Fi just was broken. Patients in the waiting room, connecting to it, would be directed to the login page of the SonicWall. DHCP addresses were being distributed but somewhere DNS to the outside world was failing. The battle began. Among the perhaps 10 opening menu settings are two settings of interest: wireless settings (obvious) and Sonicpoint settings (less obvious). It is not an intuitive design. I asked another consultant for a financial house if he had any experience with a SonicWall. He looked away and said "it's messy in there," which is perfectly true.

Problem number one: Wi-Fi

Examination of the previous wireless structure proved inconclusive. Wi-Fi was there, DHCP was there, DNS was set through the server and the default page was always the SonicWall login page at 10.10.10.1.

I thought of browsing for self-instructive videos, of which there are a few dozen and all of them rather seem to presume the tech knows how to use a SonicWall and, secondly and far worse, do not REALLY address a specific problem per video. I found many that sort-of taught me how to do this but not that other aspect of an issue, so it was frustrating yet again. By contrast, Bill Detwiler is a straight-shooter on a given subject.

I thought of RTFM (Read The "Freaking" Manual) and set about downloading guides. I should have known better, having a huge collection of truly huge computer books on my shelves, many of them 1,199 pages, and the SonicWall guides were no different. HOW CAN WE DEAL WITH PRINTED MATTER? (That is a blog for Chip Camden to address one day). 500 pages in a PDF and SOMEWHERE in there are the two paragraphs that perhaps answer what I want.

I then began pursuit of what turned out to be THE solution, creating a new SSID and comparing it to the old original configuration. The previous consultant was helpful and somewhat informative but his heart was obviously onto new subjects. I contacted a co-consultant I work with, and remotely, he did some work in the Sonicpoint tab, but wireless testing on-site showed no broadcast results. The new SSID was there, but it still went nowhere and the old one still brought me to the login page. The Sonicpoint area had a new object as created by my comrade, but it also broadcast NOT and I was still browsing thin air.

Since none of the three SSIDs were broadcasting, I came to the point of madness. I ignored and disabled ALL the work my co-consultant did and the old SSID entirely so that both were shut down. I also found I had to disable because I could not delete anything (another annoyance as SonicWalls have delete buttons but they do not actually delete an entry).

I then enabled JUST my self-created SSID and...it worked. How? I honestly do not know, but when I visited the office late the other night, and checked my Wi-Fi laptop in the lobby, it connected to the net and also visited my favorite test site: www-dot-1164-dot-com. (Try it out during lunch.) My supposition is that the original SSID was so corrupted that nothing associated with it, in any way, would work. It also could NOT be deleted so disabling everything did the trick.

Problem number two: Security hole

As security is the real strength of the device, service logs can be your best friend. Reading these takes time and patience, but they point to external IP addresses that can be researched. Thereafter, the game was truly afoot, and I had to revise this post as another problem became evident.

A downloaded game showed up on the server along with a little password blaster, Du Brute. I deleted both and added a server welcome page to the registry that prevents auto-logins, and that I recommend for EVERY server in the world: an opening login screen and statement. This requires CTL-ALT-DEL so that password blasting cannot occur EVER. Open Regedit and drill down to key:

HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENT VERSION\WINLOGON

Create two string values: LEGALNOTICECAPTION and LEGALNOTICETEXT. These are then edited to be a caption such as WELCOME TO THE PCSC SERVER and the ext can be anything legal or frightening you wish it to be. This not only puts a declarative statement on the screen, legal protection, but prevents anybody from the outside to just blast their way in. If you extract and save the registry entries, you can easily modify the key and use as designed FAR faster than drilling down.

I became interested in this because of Du Brute. This is bad business, as it is a hacker's tool, pure and simple. When running, it blasts a list of selected IP addresses (the list is in text format and I have no idea where the original list comes from) with logins and passwords every few seconds. When one IP reaches the end of the list, it moves onto the next address and re-runs from top to bottom. It is also attacking through port 3389, a good port to disable on the firewall. Server fanatics, take note to monitor SECURITY events in the Event Log. If you see Failure Audits, you likely are seeing Du Brute running somewhere else in the world and coming to knock on your server.

I copied Du Brute to my server and AVG hated it within 1 micro second. On the web it is constantly listed as a threat with no hits as a safe file. General advice is DELETE IMMEDIATELY.

Since no one did get into this server (but two others were being attacked, and those I locked down immediately with strong passwords), I also deleted my DYNDNS account as above, just to be certain, and GoToMyPC as another outside door in. I am now using LogMeIn -- free version -- as a monitoring service.

Have you had any run-ins with SonicWall? If so, share your experience below.

{"msg": "None", "status": "error", "error_type": "ServiceUnavailableError", "code": 503}

Editor's Picks