Dealing with MFT servers: a systems architect versus systems administrator love story

In my past life as a system administrator, I once had to build from a ground up a secure MFT (managed file transfer) server. I've pulled it off by using the HP-UX infrastructure I was comfortable with, and built something from the ground up using OpenSSH. You wouldn't believe, however, how much tweaking had to be done to have the user accounts (which were stored in /etc/passwd and /etc/shadow) synchronized reliabily in a clustered system spanning two sites. It took me a few days to make sure everything was correct.

Now it is time to do it again at a new place. I have to design another highly-available MFT server that will be wedged between two DMZs, and besides supporting SFTP I want it to have an HTTPS-based, "drop box" feature for end-users do be able to upload files easily without needing an SFTP client. Oh, and by the way, I need it to be able to authenticate users with a Windows domain this time.

If I was still a sysadmin, I'd have to extend the first solution further by adding an Apache HTTPD server and some open-source file upload solution. Then, I'd have to find a solution *BOTH* for Apache and OpenSSH to authenticate users. OpenSSH would probably need to rely on PAM, and for Apache I don't have a clue. Yet no problema; I would just shrug and say I can do that, then spend a few days tying everything up. The end.

But, as a system architect, things don't work this way.

Why? Because I have to assume that there is no guarantee the sysadmin who will have to do the grunt work of building this up will be willing, or have enough experience, to install and configure a custom solution. And assuming he/she is willing to do it, I have to consider that each man-hour counts for serious dough within the frame of a project. With custom hacks like this, these can sum up to a lot of hours depending on whose desk the work falls on.

Therefore, I did what system architects do: I tried to pick a turnkey solution, and it will have to be shoved down the IT team's throat.

I always hated this when it happened before. Picture this: The architect goes on a golf course or whatever, and randomly picks a solution based on bullet points and checklist tables. Then the IT operations guy has to take whatever crappy, slow and expensive "enterprise" software the architect purchased at a pharaonic price, and make it work satisfactorily to fulfill a business need. More often than not, such lame software ends up in the garbage bin with the IT team developing its own in-house solution to patch things up.

As I've been on that side of the fence before, I try to do things differently to prevent this from happening. So when I technically can, I actually try out software before choosing it, when it's not too daunting for me to do so.

So back to the MFT. I went searching on the web and picked a market "enterprise" leader to try it out. Not only doesn't it support high availability easily, the software is clumsy and it took 30 minutes to run its installshield sequence on a Windows 2008 VM. Uninstalling took the same. And to have SFTP support, I actually had to pay a premium over the base price. Not good.

Few other vendors had solutions that seemed serious enough, though. By serious I mean that they have to offer technical support, and have some agility in dealing with enteprise customers. Then a colleague of mine found out a very elegant software named JSCAPE MFT Server. Installation is a snap and it's very easy to configure. I was up and running in a few minutes. And as a bonus, its feature set is actually useful and seems to have been designed based on user requests instead of some odd crystal ball. I've been trying it this morning and up to now, it works very well.

The MFT server itself works on Windows, Linux, some Unices and Mac OS X. Installing the RPM went without any problem on CentOS 6. It is managed by a Java-based GUI that I installed on Windows -- I wasn't fond of using a thick-client when compared to a web-based administration GUI, but their GUI is efficient and interface-rich without being clumsy. No bells and whistles, and it is fine that way.

The Java-based "Server Manager" does the job efficiently

Enabling the web-based transfer option was quick and easy to do. What helps is that the software comes with a manual that, without being too detailed, provides lots of screenshots and cookbook-like procedures to configure the server quickly. It took me maybe a minute or so to enable the web server, set up LDAP-based authentication, add a dummy user, and try it out.

The resulting web service might be bland but it does the job, once again no fireworks. This is very important as it will be deployed to users who might not always be too tech-savvy.

The web-based service might be simple, that's exactly what I want

As a system administrator, I would actually want to work with software like this because it's elegant. It does a few things, and it does it well. I like it when software feel natural, and everything works the first time without a glitch. As in every software, I'm sure there are some bugs somewhere, but it sure is a good start.

Is JSCAPE MFT Server, the iPod of MFT's? I'd say it's not far from it. Chances are that if my project is greenlit, I'll be the first in line to purchase it. Whoever wrote this, good work!

O.

Interesting thread on Slashdot

Sysadmins and developers aren't the same, but they both share a strong technical background.

I suggest you read this thread. The first comment named "Stay Put" might be hilarious, it makes a lot of sense.

http://ask.slashdot.org/story/11/08/12/1433239/Ask-Slashdot-Am-I-Too-Old-To-Learn-New-Programming-Languages

The ex-sysadmin I am often asks himself if moving up was a good decision. It turns out it might be after all.

A presentation on IMS and PI might be coming

After a hiatus in 2010 due to a career change, it's now time to start writing papers and building presentations again. I'll be submitting a paper for Cooper EAS's 2011 Smart Grid conference which will consist of my experience with a major Yukon IMS deployment I've been involved with as an IT architect. I'll also explain how we used the SMP gateway to link substations to the OSISoft PI data historian in order to collect critical data.

I'm not in academia so my work is in no way scientific. Furthermore, I'm part of a huge team which counts a fair share of people from IT operations, control engineering and electrical engineering, so my view is mostly IT-centric.

There are many air travel restrictions at the office so I hope I'll be able to make it. The worst case scenario would be driving from Montreal to Minneapolis for which, if it's any consolation, won't require a full body scan.

O.

Forcing laptop users to use only an Iron Key (and nothing else)

I need to transfer files between two networks which need to be physically isolated for a few months until a beefed up and permanent security solution becomes possible.

The easiest way to do this on a budget consists of using USB keys to transfer files between two laptops, one which is connected on the intranet, the other on the secure network. If course, the "secure" laptop must be stripped to the bone and have an up-to-date Antivirus so it can trap known viruses that are currently in the wild. That won't prevent any new virus from coming in, but there is an urgent business need to transfer these files so there is not much that can be done in the short term.

I'm currently using IronKeys to ensure the integrity of the data, and also to prevent any data theft if a key is ever stolen. However, one must "encourage" end-users to use these keys, else they might end up using whatever key they lay their hands on to prevent having to enter a password.

On Windows XP, there is no way to do USB key filtering based on the key manufacturer. IronKey has a partner named DeviceLock that they suggest, but being a commercial product, it comes with a price. There are many other endpoint security tools that can be purchased to offer similar functionality, too. In my case, I was in a deadline and had missed the opportunity acquire software and charge it to the project, so it was preferable to use something free as a stopgap measure.

This afternoon, I've been making a few tests with USBSecure. It SEEMS to be free. There is no license, but all code is published so it can be tweaked if necessary. USBSecure is simple to configure: define users that use the computer, and whitelist the device IDs that are allowed on the system. I've been making a few tests for an hour or so, and it seems to work correctly. I might come back and give more details later.

Of course, transferring files between two adjacent PCs might look clumsy. But there are a lot of (justified) restrictions on secure control networks. What is sad is that that Stuxnet worked exactly this way, by propagating using USB keys. No matter how much we try to control their usage using endpoint security software, USB keys still remain a vector of infection for secure networks. Better long-term solutions must be done to ensure that any file transferred on a secure network is, indeed, clean. I'll be working on such solutions in 2011-2012.

O.

Why hosting enterprise-level videos on YouTube is not a good idea

Last week, OSISoft sent their customers an e-mail pitching their new OSISoft Learning Channel on YouTube. Since they probably knew that many enterprise firewalls block YouTube, their communication pleaded that we should politely ask IT to authorize YouTube. They also put a reference to Buck Bard's blog post Don't be anti-social on social networking where he basically says that internal collaboration sites don't measure up to public ones like YouTube.

He's right on the social networking argument -- the corporate or "private club"-type social networking sites I've seen aren't so great when compared to the behemoths who've been able to get a foothold in the last five years. But isn't that what vCampus is, in essence? To benefit from its social networking features, one has to be a (paying) vCampus user. Maybe OSISoft could consider opening up parts of vCampus?

The problem which OSISoft acknowledged in their e-mail is that most social networking sites are blocked to many corporate users. Facebook is one thing, but I'll concentrate on YouTube in this post.

To illustrate this, let's compare YouTube to a television: if I came into the office of the CIO and asked for every cubicule in the office to have a cable TV set with every channel offered by the cable company, what would be his answer, you think? Even if all this came for free, I bet it would be "no". The reasoning being that nobody actually needs this, and it's a perfect way to lower productivity. Now if I came and asked for TV sets which only had access to all-news networks because the employees are financial analysts who actually need this to do their job, it might work.

The problem with YouTube is exactly that: it's a TV with millions of channels and there is no way to filter out content that is relevant to your workplace. Yet even though we have places where YouTube is barren due to questionable content, and rightly so, there are tech companies who keep on using it to publish their stuff. OSISoft are not the only ones, by the way -- ArcSight did the same thing two years ago.

What are the solutions?

The first one is not using YouTube at all to publish content. Which is too bad as YouTube is a really good platform to publish videos easily and cheaply. OSISoft probably doesn't want to invest thousands of dollars into a private streaming solution (and bandwidth), which is understandable, but they cut themselves out from some of their customers by choosing this path.

The second one would be for YouTube to make an "enterprise-level" version of their service, under a completely different name and domain, and charge a small fee to qualifying content publishers. Someone thought of this in 2007 and I have not seen a solution yet. The problem with this scenario is that over time, it will become another all-you-can-eat lineup. Victoria's Secret would probably end up calling themselves "enterprise-level", and I don't see where their videos would fit in a financial analyst's job.

So that's it. OSISoft's Learning Channel is on YouTube. Don't get me wrong -- I checked them out, and this initiative is very appreciated!! But since my employer doesn't let me watch YouTube, I'm stuck with watching these videos on my own time, at home or at the internet café.

Time to go grab a Latte.

O.

SFTP vs FTPS: tough choices

Las week, I had to design in a hurry a secure file transfer mechanism between two DMZs on a zero budget which, in a nutshell, meant reusing the Windows servers that are already there, and not purchase any third party software.

I had to choose between using SFTP, a nice protocol, and FTPS, which I've been comparing to a bastard child for years.

I don't like FTPS mostly because it's a patch on FTP. For one, FTPS is harder to firewall than SFTP; it behaves exactly like the standard FTP with a control and data connection, the difference being that TLS is used to encrypt them. Like with standard FTP servers, the server must be configured with a fixed range of passive ports, and the firewall must let these ports through. Why? Because the firewall has no way of knowing what dynamic port has been assigned to a passive data connection... it can't sniff it out the control connection either, as it's encrypted!

Even though it's not exactly what I would call an elegant protocol, is FTPS actually easy to work with? The answer is yes: I was able to install IIS 7.5's FTP publishing service in 2008 R2 and have an FTPS server working within minutes. That is good enough. And in IT, good enough is, well, Good Enough.

So, here are my thoughts:

If your server will be hosted on any kind of Unix, choose SFTP. It has been built-in with OpenSSH for years. The drawback of OpenSSH is that it doesn't support virtual users, and this can make high availability tricky; you'll need to synchronize /etc/passwd entries, even if using AD authentication.

On the other hand, if you will host the service on Windows, you might be better off going with FTPS as it is included with IIS 7.5 and there is even high availability that is possible. To support SFTP on Windows, you either need to install unsupported open-source software (unacceptable in many secure, enterprise environments) or purchase a third-party product such as WS_FTP Server (which carries a premium if you need SFTP functionality).

As for CLI clients that support automation, no matter the platform you use, there are plenty to choose from. For SFTP, on Unix just use the sftp command and on Windows, try Putty's excellent psftp.exe. For FTPS, I suggest you try cURL which is multi-platform on Unix and Windows.

So, to conclude: SFTP if using a Unix server, FTPS if using a Windows server.

In my case, I'm going with FTPS.

O.

Gabriel Consulting Group survey on Oracle and HP-UX

As many HP-UX admins still read this blog, I thought I'd post this. GCG is running a survey to have some insights on what you're thinking about Oracle's decision to stop developing products on Itanium, and Oracle in general:

http://survey.gabrielconsultinggroup.com/limesurvey/index.php?sid=73634&lang=en

I got this link from an article that Dan Olds posted on The Register.

I takes maybe 10-15 minutes to answer the survey and I think it is worth it, as the results will no doubt end up being published by HP somewhere down the road. Even though I'm sure they're independent, the questions and tone of the survey are not, er, I'd say, totally objective. I answered it not as an HP-UX admin (which I'm no longer), but as a systems architect for an enterprise that runs a mixture of HP-UX, AIX, Solaris, and Windows. So I tried to stay unbiased. You should do the same.

O.