Deep Rants

It's a pitiful state of affairs. That is, balancing the day job with the vain attempt to keep one's finger on the pulse of the net consisting of limited reports sourcing from the minority of security clueful. It's sad to say but today is not much different, it's more of the same; bots, spam, phish, malicious code, those who fall for it, compromised hosts at non-responsive hosting providers, dev-nulled abuse mailboxes, open egress/ingress policies, SNMP foolishness, lack of validation before publication, *BREATHE*, AntiVirus updates without technical detail, unenforced AUPs, nonexistant AUPs, identity theft, corporate information loss, SOX and HIPAA violations, false positives, zero patch management and mailing list FUD... And No, I'm not Denis Leary.
Seriously. I can't address every issue that I rant about, but I've selected one that I deal with frequently.

CYA - Protecting your corporate "assets"

In addition to handler status, I'm a member of a response team that frequently handles corporate network incident response involving malicious code... namely bots. We have a short list of mitigations that resonate in every incident and find that implementation of these risk mitigators can go a long way toward reducing if not preventing future outbreaks. These protective measures are not exhaustive, but can be deployed at a higher tier in your architecture further removed from managing the host level. I'm not going to talk about workstation security policies, or the gimme of running up to date and active AntiVirus products, and no reference will be given to running host level application firewalls.

What can be done?

Centralize network egress If you haven't already consolidated your access to the Internet, fighting the botnet fight will be that much harder if your networks have many paths to the public Internet at large.
Employ Egress filtering Block everything going out to the world that is unnecessary for business. Policies are a good candidate for a new bullet point, so if you don't have them currently in place develop them. Do you connect to windows fileshares on the net? Block outbound access. Do you tftp gets and puts to the net? Block outbound access. Better yet, start from scratch and block everything, Establish your minimum outbound networking requirements, allow just that, and require all new connectivity to navigate an access request process. Force web traffic through restrictive proxy servers, arbitrary outbound TCP port 80 and 443 is a nightmare waiting to happen, or maybe just waiting for you to discover.
Centralize your logging Without easy access to logging from Firewalls, VPN concentrators and other network devices finding the threat from within becomes unnecessarily complicated. If you have identified a botnet controller on the net, you can quickly build a map of compromises of your network by identifying all connections to the malicious host(s). You can also identify possible secondary stage payload infections through the analysis of connectivity sourcing from infected hosts to internet destinations shared by the whole of your infection base.
Deploy Intrusion Sensors Finding the traditional IRC based botnet with intrusion sensor technology is easy and unending fun. Really. Unending fun. HTTP and UDP based bots get a bit trickier but are not impossible to detect, but for time and space I'm choosing not going to get into that at this moment. I personally love to watch IRC "JOIN" and "PRIVMSG" sensor alerts. You of course should modify your signatures to look for IRC communication on ALL ports not just IRC default ports, many botnet operators choose TCP ports including 443, 5190, 8080 and potentially anywhere in the 64K range for managing their botnets. Come to think of it, I don't think I've seen a port 0 botnet controller. :)
Establish flexible routing control You should have strong control of your horizontal as well as your vertical. Once a malicious controller has been identified, cut off access to the controller by advertising a null route across your network to make short work of it, this provides some breathing room to your people on the street that have the problem of physical access involved in malware response. If you have absolute remote network administrative control of every node on your network, it's that much better for you. With additional network routing tricks instead of null routing, you can control traffic path and get into some more complicated but very exciting areas of sinkholing and Honeynet technology which I'm very passionate about. However, I'm not opening that can of worms in this forum for the complexity and legal issues that I'm sure many would be quick to offer me an earful.
DNS - Blackholes, Poisoning and Reporting Botnet control is a mobile threat. If you have control of your DNS infrastructure you can protect your networks by intentionally poisoning "your" internal resolvers. You can establish zone files for known malicious botnet controller hostnames that would effectively prevent botnet herding miscreants from gaining control of any botted hosts on your network through the update of DNS records which could evade your null route on any previously known botnet controller IP by for EXAMPLE simply pointing the DNS A record for badbot.botcontroller.net to 10.0.1.128. Control of DNS makes sinkholing your botted infrastructure a trivial task. It's worth mentioning if you have the ability to take control of IP 10.0.1.128 on your network, dynamic DNS hosting providers have seemingly taken to using that IP as the blackhole for DNS records used primarily in the control of bots. If you log queries, you can determine the DNS A records behind the IP you discovered bots connecting to. If you can't enable full logging, investigate the possibility of employing Passive DNS query logging that will not provide you with a one to one match of client request to hostname query, but can still provide historical IP to name record matches.
I imagine some folks will be a little bit miffed regarding the lack of technical and how-to detail in the above statements, but I'm expecting that we'll be able to expand and dive into detail for the specific topics listed above in future diaries. This is just the starting point.
With a little bit of help I'm sure we could make this a minimum of a top 10 list for botnet fighting strategies. Help us flesh it out, you are welcome to provide us with some examples of what you do to actively protect your networks from botnets and the random, ever present malicious code threat.
-With Respect and tribute to Carl Douglas, "Everybody was BotNet Fighting...".

Malware Response - part 2 postponed

In my <A HREF="http://isc.sans.org/diary.php?date=2005-06-13">last diary</A> I mentioned that in my next diary (the one you are reading) I would offer response techniques leveraging the use of SBD as a malware acquisition tool. Well, I didn't really want to be called a liar, but I've earned the title. Next diary, I will most definitely provide at least a brief procedure that is by no means perfect when it comes to identifying every case of infectious/malicious code, but in my experience and the thousands of machines I've investigated, only a handful of hosts required any closer inspection to acquire malicious code samples. BTW, We haven't receive any reader input on remote command line response techniques, so I have to imagine it must be that you forgot to hit send on that draft email. It's okay, don't be shy. Go back to your drafts folder and hit send. Everybody's doing it.

William Salusky

wsalusky at gmail dot com

Handler on Duty (heh heh...)