- Jan 05, 2010 by the_angry_angel
Over the last few days there's been an interesting debate on NANOG [1] over the usefulness of firewalls. Although NANOG focuses on much larger networks than I typically look after, the topic of conversation does present some arguments that are interesting, and some which I simply hadn't considered because I've never been directly on the receiving end of what you could ever consider a large attack.
Roland Dobbins makes a very good point, and it's the main one that hadn't really twigged in my brain. Servers, by their nature, sit there listening for unsolicited communication. Using a stateful firewall could be considered overkill, provided that you have some degree of control over the hardware in-front of the server(s). ACLs are much faster, especially as they're typically handled in hardware on routers and switches. Combine this with hardened servers [2] and you're onto a good start.
Although some vendors are now doing stateful filtering in hardware, it's still likely that the firewall can be made to fall over before the host, by exhausting the state table. You can resolve this by making the firewall highly available, but you're ultimately only postponing the problem and simply waiting for someone able to launch a bigger attack. You're now in a hardware and cash race.
When this happens you're probably at the point of being worried by large attacks; you're a big target (such as facebook or twitter), or you're a service provider. In these circumstances detecting potential attacks and null routing the traffic, or forcing it to go through a scrubbing mechanism, you can make them useful. Fortunately for us at the much smaller end of the things, these generally aren't things we need to worry about (although I'd seriously love to set it up and play with it on real hardware [3]), and are something we can run to the service provider about.
At the end of the day us small guys and girls can only go so far. Our domain of control is much, much smaller. If you're renting very small quantities of servers you may well not have access to the hardware in front of your box(es) to implement some lovely hardware based ACLs (although 1and1 did provide this feature last time I had servers with them). For us in this situation there really isn't much of an option if you want some form of control over stuff that hits your box(es).
Ultimately I'm not advocating for the stateful firewall to go away. Hopefully that's clear. They've definitely got their uses; such as protecting a gaggle of clients, and perhaps single servers. All I'm trying to say is that sometimes you don't always need a sledgehammer, a tack hammer will do. Just make sure that the little tack hammer is more prominent in your mental toolbox!
I'll certainly be thinking a lot more carefully when it comes to all of the technical decisions over the next few months. After all, you never know - there could be all sorts of really elegant solutions that you've been dismissing.
[1] It all started with "D/DoS mitigation hardware/software needed" and is currently continuing under "I don't need no stinking firewall!".
[2] Really, turn stuff off on external cards you don't need. Like NetBIOS, networking for Windows. Bind servers to the interfaces or addresses they need. Don't be lazy.
[3] Lets be honest, virtual labs just aren't as fun.
- Jan 05, 2010 by the_angry_angel
Over Christmas we had to do a bunch of VMWare to Hyper-V conversions at work. Once you've sufficiently prepared the VM, there are a whole bunch of ways you can do this, ranging from raw converting the vmdk, to mounting the vmdk and a blank vhd and then copying the contents between. We chose it as an opportunity to play with Disk2VHD from SysInternals.
If you're using SCSI disks in your VMWare VM then you will first need to ensure that you add the IDE controller driver, to hopefully avoid a BSOD when you boot under Hyper-V for the first time. Why don't you just set Hyper-V to use SCSI disks? Sadly because Hyper-V cannot boot from SCSI. Once you've added the driver and rebooted to ensure that it's stuck we simply ran Disk2VHD and pumped the VHD off to a network share.
Interestingly Windows 2003 x64 and 2008 were a lot more resistant to the change in "hardware" than older Windows versions, which needed a Windows repair, however I can't fault Disk2VHD for that as it was something I was expecting anyway.
What worried me most was that the first run we did Disk2VHD produced a mangled VHD which I managed to repair and get working by doing the following;
- Mounted the VHD and declined Windows offer to format the partition it could see.
- Extended the partition so that it filled the VHD (for some reason it had left a whole load of space free - none of the other conversions did this). I chose to use diskpart, but whatever you're comfortable with.
- Ran TestDisk to ensure that all was ok with the partition. In this case it threw up some weird error that I failed to note down and right now I can't 100% remember for sure if TestDisk helped or not. A chkdsk /f was definitely able to, however. After this the VHD was in perfect working order.
Fortunately all other conversions didn't seem to have this issue, and as much as I would've loved to investigate why this happened, I just didn't have the time.
- Dec 22, 2009 by the_angry_angel
If you've noticed that the next Ubuntu Server version (10.4, Lucid Lynx) has the Hyper-V kernel modules packaged, alebit in drivers/staging, I'd suggest not dist-upgrade'ing even your development servers for the moment. The reason is simply that you need to devote time to ensuring that the kernel modules will continue to work with each kernel version - right now you can't seem to rely on the modules actually loading successfully from the corresponding /lib/modules/2.6.*/kernel/drivers/staging/hv directory. Which isn't a problem, provided that you have the time to deal with it.
The long and short of it is that if you're currently looking to use any flavour of Linux under Hyper-V the "old" rules still apply;
- Use the legacy network adapter
- Set static MAC addresses under the VM settings (unless you want to faff with udev)
- and learn to live with the performance penalty
- Dec 18, 2009 by the_angry_angel
If you're even slightly geeky you will have seen any of several articles in the last 2 years that state "the URL is dead". With the inclusion of the search box in many browsers this is starting to become true, and is starting to present some interesting support challenges.
Every now and then you will need someone to visit a specific site, and you might not be able to connect to the user's device to assist. The solution in most cases is to politely educate the user (or get another user to assist) and move on, but I have had a few users who have been unable to understand the concept that the address/location input is actually what we're looking for. Perhaps the user has removed or shrunk the location bar so that its really insignificant, or perhaps they're just really too stressed to follow simple instructions.
For publically accessible websites the answer is to ensure that your site can be reliably found via all the major search engines, and have a link if necessary. This means that SEO becomes an important feature of your support framework. This is scary but something that very well will become a genuine systems and support concern.
Things get worse for internal-only addresses. In theory you shouldn't be in the position where you're not able to remotely assist a user inside of your own network, but lets face it, shit does happen - or it might be a guest/embedded device (such as a WiFi enabled phone). Whats the answer in this instance? Application level filtering and redirection in your proxy server(s)?
- Dec 13, 2009 by the_angry_angel
The last 6 months I've seen 3 companies that I've used both professionally and personally for various services using CC to mass email their clients. This is not acceptable. As result one of my personal accounts is on various lists and receives a marked increase in junk mail.
The latest cock up came from MessageLabs. This is a company that provides email services. If they can't get this right, what hope is there for anyone else out there? If you're in the business of mass emailing any of your customers please, please either send individual mails or use BCC, and make sure that your staff understand why. It's not just a case of your customer's privacy, it's your company's also. Whos to say that on your list you don't have someone who want to steal your business?
This whole cock up doesn't fill me with confidence for MessageLabs, which is unfortunate as Symantec has bought Softscan, whom we use for mail filtering at work and they're now pushing new contracts onto the MessageLabs system instead. It begs the question as to whether or not they're actually technically a competent solution in comparison. In the past I've only had bad experiences. Anyone want to weigh in?
