Farewell LUGRadio?

Given it's all over the forums and it's now the end of day after the release of the episode: "LUGRadio will be finishing after LUGRadio Live UK 2008" (so that's basically 2 remaining episodes, including LRL)!

There are various reasons for this, and if you're not already aware of them I'd suggest listening to S5E21 yourself. To have a hovis moment, I discovered LUGRadio at the start of season 2, which culminated in LRL 2005. I never made that LRL, nor the following 2 UK events due to various reasons, despite my best intentions and plans of going. So here I am, stuck with a dilemma - do I follow my own little personal tradition or should I say "sod it all" and head up to Wolverhampton for the last big bash from the 4 large gents? As the gents would say; answers on a postcard!

If, like me, you're looking to fill the void soon to be left by LUGradio do not despair, for there alternatives (but never replacements) which I shall try over the coming weeks;

If I don't make it to LRL 2008 let me take this opportunity to thank the presenters (Jono Bacon, Stuart Langridge, Stephen Parkes, Matthew Revell, Ade Bradshaw, Adam Sweet and Chris Procter) who over the years have given me many laughs and much enjoyment.

Linux on Hyper-V

Unless you've been living in a hole for the past few days, or you're seriously anti-Windows or simply not into your virtualisation at all, you're probably aware that Hyper-V, the replacement for Virtual Server 2005, has gone "gold" (RTM).

There's all sorts of news on this, but little in the way of unix and unix-like related info on the web. Despite having 2 customers with it at work, I've not had the opportunity to try any of the unix-like systems on it either.

Sean on the other hand has had the time and opportunity, and has posted a nice round up of Linux distros which work and a few work arounds for known issues, all in his entry entitled "Linux on Hyper-V".

Black Windows logon screen?

We had a good one at work the other day. One of our customer's terminal servers, from their load balanced cluster, had run out of diskspace on C:\, due to a rogue update of some bespoke software and a lack of quotas. This is something which was missed from the config, but we or the customer never noticed, as we're pretty good at monitoring this stuff and resolving the issue before it causes trouble. Sadly this happened so quickly that it avoided the monitoring in this instance.

To cut a long story short the disk space was regained, but any logon attempts to the terminal server yielded a completely black screen, with exception to the Microsoft logo. We figured it was a client side caching problem, but it was not so.

Turns out that when the disk space on the primary partition (C:\) fills up the default colours can be overwritten, which results in the black logon screen.

KB906510 details the fix, but not so much that it's caused by the disk space issue. If you're looking for a quick fix to the default colours, then just save the following as a reg file and import it.Windows Registry Editor Version 5.00 [HKEY_USERS\.DEFAULT\Control Panel\Colors] "ActiveBorder"="212 208 200" "ActiveTitle"="10 36 106" "AppWorkSpace"="128 128 128" "Background"="102 111 116" "ButtonAlternateFace"="181 181 181" "ButtonDkShadow"="64 64 64" "ButtonFace"="212 208 200" "ButtonHilight"="255 255 255" "ButtonLight"="212 208 200" "ButtonShadow"="128 128 128" "ButtonText"="0 0 0" "GradientActiveTitle"="166 202 240" "GradientInactiveTitle"="192 192 192" "GrayText"="128 128 128" "Hilight"="10 36 106" "HilightText"="255 255 255" "HotTrackingColor"="0 0 128" "InactiveBorder"="212 208 200" "InactiveTitle"="128 128 128" "InactiveTitleText"="212 208 200" "InfoText"="0 0 0" "InfoWindow"="255 255 225" "Menu"="212 208 200" "MenuText"="0 0 0" "Scrollbar"="212 208 200" "TitleText"="255 255 255" "Window"="255 255 255" "WindowFrame"="0 0 0" "WindowText"="0 0 0"Or if you don't trust me just export HKU\.DEFAULT\Control Panel\Colors from a "working" Windows server. The effects are instant.

Here be dragons

The "SBS Diva" very recently posted about unfettered access to port 3389. Incase you need the blanks filled in this would be the default Remote Desktop Protocol (RDP) port, which is used to manage any relatively recent Windows box, 99% of the time.

The general take in the Windows admin world is that open RDP is basically a very bad idea and that you should protect it in some way. I'm not against this as a concept at all, and I want to make this very clear. I do have a problem with most common implementation behind "securing" it.

Despite this in some circumstances it's not necessarily an option to lock something down down, so the service remains publically open. This doesn't necessarily mean you're going to "OMGWTFZ h@x0r3d" within 10 seconds. You are likely to see brute force attempts every now and then, in the instance of RDP, much like you can see people trying to brute force FTP or SSH servers. If you factor this into the equation from the beginning then an open service isn't necessarily as large a problem as you might imagine.

At the end of the you can make the life for any attacker harder;

  1. Rename any default accounts - Most of the brute force attacks you see use default usernames, be it 'administrator', 'root' or your name (if the attacker is targetting you specifically).
  2. Employ additional authentication, such as two factor auth.
  3. Use your logs wisely - Setup the server/domain to log any failed logons and then some software to monitor that. Get it to notify you of a significant number of logon failures (lets say 3 consecutive) and then take action. Depending on what firewall, etc. you have available and what you use to monitor the system will vary on what you can do. Simply getting a notification is better than nothing. Tools like fail2ban or denyhosts can be very handy in the Unix-like world, and there's no reason why similiar things cannot be implemented for other platforms. I can think of various tools that can monitor logs and preform actions on Windows, off the top of my head (although several are commercial).
  4. Change the service away from the default port number - this is security through obscurity though, and eventually someone will probably find it.
  5. Lock it down at the firewall so only specific IPs can talk to the service
  6. Hide it behind a port knocking, or port rotation mechanism
  7. Hide it behind a VPN
  8. Use an IPSec policy to secure any incoming traffic to the RDP port (negotiate and require security)

There are, of course, other things you can do on a case-by-case basis. To my mind the automated monitoring and response is probably one of the better solutions, but I'd be relatively happy to implement the first 4 options, should a client stipulate a need to have something like RDP or SSH wide open.

However, I do have issues with the remaining options and in particular the VPN solution, which a lot of Windows admins rant about and yet use PPTP without any form of quarantine/NAC behind it (i.e. once you're connected, you're in). And here's why; Anything that requires some form of authentication, on a service that is even partially open by default, can be attacked, be it brute force, dictionary, and so on. The tools may not be available but if the protocol, or method of obsfuscation, is documented the tools can be written. Even then the tools can be written with enough time, patience and determination - which has been proven many times over. In the immortal words of a 70s SciFi: "Gentlemen, we have the technology";

  • IKECrack or psk-crack for IPsec PSKs
  • ASLEAP for Cisco LEAP and PPTP
  • THC PPTP for PPTP
  • TSGrinder, or TSCrack for Terminal Services
  • and so on and on and on...

The great thing is that there are various repositories, libraries, guides, search engines, and of course distros which make these things available for everyone, so I'm not sure there's any excuse. But, it's really up to you to decide, just how far you want to go to protect any public services and how desirable access to your systems are to an outsider, at the end of the day.

Parsing XML from the command line

This evening I had the fun of finally getting around to repairing a number of bash scripts which I use to automate a number of tasks on my personal servers. One of these parses a RSS feed and then downloads content, much like bashpodder, although unfortunately the data isn't encapsulated as nicely as you would expect in a regular podcast feed.

In the past I've solved this by using sed, and as quick and as easy as this is, it mings massively when you need to update it for whatever reason.

Rather than rewrite the entire script in another language I hit google. My first result was a fantastic tool, called XMLStarlet, that I'd not heard anything about. The blurb describes it as "a command line toolkit to query/edit/check/transform XML documents", and quite frankly it does exactly that. Nothing more, nothing less. What it fails to make a big deal about is that it's simple, and cross platform.

A quick example of using it to echo out the value of each title tag, from the RSS feed generated by example.com, would be as follows;

wget -q 'http://example.com/rss2.xml' -O - 2>/dev/null | xmlstarlet sel -t -m '/rss/channel/item' -n -v 'title'

mgrouch and arcanum - my hat goes off to you in thanks!

 1 2 3 Next →