Portcullis

• Currently Vaporware (sorry), but I am working on this idea.
• Easy to use
  
• Secure
  
• Encrypted
  
• Scaling
  

What is Portcullis?

Everybody knows what a Portcullis is. It's something you have to protect your castle. You can see it, but you know you cannot go past it.

So what is Portcullis?

It's a way to secure an open port, such that you still can get through, but nobody else. It twarts automated attack patterns (like SSH scanners) as well and keeps your services behind it secure and more easy to manage. It transparently encrypts the data (if needed), such even using telnet in a most hostile environment becomes secure.

It even can protect against replay attacks, for example in a case where everything is logged at your side, like you are sitting on a computer which has a keylooger, all bits of the networking are monitored on your side and the server's side and an infintiy-dimensional camera even records all the quantum states of your body such that you can be 100% emulated (so biometric protections are useless).

I wrote that the idea is to defend even against most hostile environments, where a weapon is attached to your head, such that you, and only you, are able to open the port, and once it is closed again, they need you - again and alive - to reopen it.

I still do not get it, so what is Portcullis?

Portcullis is something like inetd/tcpwrapper. It accepts the connection instead of the real service, protects the connection by asking some not ovious things (that is: Security by obscurity) and if everything is successfully authenticated it forwards the connection to the real service. This is either done by executing the service on the socket (as inetd does) or by port forwarding (an possibly replaying some stuff).

With the second method, portcullis is able to forward to another portcullis, of course, and start the conversation. The idea is, that you can establish a "service labyrinth" by this, something other people except you will loose orientation quickly.

Portcullis will provide several features:

• Service layer protection using Challenge/Response authentication (later perhaps even Zero-Knowledge)
• Service layer encryption via SSL
  
• Service layer authentication (Client certificate authentication)
• Decentral management (automatic autolearning distributed configuration)
• Direct client-to-client channels
  
• Automated reconnect if you loose Internet connection or for roaming purpose, without service interruption
• Rerouting to the shortest possible path (using the reconnect feature)
• Mutual authentication between clients using a PKI structure
• Hardened environment to protect against buffer overruns in the first line of defense
• Full auditing on all levels
  
• Local and central policies
  

Sounds nice, but now, what is Portcullis actually?

Well, it is more easily described by what it is not:

• It is not a VPN solution. VPN means, you are in a network. Portcullis is no network, it only maps service-points (aka. Ports). Also it currently only can speak TCP.
• It is not a port mapper / port tunnel service. The basic is to map and tunnel ports, but that's not the idea behind Portcullis.
• It is not a service firewall. So Portcullis will not protect your services against evil exploit. It will only raise the protections level to an unbearable way (if done properly) such that people not authorized to go past Portcullis cannot exploit the service.
• It is not a policy framework or a security device, which secures your laptop against a virus, trojan, rootkit etc. It only helps you to secure everything afterwards again by easily changing the authentication information, such that all data stolen does not help to again geet past Portcullis (you need fresh credentials).
• It's not complicated at all, but just a simple script.

The idea behind Portcullis is:

• Map different service ports to your local laptop and forward this ports to the right service. Regardless where this service sits.
• Keep all the IP:port combinations identicall over the complete Portcullis network you use, such that the service ports are identicall everywhere and you therefor can use absolute URLs in documentation, and share these URLs etc. with your colleagues and have these URLs working there, too.
• Forward local services over the cloud to your colleagues as well, such that they - for example - can access a preview which only runs on your laptop.
• Allow different transports to do all this tunneling/mapping, such that you can use Portcullis behind HTTPS Web proxy, over slow GPRS links or if you are directly connected to the Internet.
• Keep everything connected even when the connection breaks, until you reconnect. This is, all the connects are permanent, until teared down by either side, but not because of network outages. This way you can hibernate your laptop at work and stop using your cell phone's Internet connection, go home, start your laptop again and contine to work with your cable connection. Seamlessly. This does not work, however, if you have to reboot your Laptop (or the remote service), as then the OS does no more know of any connections.
• You have not to bother aboout how to reach somebody else. If the other is known to Portcullis and is connected to the cloud, both can talk to each other.
• Be free of the needs of any central service. You can use any forwarding service in the cloud, as the connection always is end-to-end encrypted and authenticated (no MitM possible) thanks to the underlying PKI.
• Easily administer anything through your web browser. This is convenient, as you, this way, do not do it differently if something is locally or remotely installed.
• True autolearning and autoconfiguration, so administrators do not need to think about any deployment plan. Just assign something to somebody, the rest is handled by the cloud.

Implementation

The best thing, it's simple to do:

• To protect the services all you need is a short shell script, usually less than 10 lines of code. There are some simple examples to show, how. I already have such scripts which use "putty.exe" as the tool.
• I also need a simple repeater to allow direct communication of clients - however this is left for future, for now I use socat for my needs.
• So all I need to write is a Python script to be run locally. This must be able to run under Windows as well as Linux and Mac OSX.

Python script features

Here is the feature list I want to create, step by step:

• Listen for a local port and forward it automagically to some other destination, opening some Portcullis in the way. This should be fairly easy.
• Encrypt the tunnel using standard SSL and do client certificate authentication for this. The client certificates utilize PKI, so they must be signed by the correct CA-root-certificate. The only problem for me is, that I do not know how to do this on Python yet (it's fairly trivial to do it with socat)!
• Merge local defines with other port information, which is learned automatically when contacting other Portcullis services ("suggestions").
• Write a little webGUI to make local administration of this port mapping more easy.
• Extend the webGUI to create client certificates, send and receive CSR to the cloud. (Before the Cert must be copied manually.)
• Create transports to be able to tunnel through things like HTTPS webproxies more easily.
• Make the transport configurable through the webGUI, that is, manage the different transport possibilities to select them with a single click.
• Make the transport auto-learning, that is, look at the IP of the network card (etc.) and invoke the correct transport automatically.
• Extend transports by (standard-)repeaters to enable to connect to services which are not directly reachable.
• Allow the Portcullis script to act as a repeater as well, forwarding connects of colleagues to the cloud (so only one person of a team needs Internet access, the others can use ad-hoc-WiFi to connect there).
• Allow service sharing, that is to propagate services to the cloud through the Portcullis script. (Before services had to be configured manually, for example by creating some minimal Portcullis script.) Here we now have a full featured portcullis script which does no more need other helpers. However it is NOT RECOMMENDED to use the script to protect the service, as the script is much too complicated now, it should only be used for clients, not for services/servers.
• Create auto-routing, that is, try to locate a route from some client to another, without manual intervention. This needs some discovery and decentral registration services to provide all the needed data.
• Implement Multi-routes and route truncation. That is try to find all possible routes to a target and use all at once to distribute load. On low load situation this ensures, that the shortest route is taken.
• Create more easy standard setup. That is, allow administrators to pre-configure and deloy everything, the user only needs to confirm everything. This also includes a way to join a cloud without the cloud knowing this in advance. However the CA-root must accept every client to become a part of the cloud in question. (Note that a client can be part of more than one cloud, then.)

Note that Portcullis allows to individually permit or restrict connections (but only connections, Portcullis does not monitor the application layer or data transferred) based on the client certificate used. For example, some services need that the client cert is authenticated by some special CA first to make it reachable.

So besides some usual "distributed password access" feature there can be defined multiple different other security features to open the Portcullis. All these are not part of the Portcullis script itself, these are completely open to the implementor! All there will be is a standard way to configure everything, how this then is done at the client side is implementation dependant.

For example, if you have Portcullis for your work, you perhaps want to have Portcullis for your home connection, too. In this case you do not want that colleagues are able to connect to your private computer at home as well. Portcullis allows this. So you can map local ports on your work-laptop to your home-computer without the fear, that some administrator in the company then is able to connect to your home by stealing your setup, if, but only if, there is something (like a Yubikey or some USB stick with some private keyfile) additionally needed to open your home-link.

Also there a thorough auditing is done. That is, you can easily spot if somebody even tried to connect to your home-link through the cloud (usually without success). If so, some information has leaked, and you can change your setup to evade this situation again. This means: You can locally hide your services in the Portcullis script such that only you know of them (and possibly only those people, who are able to read your local setup. BTW this can be made very difficult for others by using the standard Windows file encryption feature. The good thing is, if you loose this information there is no big harm done, as it was only configuration data which mostly can be auto-learned again).

Implementation status

This currently is vaporware and planning-only.

All I have is a portcullis script, like following:

This then is installed on the telnet-port run by inetd.

You can add the password into Putty by entering it in the "proxy"-Setting using a "Telent"-proxy type and enter the password as into the "Telnet command" line. And the SSL-encrypted connect to some web type service needs some local script which does the translation (I have no good explample for this yet):

• Listen for some local port
  
• Open the connection to the Portcullis script
  
• Send the password "AnotherNotSecretPW"
  
• Then encrypt the stream using OpenSSL's-Client with a client certificate

(To express this with SOCAT2 you will go nuts as well, therefor this needs some clever tool to implement it.)

The idea behind this is, even if socat2 or sshd have remote exploits, you cannot get there if you do not know the parole (this is not a password, as the parole chooses where to go to).

-Tino, 2010-02-15