October 2004


The “UNIX way” is pretty cool. In the true Unix form, everything is scriptable, policy is left up to the administrator, configuration is done by text files and simple task specific commands can be “glued” together to meet a specific need. While I have touched on “The Unix Way” in the past with articles such as Everything is a File! and The Power of the Pipe.. I came across another way where combining various tools together made a very useful tool that I use daily.

After the major hard drive crashes in April, I have almost been a zealot for the importance of data backup. I have particularly been interested in remote backup to keep data secure from onsite theft, fire or other issues that could destory not only the original data but localized backups of data.

I quickly learned about rsync which only transfers changed data between two systems. Over slow Internet links, transferring the least amount of data is desirable. From my research, this appears to be the quickest way to get two sources in sync and quickly became the core of my remote backup strategy.

From here, I wanted incremental backups to allow for situations involving user error (accidently deleting a file) and system error (corrupting a file). As the Unix way states everything is scriptable, I started hacking together a script that would provide the functions I was interested in. About halfway through the development of my own script, I came across “rsnapshot” which did exactly what I was attempting to do. Fantastic! With a quick setup, I had this script running and incrementally backing up remote data.

However, as rsync is designed for synchronization of data sources, the data being transmitted was not secure. As certain data sources are of important business related documents, it was important to maintain a high level of security when handling these files. Anyone with a packet sniffer between my backup server and the remote server could theoretically get a copy of my data, sniff passwords, etc.. not good.

As a result, I got rsync running over ssh. SSH or Secure Socket Host, provides encrypted tunnels via a public/private key combination . The version I utilized, openssh, is developed by the OpenBSD project, perhaps the most security minded operating system guys in the world.

Life was good. I was able to securely transmit data, store incremental backups on a localized backup server and minimize the amount of data transferred. However, after a while, I started to realize a problem.

Most of the servers I was backing up data from had a small amount of outgoing bandwidth (ie cable modems, dsl, etc..). As a result, during backups, it was completely saturating the available bandwidth making other operations extremely slow or failing.

Rsync has the ability to limit the bandwidth by setting an upper limit. While this would work, it was a bad use of bandwidth. For example, if the outgoing pipe on a server was 32kbytes/sec and I set an upper limit of 16kbytes/sec, it would take twice as long to complete the transfer. While this is ok if the other 16kbytes is being used for other activities, since the backups are occuring at night, there is a good chance the bandwidth is not being used, ultimately slowing down the backup and letting the bandwidth go unused.

What I ended up doing was setting up bandwidth throttling utilizing dummynet. With dummynet, I was able to setup a rule that specified that any traffic going over SSH be given the lowest priority. As a result, if the bandwidth needed to be utilized by other activities (web servers, email, etc..), those tasks would take priority over the backup operation. If no other activities were requiring bandwidth, the backup operation would have full use of the bandwidth. Given the time of day the backups are occuring (night) they get most of the bandwidth, but if someone needs to send an email or someone requests a web page, it will occur just as fast as normal.

Where it stands now…

For this backup solution, I ended up using 4 distinct tools (rsync, rsnapshot, ssh and dummynet) to develop a remote backup strategy that fit my needs. The solution provides incremental backups, fast transfer between the backup server and remote servers, secure/encrypted transfer of sensitive files and above all, its polite and non-instrusive to other applications requiring the bandwidth.

The solution is truly a “Unix Way” of doing things. It is scripted, policy was decided by me and not dictated by the limitations of a monolithic program, all configurations are non-complex text files, various tools were glued together to meet my policy needs, the system is modular, simple and consistent, and its fully automated.

Another day .. another TEN security bulletins, 7 critical & 3 important from our favorite Redmond, Washington software company. Heheh.. trustworthy computing .. hehe..

Here they are for your reference:

MS04-038 - Critical - Impacts all version of Windows & Internet Explorer — Lots of remote vulnerabilities including drag and drop, css heap memory corruption, install engine vulnerabilities, address bar spoofing, plug-in navigation spoofing, ssl cache (yes, secure socket layer) vulnerabilities, script vulnerabilities…

MS04-37 - Critical - Impacts all versions of Windows except XP SP 2 - Remote Exploit of the shell, Program Group Converter Vulnerability..

MS04-36 - Critical - Impacts Microsoft Windows Server systems - NNTP (Usenet server) remote exploit vulnerability

MS04-35 - Critical - Impacts Microsoft Windows Server systems - SMTP (Email) remote exploit vulnerability

MS04-34 - Critical - WinXP, W2k3 Server - Compress (zipped) Folders vulnerability - allows remote code execution

MS04-33 - Critical - Microsoft Office 2000, XP, 2001 for Windows & v.X for Mac - Remote Code Execution in Microsoft Excel component

MS04-32 - Critical - Impacts all versions of Windows except XP SP 2 - Elevation of Privileges for regular users/scripts, remote code execution, denial of service .. core component exploits (Windows Management, Virtual DOS Machine, Graphics Rendering Engine, Kernel)

MS04-31 - Important - Impacts all versions of Windows except XP SP 2 - NetDDE Vulnerability allows Remote Code Execution due to unchecked buffer — allows attacker to install programs, delete data, create new accounts, etc..etc..

MS04-30 - Important - Windows Server operating systems (web server — IIS) — WebDAV vvulnerability allows denial of service attack.

MS04-29 - Important - Windows NT Server 4.0 — RPC Runtime Library Vulnerability — allows information disclosure & denial of service attack.

For spice they updated their MS04-028 bulletin regarding the buffer overrun in their JPEG processing (GDI+) that allows code execution …

MS04-28 -Critical - Impacts pretty much everything .. Windows ia32, ia64, XP, 2003, 2000, Office 2000, Office XP, Office 2003, Project, Visio, Visual Studio, Microsoft Home software titles, Internet Explorer, SDKs and so forth..

So umm.. if your running anything from Microsoft, there is a good chance it is impacted by a known, published security issue. For all this trustworthy computing and “security is #1″ and all that hoopla, they sure do have a lot of security issues.

I am currently studying OpenBSD, perhaps the most secure of the networkable and active operating systems available. I read the slides from a presentation the founder, Theo de Raddt, had regarding innovations in improving security. It honestly blew my mind the types of security methods he has built into and is going to build into his OpenBSD OS… and then there is Microsoft.

After making their big fuss about “Trustworthy Computing” back in Feb 2002 and releasing a huge service pack for WinXP focusing almost exclusively on security, yet ANOTHER major issue has cropped up.

According to this article on eWeek, Microsoft’s ASP.NET, the latest and greatest in Microsoft secure application frameworks has a small little bug that umm.. gives people access to password secured sections of websites without the password. As Microsoft puts it — “an attacker can send specially crafted requests to the server and view secured content without providing the proper credentials.” — Nice.

Whats particularly interesting is Microsoft released this advisory back on Tuesday, has yet to release a fix for the issue but does offer guidelines for umm.. working around the issue — basically patching certain aspects of ASP.NET on the more than 2.9 million sites across the Internet. But no fret .. it only impacts Windows 2000, Windows 2000 Server, Windows XP Professional and Windows Server 2003 (Yes, the OS touted to be developed under the Trustworthy Computing initative..) — so if your NOT running Microsoft software for your webserver and operating system, your safe. :)

It absolutely blows my mind that the largest software company in the world with the richest executives in the world and access to some of the best talent in the world still falls victim to such pitiful security issues. Honestly, there is something terribly wrong when a (relatively) small project such as OpenBSD has and continues to run circles around Microsoft with regards to security (its no wonder that many companies and orgnizations will only allow OpenBSD to sit on their Internet facing systems .. all other systems have to sit behind its powerful PF firewall.. )