markwilson.it

Tag: Security

  • Low cost SSL certificates from Go Daddy

    I have a number of web services running at home, some of which are SSL secured; however, they are only used by me (and a few select friends and colleagues) so, in theory, I could generate certificates by creating my own public key infrastructure (PKI) and add my certificate authority (CA) to the Trusted Root Certificate Authorities store. The trouble is that I’m lazy, and a CA is just another infrastructure service to run (it really is a bit geeky to have as many computers as I do), so I use a public certificate instead.

    Because I don’t require the highest levels of validation, I don’t need an expensive certificate from a class 1 CA like Verisign so last year I used a free certificate from Ascertia. No matter how hard I tried, I couldn’t complete the certification path or get clients to trust the Ascertia root certificate, but last night, Scotty McLeod mentioned low-cost certificates from and, crucially, Go Daddy is one of the trusted CAs in most web browsers (certainly recent versions of Internet Explorer, Firefox and Safari).

    Of course, there are other (more expensive) options available from Go Daddy and other CAs for longer certificate life, multiple top level domains, domain wildcards or higher levels of validation (hence trust) etc. but for $19.99, I bought a 12 month SSL certificate that will work with both servername.markwilson.co.uk and www.servername.markwilson.co.uk.

    SSL certificate from Go Daddy


    Go Daddy $14.99 SSL Sale!

  • BT Home Hub users beware

    I’ve just got back from a couple of weeks holiday – a rare opportunity to spend some quality time with my wife and sons. Over that time, blogging has taken a back seat – although I had taken my laptop with me it was on the basis that it was somewhere to back up the digital photos and anything remotely work-related was strictly banned… but I’m an Internet junkie and I just had to get online.

    Turning on the laptop revealed weak signals from a number of free wifi providers in the area with names like “Netgear”, “Linksys” and “D-Link”. Of course, these were unsecured access points using default configurations but more worrying were the wireless networks that Windows Vista classed as security-enabled, named “BTHomeHub-xxxx“.

    Available wireless networks, as reported in Windows VistaThe BT Home Hub is a popular ADSL router in the UK and, although I’ve never used one, judging by what I saw WEP appears to be the default configuration (I certainly didn’t find any evidence of anybody using anything else) – BT Home Hub users should be made aware that wired equivalent privacy (WEP) is by no means secure and can be cracked very quickly, as Michael Ossmann details in his WEP dead again articles part 1 and part 2 and as Steve Gibson explained in episode 89 of the Security Now podcast (transcript).

    I should stress that I did not use any of the methods that Mike or Steve describe to hack into anybody’s network but I was tempted. Next time I may even give it a try… all in the name of security research of course.

  • Improvements to the Windows firewall in Vista

    I recently attended a Windows Vista security session at Microsoft, presented by Steve Lamb. Windows Vista security is too broad to cover in a single presentation (or even in a single blog post!) but some of the key points that Steve concentrated on were around the Windows firewall and IPsec. This post picks up on the main points from Steve’s presentation.

    The Windows XP firewall was criticised by some because it only inspected inbound traffic. Microsoft responded to customer demands and, in Windows Vista, the firewall also inspects outbound traffic; however it should be noted that a compromised machine can have its firewall disabled, so the presence of the firewall is not a reason to feel complacent; indeed Steve Lamb used the term security theatre (http://en.wikipedia.org/wiki/Security_theatre) to highlight security products that promise much and offer little.

    Consider the following process:

    The fundamental issue with client firewalls

    I wrote about this problem a while back, but in short, outbound control can only be relied upon where the computer is not compromised and the user cares about security – i.e. not on those machines where it is needed (compromised computers where the users don’t care about security)! It can be useful for restricting known software from communicating; however in such cases, prompting should be disabled.

    Trying to find a balance between ease of use/flexibility and security, the default actions for the Windows firewall are:

    • Inbound – block most traffic, with a few exceptions.
    • Outbound – allow all interactive traffic but restrict services.

    Allow/block rules can be configured for programs, services, users, computers, protocols or ports.

    The Windows Vista firewall feature list is extended in other ways too:

    Windows XP SP2 Windows Vista
    Direction Inbound Inbound and outbound
    Default action Block Configurable for direction
    Packet Types TCP, UDP, some ICMP All
    Rule types Application, global ports, ICMP types Multiple conditions (programs, services, users, computers, protocols or ports)
    Rule actions Block Block, allow, bypass; with rule merge logic
    UI and tools Control Panel, netsh Control Panel, netsh, MMC
    APIs Public COM, private C More COM to expose rules, more C to expose features
    Remote management None Hardened RPC interface
    Group policy Administrative template MMC, netsh
    Terminology Exceptions; profiles Rules; categories

    The Windows filtering platform (WFP) is a series of APIs, designed to allow developers to hook into the network stack without requiring kernel changes. WFP provides authenticated communication, dynamic firewall configuration, a foundation for the Windows firewall and IPsec, works with encrypted traffic, and because it is fully documented there is little risk that a service pack release will break third-party applications. Architecturally, this also provides improvements with synchronous API calls, exposure of the user context for auditing policy changes, access control lists on API calls (no longer using registry ACLs and escaltion of privilege) and incremental policy updates.

    Firewall configuration is still available from the Control Panel (with a few minor presentation differences); however a new Windows Firewall with Advanced Security MMC snap-in is provided which can also be used to assign settings to remote computers and to apply IPsec configuration. The new MMC snap-in is complemented with a new netsh advfirewall command line interface.

    When merging and evaluating rules, the following order is applied, from highest priority to lowest:

    • Service restrictions (restricting connections that can be established by services – operating system services are configured appropriately by default).
    • Connection rules (restricting connections from particular computers using IPsec for authentication and authorisation).
    • Authenticated bypass (allowing specified computers to bypass other rules).
    • Block rules (explicitly blocking incoming or outgoing traffic).
    • Allow rules (explicitly allowing incoming or outgoing traffic).
    • Default rules (the default behaviour for a connection).

    It should be noted that these rules are stored in the registry; however editing them directly is unsupported.

    Firewall exceptions are also more flexible, including the ability to filter based on:

    • Active Directory user accounts and groups.
    • Source/destination IP addresses/range.
    • Source/destination TCP/UDP ports.
    • Comma-delimited list of ports.
    • IP protocol number.
    • Interface type.
    • ICMP type and code.
    • Services.

    Support is also provided for multiple network profiles:

    • Domain – domain joined and connected to the domain (i.e. able to authenticate).
    • Private – connected to a defined private network (home or work).
    • Public – all other networks.

    Network location awareness (NLA) detects networking changes and assigns each connection a GUID, whereby the network profile service (NPS) creates a profile upon connection and notifies the firewall whenever NLA detects a change. Local administrator privileges are required in order to define that a network is private and the computer defines the category when multiple interfaces are in use based on the logic in the accompanying diagram.

    Determining network state with multiple interfaces

    Windows Firewall group policy processing is also enhanced. Previously, computer policies were applied on operating system boot and user policies at logon, with a periodic refresh. Windows Vista extends this to apply computer and user policies when establishing a VPN connection or when resuming from hibernation/standby. Of course, firewall policies are set at the computer level, although they can be further restricted with per-user settings as previously described.

    Windows Vista enhanced IPsec capabilities are integrated with the Windows Firewall, eliminating confusion with overlapping rules and allowing firewall rules to be IPsec-aware. IPsec configuration has been simplified in Windows Vista but it is still a complex subject, worthy of a separate post; however there are a couple of points worth noting:

    • Authenticated headers (AH) traffic is not compatible with network address translation (NAT) as it cannot be routed – an alternative is to use encapsulated payload (ESP) with 0-bit encryption to effectively provide the same function.
    • Shared secrets are stored as plain text in the registry so should not be used in production scenarios – certificates or Kerberos should be used instead for authentication.

    In summary, Microsoft has made significant improvements to the Windows Firewall in Vista and anyone who is not using a third party product (and I would question the need for the use of third party firewalls in Vista) should turn it on right away, otherwise they are asking for trouble.

  • Working around UAC

    There’s been a lot written about Windows Vista’s user account control (UAC) and personally I can’t see what the criticsm is about (Mac OS X and Linux both have similar mechanisms, although the implementation is slightly different); however it was interesting to hear Steve Lamb mention at a recent event that commands launched from a command shell (cmd.exe) running as administrator will not invoke UAC.

    Of course it goes without saying that, just as when running a root shell in Linux, the use of such sessions should be limited and I’ve written previously about how the shortcut to run cmd.exe as an administrator can be modified to make it very obvious that elevated permissions are in use.

    Steve also pointed out that, if developers wrote less code that requires privileged execution, then UAC would not appear so frequently. Although UAC behaviour can be modified in group policy, it is not recommended.

  • What was that password again?

    In the course of my daily computing activities I have to remember hundreds of username and password combinations. Literally. Just at work there are two (yes two!) timesheet applications, then there’s my corporate domain credentials, remote access, mobile phone billing portal, etc., each with their own username and password complexity/expiry policies; then there are all the systems at home; and finally the plethora of websites at which I have an account.

    There are those who say that writing down credentials is a bad idea, whilst others say that using a single username and password combination is bad practice – these people are absolutely correct as, once compromised, an attacker has access to all the systems that use those credentials but we also need to be pragmatic – how can any user seriously be expected to remember all the usernames and passwords for the multitude of systems that they access? Indeed, many of the credentials I used are stored in my browser’s password manager – I haven’t a clue what my password is and I just open up the page and let my browser auto-complete the fields for me.

    If we cast our minds back a few years to the launch of the Microsoft.net Framework, Passport.net was supposed to take away a lot of the hassle for web service authentication and we all know what a failure Passport was (outside Microsoft) – people just didn’t want Microsoft holding the keys to all their systems – InfoCard could well succeed where Passport failed but I have an identity crisis right here, right now!

    One of the systems that I access regularly was recently moved to a new server – hence to a new URL and so the stored username and password didn’t work for me. This is where one of the handy system utilities that I wrote about a while back came in useful – I went to the old URL for the application, let the browser auto-complete the details and Nirsoft AsterWin IE was able to scan for the stored password, which I could then manually enter at the new site.

    Of course, this advice comes with all the usual caveats when using third party applications to probe for security details… I haven’t checked for any unwanted side effects of using this application and you have been warned!

  • SSH addendum

    Since my recent posts about using SSH to securely remote administer Mac OS X, Linux and Windows computers, a couple of extra points have come up that are probably worth noting:

    • To use the console interactively, it may be better to use PuTTY (putty) than PuTTY Link (plink). In seems that PuTTY Link is fine for setting up a tunnel and then connecting using VNC, RDP or another remote control method but I found that control codes were echoed to the console window when I connected to a Linux of Windows computer and the command line experience was generally better using PuTTY interactively. This is because (quoting from the PuTTY documentation) “The output sent by the server will be written straight to your command prompt window, which will most likely not interpret terminal control codes in the way the server expects it to […] Interactive connections like this are not the main point of Plink”.
    • For another method of generating SSH keys, an online SSH key generator is available (I haven’t tried it myself).

  • Secure, remote administration of a Windows computer

    I was going to call this post “secure, remote administration of a Windows computer from within Windows” but that sounds a bit odd, unless you realise that the last two posts have been “secure, remote administration of a Linux computer from within Windows” and “secure, remote administration of a Mac OS X computer from within Windows“. Basically, after getting SSH tunneling to work for administering Mac OS X and Linux machines, I thought that it would make sense to apply the same principles to Windows.

    John Fitzgibbon’s comparison of free SSH and SCP programs for Windows 9x, NT, ME, 2000 and XP explains the various SSH server options for Windows but one option he doesn’t mention is Tevfik Karagülle’s CopSSH, which I found on a list of free SSH implementations recommended by OpenSSH.

    CopSSH bundles parts of OpenSSL, OpenSSH and Cygwin into a Windows installer. It’s straightforward to install, and includes a GUI interface to activate a user for SSH, including the generation of a public/private key pair (saved to %programfiles%\copSSH\username\username.key and %programfiles%\copSSH\username\username.key.pub). The private key needs to be imported into PuTTYgen after which it can be saved in PuTTY’s .PPK format and used as previously described for Mac OS X and Linux. The only other point to note is that the sshd_config file is stored in %programfiles%\copSSH\etc and requires the same AllowTcpForwarding yes and PasswordAuthentication no settings as seen previously.

    To access the desktop via VNC, I installed UltraVNC Server on the target machine noting there are two settings that need to be configured for a successful connection through the SSH tunnel:

    • A password must be defined for VNC connections.
    • Loopback connections must be allowed.

    That’s fine for using an SSH tunnel to secure a VNC session, but why not tunnel remote desktop (RDP) connections to Windows servers instead of using VNC? In theory, all that should involve is changing the forwarded source port from 5900 (VNC) to 3389 (RDP) and setting the corresponding SSH port forwarding destination to localhost:3389 but Windows doesn’t like that, producing an error message as follows:

    Remote Desktop Disconnected

    The client could not connect. You are already connected to the console of this computer. A new console session cannot be established.

    One suggested fix is to change the destination to use another address from the loopback range (e.g. 127.0.0.2) but I found this just directed me to my own machine (as might be expected with a loopback). For a while, it looked as though the resolution would be related to a change made in Windows XP service pack 2, which prevents connections to loopback addresses other than 127.0.0.1, and Microsoft knowledge base article 884020 includes a hotfix that alters this behaviour but I don’t think it helped me much (I later removed the hotfix and didn’t notice any differences). Eventually I got things working by creating a new forwarded source port of 3390 and destination of localhost:3389 for SSH port forwarding, after which I could connect using mstsc /v:loopback:3390.

    It’s been an interesting few days getting acquainted with using SSH tunnels to securely connect to remote systems running a variety of operating systems – hopefully posting my experiences here will be useful to others.

  • Secure, remote administration of a Linux computer from within Windows

    Yesterday I wrote about using SSH to securely connect to a Mac from a Windows PC. At the time, I suggested that the advice should be equally applicable to a Linux system, or even to a Windows Server with an SSH server installed and I’ve since tested it with a Linux machine (running Fedora Core 5).

    The Linux process is almost identical to my original post for Mac OS X, except that:

    • The sshd_config file is found in /etc/ssh.
    • SSH is enabled in the firewall using the system-config-securitylevel command.
    • The SSH deamon is restarted using the service sshd restart command.
    • GNOME includes a VNC server called vino, which needs to be enabled (users of other graphical environments will need to choose an alternative VNC server).

    (Also… RTFM… I spent a lot of time trying to work out why I couldn’t connect, only to find that I’d neglected to place the public key in ~/.ssh/authorized_keys).

    Falko Timme has written an excellent tutorial on key-based SSH logins with PuTTY which outlines all the key steps (in fact, if I knew that existed then I wouldn’t have spent so much time writing up the process here!) but Jeremy Mates’ OpenSSH public key authentication article includes a useful troubleshooting guide for public key authentication problems.

    VNC is all very well for forwarding the entire desktop, but X11 forwarding can be used to run individual X applications on the Windows machine. Because Microsoft Windows doesn’t include an X Window server, it is necessary to download an X11 port for Windows – I used XMing. Once XMing (and the XMing fonts) were installed and running, I edited my PuTTY connection to enable X11 forwarding and ensured that the sshd_config file on the Linux box included X11Forwarding yes (that was the default on my Fedora Core 5 installation) and could launch an xapplication from within the PuTTY terminal window with xapplicationname & (e.g. xeyes &) (I found this information at the Linux Documentation Project). XEyes is nothing special, so how about running a Linux application on the Windows desktop… try mozilla & or gimp & – it feels “wrong” but it’s also pretty impressive and oh so “right” at the same time!

    Using XMing to run X11 applications on a Windows XP machine

  • Secure, remote administration of a Mac OS X computer from within Windows

    In a recent post about multimedia file format conversions, ripping DVDs, playback and more, I linked to a number of Mark Pilgrim’s “How To” articles; however there was one which wasn’t relevant to that particular post – how to use your Mac from anywhere (although it is intended for remote control of a Mac the advice should be equally applicable to a Linux system, or even to a Windows Server with an SSH server installed).

    A few months back, I blogged about using creating an SSL VPN to access my network but Mark’s video explains how to open a single firewall port and use SSH to provide a secure tunnel through which other protocols (in this case VNC) can be run for remote administration of a single computer. I tried it earlier and it’s very straightforward. Best of all, the software involved is all freely available under open source licensing agreements!

    I recommend downloading Mark Pilgrim’s video for a full explanation but the notes below explain what is involved (some of the Unix concepts may be unfamiliar to those more used to a graphical environment and my quick introduction to Linux for Windows administrators might be useful):

    1. Download and install the PuTTY, PuTTYgen, Pageant and Plink SSH utilities on a Windows PC.
    2. Using puttygen, generate a public/private key pair and protect it with a passphrase. Save the private key to a file on the Windows PC and copy the public key to the remote computer (e.g. within a text file transmitted via e-mail or FTP).
    3. On the Mac, open a terminal session (either using the OS X Terminal application or an alternative such as iTerm) and enter the following commands from the home (~) directory:
      • mkdir .ssh (this was already present on my machine as I already had the SSH server running).
      • chmod 700 .ssh (again, I didn’t need to do this).
      • chmod 600 publickeyfilename (the default permission set is 640).
      • mv publickeyfilename .ssh/authorized_keys
      • sudo nano /etc/sshd_config (non-admin users may need to su - to an admin account first as explained in my earlier post about running sudo as a standard user) and make the following edits:
        • Allow SSHtunnelling (also known as TCP forwarding or port forwarding) by changing #AllowTcpForwarding yes to AllowTcpForwarding yes
        • (Optionally) Prevent the use of usernames and passwords for login (the public/private key pair and passphrase will provide the security for the connection) by changing #PasswordAuthentication yes to PasswordAuthentication no
        • (OS X 10.4 only) Disable pluggable authentication modules by changing #UsePAM no to UsePAM no
      • Exit nano and save the changes to /etc/sshd_config (exit to the original shell if su was previously used to escalate privileges).
      • Generate an SSH key fingerprint (to prevent man-in-the-middle attacks) using ssh-keygen -l -f /etc/ssh_host_rsa_key.pub and make a note of the fingerprint.
    4. Open TCP port 22 on any firewalls/routers between the Windows and Macintosh computers and enable port forwarding to the appropriate internal IP address (it may be necessary to apply a static IP address to the Mac but I prefer to use a DHCP reservation).
    5. If the external IP address for the network is not static (mine is) then use a dynamic DNS service to assign a DNS name so that it may be located on the Internet.
    6. Within the OS X System Preferences, Open Sharing and enable Remote Login (restart the service if it is already running in order to pick up the changes made earlier to /etc/sshd_config). Because password authentication has been disabled, remote login (SSH) will only be possible from a machine with the appropriate private key.
    7. Although OS X includes Apple Remote Desktop, which is a VNC server, alternatives such as Vine Server (OSXvnc) offer additional functionality. In particular, VNC is insecure by default; however by selecting to only allow local connections (require SSH) and start the system server (i.e. run as a service, rather than in the context of a particular user), it is possible to run a secure VNC server each time the system is restarted.
    8. At this stage, it should be possible to create an SSH tunnel to the Mac. On the Windows PC, run pageant which is a PuTTY helper application (SSH agent) to cache the passphrase for the private key, which adds a level of security if the PC is compromised but which would also become a nuisance if it needed to be repetitively entered. Add a key using the private key file generated in step 2 and enter the passphrase that was used when created the key.
    9. Next, run putty and enter:
      • The hostname/ipaddress in the basic session options.
      • The auto-login username for the Macintosh for the connection data.
      • The privatekeyfilename for SSH authentication.
      • A new forwarded source port of 5900 and destination of localhost:5900 for SSH port forwarding.
    10. Save the session with an appropriate sessionname and open the connection. On the first connection, the host key will be unknown; however the reported key can be compared with the one generated earlier to ensure that the host is the intended target computer. Assuming that all is well and the connection is allowed to continue, then a Welcome to Darwin! greeting should be displayed, along with a shell prompt.
      • If the connection fails and there is a prompt for the private key then Pageant is not correctly configured.
      • If there is a prompt for a password then /etc/sshd_config was not correctly edited.
    11. Unless command line interaction with the Mac is required, the PuTTY window can be minimised. In order to create the SSH tunnel automatically at login, a startup shortcut can be created with the target of "%programfiles%\PuTTY\pageant.exe" privatekeyfilename -c "%programfiles%\PuTTY\plink.exe" sessionname
    12. Finally, a graphical connection may be initiated with a VNC viewer such as UltraVNC. The connection should be made to localhost; however because localhost:5900 has been defined as the forwarded port in the SSH tunnel, the request is securely transferred to the VNC server on the Mac.

    It’s worth noting that when I originally tried to test this configuration from a remote network I was unable to get past my employer’s firewall; however there are plenty of unsecured wireless networks around which I could use to test the connection!

    Note that the original information that provided inspiration for writing this post is licensed under a creative commons attribution sharealike 2.5 license and consequently so is the information contained in this post.

  • A lack of business intelligence

    Earlier this year, Nationwide, the UK’s largest building society, suffered a massive data theft when a notebook computer was taken from an employee’s home.

    At the time, questions were asked about how such things could be allowed to occur but, to be fair to Nationwide, it is common practice for unencrypted data to be stored on company laptops away from the office (I have never been required to encrypt my data and I work from home routinely). Furthermore, the laptop was stolen in a domestic burglary – we are all told not to leave our laptops in the car (which in my case is another company-owned asset) so within the home is probably the safest place for the computer to be stored when away from the office.

    To my mind, the biggest issue is how it took so long for the issue to be disclosed, with millions of customers’ identities potentially compromised (although Nationwide stresses that the data was “to be used mainly for marketing purposes” and “did not include any PINs, passwords, account balance information or memorable data”).

    Two of my family members are Nationwide customers and earlier this month we received letters warning us of the potential issues, along with advice from the UK Government Home Office and Nationwide on protecting our identities; however, I was very amused by the letter to my two-year-old son, which began as follows:

    “Dear Mr Wilson

    THIS IS IMPORTANT – PLEASE READ CAREFULLY AND SHOW THIS LETTER TO YOUR PARENT OR GUARDIAN

    Earlier this year a laptop computer belonging to the society was stolen…”

    The letter was sent to a toddler! How many 2-year-olds do you know who can read a letter and follow the advice to show it to a parent of guardian? All the other communications from Nationwide about his account are addressed to my wife – so why write directly to my son this time? They noted that he was a minor and warned him to show the letter to his parent or guardian but surely their software can cope with a simple date of birth check and establish that this customer may be considered too young to read!

    Leaving aside Nationwide’s lack of business intelligence, let’s hope that they have learnt from this massively public loss of data (and the expensive clean-up operation); however as computer users we can all benefit from their unfortunate experience and make sure that our data is secured by more than just a username and password (which provides no protection at all if the operating system can be bypassed and the disk accessed directly). Windows XP and Vista both support disk encryption (as do many Linux distributions and Mac OS X) and it’s worth investigating the use of this technology, although there are complications around key recovery that need to be considered before jumping straight in.