ForHonor NAT
ForHonor NAT
It's okay. It reminded me of my college networking professor. I tolerated her for two semesters because I saw her as a challenge. I knew she truly wanted to assist, so her firm demeanor didn't bother me. I don't share that view with my classmates. She gained a reputation at the school for not being especially popular. Therefore, the client isn't concerned about the message arriving on a different port than where it was sent. This is just how these protocols are meant to function. I'm curious if the system actually got the message on the same port as it was sent, which could make the client treat it like an echo. The issue is that she doesn't understand how to handle the reply. So, much like the OP's concern, if a program could use UPnP or Port Forwarding to achieve the same goal, would UPnP be considered safer by avoiding direct network access? My question stems from my SFTP/SSH file server setup and another task that requires opening ports. Only this project supports UPnP (it uses NAT and loopback 127.0.0.1) and they suggest port forwarding, but I'm aware of its benefits.
UPnP is perceived as more secure but functions somewhat like dynamic port forwarding. I haven’t been interested in UPnP before, so its inner workings aren’t my focus. It appears to automatically assign ports, which can be risky. Despite this, it’s still seen as unsafe because hackers might exploit it to open ports and launch attacks. Port forwarding itself isn’t inherently dangerous—it depends on what’s listening on the ports. Linux usually doesn’t include a firewall by default; it assumes applications aren’t already using a port, so no attack can happen unless something is open. Opening ports often stays within the 30000-60000 range, which is typical and reduces login attempts. I rarely advise people to forward ports because they often don’t grasp what they’re enabling, leading to misuse. Common ports are frequently targeted, and weak passwords increase the risk of brute-force attacks.
At first, I used port 22 with a password for SFTP/SSH, which attracted login attempts from unfamiliar sources. After a month, I moved to a much higher random public port and implemented Public/Private Key Authentication using RSA 2048-bit with a password. This ensures that even if the private key is compromised, a password is still required. I plan to add rate limiting on login attempts. The other port forwarding uses ports in the 1000s range, but since the software allows manual port assignment, I’ll shift them to 30k–60k if it improves security. Running the program on Windows poses no additional security benefits from a technical standpoint. Someone mentioned a Linux version exists—would you like me to investigate that?
Windows remains surprisingly secure in practice. The public's concern stems mainly from setup quality. Linux offers only slight improvements in security, which comes from permission handling and regular OS updates. Even a Linux system without patches and with a weak firewall is just as vulnerable as a Windows machine lacking updates. Pay attention to what ports are active—listen on the right ports is crucial. Avoid using ports that other apps share, and ensure TCP services aren’t listening on the same port unless supported (like web servers). Be wary of unexpected open ports such as 3016-3020, which might hide a service actually running on 3019. These details matter; they’re like dialing a number and expecting an extension—if you don’t know the right one, it’s hard to exploit it.