Your Digital Media Has Never Looked So Good

 
mas
Topic Author
Posts: 281
Joined: Tue Dec 05, 2006 11:46 am

Access to remote media lib

Thu Dec 21, 2006 5:52 am

Just a hint for all those who wanna access their multimedia libs remotely:

Using the fireflymediaserver there is no limitation as in iTunes. It will serve remote hosts without any preconditions. So the only thing is one needs to get the client to discover the remote server via Bonjour.

That can be done by running RendezvousProxy, which is part of a the iLeech package on sourceforge:

http://ileech.sourceforge.net/index.php ... y-Download

Its a small java program where you need to put in the IP or DNS of the remote side and choose that its a DAAP service and then even iTunes will play from this remote host without complaints.

With fireflymediaserver there is no need to run tunnels or VPN any more therefore.

What I still have to find out is if this also works with the rokus now in the same way.
Those who sacrifice freedom over safety deserve neither.
 
mas
Topic Author
Posts: 281
Joined: Tue Dec 05, 2006 11:46 am

Sun Dec 24, 2006 2:21 pm

Found the time to test it. Took a while due to christmas and some adaptations needed.

I got it to work. Steps to reproduce

1. Start the RendezvousProxy on any PC in the local network
2. Go to settings and add a new protocol: "_rsp._tcp." (exactly the part between the "")
3. Add the IP and port of your remote mediaserver under that service
4. If you have a firewall or NAT router on the remote side then a port forward has to be properly set there.
5. reboot the roku

Then it will quite seamlessly play also the remote library, proving that it's really only the discovery thats missing in the rokus.

There are 2 gotchas to observe that Roku hopefully fixes at some point:

1. Password protected shares accepted only if you dont connect to em while they have no password. If you do and then enable the password you need to totally unpower or factory reset your roku as it saves the empty password and then tries to use it, not recognizing that now a password is set. That is a bug and I submitted it as such. Workaround: Unpower/factory-reset then reconnect.

2. No way to enable the roku to discover the server without the RendezvousProxy. Please add a way. Could be as simple as allowing a rsp://mediaserver.dns:3689 in the presets. Right now you need to run some sort of computer to enable the discovery. And unfortunately the roku looses contact once the Proxy is shut down.
Last edited by mas on Tue Dec 26, 2006 4:34 pm, edited 1 time in total.
Those who sacrifice freedom over safety deserve neither.
 
mas
Topic Author
Posts: 281
Joined: Tue Dec 05, 2006 11:46 am

Tue Dec 26, 2006 9:43 am

Ron Pedde pointed out that the firefly server didnt have its security scrutinized yet so this sharing solution may contain bugs enabling unauthorized access to the mediaserver.

So dont use it when you cant live with it...
Those who sacrifice freedom over safety deserve neither.
 
mraneri
Posts: 282
Joined: Tue Nov 30, 2004 1:17 pm

Tue Dec 26, 2006 12:02 pm

mas wrote:
Ron Pedde pointed out that the firefly server didnt have its security scrutinized yet so this sharing solution may contain bugs enabling unauthorized access to the mediaserver.

So dont use it when you cant live with it...

To further clarify/restate the above... Firefly was designed to be run only on a local network. If you choose to expose it to the internet by using RendezvousProxy, then you are potentially taking a security risk.. (At your own risk...)

This is a really cool idea, but make sure you know what you're potentially getting yourself into before going this route...

Thanks mas, for bringing this point up.
 
mas
Topic Author
Posts: 281
Joined: Tue Dec 05, 2006 11:46 am

Tue Dec 26, 2006 2:53 pm

Hehe the further clarification contains an misunderstanding which could possibly make things rather unclear.

You dont expose anything with RendezvouzProxy. The name RendezvouzProxy is probably a bit misleading. It is not really a proxy. It is a Bonjour fake anouncer.

To really clarify it now:

(Mediaserver) --> router --> internet --> router --> roku <-> local Comp: RenezvouProxy
--------------------|-???????-|-----------------|-?????-|------------------------------------
REMOTE side-------port-fw-----internet-------NAT?--------LOCAL side with the RendezvousProxy

By running firefly you already run a service that is potentially worldwide accessible! Firefly implements no limitation! So intended to be run only on local networks means nothing. It depends on your actual network configuration.
Whether it is exposed depends on whether you run a FIREWALL somewhere which blocks it. Unless you run XP2s internal firewall or an external router with a firewall it will be world wide exposed once you are online.

Only with a firewall you expose it deliberately by opening up a port resp. putting in a port forward. But the situation then is in no way different to a user running XP SP1 or SP2 with disabled firewall and connected directly to the internet via dialup or a dumb DSL modem.

The RendezvousProxy also doesnt worsen the situation as the announce packets are indeed purely local. So you shout it out only on the subnet your on. This so called proxy runs on the local side and only helps the roku to SEE the service, aka discover it!

TAKE HOME MESSAGE: If you use such a remote streaming solution, use a password and keep in mind that this usage isnt explicitly tested for security. That is what Ron pointed out and what I wanted to inform you about in my update post.
Last edited by mas on Tue Dec 26, 2006 3:05 pm, edited 2 times in total.
Those who sacrifice freedom over safety deserve neither.
 
mraneri
Posts: 282
Joined: Tue Nov 30, 2004 1:17 pm

Tue Dec 26, 2006 2:58 pm

mas wrote:
You dont expose anything with RendezvouzProxy.

So where's the new vulnerability? Or is firefly vulnerable on any system without a NAT/firewall router.
 
mas
Topic Author
Posts: 281
Joined: Tue Dec 05, 2006 11:46 am

Tue Dec 26, 2006 3:13 pm

We dont know of any vulnerability. If we knew one then Ron would have fixed it already I guess.

And yes, precisely. Firefly COULD be vulnerable on any computer without a firewall. Thats what its about.

Ron has never carefully looked into the security of the thing vs outside access, so he feels he dont wants to give it a blind tumb up. This has simply not been developed with security in the mind so this disclaimer / warning had to be given.

And the same warning applies if you run firefly without RendezvousProxy and without a firewall. Its not the RendezvousProxy that is the danger, but running a non-supertough-tested service like firefly on machine that isnt isolated from the internet proper. And whether you run no firewall and go online or run a firewall and open a port is really no different for anyone potentially trying to attack this service...
Those who sacrifice freedom over safety deserve neither.
 
rpedde
Posts: 1015
Joined: Fri Sep 10, 2004 6:25 pm

Tue Dec 26, 2006 9:42 pm

mas wrote:
Ron has never carefully looked into the security of the thing vs outside access, so he feels he dont wants to give it a blind tumb up. This has simply not been developed with security in the mind so this disclaimer / warning had to be given.


That's not to say that it's a security nightmare either -- it tries to use least privs (except on windows, obviously), and there are no obvious buffer overflows, but some of the query code is complex and I haven't done the kind of line-by-line audits you would expect for a publicly accessible internet server. Something like apache or vsftp gets much more scrutiny than does this.

Just use the same precautions you would from any other internet server... particularly one that isn't part of the openbsd base. Run it in a chroot if you can, and use least privs. Use the tightest firewall settings you can get away with, run it on a dmz, or at least don't run it on the same machine you keep sensitive or critical information on.

Just common sense, really. Also, don't forget the NO WARRANTY clause. :)

-- Ron
 
mraneri
Posts: 282
Joined: Tue Nov 30, 2004 1:17 pm

Wed Dec 27, 2006 9:05 am

Thanks for the clarification.
 
mas
Topic Author
Posts: 281
Joined: Tue Dec 05, 2006 11:46 am

Sun Aug 10, 2008 4:31 am

A few follow up hints:

I am using this remote solution now since quite a while. The server is running >1 year. Break in attempts in the log files are rare (they prefer attacking ssh service to gain more bots for spammail it seems - noone cares about music hehe) and to back-up the slightly weak security of mt-daapd (no retry counters and such) I use fail2ban on the server to block every IP that causes 4 or more failed login attempts in the logfiles.

The fail2ban also watches hack attamepts at my ssh daemon as indicated and this one gets plenty. Every day some idiot tries and gets blackholed.

That beeing said it seems that mt-daapd is reasonably safe to run remote open provided you use good passwords and something like fail2ban to break down brute force attempts. After all theres simimply not enough mt-daapd servers so noone except the rare fool targets them. It's the common and broader useful services like ssh who get the steam.
Those who sacrifice freedom over safety deserve neither.

Who is online

Users browsing this forum: No registered users and 1 guest