IMPORTANT: Stop forwarding your LMS ports to the internet!

[mherger]

IMPORTANT: Stop forwarding your LMS ports to theinternet!

> You could change LMS to require a password if the IP address is not
> local and have a maximum number of password attempts before suspending
> such access for X hours - and a setting to disable all of this for
> someone who really insists on taking the risk.

I can't change the users' LMS. And as said before: most of those
installation aren't up to date, therefore unlikely to see a change in a
new build.

--

Michael

[Jeff07971]

> A large and sticky warning on the home page of the forums would be
> wiser.

Unfortunately only a very small percentage of the SB community is
regularly visiting these forums. Even I wouldn't get to see that message!

> I note that there are a lot of v7.9.0 and more than a few v7.9.1 in the
> list of open LMS's meaning people update (or is done automatically) so a
> software change may work to help.

Interesting. In my list there are far more 7.7.x installations than
7.9.x. And many are really old, like 7.7.2/3.

> Use a list generated by THAT search engine to grab a list of open LMS's
> and automatically sent a command to turn all player on and stream a file
> from Logitech saying something like "This system is compromised please
> see article on forum" repeatedly until stopped.

This is about as far as my "hacking" would go: interact with LMS.

--

Michael

Yes I see your point I make it about 25% are 7.9.0 - 7.9.1 (BTW I searched "logitech media server" or "logitech media server 7.9.0" or "logitech media server 7.9.1")

Still removing 25% would be a start !

Jeff

[Paul Webster]

I can't change the users' LMS. And as said before: most of those
installation aren't up to date, therefore unlikely to see a change in a
new build.

I wasn't suggesting directly changing their systems - but them receiving updates (if they have automatic update enabled).
If they are very old and not auto-updating then clearly it won't help them.
However, such a change (or even better ones) would help protect those who do install new versions in the future.

[drmatt]

If you can identify their mysb accounts then you could insert a message on their login banner?

Sent from my ONEPLUS A3003 using Tapatalk

[StephenC]

I've been running LMS, open to the Internet, for years. Never had an issue (of which I'm aware, anyway). Until a few weeks ago. Bizarre alarms in the middle of the night, across a few different players. Then, 1am yesterday, multiple players firing up at full volume. A couple of these aren't local, and the users were far from impressed.

To avoid the complication of VPN, or passwords (the remote users are very technologically challenged), is the IP filtering within LMS considered 'acceptable'? The remote users are all on semi-static IPs (Virgin Media - IP addresses seem to persist for years, even through router reboots):


Thanks a lot.

Stephen.

[mherger]

IMPORTANT: Stop forwarding your LMS ports to theinternet!

> To avoid the complication of VPN, or passwords (the remote users are
> very technologically challenged), is the IP filtering within LMS
> considered 'acceptable'? The remote users are all on semi-static IPs

TBH: I don't know what IP address your LMS would see in this case. Give
it a try and let us know.

But then I'd really not expose LMS to the internet. I just wouldn't.

--

Michael

[drmatt]

On Linux I would suggest iptables.

Sent from my ONEPLUS A3003 using Tapatalk

[StephenC]

TBH: I don't know what IP address your LMS would see in this case. Give
it a try and let us know.

But then I'd really not expose LMS to the internet. I just wouldn't.

--

Michael

I used to use this function, and everything worked fine. I changed it only because one user was astonishingly technophobic, whilst at the same time entirely addicted to BBC iPlayer on the Squeezebox. Their solution to pretty much every problem in the house was to switch off the router, and leave it for an hour before turning it on again (I kid you not - even if their Humax DVR had crashed!) It was an ADSL connection, so the IP changed regularly. They no longer use Squeezebox, having switched to a Roberts Stream 93i.

I really would rather not have to implement a VPN client from the remote user ends, but it might come to that.

But, I'll see how things go with the switch to IP whitelisting, and maybe also set up some iptables entries...

Thanks a lot.

Stephen

[StephenC]

... Give it a try and let us know.

...

I gave it a try, and all was fine, except...

Spotify Protocol Handler - Booms and SB3s reported 'Bad Player (Error: -1)' when I tried to play Spotify tracks. Touches and Radios were fine.

So, I changed back to 'Do Not Block' (even though the whitelist was correct, and external Radios were fine with Spotify) and then the Booms and SB3s were ok again.

Oddly, once the affected players had successfully played Spotify tracks, re-enabling the 'Block' didn't affect them - they remained working. But, only until a restart of LMS, when they stopped again.

Have now left the setting as 'Do Not Block', and set some iptables rules to achieve the same (probably much better!) security. Here are the ufw commands (I cheated a bit - ufw is much nicer to work with than iptables):

ufw allow 22/tcp
ufw allow from 192.168.1.0/24 to any port 9000 proto tcp
ufw allow from 82.27.???.??? to any port 9000 proto tcp
ufw allow from 90.204.???.??? to any port 9000 proto tcp
ufw allow from 192.168.1.0/24 to any port 9005 proto tcp
ufw allow from 90.204.???.??? to any port 9005 proto tcp
ufw allow from 82.27.???.??? to any port 9005 proto tcp
ufw allow from 192.168.1.0/24 to any port 3483
ufw allow from 82.27.???.??? to any port 3483
ufw allow from 90.204.???.??? to any port 3483

My LAN is on the 192.168.1.0 subnet - If yours differs then you'll need to change to suit.
The 82.27.???.??? and 90.204.???.??? are the IPs of my remote users.

Hope this helps someone, some time.

Cheers.

Stephen.

[Peter Galbavy]

At the moment I do have ports 3483 and 9000 open but with a password. However there is still passwordless access available to support older SB units (like the SB3 on my desk at work).

Perhaps one step in the right direction to help those of us who run exposed services would be to add an option to not allow "legacy" password-less access and make that the default on install? Then, if we choose to knowingly connect older hardware we have to make a choice to allow this access?

[Hip-Priest]

OK - so now that I am completely locked out of LMS, can any one tell a non-techie how to get into it so that I can disable the password? I am running LMS on a Synology Diskstation, with a SBTouch/iPeng/Macbook as my player. I have closed the relevant ports on my router, but I still get the password screen when I try to log in via a my Mac.

[mherger]

IMPORTANT: Stop forwarding your LMS ports to theinternet!

> OK - so now that I am completely locked out of LMS, can any one tell a
> non-techie how to get into it so that I can disable the password? I am
> running LMS on a Synology Diskstation, with a SBTouch as my player. I
> have closed the ports on my router, but I still get the password screen
> when I try to log in via a Mac or iPeng on an iPhone.

You'll have to shut down LMS, and edit its server.prefs file. Where
exactly that file is stored you better ask in a Synology specific
thread. There are prefs for authorize and username. Remove those lines
and restart LMS.

--

Michael

[jimzak]

Other server options for external access of music.

Quick somewhat OT question.

Are other music serves such as Younity, Subsonic, Plex also as easily susceptible to attack?

I currently have SB for internal use and Plex for external use.

[d6jg]

Anything that is open to the internet must be considered a risk.
You need to check the forums for Plex etc as general advice won't be good enough. My understanding of subsonic is that it was designed for remote streaming but I'd still check.
The best solution is a VPN (not pptp) with solid credentials.

[Nonreality]

You could change LMS to require a password if the IP address is not local and have a maximum number of password attempts before suspending such access for X hours - and a setting to disable all of this for someone who really insists on taking the risk.
At least those users who have auto-update enabled would have a bit better protection.

So am I understanding that I should not have auto updates turned on in LMS?

Sent from my SM-G955U using Tapatalk