IMPORTANT: Stop forwarding your LMS ports to the internet!

[mherger]

> Ok, figured it might be something like that. Not an easy problem to
> solve. In this circumstance it would be better to receive a page back
> that says *why* the request was blocked and where to look to allow it
> rather than a 403. Anonymise the hell out of the response of course so
> people can't reasonably guess it's an LMS instance.

That's kind of an oxymoron, isn't it? Tell the user what to do to open
the door, but not tell the attacker what system it is?...

--

Michael

[Jeff07971]

> This unfortunately might be a very common problem as a VPN server is
> often the GW (Mine is both, IPSEC and SSL)

I doubt it'll be anywhere near "common". Please let me know if it causes
you a problem.

--

Michael

Hi Michael

No I don't think it'll be a problem for me, my LMS is via a HTTPs (pasworded) proxy or by VPN only so don't even need to turn the password on

Thanks anyway

Jeff

[drmatt]

>That's kind of an oxymoron, isn't it? Tell the user what to do to open the door, but not tell the attacker what system it is?...

Yes, I know. Thought that as I wrote it. But a change to default behaviour really should be documented and even this is a vast improvement over just being wide open, even if an attacker knows what's there if they can't get anything back from it (not even a password prompt) there's little they can do to get into it.


Transcoded from Matt's brain by Tapatalk

[PasTim]

> As I understand it from some of the previous discussion, something has
> been added to a recent LMS to require a password to change settings if
> coming from the router/gateway address. Is that right? If so, which
> password is that?

I tried to explain this before... If you have a password set, then
you're all fine. If you haven't, then you won't be able to access the
settings from the outside. LMS won't ask for a password unless you've
set it yourself.

--

Michael

I managed to get my remote access working again (a while since I had used it and some bits and bobs have changed). Using SSH (port 22) and public key. With Squeeze Commander I could still change the audio settings of players, even though I have no CLI password set. Is this what you would expect?

Setting a password would be problematic for some of my plugins, like the UPnP bridge.

[Paul Webster]

I managed to get my remote access working again (a while since I had used it and some bits and bobs have changed). Using SSH (port 22) and public key. With Squeeze Commander I could still change the audio settings of players, even though I have no CLI password set. Is this what you would expect?

What does your LMS system see as your IP address when you connect in via that route?
I don't remember if LMS logs it ... but you could SSH to the LMS server and type
set | grep -i ssh
on a pCP server (and I suspect other Linux platforms) you will see the IP address of this SSH session.

[PasTim]

What does your LMS system see as your IP address when you connect in via that route?
I don't remember if LMS logs it ... but you could SSH to the LMS server and type
set | grep -i ssh
on a pCP server (and I suspect other Linux platforms) you will see the IP address of this SSH session.

It's an external IP address that I don't recognise - it isn't an internal one, nor the external IP address of my router/gateway.

I have tried looking at the standard web page in the mobile browser, and can still see all the settings and have changed one or two advanced plugin settings.

I'm running Logitech Media Server Version: 7.9.1 - 1515659378 @ Thu Jan 11 09:26:58 UTC 2018

[Paul Webster]

I'm running Logitech Media Server Version: 7.9.1 - 1515659378 @ Thu Jan 11 09:26:58 UTC 2018

I noticed the changes in the secureSettings branch in github.
I don't think it is in the daily build yet.

[PasTim]

I noticed the changes in the secureSettings branch in github.
I don't think it is in the daily build yet.

I see. I think I misunderstood 'stable release' to mean beyond the 9.1 beta daily updates, rather than just in github.

[JJZolx]

> As I understand it from some of the previous discussion, something has
> been added to a recent LMS to require a password to change settings if
> coming from the router/gateway address. Is that right? If so, which
> password is that?

I tried to explain this before... If you have a password set, then
you're all fine. If you haven't, then you won't be able to access the
settings from the outside. LMS won't ask for a password unless you've
set it yourself.

How do you determine that the connection is coming from "outside"? If someone is doing port forwarding in order to make the LMS server available to the internet, wouldn't the connection appear to come from the router on the same subnet?

[drmatt]

How do you determine that the connection is coming from "outside"? If someone is doing port forwarding in order to make the LMS server available to the internet, wouldn't the connection appear to come from the router on the same subnet?

I think you answered your own question, read back up the thread.


Transcoded from Matt's brain by Tapatalk