Jamulus: Ill advised recommendation to disable portions of user firewalls

[lefty665]

In a recent post gilgongo recommended to a poster that he disable a portion of his firewall, specifically Stateful Packet Inspections - SPI. He indicated he would add that recommendation to the Jamulus wiki. That recommendation is now included in the wiki. I urge Jamulus to delete that wiki reference and to annotate the blog posting. Links to the posts are at the bottom of this post.

That recommendation is ill advised for several reasons. One of which is that disabling router firewall protections creates vulnerabilities unrelated to Jamulus. Another is potential liability to Jamulus for damages to user computers caused by following the recommendation to disable SPI. A third is the potential for Jamulus to be used as a vector of infection for other Jamulus users due to disabling firewall protections. The potential for an unwitting infected user to spread viruses or malware to other users every time he or she connects to a jam cannot be preemptively discounted. Covid19 has given us all a better understanding of how infections can spread.

Insult to injury, gilgongo suggested that I must be "doing something pretty non-standard with your network" because I valued what is a very standard feature of modern router firewalls. My response was "Tell me please, is Jamulus 'doing something pretty non-standard with your network' traffic that would run afoul of SPI? Thanks.'" . He has not responded to that beyond telling me the discussion was in the wrong thread. I trust this is the right place.

I stumbled across gilgongo's post while looking for a resolution to an issue I have been having with Jamulus erratically showing partial or blank data lists of servers to connect to. His recommendation seemed so ill advised, especially as it has been incorporated into the Jamulus wiki, that I responded to it. I have now spent more time jiving with him than in resolving the issue that brought me to these forums in the first place.

While not done exclusively in response to gilgongo's post, the computer I run Jamulus on is isolated from the rest of my network.

I like Jamulus. As an IT person, programmer and part time musician, I like how it works from the program logic to the simple and intuitive user interface. After getting up on the learning curve it has been a good way to stay connected to musician friends, band mates, and to make new musician friends from both close by and surprisingly far away. Thank you Jamulus.

https://github.com/corrados/jamulus/issues/255#issuecomment-633342772
https://sourceforge.net/p/llcon/discussion/533517/thread/0e9aa52428/?page=1 pages 2 and 3
https://en.wikipedia.org/wiki/Stateful_firewall

[gilgongo]

If you want, you can remove the reference to turning off SPI, and thereby make some Jamulus users waste time looking for a cause to their problem. Turning off SPI is a troubleshooting recommendation for a specific issue affecting a small minority of users.

To elaborate on my response in forums:

Turning off SPI is not the same as turning off a firewall. If turning off SPI was as dangerous as you make out, the option to turn it off (on a home router) would not be there. The option is in fact to help troubleshoot issues like the one we're talking about. With a possible cause established, the user can then stop looking for other causes, and take a decision about their firewall settings.

NAT prevents unsolicited requests into the LAN in any case (thereby acting as a primitive firewall), and the option to turn off SPI will leave any stateful settings untouched. If you're really paranoid, the addition of a software firewall on your machine (which pretty much all Windows users have), means you will be safe without SPI unless you are doing something unusual with routing tables or VLANs.

In which case you can leave SPI on :-)

[lefty665]

You are as naive and lightly informed as ever. SPI is a basic part of modern firewalls, and your assertion that you can turn off SPI and leave the firewall SPI settings unaffected indicates you either may not understand the difference between "On" and "Off", or that you are being disingenuous in that SPI settings may not be changed, but they will not be applied while "Off". NAT is great, but it's been more than 20 years since we have relied on it alone to provide safety on the web.

No, a software/os firewall by itself, which it is when router based firewall protections are turned off, is not enough to keep you safe. Your spreading of misinformation is a danger to users.

For the third time, why is Jamulus "doing something unusual with routing tables or VLANs" that can cause it to run afoul of SPI? The issue is with the app, not the user. You have it backwards. Please be forthcoming on the issue instead of discounting it and spreading misinformation, if you are able.

As a provider of an internet dependent app you have an obligation to protect your users from internet dangers. The obligation is heightened when you are dealing with a user community that in many cases is not technically sophisticated. Your blythe assurances not to worry our pretty little heads about following your recommendation to turn off firewall protections is not protecting your users.

I again urge you to remove your ill advised recommendation in the Jamulus Wiki to turn off portions of users router firewalls.

[corrados]

why is Jamulus "doing something unusual with routing tables or VLANs" that can cause it to run afoul of SPI? The issue is with the app, not the user.

Do you have an idea why Jamulus is causing issues for the SPI? How could Jamulus solve these issues?

I again urge you to remove your ill advised recommendation in the Jamulus Wiki to turn off portions of users router firewalls.

As a compromise: Could we write in the Wiki that turning off SPI could solve Jamulus issues but it is risky in terms of internet security? Could you do these changes?

[gilgongo]

The finding that in some circumstance turning off SPI helped the server list issue was something somebody said on the forums. I don't know if it works as I don't have that option on my router.

[Snayler]

If there are ways to work around the SPI solution, those should be used. If the cause of the problem with partial or blank server lists is UDP fragmentation, #255 has a good solution for that (which would have to be developed with fallback to UDP for backwards compatibility).

As a temporary fix, @corrados compromise sounds OK, as it would alert the user about the dangers. After developing the TCP solution, the wiki entry can be changed to "update Jamulus to latest version".

[corrados]

The fragmentation problem will be solved by smaller lists. But I think the SPI issue is something completely different. Jamulus sends out ping messages to a lot of different IP addresses. Maybe this behaviour is suspicious to the SPI causing the ping messages to be blocked. But this is just a guess.

[gilgongo]

@Snayler @corrados As I understand it, there are two separate issues each with similar effects in the UI: UDP fragmentation leading to truncated lists of servers which have users and ping times listed, and something else (not sure what) leading to truncated lists of servers that only have some servers listed with users and ping times (the latter is the problem I experience).

If that's correct, then the advice to update to the latest version of Jamulus may or may not help (it hasn't helped for me), and the same applies to turning off SPI.

[WolfganP]

Some network professionals recommend disabling SPI but strictly for the traffic pertaining to VOIP rules (ie https://support.itel.com/hc/en-us/articles/202827745-Recommended-Settings-on-a-Sonicwall-for-Digital-Voice), traffic that may resemble jamulus' streams to a certain extent.

But generally home routers doesn't have that capability, and SPI settings are all or nothing, where the action of disabling it may expose the whole home network to flood/DOS attacks -an additional consequences- if disconnected.

So as almost always, it ends up being a user decision to balance performance vs security...

[lefty665]

corrados- Thank you for your response. I have no idea why Jamulus would be running afoul of SPI, I have not had my nose down into Jamulus data streams. I was simply turning gilgongo's repeated assertion that I must be doing something strange with my network to care about SPI in the first place on its head. The issue is in the app, not the user. I was also making the point that recommending turning off standard router firewall protections was not a great idea for either the User or for Jamulus.

Even a modified recommendation carries risks for the user and potentially (see below) Jamulus. While I have run into a number of musical nerds (they rock!) on Jamulus there are many more, as Volker notes in his PDF, who have maxed their techie skills/interests with the power switch. What happens when one of the latter follows even a caveated recommendation and gets hacked because he/she turned off firewall protections? Is that an outcome Jamulus is comfortable with? I have been clear where I fall on that question, and my answer is "No". FWIW, I've been peddling apps to users for a long time, and have learned the hard way to be very careful what I recommend to people. With enough users, if something is possible someone will do it, and if it is highlighted more will do it.

Seems to me that WolfganP has a pretty good take on SPI.

FWIW, I have no problem with the work and recommendations you are doing/making with UDP fragments and a particular model router.

corrados - I too am suspicious of ping floods. But, that may be just because I am aware Jamulus makes heavy use of pings. It seems possible a buffer overruns or they trigger a firewall setting. In my case the partial/empty data lists occur after a successful population. I require a boot to clear the status. That makes me suspect the latter, but all that is is a guess.

I have seen no discussion of security and Jamulus. If I have just missed it will someone please be kind enough to provide me a link so I can become informed. An overview of the risks and steps/recommendations Jamulus has made to protect users would make me more comfortable.

Thank you for Jamulus, I enjoy using it.

[lefty665]

Here is a simple example of a security issue involving pings: The first step in hacking a computer is figuring out its address, the URL. This is commonly done by pinging URLs. If the hacker gets a response he/she knows there is a computer there to attack. Most routers produced in the last 20 years or so have a switch in the settings that allows users to turn off responses to pings from the web. In recent years many routers ship with that switch turned off.

Jamulus uses pings to establish if servers are on line, and the speed of the connection. To do this Jamulus must bypass the respond to ping security setting on the router hosting the server computer to allow it to respond to a ping from the web.

What does Jamulus do to prevent an attacker from pinging the port(s) Jamulus uses to communicate to identify a computer that it would otherwise not know existed?

Is there a place where this and other common Jamulus security issues are discussed? Thank you.

[corrados]

Most routers produced in the last 20 years or so have a switch in the settings that allows users to turn off responses to pings from the web.

Actually Jamulus does not use a standard ping. The ping is performed using Jamulus's own protocol. So for the firewall it is just an unknown UDP packet sent to some IP address.

To do this Jamulus must bypass the respond to ping security setting on the router hosting the server computer to allow it to respond to a ping from the web.

Are we talking about problems for the server or client? I thought here we are only talking about the client.

What does Jamulus do to prevent an attacker from pinging the port(s) Jamulus uses to communicate to identify a computer that it would otherwise not know existed?

I do not understand your question. Jamulus opens a port on which it listens for Jamulus protocol messages or audio packets.

Is there a place where this and other common Jamulus security issues are discussed?

Not yet. What would you recommend? To create a forum on Sourceforge?

[lefty665]

corrados, thank you for your response.

Starting at the end, I would advocate a format you are comfortable with. At some point a statement or pdf on security of Jamulus would seem appropriate. An assurance that you have addressed potential security issues would go a long way towards reassuring users that they are not risking their computer to attacks by using Jamulus. In the interim a forum on Sourceforge might be productive. There are undoubtedly Jamulus users who are knowledgeable on app and web security. Engaging them could be a good source of expertise.

Makes sense that the Jamulus ping is a proprietary Jamulus packet and not a standard ping. A question then becomes is there anything to prevent an attacker from using that packet format to generate responses that identify the presence of a computer? Are the packets encrypted.

In building a data list of available servers the client likely pings the list of registered servers provided by the central server to see which servers are available, ping times and user counts/ids. After a connection is established between a client and a server the ongoing client/server ping could come from either end. Doing the ping time calc would nominally be a server function, but could certainly be done at the client end.

The questions I am left with are what is done to protect the Jamulus pings (encryption?), same question for the client/server UI I/O and audio data streams.

Delay is the ultimate issue with Jamulus, and anything that adds to overhead, like security, potentially increases delay. That makes me sympathetic to efforts to keep Jamulus simple, functional and safe. It is a tricky set of issues, but you knew that already.

Thank you for Jamulus. It is helping me stay connected to musicians in a sequestered world.

[corrados]

Ok, I just created a new Issue specifically for discussing security issues: https://github.com/corrados/jamulus/issues/314. Let's continue the discussion in that Issue now.

[corrados]

Ok, discussion in https://github.com/corrados/jamulus/issues/314 has already started. I'll close this one now.