As a 10 year veteran, I offer that they very clearly need to revisit their gameplan for the following reasons.
The apparent total lack of a disaster recovery plan
The vulnerability was known for a month, the patch released for two weeks, and either wasn't noticed by the admin, put off for a rainy day, or was too daunting because of the all-powerful RPM system
The number of open services to the world *should* be relatively small. The 40 machines patched 99.9% don't matter. Not to patch your main ftp, web, or cvs server is (criminally?) negligent.
A friend of mine, Dan Holliman, suggested that we write an apache module that performs exactly this. When the module receives a request to the default.ida path, it sends an HTTP query back to the requestor's IP using the hole to cause a system reboot or freeze, or to remove the default route or interface on that box.
The apparent total lack of a disaster recovery plan
The vulnerability was known for a month, the patch released for two weeks, and either wasn't noticed by the admin, put off for a rainy day, or was too daunting because of the all-powerful RPM system
The number of open services to the world *should* be relatively small. The 40 machines patched 99.9% don't matter. Not to patch your main ftp, web, or cvs server is (criminally?) negligent.
A friend of mine, Dan Holliman, suggested that we write an apache module that performs exactly this. When the module receives a request to the default.ida path, it sends an HTTP query back to the requestor's IP using the hole to cause a system reboot or freeze, or to remove the default route or interface on that box.