On the RaQ

NME puts Cobalt's RaQ Internet hosting appliance to the test. At stake: Cobalt's "15 minute configuration" boast. The company makes a big thing of how easy its appliances are to configure and set up so, spurning the user manual and with a quick glance over the quick-start pamphlet, we got to work.

  • E-Mail
By  Jon Tullett Published  July 7, 2001

Introduction|~||~||~|Cobalt has made its name selling Internet appliances; black-box systems that are easy to plug into a network to quickly enable new services. The company offers a variety of solutions from consumer-level Internet gateways to high-level hosting environments. It's worth nothing that Cobalt makes very extensive use of open source software - their environments run on Linux, use the Apache web server, ship with Borland's open source InterBase relational database, and so on. Doing the integration, wrapping a custom management interface around it all and providing support is Cobalt's business, and they do a good job. A good enough job that Sun, although not a strong open source proponent and with no Linux strategy of its own, acquired Cobalt earlier this year, raising analysts eyebrows but giving Sun a foothold into a new market corner.

UAE-based Cobalt distributors TechAccess sent NME their flagship RaQ 4i machine; a fully-equipped rack-mountable server system, containing pre-configured server software, applications and extensions to offer Internet services and virtual hosting facilities. Typically, this is a solution targeted at ISPs or such-like, offering domain and site hosting facilities, although as a quick start to get any 'net hosting environment up and running, the RaQ has appeal to a far wider audience.

The company makes a big thing of how easy its appliances are to configure and set up so, spurning the user manual and with a quick glance over the quick-start pamphlet, we got to work. The RaQ has a slim (1U) profile, making it attractive to high-density hosting service providers. The front sports a small LCD, six buttons (four directional and two selection), and a recessed reset button. The back is not much more complicated: two Ethernet ports, serial ports for console management, an external SCSI port intended for backup devices, and a USB socket. We popped in a network cable and the power, and were ready to roll.

Powered up for the first time, the LCD walks you through basic network settings; IP address, network mask and gateway - just enough to get the machine online so that you can move to web-based management. The LCD can be used for a variety of other tasks while the machine's running, too, but the initial setup is quick and easy. A couple of minutes after un-packing the unit, we were online and ready to set up some services.

Out of the box, the RaQ 4 supports an almost bewildering array of web services. Starting at the bottom, the Apache web server forms the core of most facilities, including HTTP and SSL. Because few web sites these days are written in plain HTML, Cobalt bundles support for Java, CGI scripts, Perl and PHP scripts, and SQL databases (via InterBase - the open source project that sprang from Borland). This is a fairly standard Linux web-server configuration that doesn't particularly appeal to Microsoft-centric developers. Cobalt's got that covered too though, shipping ChiliSoft's ASP solution for server-side scripting (ChiliSoft was also acquired by Sun), and support for Front Page 2000 server extensions. That covers just about all the bases possible, although there's even more if you go digging - the documentation doesn't mention the inclusion of the python scripting language, but it's there too, as is the obvious support for Unix shell scripts and C/C++.

Leaving all of that on one side for now, we set about finalising the configuration of the machine and setting up some hosts and users.

All the standard features of the unit are managed through a web browser interface, which has the dual benefit of making management ubiquitous as well as consistent. In general, using the management front-end was easy, although the pages are perhaps unnecessarily complex. The frames structure, for example, means that backwards and forwards navigation doesn't work as you might expect. This might be a good thing; it prevents confusion when you've made changes and a cached copy of the page would differ, but there are better ways of handing dynamic web pages. This is a small issue though, and the interface is easily understood once you know what to expect.

Typically, the administration page has a left-hand frame with links to the various areas of management, with a central frame showing the actual data. Very simple and easy to handle. Many options are shown with small icons, but a key is always provided at the bottom of the page for easy reference. The consistency is great - with little reference to the manual we were able to find our way to just about every component.

First off, a configuration wizard asked for some basic server settings had to be configured, such as the name and domain of the server and DNS. Next, it asked which services to run by default - web, email, FTP, telnet, SNMP and DNS. HTTP services can't be disabled since that's the primary use of the box, although I would like this to be an option (of course you could telnet in and disable the HTTP daemon manually). In the event of an HTTP-based DDoS attack, this service could be suspended, leaving ftp access to files, email services, mailing lists and all the rest still operating in the background.

The wizard also asks for time zone and locale settings, and then offers to register online.

That finished, still easily under the promised 15 minutes, we headed on in to get users and content online.

||**||Managing sites|~||~||~|
Virtual hosts (or "virtual sites" as Cobalt persists in calling them) are easily added. The RaQ supports both IP-based and name-based sites - you'll have to do some DNS configuration in the back end here if you aren't using the RaQ to provide name services. Using IP addressing, you can put a maximum of 250 sites on a single system - that's 10,000 in a fully outfitted rack - but there's no logical limit to the number of name-based sites.

Most sites will use generic default settings, which can be configured separately, toggling the availability of various services (shell accounts, POP3, CGI, SSI, SSL, FrontPage Extensions, ASP, PHP and FTP), the user limit, disk quota, and the domain and IP addresses.

Although the RaQ offers bandwidth limiting, we were disappointed that it can't be set here in the defaults or in the actual virtual site management page - it's hidden away in the server management pages.

The only addition when actually adding a virtual host is specifying the host name and optionally adding aliased names for the web server and email services, which allows the server to accept mail connections for other domains. Again, some DNS maintenance will be required here, but let's be realistic - an ISP using these boxes is very unlikely not to be able to cope with DNS administration.

Once the site is added, the next step is to add some users. This isn't a requirement - a wholly managed hosted site may be run with no users, but it's likely you'll want at least a site administrator account to which mail can be forwarded and which can do routine maintenance without being logged in as the RaQ administrator.

There's no limit to the number of site administrators configured on the box, but there can be only one RaQ admin. It's good practice to delegate network administration tasks in general, and this is no different. In fact, the limitation of a single RaQ administrator is a limitation itself - especially in larger sites it would be useful to allow multiple administrators with separate accounts. Possibly not much of an issue, really, since those larger sites will likely use Cobalt's ManageRaQ solution, which centralises management for several RaQs in one place, allowing control over various tasks including backup and updates from a single console.

Being power addicts, we added a virtual host with every service enabled, even though the intention was only to test vanilla services. I've worked with ChiliSoft's solutions before for example, and they work extremely well.

||**||Managing users|~||~||~|
With a site configured, it was on to the user configuration. This is very similar to the site management - defaults can be set to control disk quotas and default services (telnet, FrontPage User Web, and APOP), and the default format for user-name based on the full name provided. For instance, Bob Smith can generate a default bsmith user-name. When adding a user, you can also create mail aliases. This is fairly normal, but there are a couple of considerations worth mentioning. First, specifying "@domain" for an alias will forward all email for non-existent addresses to that user, a useful feature if you want to prevent bounce messages. Second, although you can have as many aliases as you like, usernames have to be unique, so if you want an "abuse" account at every virtual site, you'll have to alias it to different users each time.

The username limit is a pain. It's clear why this it works this way - the RaQ system is creating a Linux user account each time - but I'd definitely like to see a way to create users and then assign them to sites. That way, complex sets of mail aliases and all the other settings would not need to be created from scratch. While separating user management from the site management may make the process more complex, it would also allow for far more flexibility than the existing method. This is probably my only real gripe with the RaQ admin interface.

Many sites need to maintain mailing lists, and Cobalt ships Majordomo list management software with this in mind.

Most advanced Majordomo features are configured by sending to the system aliases, but the RaQ's web interface allows the basics of each list to be set up and administered.

Speed is always of the essence in the Internet space, so it's a point in Cobalt's favour that all our site and user configuration, including exploring the interface and experimenting with settings, took about half an hour. At this point, we were ready to add content to our virtual site and check it out in action.

This is a part I'll gloss over - everything we expected the unit to do it did, flawlessly. Using FTP and then FrontPage to upload files was as easy as it should be, test scripts worked just fine, and htaccess control mechanisms behaved properly. The ChiliSoft ASP backend was as good as ever, and while tinkering with the InterBase relational database involved a little trial and error, we're sure it's doing its job as promised. All we can really say is that it served pages like a well-configured Linux server should, with a lot of bells and whistles for accompaniment.

The RaQ is a superb box. It's got everything you could want in a web server and a lot more besides, at prices you'd be hard to beat even if you sourced the parts and built the box yourself. Although there are some security concerns (see pg36), for sites ranging from big hosting providers to small companies wanting an out-of--the-box server solution, this is a very good buy.

||**||Backup and restore|~||~||~|
Backup and restore

Backing up and restoring data is en extremely important part of hosted web environments, or even private sites, and Cobalt has this well covered. All users can back up anything they can manage; site administrators can back up site data, the RaQ administrator can back up the whole unit, and individual users can back up their personal files and email. Data is stored in proprietary .raq files, which can be retrieved, and also restored, using the web interface.

The unit also ships with support for Legato and Arkeia backup software, and can use an external SCSI device if you prefer.

Full system restores are also easily accomplished, although this deletes all site content which must be separately restored. Recovery images are provided in .iso format which the administrator needs to write to CD. This is a good method; new images are available on the Cobalt web site with recent patches, so the units can be restored with patch levels intact. The CD is booted on a workstation, which will then offers DHCP services and the OS restore software. Restarting the RaQ with a panel button held down instructs it to find the restore server and reload its OS.

In a test, the supplied boot CD failed to start on a variety of workstations - we didn't have a machine with the suggested model NIC, which may have been the cause. Users are advised to check they are able to run this before building sites.

All system configuration files can be exported as gzip files for analysis, if you want to see what's going on and make some tweaks of your own.

||**||Specifications|~||~||~|
Sun RaQ 4Server Appliance
450 MHz CPU
64MB DRAM
10.2 GB Hard Disk
Single Ethernet Port
$1500

Sun RaQ 4iServer Appliance
450 MHz CPU
256MB DRAM
20.4 GB Hard Disk
Dual Ethernet Ports
External SCSI Port
Single PCI Slot
$2700

Sun RaQ 4rServer Appliance
450 MHz CPU
512MB DRAM
Dual 30 GB Hard Disk
Dual Ethernet Ports
External SCSI Port
Single PCI Slot
RAID 1
$3600

||**||Security concerns|~||~||~|
Security concerns

Because this is a sensitive topic, it's worthy of special mention. Security issues came up several times while working with the RaQ - not that it's less secure than any other out-of-the-box server, but because there are some steps you'd definitely want to take to prevent abuse.

Firstly, it's important to understand the positioning of the product; it's aimed at rack-mount environments where physical security is not much of an issue. If someone has physical access to your NOC, you've probably got more of a problem than just looking after a web server. Nevertheless, it's important to mention that physical security is an area where the RaQ is not just poorly protected, it's completely vulnerable. For starters, the recessed reset button on the front panel sets a blank admin password, in case you forget it. There's no way to lock the button or prevent this activity, which makes me very nervous. Likewise, the LCD can be used to reconfigure networking on the fly, changing addresses and gateways, as well as reboot the box, which is open to abuse. If you're environment isn't extremely secure physically, think twice before deploying this baby.

Application-wise, there are some security problems too. To start with, it uses telnet not SSH for shell prompts, meaning traffic is sent unencrypted. Moments after connecting the unit to our network, we opened a telnet session and experimented with logins - having ignored the manual - to see if there was a default password. Sure enough, although root logins are forbidden, an "admin" account exists by default. Blank password? No. "admin"? Yes. Two guesses and we're in, and ten seconds later we have a root prompt, since the root account has no password. Again, this is a vulnerability that is unlikely to present a problem in the real world, but I distrust any system with such weak default protection. A better option would have been to have the admin password set to something random on first boot, and displaying it on the LCD during network configuration.

Looking at the software itself, there are some serious vulnerabilities. The ftp daemon (proftpd) shipping with the unit is exploitable, for example. There is a patch available, but we know how many network managers apply patches reliably. The system is also vulnerable to a DoS attack - malformed requests sent to the HTTP service caused resource starvation, and the box crashed. A number of other vulnerabilities were spotted by our scanners - nessus and Retina - fortunately all of them are either patchable or can be closed manually. Users are advised to watch the Cobalt support page carefully for security patches.

There is very little available in the web management interface for security, and many of the OS security features are not used - hosts.allow and hosts.deny are both empty, for example. I'd like to see tighter control of services - what is allowed to run, what addresses can connect to them, and so on.

Since the unit uses telnet and not SSH, this is especially important.

Most of this is something you can fix yourself, if you are minded to do so. It's just a Linux box, after all - and if you have some Unix skills available some basic tightening up isn't that hard, although it does weaken the "black box" image Cobalt presents.

More granularity at the user level may also be a good idea. Any site administrator can create a new administrator, or upgrade an existing account to have admin status. Assigning too many administrative users is not a good idea, but it's a scenario that plays out at many smallish sites (virtual or not) when there are several people working on services. To prevent this, I'd like to see this capability more protected, which may require two levels of admin. This would be simple to implement and easy to ignore if it's not a feature you need.

Lastly, there's very little logging available. The web GUI has usage stats, so why not a breakdown of recent shell connections, admin logons, attempts by a shell user to gain root privileges, and so on. This isn't rocket science, and is something that, as a fairly paranoid network manager, I sorely missed.

Provided you're comfortable with your existing security - firewalls, physical access, and the rest - you can probably drop in a RaQ and get going from the word go, and this is obviously the target customer for Cobalt. The rest of us will have to get our hands dirty and do some tweaking if we want to feel secure.

||**||

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code