Dawson College: What Island Are You On?

I've been viewing the growing story about Ahmed Al-Khabaz, a Computer Science student at Dawson College in Montreal, Canada, who was expelled for running a security scan against their public web presence to discover if a flaw he found was resolved. I stumbled on a subsequent interview with prominent IT Security professional Chris Wysopal. I hadn't heard of him, but when I saw he was previously associated with l0pht Heavy Industries my eyes snapped open.

This guy has credentials, and I don't know of an IT professional active around 1997 to 2003 who hadn't heard of, or actually used, l0pthcrack, often to solve real-world problems. First and foremost a password auditing tool it can be used maliciously, but the so can a toaster oven. It is a piece of code art: Necessary, useful and (at the time) industry-shaking.

White Hat hacking is a tricky business. Even I've done it, against a bank no less, fully in the knowledge that I was doing something the system owners would be very unhappy about. In some cases it can get you arrested. I was was pleased with the results when my concerns were taken seriously and fixed fairly quickly. I've worked in financial services companies and know their software release process is iceberg slow so this was very reassuring. There's one thing Mr Al-Khabaz and I both know that drives thousands around the world to the same end: I'm at risk.

Dawson College is hand-wringing and special pleading: "the law ... forbids us from discussing your personal student files" is in this case weak. I am pretty sure the former student would agree to a waiver of his right to privacy to clear the air, but I have seen no mention of an offer. Fourteen out the fifteen professors convened voted for his expulsion, for doing what some professionals get paid extremely well to do (even I've been offered this job): Evaluate the security of publicly-accessible websites. I would like someone better informed than me to comment on what the implications would be for the institution if it was discovered a breach because of this flaw caused losses thanks to the personal information disclosed.

I can appreciate that the college does in fact have to abide by law, and is unwilling to get into a mudslinging match in the public forum. They have rules for ethical behaviour that may have been violated (I haven't seen them). But beyond those considerations, every one of the fourteen professors needs to answer one simple question:

Why, if these actions are so outrageous of a Computer Science graduate that it demonstrates
"behavior that is unacceptable in a computing professional" has the company whose software flaws he exposed taken it upon themselve to pay for his further education?

Academia is often seen as disconnected from reality; some lines of research beggar belief, and the same could be said of Computer Science. I've met a few graduates who arrive in the IT industry ill-prepared, full of theory of operation and design but unable to command a command-line. No matter what their actual instruction is, a critical point they need to learn is that the Internet is a hostile place. It is also a collaborative place, where FOSS abounds and Creative Commons is richly rewarding. Poking around is the norm, and if this college is telling their students that they are to accept their instruction blindly without considering real-world implications, or use those skills to explore, then they don't deserve to be associated with the term Higher Education.

They may perhaps be able to educate Code Monkeys, but thinking professionals able to design and protect systems that impact their lives? Not really.

Do the ends still matter?

One of the biggest conflicts of interest in my role as an infrastructure architect (I'm responsible for servers, applications, security, storage etc) is that I have a heavily vested interest in the service they provide. This may sound like a no-brainer, but often I need to find ways to get my traffic to users at the expense of someone else. I want preferential treatment if conflicts with other traffic.
Of course, it's not quite as simple as that. Pragmatically I realise I am competing with others on limited resources, whether it's rack space, hypervisor RAM or network bandwidth. One of the less-known principles underlying the Internet ethos is the End-to-end Principle. Put simply, it's this:
Complexity in any network should be implemented in the end points - the network stacks of communicating nodes and in applications - and not in the network itself. Since standards change any benefit of implementing too much intelligence in the network is quickly undermined with the need to continually match those changes in end-points, as well as legacy issues.
Essentially, the network should be as dumb as possible. Packet comes in, packet goes out, wait for next packet. This is reasonable in principle but different traffic flows require different treatments - VoIP and video streaming protocols prefer low latency and are almost always jitter sensitive, while file transfers can tolerate enormous latencies as long as they are accompanied by high bandwidth. If both types occupy the same link the risk is that the insensitive consumption of one protocol can impact the requirements of another, so QoS arrives.
This is already a necessary evil (though some may object to my use of that label in this context) since we now need to build knowledge of services into the network layer. Large IP transport installations (Internet backbones) handling gigabits of traffic per second literally don't have the time to implement protocols like this as processing adds both cost and latency. This is different from implementing different virtual circuits for different traffic types, in that it forms logic links and is a very common practice with ISPs in the final mile. As far as intelligence on network devices go, this is very low - again packets come in, figure out where packets go out.
A very interesting turn is in the development of new forms of network acceleration. Routers have long been capable of doing in-line compression of data to reduce consumption of a specific link, but this is point-to-point. If an application protocol can truly benefit from compression, this really should be done at the application protocol level (basically above Layer 3) so routers and switches can shuffle packets. A possible side-effect of link compression is to mask real versus usable bandwidth from applications (some portions of a stream may be highly compressible, others not) hindering flow-control algorithms built into TCP.
TCP sessions can be rather chatty, and some applications implement redundant techniques inside their own specification, so some network acceleration can initially make sense. Essentially, new sessions follow a well-known pattern of window sizes and other parameters, so network accelerators intercept packets and simulate the repetitive parts on each end of a link, reducing session setup time. This sounds simple, but now we enter dangerous waters. Next comes protocol caching; I request a file from a file server across the WAN and the contents are cached on my local acceleration appliance so that the user next to me can get a cached copy when her request is made. Again, sounds simple, but to prevent interception and modification the protocol implements signing, so re-generated content requires a re-generated signature. SSL acceleration similarly can be implemented using reverse proxies holding a copy of the private key for the service to extract the plaintext and look for compression and caching opportunities. I've been involved in design and deployment of many reverse proxy and SSL acceleration projects but these were explicitly part of the service.
To accelerate generic payloads the appliance needs to get heavily involved in the infrastructure, either by hosting all SSL keys and being able to masquerade as endpoints. This is where it gets very complex and risky, not only in the dissemination of privileged access (private keys and domain credentials being the most highly-prized items in any network), but also a continual catch-up game to implement these techniques on newer protocols as they are developed. There are also more intrusive techniques such as automatic downscaling of images when using mobile data to browse the web that are subtle but insidious.
Net Neutrality is the overall drive in this direction and correlates with the End-to-end Principle, treating network devices as simplistic and all traffic as equal.Smarter protocols such as (distributed) BranchCache and BitTorrent (yes, BitTorrent is a case for Net Neutrality) reduce redundancy over constrained links and better content intelligence (I explicitly convert all images in my documents to 8-bit PNGs before embedding) are far better strategies. Content distribution networks are an active participant and used by some of the largest providers (both content generators and ISPs) to reduce long-haul bandwidth and improve user responsiveness. HTTP compression is a rigorously defined standard but very sparsely used even on static pages where on-the-fly zipping is unnecessary. I could go on...
When looking into how best to transport content I prefer to let the network do what it does best and work my requirements into it than engineer a network to suit my needs unless absolutely necessary. Where my application is burdensome, I would prefer to engineer the application than throw bandwidth at the problem.
Technology marches, and bandwidth - while logically finite - seems to be keeping up rather well.

Zero-effort Theft Tracking

This little nugget (nhinkle on SuperUser blog) popped up on Slashdot recently, describing just how Windows 7 (and I presume Windows Vista) knows whether your network connection is an unrestricted Internet conenction, has no connectivity beyond the local LAN or are behind a hotspot authorisation page. Of course, the state of your network connection may be more complex than that (proxy server requiring authorisation, badly configured routing, or wrongly reporting a working connection that drops your VPN traffic), but it's mostly quite good.

Essentially, the first thing the Network Location Awareness service does is check if it can retrieve a url specified in the registry, and if the contents of that file match a set string. If successful, NLA assumes you have full connectivity. If it fails, a DNS lookup similarly needs to match a specified IP, in which case it assumes you need to authenticate (e.g. you're on a hotspot).

The privacy concern is that your system is checking-in with a server controlled by Microsoft every time it attaches to a network, and periodically after that. Obviously, nobody knows how or if Microsoft is using any logs of these check-ins, but it opens an intriguing possibility now that instructions in the article reveal how to customise this behaviour. Essentially, you can instruct NLA to check-in with any URL you like.

As long as the file is retrieved with a 200 OK result and the string matches (apparently it's even sensitive to an extra CR/LF, so make sure it's generated correctly), everything is hunky-dory. But here's another possibility...

The URL retrieved doesn't have to be a simple text file. The URL could actually query a script (PHP, ASP(X) etc), as long as it returns a specified result. Using Group Policy, an administrator can update the URL to include a client-specific parameter (say an asset code, MAC address, serial number, username etc) in the form of http://some.server.com/NLACheckin.php?Serial=1234. The server script can then note the source IP/subnet of the request in a database, and presto! Real-time location tracking. Group Policies and/or client-side scripts make this rather trivial.

The great part of this is that it doesn't require any specific check-in, theft tracking or other location software to be installed, and the service cannot be disabled by an ordinary user. It doesn't look like there's any action that can be launched on a specific response in the client end (say shuitting down the device), but it offers an extremely simple way to find stolen computers. It's no defense against a wipe-and-reinstall, but for the gain it's well worth the effort.

 

Getting IP Right in Windows: 5. NAT is not a Firewall

Networking in Windows is deceptively easy. The level of development Microsoft has achieved to make it so is quite considerable, and I contrast it here with the amount of tweaking required to get Unix services off the ground.

That said, a well-implemented IP structure is the cornerstone of any enterprise (or even serious home) office deployment. I’ve composed a series of five articles on topics you should be really getting right! There are certainly more, but these stick out in my mind.

5. NAT is not a Firewall

Here’s the part where I put on my flame-resistant suit. I know this is divisive, so let it be known this part is entirely my opinion :)

NAT was devised as a mechanism for hosts on networks with incompatible routing structures (either overlapping network numbers or RPIPA addresses seeking Internet connectivity) to have their addresses transformed into something more palatable. This happens every day in millions of home and corporate routers and firewalls, allowing millions more computers to consume Internet services without consuming the Internet’s most precious resource – global IP addresses.

Since these private networks use IP space that cannot be Internet routed, they are translated on the fly to, typically, one address which is what the destination sees as the source, while the router/firewall maintains a mapping of who asked for what from where, so that replies make it back to the requestor. If a packet arrives that has no apparent previous relationship to an internal host, it is dropped. In this way, NAT is an implied firewall, dropping unsolicited packets from the nasty Internet. Of course, if we need, say, HTTP or VoIP to be let in, we poke some holes and make exceptions.

Precisely because this is an implicit form of security, it is dangerous. Security is all about paying attention, making sure we understand how a threat can enter a network, how the people are affected (or risks themselves), what systems are vulnerable and how to defend against them etc. Defense in Depth, an NSA-derived concept, is all about layering security at different points in the network to increase the overall robustness.

Yet so often, NAT is simply assumed to be a line of defense. True, unsolicited traffic is bounced, but this causes problems for traffic like FTP (unless the firewall has application-layer awareness) and VoIP, whose Session Initiation Protocol has a rough time of NAT. Why then is the security only played out one way?

A commonly portrayed threat is of a trojan application or other type of malware being installed on your computer, scanning for personal data like credit cards and bank statements then uploading them to the nefarious source. NAT, in assuming that your network is the safe place and the Internet bad, gladly allows the outbound traffic through without question, and bang goes your credit rating.

IPv6 makes the need for NAT moot, since the address space and allocation policy should allow everyone to hold their own huge chunk of the address space with Internet-valid addresses. I haven’t yet seen a convincing argument why NAT should live on in an IPv6 world.

While NAT does indeed provide a great amount of protection, blindly approving that it makes you safer is missing the point. IP is a versatile protocol suite, and the fact that NAT is so readily implemented proves it, but without a little attention, you’re letting your router vendor dictate how your network is protected.

Recent versions of Windows include a host-based firewall, allowing each device to control what traffic is allowed to arrive at the network interfaces, and even what traffic is allowed out. Get to know the workings of the firewall and how to define the rules that are appropriate for your environment, including specific applications and how they communicate. Unfortunately, a lot of the protocols used on Windows tend to negotiate dynamic ports for communication, but since the firewall is also application-aware (specific executables are allowed to communicate instead of simply this or that port), it is a fairly easy task to secure your Windows hosts from a lot of the prevalent threats.

Enterprises know this and carefully craft the types of traffic that are allowed in and out of the network, with a little thought your networks can be secure, responsive and available.

Previous: 4. Disable NetBIOS

Getting IP Right in Windows: 3. IPv6 is coming

Networking in Windows is deceptively easy. The level of development Microsoft has achieved to make it so is quite considerable, and I contrast it here with the amount of tweaking required to get Unix services off the ground.

That said, a well-implemented IP structure is the cornerstone of any enterprise (or even serious home) office deployment. I’ve composed a series of five articles on topics you should be really getting right! There are certainly more, but these stick out in my mind.

3. IPv6 is coming

If you haven’t already started looking at IPv6, you should. Even though there are billions of valid IPv4 addresses, a lot are wasted by the way they’re carved up so there won’t be enough to go around. The predictions of doom get revised by the week, but at the very least the protocols themselves are long overdue for a makeover, and you should get ready sooner than later/

IPv6 includes some considerable improvements, the most obvious and famous is the gargantuan address size, so big we have to dump it down to images like addressing every grain of sand of every beach on the planet.

The big benefit here is that address spaces virtually as large as the entire IPv4 space can be assigned to single countries, and over-provisioning of the space is a key factor in deciding how to carve it up. Internet routers have a lot of work deciding which of the myriad paths is right for traffic, and by dividing the space into these huge units, the routing tables can become much, much smaller, allowing the Internet to continue it’s amazing rate of expansion.

But the address space is only one of the improvements. Considerable work has been done to ensure IPv6 networks just work. One of these innovations is the creation of link-local addresses, a form of DHCP, and Router Solicitation. The task of configuring your devices has been moved from your centralised or distributed DHCP server to the devices that know your network the best: your routers.

IPv4 evolved from the first networks mostly when 256kbps was FAST! The protocols have been extended and augmented with things like Quality of Service, IPSec and all kinds of other solutions for secure (and plain) tunnelling. This has resulted in a confusing array of features and incompatibilities.

IPv6 includes a lot of these as standard (IPSec is now mandatory), and improves on others. QoS is vitally important for letting your routers know that your VoIP conversation is much more important than downloading your iTunes purchase, and IPv6 handles these decisions much more intelligently and consistently. Each part of the data packet (IP header, IP payload, TCP/UDP payload, and frequently the application itself) is also checksummed to detect errors, and each layer adds its own checksum, so IPv6 assumes these problems will be detected higher up in the protocol stack and does away with its own layer, further increasing speed.

You should even be able to request addresses for your entire organisation that are all internet-valid, doing away with RPIPA-type addressing (as I mentioned in my previous post here). How organisations deal with the change is still to be seen, but I sincerely hope NAT dies the death it deserves. More on this in my later article, NAT is not a Firewall.

Not all ISPs route or offer the protocol yet, nor do most Internet services, so don’t expect your Internet connection to be switched over any time soon. Versions of Windows from Vista and Server 2003 onwards (XP/2000 has limited support) now including IPv6 out-the-box running gladly alongside the IPv4 stack, you’re free to experiment and explore.

These are challenges you’ll be facing before long, so getting to grips now is well worth the effort.

Previous: 2. Subnets and Private IP space
Next: 4. Disable NetBIOS

Getting IP Right in Windows: 2. Subnets and Private IP space

Networking in Windows is deceptively easy. The level of development Microsoft has achieved to make it so is quite considerable, and I contrast it here with the amount of tweaking required to get Unix services off the ground.

That said, a well-implemented IP structure is the cornerstone of any enterprise (or even serious home) office deployment. I’ve composed a series of five articles on topics you should be really getting right! There are certainly more, but these stick out in my mind.

2. Subnets and Private IP space

The IP address space is global, centrally controlled and handed out to the bigger ISPs and national controlling bodies in big chunks, and broken into progressively smaller groups to hand out to their customers.

Knowing how to carve the IP address space into networks, subnets, supernets, using broadcast domains and multicasts can be readily understood with a little thought, is certainly very logical, and a bit of planning up front can save you a lot of headache down the line. A great graphical explanation can be found here, and a famous graphical map of world’s IP space is here.

If you’re not responsible for the network design at your organisation, have a chat with the guy who is to understand the principles, how it is expected to evolve over time and what you can expect as it does.

IPX was all the vogue in Novell’s heyday, and it is still a neat protocol, able to route across a vast network, but without a central registry for network numbers it was easy to find conflicts, and certainly inappropriate for Internet-type deployments, hence the rise of IP in the corporate space.

I worked at a 2,500+ user company that had a randomly chosen Class-A IP network to deploy internally, at the time I discovered these numbers had officially been assigned to the People’s Republic of China. Thankfully, none of the business interest lay there, but getting these overlapping networks to communicate had there been a need would have been a tedious task.

A special class of IP address are the Reserved Private IP Addresses (RPIPA), and if an Internet router sees traffic from or to these, it is simply discarded, so you can be certain you won’t conflict with someone on the Internet and deploy them as you like!

192.168.0.0/16 is probably the most well-known, and the two most common (192.168.0.0/24 and 192.168.1.0/24) are used almost universally in the default configuration of home routers. Since home networks rarely get integrated with others, this tends to work just fine.

Unfortunately, this also means that a lot of inexperienced network engineers use these as a default. In fact windows XP Internet Connection Sharing (ICS) requires that the internal interface receive the 192.168.0.1/24 address, no other will do, and they’re so common that very little attention is required to remember them.

But that’s the problem. This can lead to big headaches when two sites with these common subnets do want to communicate, from simple VPN access to your company network to handling a merger and linking it up to your network. There are two other ranges to choose from (172.16.0.0/12 and 10.0.0/8) offering literally hundreds of thousands of the good-old 24-bit subnets, so get creative.

A well-implemented DNS (as I wrote about earlier) will mask your numbering for day-to-day tasks, DHCP keeps track of the pool of assigned addresses, and if you're managing a larger network with different WAN links and routers, you should be documenting it in a coherent design anyway, so there isn’t much of a reason not to.

Previous: 1. Understand DNS
Next: 3. IPv6 is Coming

Getting IP Right in Windows: 1. Understand DNS

Networking in Windows is deceptively easy. The level of development Microsoft has achieved to make it so is quite considerable, and I contrast it here with the amount of tweaking required to get Unix services off the ground.

That said, a well-implemented IP structure is the cornerstone of any enterprise (or even serious home) office deployment. I’ve composed a series of five articles on topics you should be really getting right! There are certainly more, but these stick out in my mind.

1. Understand DNS

IP addressing is a computer task, in that is involves computations of 32- or 128-bit integers. It’s only for our clumsy brains that dotted-decimal notation was devised (and no amount of fudging improves IPv6 legibility), and hostnames are even simpler since they gives us names to work with, easier on the grey matter.

DNS is the magic that transforms the two, and it is involved in almost every conversation and transaction on the LAN, and certainly on the Internet, perhaps not continually, but certainly at the start of a digital dialogue.

Get to know the DNS namespaces:

• Domains; In the first IP networks, the hosts of the entire fledgling ‘Net were stored in one grand file, which simply couldn’t scale to today’s Internet, so they’re broken down to domains, with distributed control and querying. These are the most jealously guarded servers on the Internet, as compromise causes outages and have serious security implications
• Hostnames; Every box has one, and it helps to have a standard to make things easy to locate and avoid conflicts. Understand how they relate to the domain space – a common practice to differentiate the interfaces on a system is to register different address suffixes on the hostname depending on the function (e.g. server1.mydomain.net, server1.backups.mydomain.net), so it’s useful to know how they relate to each other

DNS consists of various record types, depending on the kind of information you’re looking for:

• A/AAAA; The simplest type of record, it maps a textual hostname to an IP address (IPv4 for A, IPv6 for AAAA). This is just the hostname portion, and is only useful in the context of a domain (see my later post on the evils of NetBIOS)
• CNAME; This is an alias, useful for making an abstract name like www out of webserver1 for instance, and when multiple entries are used together, send users asking for www to one of webserver1, webserver2 and webserver3 without having to let your users know the difference.
• PTR; This make backwards resolutions from IP addresses to names, and is useful for debugging or checking the identity of incoming connections
• MX; Mail eXchanger records tell the world how to get mail to your domain, with rules on precedence and load-balancing
• SRV; The newest in the family, and more and more widely used. A critical record for operation of your Active Directory domains and services, this record helps clients and servers figure out where they are on the network (sites), where the nearest service provider is (e.g. local domain controller) and even where to go if the local service is unavailable (e.g. lowest cost neighbouring AD site)

By getting into the habit of using Fully Qualified Domain Names (FQDNs) for your network activities, you’ll avoid common pitfalls such as failing (or mismatched) requests for a service in another domain, connecting to the wrong interface, or even just helping you map out the network in your head.

Wherever possible (and this doesn’t work everywhere I’d hope), use the User Principal Name (UPN) for your Active Directory logins and when asked for credentials instead of the old NT style, e.g.

Liam.Dennehy@leptech.lan – good!
LEPTECHDOM1\Liam – legacy, outdated. Not good!

All of this helps you put the resources in your Windows network in their correct place, avoids confusion and generally makes your life a bit easier in the long-run.

Next: 2. Subnets and Private IP Space