Some folks here responsible for keeping the computers patched up were looking to add some functionality to their patching capabilities. They were looking to use our PC’s wake-on-LAN features to power the computers up in the middle of the night so they can be patched outside of normal working hours. A few months back management decreed the (politically correct) policy of everyone needing to turn their PC off when they leave for the evening. This, as you can imagine, has made it difficult to patch computers during the off hours.
The solution? You guessed it – we’re now using directed broadcasts. Our patching software has some functionality that utilizes directed broadcasts along with the wake-on-LAN capability of the PC’s NIC cards to power up all of the PC’s on a remote subnet, patch ‘em up, and then shut them back down. Pretty cool stuff.
For those of you not quite familiar with the concept, a directed broadcast is a packet destined for the broadcast address of a remote subnet. Security types generally considered these type of packets to be a no-no, due to their vulnerability to a denial-of-service attack called a Smurf attack.
Fortunately, we already have a pretty decent base for foiling these kind of attacks. Any traffic of this type coming from an outside source (even through our remotely connected clients) would not be allowed into our internal network, even if an attacker was doing something funky like spoofing their source address. So we only need to really worry about malicious traffic being sourced from inside the enterprise (which I suppose COULD happen if someone hacked access to one of our internal servers – but I doubt they’d bother with a Smurf attack if they made it that far).
So to utilize directed broadcasts in the safest way, we’re taking a two-pronged solution:
- Only allow directed broadcasts from the specific server(s) that are doing the patching.
- Verify the source address of any directed broadcasts that are sent out.
The first requirement is pretty simple on Cisco gear. The ip-directed broadcast {list} command will allow directed broadcasts on the interface it is configured on, and you can utilize an access-list for the list portion of the command to allow directed broadcasts only from IPs specified by the ACL.
Things are a bit more complicated on a few Juniper Netscreens (running NetOS) we have in production. There is no command that has the functionality of the ip-directed broadcast command, so we have to improvise a bit. First, we set a static arp address to that subnet’s broadcast address. The command ends up looking like this set arp 192.168.1.255 ffffffff trust. This command statically maps the broadcast IP to the broadcast mac address out of the Netscreen’s trust interface. We then can limit the directed-broadcasts to certain sources by defining a policy for that source traffic.
For the second part of our solution, verifying the source addresses, we’re using the Cisco feature Unicast Reverse-Path Forwarding where appropriate.
The result? Everything is good. The security guys are happy with the solution. The patching team is patching away to their heart’s content. And myself and my colleagues have proved our usefulness and survived another day.
If you’d like to read a bit more on the subject, I came across this article yesterday where the author is also dealing with Cisco Wake-On-LAN issues.
Thanks for reading,
Jason