[GH-ISSUE #470] The service can be contacted from remote hosts (Linux) #424

New issue

Closed

opened 2026-02-26 00:32:36 +03:00 by kerem · 2 comments

kerem commented

2026-02-26 00:32:36 +03:00

Owner

Originally created by @jonremy on GitHub (Apr 17, 2018).
Original GitHub issue: https://github.com/hirschmann/nbfc/issues/470

The service is listening on all interfaces (0.0.0.0:8523 in netstat -plnet) and thus can potentially be contacted from remote hosts.
Also it may be beneficial if the service was accessible by the root user only.

Potential cause

It seems that localhost in WCF addresses cause the service to listen on all interfaces, as described here.

Partial Fix

By changing the address to 127.0.0.1, the service only listen on the loopback interface (in IPv6 for some reason). As I don't know .NET, I'm unsure this is the best change to do.
Additionally the service is still accessible by any user on the host.

System

Mono version: 5.10.1.20
Fedora 27 with kernel 4.15.6-300.fc27.x86_64

Originally created by @jonremy on GitHub (Apr 17, 2018). Original GitHub issue: https://github.com/hirschmann/nbfc/issues/470 The service is listening on all interfaces (`0.0.0.0:8523` in `netstat -plnet`) and thus can potentially be contacted from remote hosts. Also it may be beneficial if the service was accessible by the root user only. ## Potential cause It seems that `localhost` in WCF addresses cause the service to listen on all interfaces, as described [here](https://bugzilla.xamarin.com/show_bug.cgi?id=275). ## Partial Fix By [changing the address to 127.0.0.1](https://github.com/jonremy/nbfc/commit/1689c35ccb37395d612c4ba8e138da287a1abeca), the service only listen on the loopback interface (in IPv6 for some reason). As I don't know .NET, I'm unsure this is the best change to do. Additionally the service is still accessible by any user on the host. ## System * Mono version: `5.10.1.20` * Fedora 27 with kernel `4.15.6-300.fc27.x86_64`

kerem

2026-02-26 00:32:36 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-26 00:32:37 +03:00

Author

Owner

@hirschmann commented on GitHub (Apr 17, 2018):

Thank you for the bug report. I think your fix is a good solution to this problem.

The service is accessible to all users with intent. After all the goal of this project is to make it as easy as possible for the users to control their notebook's fans.

I know there might be scenarios where this is a problem. In such cases, you could deny the access via iptables:

iptables -I OUTPUT -p tcp --dport 8523 -j REJECT
iptables -I OUTPUT -p tcp --dport 8523 -m owner --uid-owner root -j ACCEPT

@hirschmann commented on GitHub (Apr 17, 2018): Thank you for the bug report. I think your fix is a good solution to this problem. The service is accessible to all users with intent. After all the goal of this project is to make it as easy as possible for the users to control their notebook's fans. I know there might be scenarios where this is a problem. In such cases, you could deny the access via iptables: ``` iptables -I OUTPUT -p tcp --dport 8523 -j REJECT iptables -I OUTPUT -p tcp --dport 8523 -m owner --uid-owner root -j ACCEPT ```

kerem commented

2026-02-26 00:32:37 +03:00

Author

Owner

@jonremy commented on GitHub (Apr 17, 2018):

All good. Thank you for this project and maintaining it !

@jonremy commented on GitHub (Apr 17, 2018): All good. Thank you for this project and maintaining it !