I found this *AWESOME* website while testing an Exchange 2007 server for an ActiveSync issue. Thanks, Microsoft!
https://www.testexchangeconnectivity.com/

Cryptednets.org now supports all major (and some minor) mobile web browsers.
Check it out on your mobile device, and let me know how it’s working.

Lately, I’ve been ripping out and replacing antivirus software in the Enterprise. Funny thing is, most of these types of software do not have a remote uninstall utility. Being the famously lazy admin I am, I had no interest in logging into each workstation, and manually removing it.

Instead, I used psexec. It’s just one command in an awesome toolset written by Mark Russinovich called Pstools. So, I saved the following as a batch file, and executed it against all domain workstations. Here’s the contents of the symantec_removal.bat file:


REM save this as c:symantec_removal.bat
@reg add HKLMSOFTWAREIntelLANDeskVirusProtect6CurrentVersionAdministratorOnlySecurity /v UseVPUninstallPassword /t REG_DWORD /d 0 /f
@reg add HKLMSOFTWAREIntelLANDeskVirusProtect6CurrentVersionAdministratorOnlySecurity /v LockUnloadServices /t REG_DWORD /d 0 /f
msiexec /norestart /qn /x{46B63F23-2B4A-4525-A827-688026BE5E40}


Then, just install pstools into your PATH, and open a command prompt on the server, and do this:

psexec \* -c c:symantec_removal.bat

You’ll notice that the msiexec command has a GUID, so if your version of Symantec is different than mine, you’ll need the correct GUID for your version. This can be found here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Just look through the GUIDs located here until you find your version of Symantec. Then, just replace {46B63F23-2B4A-4525-A827-688026BE5E40} with the GUID found in your registry.

BTW – The first 2 lines in that batch file are for removing the uninstaller password from symantec antivirus. If you don’t use an uninstall password, you can remove them.

I wrote (swiped and altered) this script to check for a Symantec Uninstaller password. You might notice that it’s very similar to the Remote Desktop script I posted a while back. Still it works, and saves some time, so here it is:

symantec_uninstall_password_checker.bat

Recently, I needed to determine which local LAN hosts were infected with spyware on a network of Windows XP computers. This network is a single Active Directory Forest, with a single ‘domain.local’ domain name.
In the absence of any anti-spyware management tools, I decided to use the DNS server on the domain controller to help me determine which workstations were infected.

First, I changed the outbound forwarder servers to use OpenDNS. OpenDNS is a free recursive DNS service that you can use to resolve all DNS queries on the Internet safely. The reason for this is that the OpenDNS servers will re-direct your infected machine’s traffic away from known botnets and known distribution points for spyware to their own, essentially cutting off an infected workstation’s access from known “bad guys”.

Usually, when I implement the OpenDNS service on a LAN, I notice an *INSTANT* improvement in available bandwidth.. Try it for yourself. More info here: www.opendns.org

Next, you need to clear the cache on your DNS server. To do this, open DNS Management in your MMC, right-click the server, and click “Clear cache”. Now, click “View”, and “Advanced” in the MMC’s menu, and you can now view the cache.
Right-click the server again, and click “Properties”.
On the “Logging” tab, turn on “Debug Logging”, note or set the location of the log to be written.
Now, right-click the server, and click “All Tasks” -> “Restart” to restart the DNS service.
Since most spyware infected hosts need to phone home on a regular basis, you can now just watch the cache for incriminating lookups, and read the DNS debug log for the IP address of the offending hosts.
Anyway, it worked for me, and I was able to identify the 3 hosts on the LAN that had spyware infections, in about 10 mins… (without staring at a protocol analyzer…)

Note: Do not forget to turn the DNS debug logging off again when you are finished. This logfile will grow *very* quickly, and become difficult to open or manage within hours on a busy LAN.

antivirus on linux is like lipstick on a pig… sure, you can put it there, but it’s a waste of time, and it annoys the pig…

Have you ever set up 150 workstations, all from one cloned base image, and forgotten to turn on Remote Desktop? Even if you haven’t, this may save you some work. Save the following batch script to your desktop, and double-click it.

remotely_enable_rdp.bat

Thanks, Microsoft!

Sorry for the drastic measure, but I’ve only got about 1mb up and 1mb down, and I hate to be used by anyone as a DDoS reflector. My DNS server no longer allows queries for the root nameservers, (thx again, Kiter) and the block list has been cleared. The entire world may now freely access this site, though I’m not sure what for, save for some comic relief, and sparsely located golden nuggets of networking knowledge.
If you *do* happen to be reading this, just drop a comment to say “hey”.
You don’t even need to register…
It won’t hurt a bit…

There is a new(? or more frequently used?) method of DDoS attack being currently used against victim networks. This involves UDP queries from spoofed IP addresses, requesting the addresses for the DNS root servers. This turns misconfigured nameservers into a sort of DDoS “Reflector”, allowing attack amplification.

The reason for this is that it’s a really small UDP query (it’s a query for “. NS/IN”), resulting in a large amount of data “returned” to/at the victim’s network.
Here’s how it works:
The attacking server (let’s call them ns.attacker.net) spoofs the IP address of the victim (let’s call them victim.net), sending multiple UDP queries to many recursive, resolving DNS servers, pretending to be the victim host or network.

The attacker assumes the victim network’s IP
ns.victim.net:{high-order port} -> ns.resolvingDNSserver.net:53 . NS/IN

This query, when issued against any recursively resolving nameserver, will return the entire root nameserver list to the victim network, which is rather large in comparison with the query itself.

If your DNS server allows recursive queries to the general public, you may want to disable their ability to access your nameserver via UDP/53, or turn off their ability to make “. NS/IN” queries. (a query for the nameserver list of the “root” domain)
For BIND, you can add this line to the options section of your named.conf, stopping them from getting an answer to this query.

additional-from-cache no;

Alternatively, you can just disable the public’s ability to use UDP to query your nameservers, as a 3-way TCP handshake makes the IP spoofing almost impossible.

For further reading, check out this article by Don Jackson@SecureWorks:
http://www.secureworks.com/research/threats/dns-amplification

Thanks, Don… Great read!

Just in case there were any valid readers coming from Russia, I must apologize. I have blocked all traffic coming from Russia, due to a spoofed DNS attack appearing to come from invest-pool.ru servers.
Also, in case you’re wondering who is affected by this block, here’s a CIDR list of the Russian Federation IP address space.

If the spoofed DNS attack appearing to emanate from invest-pool.ru stops, I’ll lift the ban.
Thanks for the info, Kiter. I figured it may be something like that, but had no way to be sure.