Articles with tag - Cluster

29.09 20107

My take on MS10-070 – A tricky patch

ASP.Net logo, brokenLast night I attended the Microsoft Security Response Team webcast regarding the Out Of Band patch for the ASP.net padding Oracle vulnerability discovered by Juliana Rizzo and Thai Duong 11 days before.

My main objective in watching the webcast (which is not my usual habit) was to find out if systems that have the described workaround applied still need to apply the patch. The webcast did not give a definitive answer but this YouTube video and the Netifera website and the twitter accounts Thai Duong provide the answer: Yes you should apply the patch a.s.a.p!

YouTube Preview Image

However the Q&A section of the talk did give me, as a security operations guy, quite some food for thought. I made some notes in my own Twitter feed, which I have summarized here.

Q: Why did Microsoft release and OOB update for a vulnerability rated “only” as important?
A: The vulnerability itself is rated as Important because it is not a vulnerability that directly leads to remote code execution on the vulnerable system, however exploitation of the vulnerability will lead to disclosure of all information in the webroot including web.config. This information can be used for session hijacking, compromising backend databases and to attack associations between websites, e.g. the association of a website with PayPal. Hence an out of band patch was warranted.

Q: Why only release to the download center and not to WSUS etc?
A: We felt we needed to get this update out quickly, the people that need to apply this patch quickly are mainly enterprises who are capable of applying patches without the aid of WSUS. Developing the WSUS capabilities would add another few days of delay to the deployment of this patch.

Q: Is the attack actively used?

 

read more
09.10 20090

BUG (and work around): Persistent routing issue on Win2k8 clusters

Another good (shoudl I say brilliant?) information from our collegue Elianne van der Kamp.

Yesterday we discovered an issue with Windows 2008 clusters: manually added persistent routes disappear from the active routes table, when taking offline (or failing over) a cluster group containing an ip-address-resource.

This issue is documented here. This same article also describes a workaround for when you have multiple gateways on multiple NIS’c.

By changing your route add command from e.g. <route add 10.1.0.0 mask 255.255.255.0 10.1.0.1 –p> to <route add 10.1.0.0 mask 255.255.255.0 0.0.0.0 if 25>

With this second command you bind the route to the interface instead of an ip-address. And since it is now bound to a local device any cluster failover will leave the route in the routing table.

However this will not solve the issue we discovered yesterday: We are using 2 gateways ‘behind’ the same interface. So binding the route to the interface will not help here.

Example interface 18: 192.168.251.36 mask 255.255.255.0 192.168.251.1, with added route 192.168.250.0 mask 255.255.255.0 192.168.251.3 –p.

When an ip-address will be taken offline (fails over) the Active route 192.168.250.0 255.255.255.0 192.168.251.3 will be removed.

Accidentally we found out that adding the interface to the route will solve this new issue (thanks our collegue Enrico). So our new route command will have to look like this:

<Route add 192.168.250.0 mask 255.255.255.0 192.168.251.3 if 18>. This will leave the route in the active routes table.

Why does this work? And is it reliable?

Since we couldn’t find any google/Microsoft hits on this particular issue, we had to do a little registry digging.

The standard command <Route add 192.168.250.0 mask 255.255.255.0 192.168.251.3 > just adds the persistent route to the registry which triggers the ‘bug’.

However the new command <Route add 192.168.250.0 mask 255.255.255.0 192.168.251.3 if 18> also makes 14 changes in the cluster part of the registry telling it that this route is bound to the adapter and to be left behind on the local server in case of a failover

So I think it look pretty reliable. We did lots of reboots and failovers on the cluster and the routes seem pretty persistent now..

read more
02.07 20090

ESX Cluster Stretched over two DC’s…

While doing some research found this article on the Pro’s and Con’s of stretched ESX cluster across two datacenters.

A stretched cluster is the practice of having ESX member servers in a cluster that are geographically separated.   The reason this is generally done is to provide the ability to dynamically move workloads from one datacenter to another.   Often, the customer is also considering it for disaster recovery purposes (“I’ll just VMotion in case of a disaster”).  Can this be done – ABSOLUTELY – but not considered lightly.

More here: http://virtualgeek.typepad.com/virtual_geek/2008/06/the-case-for-an.html

read more