RTMP & Flash Media Streaming Server Live application

[teh_chicken]

I'm running Flash Media Streaming Server and have only been serving VOD up until now.  I had my network administrator open up port 1935 to the outside world during the setup process and now I can't remember if that was actually required for streaming VOD to clients.  Most documentation I've read says that this port should be open, but I seem to recall reading something at one point that suggested it wasn't necessary.

I've just started messing around with publishing live streams using Flash Media Live Encoder to the Flash Media Streaming Server.  I have that working without issue but was surprised to find that no authentication is required before a client running the live encoder can publish a stream to the Flash Media Streaming Server.  An authentication module is available however it only works with Flash Media Interactive Server and Flash Media Development Server.

If I leave port 1935 open to the outside world, there would be nothing to stop anybody anywhere from streaming video via my server.  Anyone else running a default install of Flash Media Streaming Server and with port 1935 open to the outside should see that this is true of their setup as well.  I'm wondering if I can safely close port 1935 without limiting the functionality of the server or if there's some way I can require authentication prior to publishing a live stream even though I'm not on the four-and-a-half-times-more-expensive edition of the product.

[Asa_-_FMS]

This lack of authentication options on FMSS live is a known issue that we're working on here.  There's not really a great option for this now, minus restricting who can connect to the application in question with IP configuration.  It doesn't work well for this purpose in authentication and it's a known problem that doesn't have a good answer now other than deferring clients toward FMIS that doesn't have this issue until we can resolve it.

Asa

[teh_chicken]

Is there a way to restrict, by IP address, who can publish a stream to the live application without limiting which IP addresses can view said stream?

[Asa_-_FMS]

Not on FMSS - hence the acknowledgement of the problem, it's not really a tenable solution.

[rubens_queiroz]

I have the Flash Media Interactive Server, and I have also installed the authentication module. However, port 1935 is still open to the world, and this is a grat concern of mine. Is there a way around this problem?

Best regards,

Rubens

[teh_chicken]

It's my understanding that if you close port 1935, FMS will fall back to tunneling RTMP over HTTP instead, so blocking port 1935 won't ultimately block the traffic.  Having the port open isn't much of a security risk in and of itself anyhow; the only reason I can think of to close it is to prevent externals from being able to stream to / from your server, which you've already done with the auth module which in turn gives you more flexibility (streaming to / from the server via straight RTMP from outside of your network if you authenticate.)

It's good practice to keep open only those ports which you absolutely need to deliver your services, but you can't deliver services without opening a few ports.  I could compare this to an attempt at making an omelette without breaking any eggs, but I'm too tired to figure out how to phrase the analogy.

teh_chicken

[rubens_queiroz]

That's exactly my concern. As it is, anybody, anywhere, anytime, can send whatever they want to my streaming server. I am migrating from the Real Networks solution, where I could determine who were allowed to broadcast through my server. The auth module is what I want, to create a username and password to those who can use the system. I don't see the point of this module as in practice anybody can stream to the server. For us this is a real issue.

Thank you very much for your attention,

Rubens

[teh_chicken]

I was under the impression that, if you were runing FMIS or FMDS and installed the auth module, that users of Flash Media Live Encoder were required to authenticate before they could stream via your server.  Have you tested this and found it not to be true?

I'm not sure I understand your question anyhow.  In your earlier message you say:

"I have the Flash Media Interactive Server, and I have also installed the authentication module."

yet in your more recent message you say:

"The auth module is what I want, to create a username and password to those who can use the system."

If you want what you already have, you should be fairly satisfied at this point.  Did you find that the auth module does nothing?

[rubens_queiroz]

That's it. I have the auth module installed and streaming is still open to all. What I meant is, what use is the auth module if I cannot restrict who can use the server? As it stands the auth module is useless.

Best regards and thanks again for your help,

Rubens

[teh_chicken]

Wow - that's terrible!  You're absolutely right - what good is the auth module if it imposes no real limits?

[rubens_queiroz]

Yes. Truly amazing.  Unless I am doing something wrong, which I believe I am not.  But this is always a possibility.

Best regards,

Rubens

[Asa_-_FMS]

There's a missing piece of information that we're working on getting into public hands - here's the combination you want to use

FMLE authentcation plugin - this covers the authentication of FMLE based user agents ONLY

SWF Verification with a UserAgentException for FMLE based clients - this covers all other user agents.

We're documenting this more clearly upcoming, because this hasn't been clear to users how to do this and sites are consequently not being secured.  This is why we're going to be publishing a hardening guide, which I'm working on.  For now you're going to want to activate SWFVerification - go to the configuration in Application.xml and allow an exception for FMLE based publishers (the example on how to do so is in the configuration file).

Asa

[rubens_queiroz]

Thank you very much for your help. I'll do as you suggested and report the results here.

Have a nice weekend.

Rubens

[rubens_queiroz]

We did as you suggested but we still weren't successful. Perhaps we have forgotten to do something. In the

"Application.xml" we changed the "SWFVerification enabled" from "false" to "true". But after that, even the users who were authorized to connect were blocked from streaming video from our server, so we had to set this parameter back to false. Have we forgotten to do something?

Thank you all for your attention,

Rubens

[Asa_-_FMS]

You need to include the SWF that your users are connecting with in your SWF Verification folder now.  I recommend checking out this online demo on use of the feature

http://www.adobe.com/devnet/flashmediaserver/articles/fms3_demos_print.html

or there's a few other breakdowns I found when googling FMS SWF Verification that demonstrate how to approve a SWF.

Asa

[Angelos_1]

Hello,

I'm running Flash Media Streaming server and we are publishing live video through "Adobe media live encoder". I tried installing the "FMLE authentcation plugin" on the server but it doesn't seem to work, the Live encoder still does not ask for credentials. From what I can see on https://www.adobe.com/cfusion/entitlement/index.cfm?e=fmle3 The authentication plugin is not supposed to work on streaming server.

I'm now sure how the SWFVerification should be configured in this case, can you please help?

Thanks!

Angelos

[Asa_-_FMS]

Hi Angelos,

Right now there's not a good answer for how you can secure your Live Encoder on FMSS.  That's being remedied soon in an upcoming release of FMS.  For now FMSS isn't capable of using that plugin and the FMLE encoder can't be authenticated.

Asa

[Angelos_1]

Hi Asa,

When you say 'upcoming release' do you mean a new version (which customers need to purchase), or an update that would be free for existing customers?

[Asa_-_FMS]

The intention is the latter - this would be a free update.

[rockhouse_jones]

Hi Asa,

More fuel to this discussion: we, too, are looking forward to increased security measures to prevent unauthorized broadcasters. We have clients delivering RTMP streams to non-SWF players on mobile devices, which renders the allowDomains and SWFverification protections unusable. A secure, encoder-based authorization is the best solution.

What mailing list should I join to receive notification when this update is public?

Andy

[Asa_-_FMS]

Funny you should ask but we're working on the mailing list item too.  Right now you can use the Adobe security mailing in general

http://www.adobe.com/support/security/

That's not FMS specific, but it's the best approach for email based notification right now.  Something more FMS specific to come.

As for the FMS updates, very soon now.

Asa

[Angelos_1]

Hi Asa,

I noticed that Adobe streaming server 4.0 is out, is the issue with the credentials resolved in this release?

Thanks

Angelos

[Guest]

any update about this issue ?

[SE_0208]

Hi HityrPetyr,

If you are talking about support for FMLE Authentication Plug-in on Streaming Server Edition - then its already fixed in 3.5.4. let me know if you had different query altogether.

[teh_chicken]

Unfortunately while the authentication add-in now works on FMSS, there's still a gaping hole.

I've just updated to Flash Media Streaming Server 3.5.5 and installed the authentication add-in.  I added a user account (via conf/users.exe) and then started streaming from FMLE on a Windows box.  I was prompted for credentials - so far so good - and logged in and started streaming successfully.

I then went and tried to do the same, from a Mac, using Wirecast.  I was not prompted for credentials, but was able to stream.  I went through the Broadcast Settings options in Wirecast and changed the User Agent from Wirecast 1.0 to FMLE 3.0, then tried to stream again and was prompted for my credentials.

So from what I can tell, anybody using a third party streaming application (or with the ability to modify FMLE's user-agent string) can bypass authentication altogether.

Currently all that I can do to effectively restrict the ability to stream is to set the <Allow /> tag in conf/_defaultRoot_/_defaultVHost_/Vhost.xml to 'domain.com' and then either add DNS entries (or entries in the hosts file) for each machine that will need to be able to stream so that their FQDN falls somewhere within 'domain.com'.