Appendix D. Locking Down Your NetKernel Instance

Originally, this appendix was Linux only and based on a how-to I once wrote for the NetKernel forum. In the meantime, I was able to experiment a bit with some Windows instances, and I’m happy that I can now also present a procedure for that platform.

Cover Story

These days, having your own (virtual) server on the Internet is within the reach of many. There is power in being able to show the world what you can do. However, with (great) power comes (great) responsibility. While no single server can withstand a coordinated attack, there is no need to hand over your paid-for server to the first script-kiddie that comes along, either.

As I said, client and server in what follows can be either Linux (tested with Ubuntu 10.04 LTS—the Lucid Lynx) or Windows (tested with Windows 7 Home Premium). Here’s an overview of the components we will use:

Firewall

For Linux, we will use iptables; for Windows, the default Windows Firewall.

SSH Client

Both platforms will use openssh; for Windows, that means openssh under Cygwin.

SSH Server

Both platforms will use openssh; for Windows, that means openssh under Cygwin.

These are the points we want to accomplish:

  1. Default remote access to the server: none. One non-standard port is opened for ssh access.

  2. The Frontend HTTPFulcrum is remotely reachable (port 8080).

  3. The Backend HTTPFulcrum is not remotely reachable (port 1060), but it can be tunneled to through the port opened for ssh.

Note

This is a very strict setup. ...

Get Resource-Oriented Computing with NetKernel now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.