Jump to content
beverage

Exposed ports / exploitation?

9 posts in this topic Last Reply

Recommended Posts

Sorry for the long explanation.  TLDR at the bottom.

A bit of setup background:  Common dockers (i.e. sonarr, radarr, sabnzbd, ombi, bitwarden, etc.).  A couple weeks ago, I decided to try nginx-proxy-manager to allow external access to ombi, so setup duckdns entries and opened router firewall ports 80 -> towerIP:1880 and 443 -> towerIP:18443 to direct traffic to the NPM docker.  The NPM proxy host was set to block common exploits, force SSL.  Seemed to be working well, but my ISP-provided modem/router was a bit flaky (random restart about once per week) so a tech was scheduled to replace it.

 

Replacement modem/router was put in place (a different brand/model).  Immediately changed the default admin password.  I setup the same port forwarding, and turned on MoCA (used to wire my AP).  External access to ombi working well.  First night with the new modem/router, at exactly midnight, it appeared to restart (AP wifi went down).  When the wifi didn't come back I tried to login to the router.  My configured password didn't work, but the default did (first flag).  Checked the MoCA settings, and it had been disabled (flag two).  My ISP has been known to push their default config, and since I don't use their TiVo devices, they assume MoCA should be off.  Not sure what else they tweak, but definitely not happy about the password and MoCA reset!

 

I checked the port forward settings, and this is where my concern increased.  In addition to the two port forwards I had configured, there were two more:  ports 80 -> towerIP:0 and 443 -> towerIP:0 with external IP restricted to 255.255.255.255.  The two new ones were listed higher than the ones I had configured.  Not sure if that matters but I assume since the same external ports were being forwarded, the first would take priority, although the external IP restriction is an invalid IP address.  I deleted the two "new" ones.  For the heck of it, I tried to recreate them but was unable to do so via the UI due to the invalid port and invalid external IP address.  Did some reading about port 0 and apparently on Unix/Linux it's a wildcard that tells the system to find a suitable port number.

 

I'm "assuming" that all the changes were the result of an ISP push.  A big concern though, has to do with the port forwarding to port "0" on my unRAID server.  I'm not sure how this could be exploited or the exposure it caused, and what I should now look for or check on unRAID to make sure things are as they should be?

 

TLDR: Suspected ISP push added odd forward rules in my modem/router to port 0 on my unRAID tower.  Should I be concerned, and what should I check on the server to make sure nothing is amiss?

 

Share this post


Link to post

I see this has over 100 views, but unfortunately no feedback.  WAN reset last night on my ISP supplied modem/router, and I see the odd port forward rules are back again.  At least the other settings and password didn't reset this time.  This time I took a screenshot, so perhaps a picture is worth a thousand words!

image.png

 

The bottom two are my entries pointing to my unRAID server.  The top two are the ones that "magically" appear.  They must be inserted/injected programmatically as the UI does not allow entering port 0, or remote IP 255.255.255.255, or duplicating the Application Name.

 

I've tried changing the status to off for those two rules, but saving the change fails, likely due to the "invalid" nature of the rules.  I tried entering a port blocking rule, but again no luck due to invalid port 0.

 

What risk does this pose to my unRAID server?

 

Edited by beverage

Share this post


Link to post

Hi, I don't know why that rules are automatically created: remote ip 255.255.255.255 is a special ip address that means "this network" (in other words the local network).

Port 0 is a special port that means that it is up to the operating system to find a suitable and not in used port (in case of applications that use bind() for example).

A socket connection requires a source port and a destination port: when a packet is transmitted from the source it contains both the source and destination ports, so when the packet reach the destination, it knows the correct endpoint.

 

So by merging these definitions, this should mean any address of the local network (remote ip 255.255.255.255) can request a connection from port xx to port xx, where port xx is chosen by the os (not too much sense for me, especially for the destination port.., it should be related to fragmented packets).

Edited by ghost82

Share this post


Link to post

Port "0" is a reserved port, and there is nothing on Unraid listening or using that port (otherwise it would violate the RFC standard).

 

The address 255.255.255.255 is the broadcast address and is not routable. An ISP will never forward on such an address. In other words it is an unreachable destination.

 

Share this post


Link to post

Thanks for the feedback.  I spent a considerable amount of time chatting with my ISP tech support about it, and it's nothing that they're aware of.  They suggested it was added by a service running behind the firewall (i.e. this would mean the NPM docker container running on my unRAID box) - not likely, but what more could I expect from the ISP tech support?  I also tried contacting the modem/router hardware manufacturer but, without even considering the question, they punted me back to the ISP because the ISP's typically load up customer firmware.

 

In the NPM thread, I mentioned a NAT reflection issue related to reaching a website hosted on my unRAID box from a machine on my LAN.  I was unable to find any NAT reflection type settings in the modem/router.  I'm beginning to think these odd forwarding rules that automatically get added are some kind of workaround related to NAT reflection.  Does that make sense?

 

Share this post


Link to post

Unless you really need it, make sure UPnP is turned off on the router.

Share this post


Link to post

To be honest, these settings look very odd to me.

Does your router have a setting for NAT reflection, also called hair-pinning or NAT loopback?

 

Share this post


Link to post
12 minutes ago, bonienl said:

To be honest, these settings look very odd to me.

Does your router have a setting for NAT reflection, also called hair-pinning or NAT loopback?

 

I was unable to find any settings in the router for NAT reflection / hair-pinning / loopback.  This is why I'm now wondering if these odd rules are a way to achieve the same functionality as NAT reflection?

Share this post


Link to post

I've never seen anything like that before. A wtf might be appropriate, pardon my french.

Edited by ezhik

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.