Web interface is supposed to be used externally only for debug, and by default there won't be open ports susceptible to an atack. We are still under development, at this point there are some known issues already reported in Mantis, but feel free to fill Mantis reports if you consider necessary.

After reviewing some of the previous posts os security concerns it seems that there are a number of ports open to the outside. However, my concern was with the actual PHP code of 'pluto-admin'.

If people want to remotely control everything from, say sitting at the office, one would need to use this web interface (correct me if I'm wrong).

If that's the case then the documentaion regarding code security is missing. If one was to find a security bug then I don't think it should be posted in bugtracker since it will allow people to exploit it.

I think that if you want to control your home when sitting in the office you may want to use a remote orbiter, not the pluto admin web interface.

Orbiters use port TCP 3456 (if I remember well) but they exchange data with core/hybrid in "clear mode" i.e. not encrypted.

In this case I use SSH tunnelling, and from my laptop I can connect safely to my house from wherever I am.

You may also want to use the WebOrbiter, that uses port 8080 (if I remember well). Here there is the same issue related to security, that can be solved exactly in the same way with SSH tunnels.

So the idea is (whichever may be the open ports on your core) to close all your sensitive ports on your router, and open only SSH.This of course prevents you to connect to your house via a mobile phone when you are away (via wap protocol), but it is up to you to decide what is "safe" and what is not.

I think that if you want to control your home when sitting in the office you may want to use a remote orbiter, not the pluto admin web interface.

MarcoZan is correct, Pluto admin is designed to configure everything in your Pluto system, but not to use it as a orbiter.

Regarding puting security holes in bugtracking software, I think it's something beneficial from more reasons:- any bug marked with priority "urgent" must be fixed in 48 hours;- the bug can be marked as "private" so only devs and the reporter will see it.

I apologize since I have not explained my self correctly. My conern is of code security rather than remote functionality. I have not seen any information on this issue in the documentation.

After performin a personal code audit I came to a conclusion (perhaps too fast, time will tell) that the 'pluto-admin' web interface is not designed with security in mind. Which, in my opinion, lightly put, is bad.

I have posted a bug report, as suggested by the above post, to fix an issue which is rather trivial to exploit. There might be more exploitable bugs in PHP code, I don't know at this point. I only hope this will encorage developers to incorporate a security model in their code design.

I got your point.Although I'm not a Pluto developer, I can guess that probably they designed the whole system to be externally accessible only via wap.

No other type of interaction were probably forecasted or seriously considered, so the security of the system was simply based on "close all router ports" rule.

Let's say that from a theoretical point of view this is bad (as you say), from a practical point of view this makes sense.

Say that at this stage the only people that can hack my system is my wife or my kids, and in general this more or less applies to almost all Pluto systems.

Given this, and given the fact that they rely on a non-infinite resources I think they decided to focus mainly on features rather than security.

Nevertheless I agree that a security model may be adopted, expecially now that they are supposed to approach to an official release where features are more or less freezed and the main concern is reliability.

The only question I have is: Is the pluto-admin web interface enabled by default on the external network interface of the gateway after install?

If yes then code security is of big concern, if this is an optional feature then it's up to the user to protect it.

However, I still believe something about gateway security (Dos, Donts, or suggestion) should be in the documentation.

I only hope that this thread helps to progress the product securely. From previous experience, if security wasn't taken into consideration early in development then chances are it will be extremely difficult to incorporate it later on.