OBS Studio plugin uses SSDP on multicast - Receiver blocks reception of traffic

Comodo Internet Security - CIS Firewall Help - CIS
1

Hello.

I’m a longtime user of Comodo products and I have a bit of an issue here.

I use a plugin for OBS Studio called Teleport which allows me to send the composted output of my OBS Studio setup on a “studio PC” to another computer for encoding and sending to someplace like Twitch or YouTube.

However, in order for the receiver to find any transmitters, it listens to multicast IP 239.255.255.250. On the sender side, I can confirm sending of these packets with no issue, though it only sends on the IPv4 address as opposed to the IPv6 address of ff02::c.

The receiver sees absolutely nothing.

As an example of what I’m trying to do, I add both IPs (IPv4 239.255.255.250 and IPv6 ff02::c) to a network zone, which I’ll call “SSDP”. I then add a rule to the application C:\Program Files\obs-studio\bin\64bit\obs64.exe to allow UDP traffic to flow in and out with the source IP being the network zone of my network segment and the destination of the network zone “SSDP” as I had defined above. I do this on both sides as the setup could send or receive this traffic.

The sender side works. The receiver does not.

I even checked the checkbox to log when the rule is triggered. The sender has plenty of entries. The receiver has nothing.

Ultimately, the only solution was to uninstall Comodo Internet Security on the receiver. CIS can stay on the sender.

Once CIS is removed from the receiver, I can then look for transmitters and select which sources to pull from the remote host. That is because there is nothing to block the multicast traffic I need to use in order to find a source to bring into that machine.

Help?

–Katt. =^.^=

2

Hi KattPhloxworthy,

Thank you for reporting, may i know your:

  1. CIS/CFW version on both device ?
  2. Win version along with system bit type on both device?
  3. Any other security software installed on your machine other than CIS/CFW ?
  4. Any related screenshot ?

Thanks
C.O.M.O.D.O RT

3

I am collecting screenshots, plus I have to reinstall CISPremium on the Encoder machine so I can generate error messages, so screenies will be posted on a separate post.

I’ll answer the others here:

They all apply to both machines unless otherwise noted.

  1. CIS version: 12.2.2.8012
  2. Win version: Windows 10 Pro 64-bit release 21H1, build build 19043
  3. Other security software: Other than what was bundled with Windows (which is disabled), no additional security software is installed.
  4. Screenshots are forthcoming.

I will be furnishing screenies soon, so please stand by.

4

Hi KattPhloxworthy,

Thank you for providing the information.

I will be furnishing screenies soon, so please stand by.
ok.

Thanks
C.O.M.O.D.O RT

5

I have to get ready for a stream, so I had to uninstall CIS Premium so I can have a working Teleport setup. I may do it later today as I need to collate all the screenies from both machines.

For the record, there are no errors because the machine that is receiving the traffic from the “studio PC” which is sending traffic is not even seeing the traffic so the stream can connect. I’ll have screenies for that soon; it may be later because it’s super early here in California and I haven’t had any sleep yet.

–Katt. =^.^=

6

Attached are several images with descriptive filenames of what they depict.

I am not attaching anything from the destination apart from what I am supposed to see yet what I see with Comodo. There is, quite literally, nothing to show that the system is even processing those packets that I can tell, even if I SPECIFICALLY mark it as traffic to “allow”.

Even when I put an allow rule for the 239.255.255.250 and ff02::c destinations from IPs on my local network, nothing shows up in the logs. I’m completely convinced that, because it’s not considered “local” traffic because the destination is something that “looks external” despite being a MULTICAST IP address with a local IP originating it. I tried adding it as an application rule, and I tried adding it as a system rule. It does not work.

Supporting documentation for what I’m talking about:

RFC 5771 describing Multicast in general. section on 239.0.0.0/8

RFC 2365, very specifically about the multicast block 239.0.0.0/8:

I understand that there are SSDP reflective attacks, but these should originate and be handled locally, which the system seems apt to handle, but is fully unable to. Comodo’s firewall appears to consider 239.0.0.0/8 as external, despite the fact it should be local in origin and interpreted in destination.

If multicast support isn’t in Comodo, I can’t use Teleport, therefore I can’t use Comodo. About the only thing I can do is convince the author to optionally use unicast broadcasts.

If you need anything further, please let me know.

–Kat… =^.^=

7

perhaps a question without interest: would you have a global rule managing UDP & Port 1900?

8

You need to allow it through global rules for incoming connections, so create an allow global rule and set the source address to any and destination address to the multicast address.

9

It’s not that simple. Far from it, in fact. It has to do with the destination “IP address”, 239.255.255.250. That is a called a multicast IP address. That is not a simple IP address that gets addressed like any other. It’s a very specialized address.

There are two different types of broadcasts, unicast, which takes the uppermost IP address of the netblock you’re using, then sending UDP traffic to it. Furthermore, we are talking about IPv4, or 32-bit IP addresses. In the case of my subnet, which is 512 IP addresses, homed at 192.168.0.0/23 (or "192.168.0.0 netmask 255.255.254.0), the uppermost address that is called the “broadcast address” is 192.168.1.255. For example, NetBIOS uses UDP port 137 via the unicast broadcast to locate hosts on the subnet. Other ports have other purposes, but there are only 65536 ports.

Multicast, on the other hand use VERY SPECIFIC IP ADDRESSES for specific purposes. Software that uses multicast have to listen for traffic directed to these “IP addresses”. In my case, the address in question, 239.255.255.250, is for SSDP, or Simple Service Discovery Protocol. Basically, going a bit lower, specifically to the IP layer, instead of having to figure out which IP address is the broadcast address, the plugin in my OBS Studio installs send traffic to the "IP address " 239.255.255.250 on various UDP ports, advertising the names of various streams the program is outputting. If other OBS Studio instances on my network have that plugin installed used as receivers, they have a dialog to ask the user to select which stream to listen to, then connect to it based on the source address, in this case, my main PC at 192.168.0.128. As for the port numbers, I would have to read the source code for the plugin (entirely in Go, so I have to learn Go; I’m more a C/Perl person), which I have at a rather basic level.

Multicast also allows a machine with multiple interfaces to send the same broadcast on all interfaces without having to adapt (other than source IP) for each subnet it talks on.

For more information, I suggest reading RFC 5771 at the Internet Engineering Task Force’s (IETF’s) website. I’ll link it again for your convenience:

https://datatracker.ietf/org/doc/html/rfc5771

For netblock 239.0.0.0/8 (239.0.0.0 netmask 255.0.0.0), near the end of which SSDP finds itself, refer to section 10 of RFC 5771 above, or for more specificity, there’s RFC 2365. I’ll link it as well:

https://datatracker.ietf.org/doc/html/rfc2365

Once you have a basic understanding of multicast, you’ll understand my dilemma. Unless unicast support is written in to this plugin, I cannot use it while I have Comodo Firewall installed, unless there’s a rule I can use to make it work. I can at least track its emission from the source, but I cannot even DETECT it from other computers on my network, especially the one I want to actually use it on if either CIS or CFW is installed. Given what research I’ve done, apparently, there are reflective DDoS attacks using outside, forged packets sent to the target network. SSDP is meant to be used on a local network and should never be used from the outside. This is just like how you block directed unicast UDP broadcasts.

I hope this makes things somewhat clearer.

The rule is something like this:

allow from 192.168.0.0/23 any udp port to 239.255.255.250 any udp port.

So you know, that is NOT a typo. I use a 512-address subnet, hence the 23-bit subnet mask.

On the sender side, that works until the cows come home. I can even log when it happens. In fact, one of the screenies I posted above is that very log, and it’s the ONLY rule I even logged for the sake of this test.

On the receiver side, it -SHOULD- work. The receiver -SHOULD- say to a packet with these source and destination IPs, “allow if it’s from this subnet and it goes to the SSDP multicast address”. Only it doesn’t even go up the stack when that rule is put in. I’ve even told Comodo to log when the rule gets fired. It doesn’t even get that far, likely due to mitigation for the aforementioned SSDP DDoS attack.

–Katt. =^.^=

REVISION: I did say I used it as an application-level rule. I hadn’t tried it fully at the global level. I figured it SHOULD still work, but that makes sense for other applications that use SSDP. It’s just that RFC 1918 IPs have to be blocked at the border (which they are by default, being pfSense having those rules in there from the outset).

10

It doesn’t matter what you have for the application rule if you don’t have a corresponding global allow rule to allow the incoming packets. You need to make an allow incoming rule in the global rules, once you do that then you will see it will work. Refer to the help documentation for the global rules.

11

Nope, it didn’t work. I put the rule in as originating from the network segment I’m doing my streaming on, destination as 239.255.255.250, placed at the global level, this is on the machine that I am receiving the stream from my studio PC and it isn’t working.

At present, the only solution is to uninstall Comodo.

12

I’m sure you’re knowledgeable enough but just in case, please double check that your newly created ALLOW rule is above any other pre-existing rule in the global rules list that could block an unsolicited inbound request.

The global network rules are the first rules tested when receiving an unsolicited inbound request and they are parsed from the top of the list downwards. Any higher placed BLOCK rule would prevent your ALLOW rule ever being tested.

HTH
Ewen :slight_smile:

13

It was, in fact, the very first rule in the global rule list. I made ■■■■■■ sure of it. Still no dice.

The solution still stands at uninstalling Comodo on the receiver end.

–Katt. =^.^=

14

I’m sorry but you obviously didn’t create the rule correctly, in fact you don’t even need to set source and/or destination IP address, you can set both to any and as long as you set the protocol and port number that is needed it will work.

15

Please bear in mind that this is a multicast broadcast, not a unicast one.

Unicast broadcasts do rely on specific ports by way of the subnet’s broadcast IP address in order to work. As an example, in my case, my subnet is 192.168.0.0/23 or 192.168.0.0 netmask 255.255.254.0. A unicast broadcast for NetBIOS name resolution, for example, sends a packet to the address 192.168.1.255, that subnet’s broadcast address, on UDP port 137.

However, SSDP uses multicast, which doesn’t use any specific port, but a specific IP address in the reserved multicast IP space, in this case, that address is 239.255.255.250 for IPv4.

The log I created based on what I saw in the source with logging set when the rule is triggered on the sender shows that the ports are different each time. The destination address is the same each time, a multicast IP address, in this case, That’s why I set it to look for any UDP port on the source and destination addresses.

The main distinguishing characteristic for this protocol is that it relies on specific IP addresses in the multicast address space. In IPv4, it’s 239.255.255.250, which I used as the destination address on the receiving end.

Another characteristic: It never leaves the network. It is considered local.

Here’s an article on the subject of SSDP as well as a bit of information concerning why it may not be working (DDoS mitigation measures in place, but I don’t know whether it’s a case of Comodo being unable to handle multicast traffic or what):

And for multicast in general, please read this Wikipedia article:

I may as well pay for a license and get actual technical support at this rate.

–Katt. =^.^=

16

It doesn’t matter what IP addresses is being used, as long as the rule is set to type any for the address fields for both source and destination address. Again, you’re thinking way to hard about something that is very simple to do, in fact you knowing that its local network traffic is more of a reason to NOT create rules based on IP addresses. See my screenshot of what I mean by setting the address to any for both the source and destination address of the allow rule. Then just set the destination port(s) if you know what it needs, otherwise you can also set the destination ports to any.

17

As a test, how about deleting all Global rules and adding a Global rule that Allows everything In and Out and then create an application rule (also added at the top of the list) with Action Ask, Protocol IP, Direction In, Address Any, Port Any to check if that application would receive the incoming request after answering Allow on the FW Alert pop up?