Having set up Rockstor to serve media through Jellyfin, access from the WAN was tricky but finaly managed through DHCP settings on the Virgin Hub 4 Router. During the setting up process several pings were made in an attempt to test connectivity with DuckDNS and DNSchecker.
An email has been received from Virgin Media stating:
"A device connected to your home network has been identified as having a potential Portmapper vulnerability.
A Portmapper vulnerability is a security issue whereby a 3rd party can use this protocol to gain unauthorised access to your network/devices for malicious purposes. If a 3rd party has access to your network/devices they will be able to perform a Distributed Denial of Service (DDoS) attack."
I am assuming that this was because of the probing carried out during the connectivity investigaton.
However
The Question of firewalls and security has arisen as port 111 has been found to be open.
Do any rockons needport 111?
Does the Rockstor V4 have a firewall or alternative security?
Anybody help on this please?
As a security measure, the NAS has been powered down for the time being whilst this question is pending.
@Mike-B Hello again.
Re:
This is an issue for some internet providers. They would often rather you run nothing at all really.
But re;
No as it is an intentional user step to expose the Rockstor server/services to the internet. Upon doing this one opens up such possibilities across the entirety of the Rockstor base OS (see firewalld later) and all subsequent Rock-ons.
A better way to expose the server is by select ports only. By the looks of it you may have put the Rockstor system in it’s entirety into say a DMZ (De-Militarised Zone) where all ports are exposed. Not ideal as you are by-passing your routers firewall.
firewald
A systemd service is disabled by default in Rockstor, this is to allow it’s base function of serving stuff. And we only turn on/install, and users only intentionally turn on/install, services that are required to be available outside of the machine itself. This is a move that was, at one time, seconded by the openSUSE security team. See:
https://github.com/rockstor/rockstor-core/issues/2024
But there was push-back and it was reverted in openSUSE.
So in short you have inadvertently, likely, installed a service that your likely domestic internet provider is a little nervous about and feels inclined to inform you about. Domestic internet connections are limited/touchy about services running and will likely simply block them entirely; bar the basics.
And given you have, or we have, inadvertently opened port 111 to your internet via likely DMZ use rather than individial port forwarding you have this itchy response form your internet provider.
From a file on your system which stores the regular use of port numbers in tcp/ip we have:
grep " 111/" /etc/services
sunrpc 111/tcp rpcbind # SUN Remote Procedure Call [Chuck_McManis]
sunrpc 111/udp rpcbind # SUN Remote Procedure Call [Chuck_McManis]
Further searching should help with identifying the cause of this port being open but note that it most likely is not required to be open to-the-internet and that’s the num here. Only put Rockstor in it’s entirety on the internet directly if you are fully aware of such things. Best to port forward only the stuff you need to forward and that is most likey on a select set of ports. The build in firewall only sees the lan connection and it’s use or otherwise. The main, but not only issue, is that you likely have a missconfigured existing firewall, your router. And as we only configure ipv4 via the Web-UI, which is not routable (read visible) on the internet unless configured to be so via external firewall permissiveness (read non default router configuration) we have the main issue at hand. Router config exposing likely more that you or at least your internet provider intended/wanted.
Hope that helps and there are many here on the forum way more up on this than myself so hopefully we will get further input in that regard. Our base system is that of a JeOS (Just enough Operating System) and the user then turns on/installs what they want to be available. Making those ports/services then accessible on the internet is anther user step that we can’t actually control. But we could have a doc section on this. But it would be the same for any other computer system that is routed through your house/business firewall to the internet.
Thanks @phillxnet
A set of networking docs would be very usefull especially for users of os such as windows (me 
) where most of these aspects are handled in the background leaving the user non the wiser.
I’ve not replied sooner as an in depth review if my understanding of the network situation has been underway and a change of isp has been instigated for one where a static ip can be obtained with little hastle.
I will get back to the forum when the new static isp has been set up and the new router in place.
New year regards to all. Mike
@Mike-B Hello again.
Agreed. Specifically a section on remove access I think in the context of this thread. Re port forward advice rather than DMZ (De-Militarized Zone) advice and the like. Incidentally the port you mentioned is often associated with the NFS service which is off by default. Again when taking the open only what’s needed, which is what we default to, and docs to advising only forwarding ports that are required outside the LAN would help folks get off on the right foot. Tricky thought as in some instances some services, such as torrent servers, don’t tend to work unless they are in a DMZ as they open a tone of randomly numbered ports. A work around in this case can sometimes be to specify a range that is port forwarded. Not ideal to go the uPNP route at the router and this is best disabled anyway I think. Thought many domestic routers have it enabled by default. This is a service where any internal service can ask, and receive, an incoming port forward!!! Just by asking. Makes stuff work - and a hole lot more. Much like many other ‘security’ features. The easier it gets the less secure/controlled it ends up actually being.
Anyway, thanks for the feedback and maybe in time we can get another proof read from you as per our client samba access docs recently. All helps and bit by bit.
So, static public IP on the way: aren’t you fancy. Take care to not publish it on public forums.
Cheers.