Suspicious Outbound Requests from Channels DVR – Need Clarification

Channels DVR Server
#1

Mod Edit

These connections were inbound, NOT outbound.

This is nothing more than simple probing from external computer on an open port. This is normal for the Internet. Authentication from Channels DVR Server stops any of this probing and keep it safe.

- Mods

Hi everyone,

I’ve been noticing some unexpected outbound connection attempts from my Channels DVR instance, and I’m hoping someone can help clarify whether this is expected behavior or something I should be concerned about.

What I’m Seeing

Checking my logs, I found several 403 Forbidden responses for outbound HTTP GET and CONNECT requests to various IP addresses. Here are a few examples:

2025/02/12 23:13:33.731154 [HTTP] | 403 |   10.329514ms | 162.216.149.117 | GET      "/"
2025/02/13 03:03:38.248828 [HTTP] | 403 |   11.738522ms |   194.48.251.26 | CONNECT  ""
2025/02/13 03:03:38.467554 [HTTP] | 403 |    3.116849ms |   194.48.251.26 | CONNECT  ""
2025/02/13 05:41:20.594449 [HTTP] | 403 |    7.218779ms |   204.93.227.26 | GET      "/_security/public-proxy-check"

What I’ve Investigated So Far

• The IPs:

• 194.48.251.26 resolves to a hosting provider called “Cheapy.Host” in Bulgaria, which doesn’t seem related to Channels DVR.

• 204.93.227.26 appears to be associated with a datacenter (DEFT.COM) and seems to be related to proxy detection.

• 162.216.149.117 is unclear but could be another datacenter.

• The logs indicate that Channels DVR is attempting these outbound requests, but they are being blocked with 403 Forbidden responses. by my IPS system

• My instance is running on Unraid and is fully updated.

My Questions

  1. Are these outbound requests expected behavior?

  2. What would trigger Channels DVR to attempt a CONNECT request to 194.48.251.26?

  3. Is the /security/public-proxy-check request a normal feature, and can it be disabled?

  4. Has anyone else seen similar requests in their logs?

I want to make sure this is intended behavior and not something unexpected. Any insights from the community or the Channels DVR team would be greatly appreciated. Thanks in advance!

1 Like
#2

While I might be wrong, it looks like your channels server has been compromised.

Do you expose it to the Internet for remote viewing? If yes I recommend uninstalling and reinstalling.

If the answer is yes, then the community would be advised to avoid using this method and instead use a VPN such as the built in Tailscale.

Please let us know what you discover.

I also wonder if the developers do any sort of penetration testing.

1 Like
#3

These are not outbound??

And they're 403s so they were rejected

If you're concerned use Tailscale

1 Like
#4

Not sure if you're asking me or telling me that these are not outbound?

From everything I can tell in the IPS logs, they are indeed originating from the Channels docker. They are 403's because my IPS is blocking the requests.

#5

You are mistaken

3 Likes
#6

These look like inbound requests that are denied. Like @tmm1 said if you are concerned turn off remote access and use tailscale. Nothing abnormal about probing... part of life on the internet

2 Likes
#7

Yeah, I think you're correct now that I look at these logs in the greater context after some playing around Still baffeled why my IPS (Unifi) thinks they are outbound.

image
image2006×730 272 KB

image
image1218×452 73.5 KB

I have gone ahead and disabled remote access on the server. As I stated, something wasn't adding up and figured it was better to ask than ignore.

Thanks for the feedback!

1 Like
#8

I used to see these in my unifi logs when I was port forwarding my server. It was very strange because upgrading to a different pre-released seemed to stop it.

They freaked me out a little bit as well.

That said, looking at it more, it seems to be its logged as an outbound connection because Channels wants to send a 403 Forbidden response which could provide details to an attacker on the type of service that is running on the machine. The IDS/IPS definition provider for Unifi simply has a rule in place to say if it is a 403 forbidden response, do not display any additional information for the attacker to try and exploit and then it is logging for your awareness.

Probably harmless, but might be worth using tailscale if you are able.

2 Likes
#9

The last time I opened my server it correctly blocked inbound attempts and logged them as inbound. By any chance have you changed to using the zone based firewall? Are you blocking via a firewall rule or using the IPS (Protection tab)? I block with the IPS

1 Like
#10

Oh I have inbound ones on my plex server all the time. But those are matching on a different IPS/IDS rule. Generally, Scan or RDP attempt. There is something about the way this request comes in and Channels drops the request that matches Suricata's Outbound 403 rule.

Actually the source code for all the rules are available at suricata-rules/emerging-web_server.rules at main · vncloudsco/suricata-rules · GitHub

If you search for GPL WEB_SERVER 403, it does show it is originating from the direction of the server.

1 Like
#11