Add protection for private servers

[ann0see]

Would it be possible to add some kind of protection to private servers so that not everybody who knows the IP can join?

Adding a password for private servers would enable real private sessions and increase overall security and privacy.
Maybe it's not easy to implement with udp or would add some overhead?
Maybe a ip unblock after somebody has input the correct server password would be an option?

[corrados]

Jamulus shall be a free jam session tool. Nothing is more frustrating if a server is listed in the server list but it is protected by a password.
If you have setup a private server, then this is enough protection. Nobody will guess the IP number and the port number you have chosen.

[genesisproject2020]

Suggestion. A server listed has to be open. Adding a private flag and when it's set on a server the server will be not listed.

[ann0see]

I totally agree that public servers shouldn't have a password. But especially for private servers some kind of protection would be good (since a portscan is easy). Maybe I'm a bit paranoid but I don't like the idea of somebody being able to connect to my private server and possibly interupt or disturb a jam session.

[corrados]

I use the software since 14 years now. I regularily use private server for some rehearsals. I had never the case that some stranger entered that private server.

[gilgongo]

Adding a private flag and when it's set on a server the server will be not listed.

Interesting, because it implies you wouldn't need to set up a private server (with port forwarding etc.) as you do today. On the other hand I don't think it would work with a 150 server limit to each Central Server. They'd probably just all fill up.

[genesisproject2020]

Adding a private flag and when it's set on a server the server will be not listed.

Interesting, because it implies you wouldn't need to set up a private server (with port forwarding etc.) as you do today. On the other hand I don't think it would work with a 150 server limit to each Central Server. They'd probably just all fill up.

Could be a list that doesnt update that often and then a bigger list that will not show up in the client at all.

[WolfganP]

If it's a private server, why listing and hiding it? I don't see any purpose on it if the intent is being non discoverable. Just host it without registering into a central server.

Regarding the port scan, I don't see what adding a password will add in terms of security of the session:
*if it's not an authorized user that received the IP:port via a side channel (sharing via mail or IM group), most likely s/he also received the password as well.
*if it's a matter of portscan, Jamulus is UDP based so it will react as any other stateless server on the machine (game, voip, conference, ...). You may change the server port to a non standard one, and that will mitigate the risk if anyone is purposefully targeting Jamulus default port 22124.

[gilgongo]

If it's a private server, why listing and hiding it? I don't see any purpose on it if the intent is being non discoverable. Just host it without registering into a central server.

Because then you don't have to mess with port forwarding and stuff. Just fire up your server and off you go (Of course, this would mean you'd need to know what to tell your friends to put in their connection window in order to connect to you, and that there wouldn't be more than 150 servers of any type (public or private) on that Central Server).

[WolfganP]

If it's a private server, why listing and hiding it? I don't see any purpose on it if the intent is being non discoverable. Just host it without registering into a central server.

Because then you don't have to mess with port forwarding and stuff. Just fire up your server and off you go (Of course, this would mean you'd need to know what to tell your friends to put in their connection window in order to connect to you, and that there wouldn't be more than 150 servers of any type (public or private) on that Central Server).

So you propose to use the registration procedure as a trigger for the port forward of your router?

[gilgongo]

So you propose to use the registration procedure as a trigger for the port forward of your router?

Well that's how it works today :-) When you register a public server today, it's public and anyone can connect to you without you needing to port forward (this is part of the point of having a Central Server system). The idea @genesisproject2020 had simply implies you'd have the ability to prevent it showing in the list.

But all this is academic. I don't think we can have (or need) "private public servers" like this.

(BTW totally off topic, but I do get the impression some people think you have to port forward to run a public server. It doesn't do any harm of course, but it's completely unnecessary).

[sthenos]

I think a lot of people get confused between port forward and opening a port on their firewall. The two things are mutually exclusive.

[gilgongo]

@sthenos Interesting. I've not noticed any talk about that on the forums I don't think.

If somebody simply opened UDP 22124 on their firewall so that all machines on their LAN were exposed to that, instead of port forwarding 22124, it would appear to be the same as port forwarding, is that right? I didn't realise routers made them mutually exclusive.

BTW the other day I added this to the Server Types docs on the wiki: "Note: It is not necessary to port-forward or otherwise configure your router to run a public server."

[WolfganP]

As there's no registration process/announcement while running a private server, a compromise solution may be for the (local) private server to send a dummy msg to the (remote) central server (no action on central server other than discard the msg, or just update anonymous stats on private servers), and use that initial outbound packet to trigger a port forwarding (that the router/firewall will close once the private server is shutdown and the firewall timeout acts), and avoid any permanent port forwarding/opening that way.
What do you guys think?