Over the past two decades in this profession, I’ve worked with a number of great people and shared many ideas with many people. It’s the part of the job I enjoy most – sharing ideas and learning from the people I talk to. One question I’ve been asked over and over in one form or another is how to implement network controls to prevent unplanned outages or defend against the next fast-spreading worm.
My first article on the topic goes back more than a few years, back to the days of the Code Red worm. We looked at the attack vector and instead of focusing on the worm itself, we looked at what it used to spread. Applying an attack tree methodology, it became evident that the worm, and many that followed, used the TFTP service on the endpoint to spread from machine to the next. If we blocked TFTP at the network layer we could stop the attack from spreading. By focusing on a single common vector we didn’t need to write new access rules for every worm and were able to block the common method of propagation.
In the days before NAC or widespread SMS deployments, this approach helped curb many of the successors from gaining ground. As for TFTP, many of the customers that I have consulted with did not have a use for that protocol on their ordinary desktop. It was relegated for use within IT for upgrading infrastructure and the like.
We expanded our attack tree methodology and looked at other common problems and started to map services that could be blocked easily at the user port, without affecting network operations. In fact, restricting these applications to the data center improves network availability and reduces costs. An example of cost reductions can be found in my Interop blog post “8 Simple Rules for Using My Network”. In one show, restricting data center services reduced help desk volume by more than 30%!
Think about common problems you may have experienced over the years on your own LAN. Has someone incorrectly attached a router that starts offering invalid addresses to your corporate machines? Have you been challenged by end-points running services that impact your users? I’ve compiled a simple list of protocols that can be statically mapped to the data center. In addition to our earlier study, I’ve include DHCP server (UDP 67), DNS server and SMTP along with topology protocols that shouldn’t be sourced from a traditional user port. A collection of these can be found in a 2009 article I wrote on the topic “10 Policies to a More Secure Network”.
I hope you found this inaugural post of mine useful, and I am interested your comments regarding network filters or other tips you’ve found useful. I’d like to include them in future versions and even possibly add them to our network templates in our Policy Manager product.