OpenBSD Journal

Tunnelling out of corporate networks (Part 3)

Contributed by mtu on from the smaller-is-better dept.

Tunnelling out of corporate networks - Our quest for a solution

We were on a quest for a security solution that would prevent anything bad and allow all the good. It's a problem that almost everyone in IT security has to struggle with. Get it wrong on either end and you risk compromise or the wrath from users complaining that you are inhibiting their work because of all this security stuff.

Read on to find out more about our battle between the good and the bad:

Articles 1 2 3 4 5

In the first part of this series, I showed how easy it is to create a ssh VPN tunnel. In the second part, I discussed why tunnels can be scary but more importantly why relying on endpoint security is bad security dogma. This next part will be broken down into a series of smaller articles. It's just too much information to disseminate in one go.

I am aware that there are a multitude of solutions and variations on what I am going to discuss in the coming series of articles as all environments are uniquely different. Therefore, far be it for me to say that what I present here is going to work for you too. Yet, I hope that there is a little something in these series of articles that you may be able to benefit from and apply to your environment. At the very least, I hope that I have given you some food for thought.

Our infrastructure consists of primarily Windows and OpenBSD. In fact, OpenBSD is used for everything network and security related. Windows is used for the workstations and servers that are running internal applications. The non-workstation infrastructure is a rough 60/40 split between Windows and OpenBSD. It's a small company of around 100 people with 4 full-time IT staff, to give you an idea of our size. We host services for other companies so our server infrastructure to workstations ratio is atypical. I can't disclose more than this.

In our quest for an optimal business friendly security solution, we made an important assumption; all hosts are or can be easily compromised. Obviously, this is the worst case scenario. We made this decision many years ago and our remote access solution came out of this assumption. There is a write up about it here. We've had great success with this remote access solution, totally eliminating any kind of infection on our internal network from the outside via remote access users. We then took this to the next level and in the other direction. I'll explain this in detail over the upcoming series of articles.

I want to touch on another point about security and usability. Schneier wrote, "Designing systems for usability is hard, especially when security is involved. Almost by definition, making something secure makes it less usable." Well, contrary to this statement, our goal was to increase security without sacrificing usability. In other words, we wanted to make sure that our staff were working as efficiently, effectively and productively as possible, all the while making security transparent. That is, we didn't want the staff to feel that there was any need to do any "benevolent hacking". We also wanted to make it extremely difficult for our staff to somehow circumvent all the security goodness that we painstakingly put in place. I know that it sounds like a pipe dream but that's what we did.

I should also mention that we could never have pulled this off without the full support of management. We have a small team with a proven track record and everyone is involved, engaged and serious about security as well as usability. We all know the merits of good security design. It means less downtime, less data loss and less stress.

Throughout this series, I'll also try and explain why we made certain decisions along the way searching for the best approach for us. As an example, after studying what Gutmann and Schneier had to say about PKI, we deliberately stayed away from any SSL solutions for remote access. Now let's get on to some of the technical details.

Workstation Naming Convention and DNS

Security Policy is usually enforced through your corporate firewall but what about those blocked connections? How do you detect and follow up with your staff and their computers when you see this kind of unwanted traffic? Following up can be difficult and onerous unless you have some kind of reference or link between the user and his/her computer and/or their IP address. This next section will lay the framework for future articles that will go into how we detect and manage logs.

One of the best decisions that we made many years back was to disassociate DNS from our Windows Active Directory and use OpenBSD for DNS. Bear with me here as I know that this may not make sense if you are using DHCP for all your hosts and aren't using pf. However, we wanted more useful real-time information from our logs and we thought that the following was a good logical naming convention for our needs.

Our staff are issued their own workstations dedicated for their use only. We used the MAC address of each machine for the computer name as they are unique. Staff telephone extentions are also relatively unique as are IP addresses so we made sure that the four digits of their telephone extension were also the last four digits of their static private IP address. This may not be feasible in your company but it was simple and logical in our case. Once this was done, we associated their AD logon names with DNS.


Username   MAC                  Machine Name    Ext     IP
muemura    00:0a:e4:2a:d8:af    000AE42AD8AF    5923    192.168.59.23

  • pinging 192.168.59.23 gives us the MAC 00:0a:e4:2a:d8:af with an arp
  • a nslookup 192.168.59.23 gives us the machine name 000AE42AD8AF
  • a nslookup 000AE42AD8AF gives us the IP address 192.168.59.23
  • a nslookup muemura will also give us the user's telephone extension 5923
  • we associate IP addresses with usernames in real-time log output using swatch
  • There are other benefits to hard coding all this information into DNS. It is useful for the staff as we use Remote Desktop Connection for training and presentations. From dedicated meeting room laptops, staff would Remote Desktop to their own computer by just typing in their login name.

    However, the real purpose of our naming strategy was to extract useful information from our logs while monitoring and/or troubleshooting. If this seems impossible to do on your network, then you may want to look into authpf as an alternative.

    I will talk more about logging, malware detection and monitoring later but our solution (as you will see presented over a series of articles) is really based on years of common sense security. It is the culmination of a lot of great minds in security showing us the light. We just listened, field tested and implemented what we learned to the best of our ability. I hope that you stay tuned.

    Mark T. Uemura

    (Comments are closed)


    1. By jirib (jirib) jirib@mailinator.com on

      interesting because i work in a team which maintains monitoring infrastructure but using commercial software (really crap :)

      i wish you unhide more about your setup. how are alerts delivered to administrators (or people in operation center?)... i read something about `sec', looks intersting... for example in our environment people in operation center have a console with alerts, then they can 'close' the alert when it is solved etc...

    Credits

    Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]