How to prevent cache pollution... http://support.microsoft.com/default.aspx?scid=kb;en-us;241352

I'd never leave a DNS server directly exposed on the internet.  Proper network design, in my opinion, requires that some kind of filtering/IDS be sitting in front of such a box.  Doesn't matter if its DNS, HTTP, FTP, running BIND, M$, with Apache, IIS, SQL, mySQL, etc... Why would you leave it sitting there all alone?  At least have Snort running on the same subnet to alert someone if junk traffic comes in!

Anyway - check your DNS servers... make sure they're clean!

Its my practice to have strict regulations for server traffic.  Especially ones that are published to the internet through some NAT/proxy/port forwarding.  My internal servers have no direct internet traffic unless its initiated from the outside.  For maintenance (You check your boxes nightly, don't you? :P), I open rules for antivirus/IDS rule updates, software patches, and then lock the thing down again (no unsolicited outbound traffic).  I don't know what kind of servers you run, but why would you allow unsolicited HTTP outbound on your webserver?  Or leave port 135 open?  Slap an ISA Server in front of it if you MUST have port 135 available.

I think the most dangerous thing is how eager some system administrators are to "get the job done".  Just "opening the port to the world" is absolutely ridiculous.  I don't care how secure it is, be it FTP, SSH, MS SQL, FileMaker, VNC, remote desktop... why would you leave such ports wide open?

Enforce perimeter security!  I use a simple dyndns.org DNS verification on my servers where possible.  So ports are only open to certain DNS names (the rules are updated every 5 mins or so...).  So if I'm on the road, my DNS updater client updates my roaming DNS entry, I wait a few minutes, and then I have full access to the ports.  Then slap on the extra encryption/security on the actual protocol. (POP3S instead of POP3, SMTPS instead of SMTP, HTTPS instead of HTTP.)  Don't let ANYONE get to a Terminal Services (or equivalent login prompt) unless they're at the right IP address.  Then make sure those passwords are secure.

Yes, technology is meant to be ubiqutous, but so is properly implemented and designed security.  If you can't secure it, don't open the port.  Sure, it "would be nice" if users can do *blah blah blah* from home - but at what cost?  Do not compromise security for functionality - a properly implemented network has security and functionality working hand in hand.

Baseline your systems and verify compliance to the baseline network port profile, monitor all threads and processes for unrecognized/unauthorized activity.

Because if you don't -- I'd hate to be the one explaining why your servers were hacked/compromised.  Its so easy to blame the software manufacturers, isn't it?  To blame Microsoft for not writing "secure" code.  "Oh there's another security patch...! Tsk tsk tsk..." Most of these patches wouldn't even affect a properly configured server. Why blame Microsoft for ANOTHER Outlook security problem if you're the one allowing EXEs that are CLEARLY packaged trojans? Or not even monitoring inbound attachments? Why would you allow inbound VBS scripts?

Wireless networks are also headaches.  Keep MAC address authentication enabled, and SSID broadcasting disabled.  Plug access points into managed switches and keep another ACL on the port to make sure only authorized traffic is flowing.  WEP encryption is useless - it just slows you down.  If you need to transmit secure data, plug/route your wireless VLANs into a VPN server and force VPN tunnels on all traffic into your internal network.

Carefully designed network perimeter security is key.  You need attachment inspection on your SMTP gateways - packages like F-Secure for Exchange, Antigen for Microsoft SMTP has worked wonderfully for me.  As for spam... heh... Symantec Brightmail or GFI MailEssentials?  The folks at Finjan also seem to have their act together.

I'm tired of hearing people tell me how insecure Microsoft products are - because they're not.  Microsoft systems get compromised because the "system administrators" fail to not only look after the systems, but to design a tight network in the first place.  It doesn't matter who writes the OS, or if its open or closed source.  You're asking for trouble if you leave critical network assets unprotected and unmonitored.