Currently viewing the tag: "OpenBSD"

To sum up in a single word…. CONSISTENCY

By On · Add Comment

There is one word that comes to my mind when I think about how to run a data center, consistency! I have worked with many people and organizations over the years. Recently I have seen a fair number of issues and to summarize them with one word I picked consistency.

In my mind this means right or wrong, if you are going to do something be consistent with it. If you’re using jumpstart or kickstart then put the environment in a revision control system, like CVS or Subversion. This way changes can be tracked and logged. Sometimes it is the simplest things that tip me off that say one system out of ten is different.

For example, when I’m deploying applications on many servers at the same time I use cluster ssh. Once connected I’ll ‘sudo su -’ so I can do what I need to do. If some servers have different root prompts then that is an immediate tip to me that the servers are not all the same.

How do you achieve consistency? Automated scripts/tools. When I deploy the applications I don’t do a lot by hand, except for running some scripts that install the various applications.

Now I’m off to continue the fun I’m having today with ESXi and OpenBSD. I’ve figured out how to create hosted servers from the command line, using ssh. Right now I can easily create an OpenBSD virtual server, power it on, and have the install started all using ssh and the ESXi command line. Next up is to create a fully automated OpenBSD install routine. While the installer is simple and easy, it does require someone answer questions. I want a fully automated and customized environment. I did this a few years ago but am now going to re-visit and improve it.

Forcing ssh login via s/key

By On · Add Comment

In the back of my mind are the recent attacks against Google and others by the Chinese government.  I keep asking myself how I would setup and defend against such attacks, and more importantly mitigate them. The end goal of this exercise for me, is to limit Internet access to devices that have authenticated to the gateway/proxy.  Thus when the user logouts of their workstation for the day and goes home, their computer is now cut off from the Internet.

I’ve thought about using key based authentication.  Trick is, if the system has a keyboard logger installed, then both the keys and the passphrase protecting the keys can be stolen.  Harder than most, but not fool proof.

I’m thinking of a case where the user’s computer is compromised by someone external to the company.  At this point my intent is to limit the ability of the computer to access the Internet.  If the computer can not talk with the Internet then the person who compromised the system can not get data out of the company network.

At this point the solution in my head was to use authpf, ssh, and s/key.  I would prefer that users not have a local password.  Instead they can only use s/key to login.  I also would prefer that users don’t have to type user:skey@host and instead just user@host and have s/key forced upon them.  I created a new login class, a new user, and had s/key as the authentication method for the class.  I assigned the user to the class.  Then  I ‘su – user’ and then tried skeyinit but the “user” then gets prompted for their password.  Because their login class requires s/key the password being requested is an s/key password.  A catch-22.  :(

If you’re reading this and have a suggestion or idea on how I might work around this or otherwise accomplish my goal, please leave a comment.

idea for authpf

By On · Add Comment

I know some sites trust their servers and let the servers talk to anywhere on the Internet or internally.

Just had a thought, instead all servers should be blocked for all traffic except for business needed traffic. What about updates? The servers need to go fetch updates. (In those cases where the patches/updates are not handled in a centralized method.) Give those who are responsible for patching servers an authpf account that gives the server the permission to go get updates.

When the sysop logouts of the gateway system the rules are reverted back to a very restricted state. The nice part is that this will work 24×7 and the firewall admins need not be around to change the rules.

To further contain possible unwanted behavior, give each application owner their own ID and limit that ID to the specific IPs of the application servers.

What do you think?

Whitfield Diffie talks about secure cloud computing

By On · Add Comment

In this article Whitfield Diffie talks talks about secure cloud computing.  I take comfort in knowing that he and I used to work for the same company, Sun Microsystems.  There are some really smart people at Sun.  The article is small and I recommend reading it.  I specifically quote part of the article below as it mentions OpenBSD.  I’ve been running OpenBSD for years.

TR: If a full cryptographic solution is far-off, what would a near-term solution look like?

WD: A practical solution will have several properties. It will require an overall improvement in computer security. Much of this would result from care on the part of cloud computing providers–choosing more secure operating systems such as OpenBSD and Solaris–and keeping those systems carefully configured. A security-conscious computing services provider would provision each user with its own processors, caches, and memory at any given moment and would clean house between users, reloading the operating system and zeroing all memory.

An important component of security will be the quality of the personnel operating the data centers: good security training and appropriate security vetting. A secure data center might well be administered externally, allowing a very limited group of employees physical access to the computers. The operators should not be able to access any of the customer data, even as they supervise the scheduling and provisioning of computations.