A short parable on network security

[dtm]

I call this a parable because although I'm sure that there's a lesson to be learned from this, I'm not quite sure what it is. I do have certain points in this story that feel important, and I've labeled those as "parable events". As I said, though, I leave the conclusions to the reader.

My employer (call them "company E") has over the past year tightened up the corporate network, including restricting outgoing connections to nothing other than ftp and web browsing.

The TCP-literate will wonder if I actually mean is that company E is restricting outgoing connections to ports 20, 21, 80, and 443. In fact, that's exactly what I mean. Connections to those port numbers are allowed and others are not. In theory, one can submit tech. requests to network engineering if there is a business reason to allow some other type of access to a certain location.

Not only are external connections limited in this manner, intra-company connections are similarly limited. We've had to submit requests for all the servers we access to open up ssh access between them and our desktops.

As might be expected, in very short order I had set my home computer up to accept ssh connections on port 21, and thus had access while at work to my home email and anything else I might need on my home linux box. Here is the first parable event: a sufficiently motivated user will gain shell access to the outside world anyway.

Now, recently my employer acquired another company (call it "company S"). I was given the task of looking at a certain product of company S to see if I could take parts of it and fold it into one of company E's flagship products. To do this, the people at company S provided me with the name of a server over at S.com and told me to ssh into it to poke around.

Naturally, company E's firewall prevented this, so I simply connected to my home machine and from there ssh'ed into the servers at S.com. Here is the second parable event: when I had a business reason to have access prevented by the network firewall, I chose the to circumvent the firewall rather than file a tech. request for an open port.

Now, there's this guy over at company S who I've been working with trying to get a certain product of company E's set up and running over in the S office so that they can look at it and see how brilliant their new corporate overlords are (or not). Anyway, this guy at S has been running into all sorts of problems, and today finally asked "look, I'm under time pressure and really need to do other things. Is there some server you have over at E that I could just point my boss at for a look?"

Now, in fact we do have such a server for our QA department to look at, and which we use to show our sales people what this product looks like. Once again, though, it's only accessible inside E. Our network firewall, and various routing issues, prevents people on S's network from accessing this part of E's network.

So I set up a process on one of our servers here to ssh to my home machine, and ssh from there to a machine at S.com, where it runs a perl port forwarding script that bounces incoming connections all the way back here and to our test machine. This is now truly in the realm of Rube Goldberg, and yet for all that it appears to be horribly complicated, it was relatively easy to set up. Along the way I had to contend with the fact that the sshd at S.com didn't have the GatewayPorts option enabled, but that was simply a matter of finding a perl script that would forward incoming connections.

Here is the third parable event: there are now other users employed by E who are as a part of their job using a network connection that is bouncing off of my home machine. This is a temporary setup, I hope, but anyone adequately experienced with the real world knows the unexpected permanence of temporary hacks.

Update: The hack turned out to be temporary after all. Now, I've got an ssh connection going from our server at E to the server at S.com, using ssh to forward the port connection, so my home machine is out of the loop. It only took about 30 minutes on the phone with networking as it turns out, which phone call was arranged within a day of filing the port request.

Comments

[joxn.livejournal.com]

Microsoft would give you a stern talking to or perhaps fire you for such a hack. But Microsoft doesn't have insane policies about network connections to its corporate intranet -- any full-time employee can get VPN access without all that many hoops to jump through, and certainly with no requirement to justify it to anyone.

[dtm]

For which aspect? Presumably, you mean the first point, obtaining ssh access to my home machine by running it over a port that was allowed out, even though in general outbound ssh access was restricted. Presumably the general principle is that circumventing the access policies implicit in firewall rulesets is bad. (*)

Allow me to quote from a Microsoft white paper preserved on the wayback machine:

While they're essential to secure use of the Internet, firewalls make the efficient use of distributed object protocols very challenging. To address this problem, Microsoft has created the Simple Object Access Protocol (SOAP). SOAP is a distributed object protocol that, like DCOM and other protocols in this category, allows RPCs between clients and servers. Unlike existing protocols, however, SOAP is explicitly intended to be usable with firewalls in place. Equally important, SOAP is not designed to be used with only one component technology. Up to now, a great deal of effort has been spent debating which distributed object protocol, and thus which component technology, should be used. However, unlike the distributed object protocols in use today, each of which is tied to a specific technology, SOAP does not assume a particular approach to creating components—this single protocol can be used with any of them.

Not to flog a dead horse, but let me also quote the summary at the top of the paper:

Summary: The Simple Object Access Protocol (SOAP) is a way to use the existing Internet infrastructure to enable applications to communicate directly with each other without being unintentionally blocked by firewalls.

(*) I've tried to find explicit written network access policies - as far as I can tell, those don't exist beyond the general "business use only, though incidental personal use is allowed" statements in the employee handbook that also cover use of the office telephones.