- Dec 13, 2011 by the_angry_angel
- Microsoft, Developers and Motives
The majority of IT workers are aware of Steve Ballmer's "developers, developers, developers" incantation from 2006. Earlier this year Ballmer performed a repeat of Microsoft's modern day rain dance at BUILD 2011.
Due to this philosophy Microsoft have produced some pretty nice tools for developers and designers. I'm told (admittedly by a more Microsoft orientated HCI designer) that XAML is the dogs bollocks. I don't really mix with many other UI or HCI designers, so that maybe very biased and it's out of the scope of things I'm interested in. However generally speaking, I believe that Microsoft are widely considered to be behind when it comes to producing what is considered to be cool and "bleeding edge" - not just in the circles that I roam.
Combine the developer orientated philosophy and what are most likely newer, and younger, employees and I believe you get the Microsoft that the world is seeing today. A Microsoft who is contributing patches to projects that have garnered a reasonable amount of developers attention in the last year - NodeJs and Redis are two that spring to mind immediately - as well as long established projects, including the Linux kernel (I was going to ramble on that one, but I'll save it for another time).
Paul Querna brought up a related anecdote whilst talking to Venture Beat a few weeks ago; he got into developing after installing Perl on Windows. Ultimately many people hacking together code must be starting from this point because of the sheer pervasiveness of Windows. The loss of these developers as they progress is the issue at hand for the Microsoft of today and the future. Microsoft needs to retain developers on their platforms.
With the world moving into a more cloud-y (bleurgh, I mean SaaS/IaaS/PaaS - delete as appropriate) environment, retaining control over the developer will become increasingly important to Microsoft. After all, if you're developing on Windows, using the latest and coolest tech, deploying on Windows is a logical, and safe, step for most professional developers. And if the developer wants to run cloud based Windows, where else would you go, other than with the developers of Windows itself? After all, who better understands and importantly has a hot line to the developers and source?
The reason for this, painfully obvious post? Apparently it's not painfully obvious to some.
Is this something to be worried about? Not yet, and here's to hoping that it will never be.
I know that the content of this entry is common knowledge among certain circles, especially after an email to van Hauser of The Hackers Choice (THC), and some time spent this afternoon checking out a few mailing lists.
However this is not who I'm aiming this post at. Or that's what I'm telling myself so that I don't feel like I've wasted a few hours of my life over the course of 2 days. This post is aimed at those who do not have a large amount of experience with IPv6, be it system or network administrators, or just general passers by. Or people on facebook, where this will end up being syndicated.
If you want to skip this ridiculously long post, and check out the extremely quickly hacked together proof of concept code, head to github.com/theangryangel/deprecate-ipv6-slaac.
I'll start off with a quick bit on IPv6 address configuration. In comparison to IPv4, there are 2 ways to dynamically configure an interface with an address. Stateless Address AutoConfiguration (commonly called SLAAC), and DHCPv6. Both SLAAC and DHCPv6 require a router to be sending out multicast packets (called Router Advertisements, or RAs), stating what prefix(es) the router is capable of routing, what length these prefixes are, and a bunch of other details. For the purposes of the rest of this post I'm going to focus on SLAAC.
SLAAC addresses have 2 lifetimes attached to them; "preferred" and "valid". Once an address has a preferred lifetime of 0, only pre-existing network traffic may use this address. Any new traffic MUST use a different one. The address is then marked as deprecated until the valid lifetime reaches 0, at which point the device must remove the address.
Now the clever guys and girls behind the relevant RFCs designed it so that any changed options between RAs for a prefix being used by a device, such as lifetime, must be honored when different from those previously collected. The only special case is that the valid lifetime cannot be set below 2 hours.
If you're following you should see that there's a very simple way of changing the values for many of the settings.
This isn't the biggest issue in my opinion - mostly because RAs are here to stay. That's been made abundantly clear in the last few years. There is a potential fix with SEcure Neighbor Discovery (SEND) (see RFC3971), but that in itself has other issues.
No, the big issue as I see right now is down to how the current tools we use to manage IPs display this information on desktop, server and embedded operating systems. All of the more commonly used tools and places that most sysadmins interrogate, state nothing about an IP being deprecated. Until an address has reached a valid lifetime of 0, the address is still displayed. It is not until you get down into lesser used components of some network tools, that you can see the state of these addresses. All the major OS' that I played with have this problem. Windows ipconfig, and GUIs say nothing about addresses being deprecated, and ifconfig on all the unix-likes that I've played with also have the issue. However, if you get down into netsh or ip for example, then you will see the state. Even then it's not displayed under the commands that you would generally use.
This means that for all intents and purposes, with the right administrative team who doesn't know IPv6 well enough, you can knock out parts of an IPv6 network, causing it to fall back to other prefixes, or IPv4. If you've managed to MITM, or otherwise exploit IPv4, then you're laughing.
The sheer number of administrators who are not knowledgeable enough about IPv6, and the number of networks that are driving to be dual stacked, it has to make you wonder - what's the opportunity here? For the naughty people, obviously...
What about RA guard (RA equivalent of DHCP guard)? Fragment the packets and you've basically negated RA guard. I've only had the opportunity to test this on a few implementations, but it looks like THC are way ahead of me on this one. Other than that, SEND (which has no support anywhere effectively), and MAC filtering on switch ports I can't immediately see any other methods of mitigation.
If you're interested I've published a simple proof of concept tool, using Scapy, on github.com/theangryangel/deprecate-ipv6-slaac. It has 2 modes of operation; manual and fully automatic. Manual, where you must provide all the details of your target network's router, so MAC address, link local IPv6 address, prefix and so on. Automatic, where it will listen for the first RA and then steal all the information from that packet, and then send out on your behalf.
The proof of concept is very noddy and will fall over. It's written and tested under Linux only.
Next on my play list is DHCPv6 and DHCPv6-PD next. Thinking there's some fun to be had with the RECONFIGURE part of the protocol.
Bear with me. I've not gone completely insane.
When I first started doing IT stuff professionally I found it reasonably common that the go to excuse from other technical people, when they didn't know the answer and didn't know how to find out the answer and didn't want to admit that they didn't know, was that the program or data had become corrupt. To being with this made me laugh, especially when it was something completely innocuous, such as a shortcut being wrong (seriously, that happened).
Over time I began to find utter disdain for these technical staff who instead of admitting that they didn't know the answer, or didn't spend the time understand the problem properly before reaching for this excuse.
About 2 years ago I saw this excuse disappear. I rejoiced. Unfortunately it was not so. I simply had failed to notice that I just wasn't dealing with these sorts of problems any more.
The last few months I've had to get in touch with one particular customer's third party support for their financials, stock and reporting software a few times. This company is now also our partner, of sorts.
Apparently it is now cool to blame everything on file system permissions. Unhelpful when it's just their software not being configured at all, or even better, a prerequisite of their software not installed.
Not knowing is not a crime in the company that I work at (unless the staff member has been told repeatedly). Not admitting to it, or not asking for help is, and I do wish that was more common.
- Jun 02, 2011 by the_angry_angel
- Virtualisation, Linux, Hyper-V, Debian and Ubuntu
Whilst it's possible to get Debian, and by proxy Ubuntu, running under Hyper-V it's nice to see that Microsoft are potentially going to officially support them along side CentOS, Red Hat and SuSE.
As someone who is running Debian and Ubuntu under Hyper-V I would heartily welcome this official support.
Sadly I suspect that if Gupta really does represent Microsoft's view, then the odds of getting on the official list is probably going to be quite low;
"Gupta says Microsoft is drawing the line at 'touching' the Linux code. It won't provide patches."
I'm afraid that for this blog entry you're going to have to sit through some "bullshit-back-story".
For whatever reason our live cluster, running under System Center Virtual Machine Manager (SCVMM) 2008 R2 had gained duplicate copies of 3 virtual machines, and all the duplicate VMs (Virtual Machines) were marked as missing.
SCVMM is a relatively new "toy" for me, however I'm already starting to feel the love-hate relationship growing, probably indicated by the fact that I'm referring to it as "scum" to my co-workers and friends. My point being forgive me if this is common knowledge. It doesn't appear to be.
Delving deeper the Failover Cluster Manager MMC was showing only a single copy of the virtual machines in question. That narrowed it down to just SCVMM being the problem child. All attempts to perform a repair, or even an attempt at removal (despite my better judgement) in SCVMM itself resulted in a bullshit error message. Frankly a restore at 23:00 isn't exactly what I'd want to have been doing any way, so I was somewhat pleased by that.
Poking further there appeared to be a MS KB (KB2308590) that directly addressed this problem No joy.
So, doing what I always do in these situations, I started prodding at the database that powers SCVMM, using SQL Studio Manager. Yeah it's a GUI, but it was nearly midnight, and it was easier.
If you're using the default database you'll want to connect to COMPUTERNAME\MICROSOFT$VMM$. Otherwise it'll be where ever you specified at install. The table that interests most of all is the tbl_WLC_VObject. If you select with a where statement to find your problem machines you should fine that you have duplicate entries. Carefully choose the entry that is not running, and delete it. Luckily our duplicates had no tags, and no owners, so it was actually fairly easy to figure out which ones to remove. Close and reload the SCVMM console and you should find that you have a less scary looking SCVMM administration console.
I'm sure that there are some bits left behind in other tables that are referencing the VMs, however I'm going to bed. It can be tidied in the morning.
