|
Introduction:
At some point you may be required to audit the configuration of a SonicWALL device. If you have physical/admin access to the management interface, then this is probably the easiest method - drill down every option and check for misconfiguration. If not, obtain a configuration export file (file name is generally 'sonicwall-name-date.exp') such as sonicwall-SydneyDC-20100607.exp. You will notice the file is a single line of Base64 encoding. Method: Either use software such as nipper (a tool to automatically decode multi-vendor firewall, router, switch etc.. configurations then analyse the settings and make recommendations in a pretty report) or Base64 decode it yourself and read the variables. Linux: 'base64 -d file' Windows (if you have ActiveState Perl): 'c:\bin\decode-base64.bat file' Recommendation: Often issues such as SSH v1 and SNMP will be present. Also check the firmware as SonicWALL is notorious for format string bugs. Over the past 6 months, a new rootkit known as Max++, ZeroAccess, Sirefef (and others) has been impacting a significant number of businesses and home users.
Recently, OSI Security responded to a client affected by this malware:
To fix this issue, the TCP/IP stack needs to be working (check Device Management, Hidden Devices and TCP/IP may have the yellow exclamation mark if the device is not working). In our situtation, TCP/IP would not start because a group dependency failed. The IPSEC Service wouldn't start, and a check of the system32\drivers directory showed ipsec.sys driver was missing. To fix, get the ipsec.sy_ (cab) file from the Windows CD-ROM in the i386 directory and extract it to C:\Windows\system32\drivers\ipsec.sys. For example, go to Start -> Run -> cmd.exe, then in the command prompt type (assuming D:\ is your Windows install CD). extract d:\i386\ipsec.sy_ c:\Windows\system32\drivers\ipsec.sys If the above command worked as expected, you should now be able to go to Services (services.msc) and start the IPSEC Service. If it started as hoped, you should now reboot and find that the issue with ipconfig / the network adapter not being able to obtain an IP address is now resolved. If not, consider doing the same extract for tcpip.sy_ and doing a 'netsh ip reset all' and 'netsh winsock reset catalog' then rebooting. Once we resolved this matter, we encountered another issue:
This occurs because the Microsoft Windows TCP/IP stack or Winsock API is corrupted. Specifically, the nslookup tool works because it is sending DNS lookup information directly across the wire, whereas everything else uses the Windows host operating system's Winsock gethostbyname() API which is broken. To fix, firstly reboot into the Microsoft Windows Recovery Console, then (where D:\ is the Windows install CD-ROM); expand D:\i386\dnsapi.dl_ C:\Windows\system32\dnsapi.dll expand D:\i386\dnsrslvr.dl_ C:\Windows\system32\dnsrslvr.dll Reboot and you should find that nslookup, ping, Internet Explorer etc is now functioning as expected. Note 1: Under normal Windows, the command is 'extract' to extract a CAB file (the .sy_ or .dl_ files). Under the Recovery Console, the command is 'expand'. Using either is fine for ipsec, tcpip, dnsapi, dnsrslvr files however you will likely find using 'extract' is denied as the destination file is in use by Windows and cannot be replaced - thus, you may wish to use the Recovery Console and 'expand' for all 4 files to avoid the file in use / access denied message. Note 2: We observed other users with similar issues i.e. nslookup works but ping does not. The above dnsapi.dll and dnsrslvr.dll replacement should in theory resolve the issue, irrespective of presence of any malware. Worth trying.. Good luck! |
Archives
September 2017
Categories
All
|
RSS Feed
|
NSW Government ICT Services (SCM0020) approved supplier
|
|
|
|
|
|
|
|
OSI Security is proud to support a number of recognised charities, development projects and industry groups...
|
|
|
|
|