Jump to content

Recording Service and getting attacked


Lars Bartel

Recommended Posts

Anyone else having problems with RS and being attacked?

 

I am using the standard ports for RS opened to the internet; I got an Administrator user and a Guest user with password.

The last 5-6 hours I noticed that a lot of new ip was using RS (using transcoding), so I changed the password for both users, but that did not help.

 

One of the ip was this one x1-6-00-18-39-29-84-fd.cpe.webspeed.dk, so for fun I just tried to post it in my browser http://x1-6-00-18-39-29-84-fd.cpe.webspeed.dk/ - It pointed to something called TV Webserver.

 

Just changed all ports on RS and the problem disappeared.

  • Like 1
Link to comment

if they download playlist they don't need user/pass anymore so changing them does nothing... also changing the port does mostly nothing as long as they have the playlist they can edit the port in it until they get it and can watch again...

theres no really good way to secure RS I think...

 

my solution was easy... I just made a vpn server... and if I need to access it from the internet I connect the vpn

Link to comment

Only the Web interface port has a password protection.

 

As thor2002ro has written, everyone how knows you IP and the port (and how the RS url is build) can assess the streams.

I would recommend a VPN server in you LAN as well. Don't open ports to the internet.

 

The RS is security wise not designed for assess from the internet. It is only design for a LAN wher you have the control.

  • Like 1
Link to comment

I have solved this with a reverse proxy. Now anyone outside needs to know the actual hostname like http://mytv.mydomain.net

This is then rewritten with a rewrite rule to my internal IP http://192.168.1.1:8089

So anybody trying his luck to access my recording service via IP address has no access. Reverse lookup also does not reveal the hostname.

Of course port 8089 is not open on my firewall, that is not needed. Everything goes through the reverse proxy on port 80.

Edited by esackbauer
Link to comment

@esackbauer,

 

sounds interesting, especially that there is no more open port (8089).

 

How exactly and where is that to be changed? Router?

 

LG

 

Goggo

Edited by Goggo16
Link to comment

The basic steps are:

  • register a domain name like "dvb.mydomain.net" with your DNS provider (if you dont have one get something off e.g. http://freedns.afraid.org/ that supports dynamic and static IP addresses)
  • Configure your router to update that DNS hostname if you are on a dynamic IP
  • install a reverse proxy. The simplest thing is if you have already a linux installation somewhere so you could use nginx or apache2 with mod_rewrite. Google for instructions on that.
    For Windows you can use IIS with an additional module ARR: http://www.microsoft.com/en-us/download/details.aspx?id=39715
    Maybe your router can do this as well (e.g. if you are on OpenWrt or DD-WRT)
  • Configure a rewrite rule: Enter condition for host header value, so that the rule only accepts the hostname "dvb.mydomain.net", Rewrite it to e.g. http://192.168.1.2:8089/{R:1}
    The appendix {R:1} would pass all parameters and so on to your Recording Service
  • Configure firewall rule on router to forward port 80 to your reverse proxy IP. If the reverse proxy is on your router, just open port 80.

Its not a trivial thing as you can see. Having some knowledge on DNS, web servers and URL rewriting helps.

 

Easier it is to just change ports or use VPN.

But e.g. when I sit in the office, the company would not allow outgoing ports other than 80 and 443 via web proxy. With the reverse proxy that is no problem anymore.

Also I am running several other web services behind the proxy like Owncloud, Friendica etc. So I can do that over the ports 80 and 443 with just one external IP address, using different DNS names for each service.

Edited by esackbauer
Link to comment

Not without major hassle. "Direct streaming" is actually a M3U file that contains URLs like this when downloaded via reverse proxy:
http://localhost:7522/upnp/channelstream/37.ts

Recording service is not aware of its "external" dns name and puts "localhost" instead. And as the URL is in a file, you cannot process it with a reverse proxy. (well it can be done somehow, but on the next level of webserver knowledge)

It would be of great help if Recording Service would have a configuration option to build the m3u files with the external DNS name.

 

You would need to edit the m3u file and change this string to:

http://dvb.mydomain.net/upnp/channelstream/37.ts
As the direct stream runs on a different port than 8089, a second rewrite rule is needed:

Configure a rewrite rule: Enter condition for host header value, so that the rule only accepts the hostname "dvb.mydomain.net" AND URL starts with "/upnp/. Rewrite it to e.g. http://192.168.1.2:7522/upnp/{R:1}
The appendix {R:1} would pass all parameters and so on to your Recording Service

Edited by esackbauer
Link to comment

By simply passing the data though a reverse proxy get you no protection.

Everybody how knows the URL will be able to play the stream without any password.

 

You need to add basic authentication or something of this kind in the reverse proxy configuration.

Link to comment

@esackbauerm,

 

thanks for the comprehensive explanation.

 

Does not sound straight forward. Usually, I also want to stay away from implementing such security things into any of the client PCs (IIS, etc). Would prefer to do it into the router (Fritzbox with Linux), so that all client systems benefit from it.

 

Will have a look into it and need to understand this mechanism better, Then perhaps a new Fritzbox-Firmware compiled with Freetz will give me the option of a "reverse proxy".

 

It would be of great help if Recording Service would have a configuration option to build the m3u files with the external DNS name.

 

 

This does work for me with my active DynDNS. If I access the RS-Webpage with the DynDNS-address, the downloaded m3u-file does have the external DynDNS-addresses instead of the "192.168....".

 

LG

 

Goggo

Link to comment

By simply passing the data though a reverse proxy get you no protection.

Everybody how knows the URL will be able to play the stream without any password.

 

You need to add basic authentication or something of this kind in the reverse proxy configuration.

 

Tjod, you must know the correct DNS name of that service to access it. If you do not publish it into public, noone will have access to Recording Service from outside (or must make brute force attack with alternating DNS names).

 

"Simply passing through" is indeed not enough, this is why you need a condition for the rewrite rule on the host header value of that DNS name.

 

Of course additional authentication, authentication passthrough or even https to http rewrite are more advanced topics.

Edited by esackbauer
Link to comment

This does work for me with my active DynDNS. If I access the RS-Webpage with the DynDNS-address, the downloaded m3u-file does have the external DynDNS-addresses instead of the "192.168....".

 

That is true if you are port forwarding directly to Recording Service. However if you use a reverse proxy, you will get "localhost".

Link to comment
×
×
  • Create New...