If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I'm not sure whether I'm an 'average joe' or not. However, having spent a working lifetime in IT (albeit nothing much to do with security) I suspect not quite (judging by most of my friends). Nonetheless I have found it pretty hard to work out how to do stuff like use ssh, ddns (my IP address changes most nights), open selected ports in the router and so on to make it all work with some semblance of security. I have a public key exchange set up between my mobile and laptop (using ssh) and my music server, and don't allow password access. Being retired I have time to work such things through when I know they must be possible, even when I can't quite get them to work for quite a while

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 have LMS from yesterday installed.

>
> Interested to see how the code can distinguish an external request from
> internal though.[/color]

It's not very sophisticated, and not even fully correct: when a request is coming from the network's default gateway, I'm assuming it's coming from the outside. I know that this is a rather simplistic approach. But I thought I'd push it out this way and see whether people run into issues :-). If they do, then at least they can double check their network configuration to make sure they really don't open things up.

And then there's that undocumented pref you can set to disable the check in such an exceptional case.

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.

IMPORTANT: Stop forwarding your LMS ports to theinternet!

> 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.

IMPORTANT: Stop forwarding your LMS ports to theinternet!

> 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?...

>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.

> 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.

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.

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.