Jamulus
Add protection for private servers #1057
Replies: 43 comments 22 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Could be a list that doesnt update that often and then a bigger list that will not show up in the client at all. |
Beta Was this translation helpful? Give feedback.
-
|
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: |
Beta Was this translation helpful? Give feedback.
-
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). |
Beta Was this translation helpful? Give feedback.
-
So you propose to use the registration procedure as a trigger for the port forward of your router? |
Beta Was this translation helpful? Give feedback.
-
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). |
Beta Was this translation helpful? Give feedback.
-
|
I think a lot of people get confused between port forward and opening a port on their firewall. The two things are mutually exclusive. |
Beta Was this translation helpful? Give feedback.
-
|
@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." |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Just found this sourceforge thread about a (probably not well working) jamulus fork https://sourceforge.net/p/llcon/discussion/533517/thread/a17b6db848/
I‘d nevertheless suggest to add a commandline flag to the central server which disallows protected servers to connect. The client should show a lock icon or something similar to flag protected servers. I‘d be happy to code something but unfortunately don’t really know QT or C++. I do know PHP and can work it out probably but need some guidance/description of the connection progress/... The registration progress or connection to a central server to overcome the need of port forwarding in my opinion should not be connected to this feature. |
Beta Was this translation helpful? Give feedback.
-
|
The servers listed in the official Jamulus server lists are free to use for everyone. There will be no password protection. If you require a private session, you have multiple alternatives with Jamulus:
|
Beta Was this translation helpful? Give feedback.
-
|
Is there a reason this concept is not generalized to protect a jam session? Consider: Sometimes we want to allow visitors, some times we want the rehearsal to be private (meaning interrupted or free from distractions). If only "private" servers are protected as implied in the other comments, my examples would require three or more servers to be created and each ensemble will have to have admin skills. It would be much better for one chorus with the technical skills to support the community (4+ choruses?). |
Beta Was this translation helpful? Give feedback.
-
|
Private means free from distractions, but it also means inaccessible by outsiders. Your chorus or students could each click Solo for every other member of the chorus/class. Then they will be free from audio distractions from any other visitors. This does not protect participants from being heard by visitors. But this core skill needs to be practiced by established groups to maintain a distraction-free environment. If a server could one-time-push Solo settings to participants, that would assure their session is free from audio distractions. They may see sliders, and slider panels might even be visually burdened by visitor signals, but the protection you seek is attainable. I do wish a server operator could mass-set a Solo group, even if participants change this setting later. |
Beta Was this translation helpful? Give feedback.
-
|
For me private means that only the people of a group can only hear and see the members of this group. If other people are using the server but can't interact with the group, this would be fine too. |
Beta Was this translation helpful? Give feedback.
-
|
I forgot that the solo feature can isolate the group. Then the only remaining scenario is when the ensemble is preparing for a performance/competition where they/we want the set to be a surprise. |
Beta Was this translation helpful? Give feedback.
-
|
@gene96817 You may also be interested to know that you can switch severs between public and private on the fly. Note also that if people are in the server when you switch between modes, they will stay connected. If "undesirable" people are connected when you wish to move between states, then you can disconnect them by using the If you are running a Linux server it would be pretty easy to script this behaviour on a cron job in fact, so enabling a public/private server "schedule" if you wanted. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the info. However, I don't want to be available to support every session. I also don't want musicians in my chorus or guest to have Linux access to control the server. It is my opinion that the Jamulus server should be controlled through the UI and not by being a system admin. |
Beta Was this translation helpful? Give feedback.
-
If you adopted the "schedule" idea with a cron job, then the server would automatically go from private to public and back again at intervals without you.
Well, that can be done too of course. Run a windowing system on the server and set up a password-protected VNC login (with the server process's userid so nothing else on the server can be changed). I've not actually done that myself, but I believe others have. So you can have an icon on your desktop called "Server admin" :-) Or run Windows on the server and do it that way? In general though, the answer to your question "Is there a reason this concept is not generalized to protect a jam session?" is that if it can be done with other tools/methods then (right now at least) it's probably better to prioritise work on other things. That's not to say this might not change, but doing what you need would require a very large amount of work on some fundamental aspects of Jamulus I believe. |
Beta Was this translation helpful? Give feedback.
-
|
Moving to a discussion now as we need to keep the Issues for actionable specs. |
Beta Was this translation helpful? Give feedback.
-
|
A private server means only it is not visible in the public jamulus server. This is the first part which might not be acceptable because someone who maintains such server has to pay for it and maybe is not willing to pay for many who is not invited (special group). Without an authorization mechanism it is not even possible limit the people on a particular server. Group aspects:
Security:
The argument: No one knows the ip or the port can't be guessed (security by obscurity) is simply wrong because an ip address/port can be found and there are lot of attack machines out in the internet. So we have at least three aspects:
|
Beta Was this translation helpful? Give feedback.
-
|
I still think that we should have a short-term solution. I like @ann0see's eduMode branch, although I haven't tested it and the user experience is probably limited to what's possible without distributing custom clients (e.g. using the chat window).
In my opinion:
|
Beta Was this translation helpful? Give feedback.
-
|
DHCP leases may cause some havoc with IP-based stuff in 1. But hey. Short term as you say. BTW does "no more UDP for protocol messages" mean "total re-write of Jamulus losing all the optimisations made in the last 5 years" as has been mentioned sometimes? I don't know how seriously that's been said though, but if it does mean that then anyone on this thread wanting protection for private servers may want to be careful what they wish for, no? |
Beta Was this translation helpful? Give feedback.
-
I assume you are referring to ISP-side DHCP. I agree, this would be a problem if your dialup connection reconnects during a session and you get a new IP assigned.
I don't think it's a rewrite, but it's a substantial change (or extension) which will need lots of work and lots of testing. This will take time to plan, to develop and to test. Plus, as far as I know, noone is actively working on it. A possible TCP implementation would have to be placed carefully to avoid interferring with other parts of Jamulus. I don't think this part of Jamulus is optimization-critical though, as the critical code path (audio sending/receiving/processing) would stay as-is (UDP). I don't think moving that part to TCP is a viable option. I'd only see downsides and no upsides. |
Beta Was this translation helpful? Give feedback.
-
|
Things like router reboots, power outages etc. and I also notice my ISP apparently randomly renewing my lease to another IP a times too. I don't think it would be a huge issue but would confuse people from time to time. And yes as far as I know, TCP has only barely made it out of the "what if?" stage, and is nowhere near any real architectural thinking. But there are quite a few recurrent themes in discussions about new features that would as far as I know require it (eg this one). |
Beta Was this translation helpful? Give feedback.
-
Maybe, but even if it was session based a re-login might be necessary. That's the case for anything I can think of as well (e.g. WebEx, Citrix).
Yep :) |
Beta Was this translation helpful? Give feedback.
-
|
In my own case, I wish to allow distinct groups of people to access my private server at distinct times. I clearly need to give each member of these groups the IP address, which means the difficulty of managing mildly embarrassing interruptions etc rather than malicious acts. My use case doesn’t really require high levels of security, and could possibly be supported by a mechanism to assign users to a specific group of solo’d participants on connection. The issue would still remain that the total number of people who can access the server concurrently is limited.
|
Beta Was this translation helpful? Give feedback.
-
|
You could think about something like IP whitelisting with some kind of web UI written in PHP which unblocks IPs on a successful log in. |
Beta Was this translation helpful? Give feedback.
-
|
I think Jamulus could extend the whitelist it already has. |
Beta Was this translation helpful? Give feedback.
-
|
Personally, a lot of the motivation for this discussion appears to me motivated by people unable to set up a private server. Setting up a private server has two components: an outside-accessible IP address and port forwarding. The outside-accessible IP address can be communicated or set up via some DynDNS service, the port forwarding should be doable by using UPnP if I understand correctly. At least the latter seems like something that a Jamulus server could be taught to do automatically, and most routers these days can support UPnP I think. So that would be a first step to reduce the clamor for using the public server directories as a crutch for making private servers work with less of an effort. |
Beta Was this translation helpful? Give feedback.
-
For me personally not. I do know how to set up a private server but I don't since I host one at 1fire.hosting. My intent behind it is that only a controlled group can enter the server and participate although the server address is shared. |
Beta Was this translation helpful? Give feedback.
-
|
Actually the usecase of @TPennick is the appropriate one; you have 1 server that you want to timeshare among different audiences. It should be easy to have a password/code that ensures only the correct group can connect at a particular point in time. Sending people to a website to "login" which will whitelist their Ip address work but is ugly unless you can then do a subsequent redirect to the jamulus application on the relevant platforms. |
Beta Was this translation helpful? Give feedback.
-
This does seem a fair edge case which you could meet using existing functionality though - eg private servers on cron jobs, or setting up your own directory and have servers for each audience, or combo of those etc. |
Beta Was this translation helpful? Give feedback.
-
|
not if you all want them to be on the default port |
Beta Was this translation helpful? Give feedback.
-
|
Setting up your own directory wouldn't need that (and the difference between giving out an IP and an IP with a port on the end pretty small). But my point is that there are ways of doing it without building stuff into Jamulus. I understand of course that things like port forwarding etc. may not be easy (or even possible), but then running a server for something more serious than just jamming is an "undertaking" that isn't trivial in other was too, so it really comes down to how many people this stuff affects if there are alternatives to achieving these things. |
Beta Was this translation helpful? Give feedback.
-
|
As I understand the discussion here, you can always put a Jamulus server behind a router/firewall to control who can reach the server. However: I have proposed a method for Jam Session Management (discussion #1371) to cover this as one of many use cases. |
Beta Was this translation helpful? Give feedback.
-
|
Hi,
Could you provide an updated link to the Edutools release which includes the waiting-room functionality? Also, is there a summary of how this works somewhere as I’m keen to give this a try.
|
Beta Was this translation helpful? Give feedback.
-
|
Sure!
|
Beta Was this translation helpful? Give feedback.
-
|
@TPennick |
Beta Was this translation helpful? Give feedback.
-
|
I dislike the idea that some servers on the public directories might be password-protected. But perhaps there could be a new directory that lists password-protected servers, while the rest don't. This gets private servers past the "set up your router" barrier, and keeps them off public directory listings. |
Beta Was this translation helpful? Give feedback.
-
|
There is a private directory (you can probably see it in the DNS) for private servers already. I think the consensus is to disallow servers with protection features on all public (integrated) directories. We'd need a specification + protocol message for this. |
Beta Was this translation helpful? Give feedback.
-
|
@ann0see Could you define protection features, thanks. |
Beta Was this translation helpful? Give feedback.
-
|
Anything which allows another person (e.g the server admin) to control connected users and could be non inclusive.
|
Beta Was this translation helpful? Give feedback.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions