How do I block a port from forwarding?
By default Linode forwards all ports opened, but what if I want to block a certain port from being forwarded? Is this something you can do on the server or do you have to change Linode settings?
What you are talking about is not port forwarding… What you are talking about is opening/closing ports in a network firewall for purposes of local or remote inter-process communication. Port forwarding is a specific technique (most commonly used in routers) to direct network traffic.
When you block a port in a firewall, it's closed for all sources and destinations unless you specify exceptions in the blocking rule. Ports are open by default so the first rule in my firewall is to close everything and then re-open selectively…according to my needs. For example, I block IMAP (tcp/udp port 143) everywhere but localhost because I have rules-based agents that file my email automatically that use IMAP to do their jobs. I don't want any remote system to talk to mine using IMAP.
I generally eschew "friendly front-ends" like ufw because the authors of these things never understand my situation better than me and they always have unanticipated side-effects.
There are three ways to do local inter-process communication on Unix/Linux: internet-domain sockets, local-domain sockets (sometimes called unix-domain sockets) and pipes. Internet-domain sockets require an IP address and an open port number…however you would restrict communication on that port to localhost by closing the port to all sources/destinations EXCEPT localhost (IPv4 address 127.0.0.1 and IPv6 address ::1).
The second choice, local-domain sockets, is network-style communication that is LOCAL to the system on which the socket lives because they require entries in the file system (watch out for ownership/permission problems here!). Consequently, you don't need to mess with your firewall at all since traffic can never escape across a system boundary…so there are no port numbers involved. Because local-domain sockets largely short-circuit the network stack, they are blazingly fast. Because traffic can never escape across a system boundary, they are also very secure.
You can read about the advantages and disadvantages of each here.
The last option for local IPC is pipes -- both unnamed and named. Pipes are part of the file system so their performance is significantly less than that of local-domain sockets. They are however easier to set up and manage from a programming perspective. They're much older than socket communication (unnamed pipes were in the first research edition of ATT Unix…named pipes -- called fifos -- first appeared in 4.3BSD…somewhat after internet-domain sockets).
As a final note, there are none of the features generally associated with "protocols" in the use of local IPC (congestion control, routing, fragmentation/re-assembly, etc) unless you invent them. There is only rudimentary signalling. Generally, anything more than that is not needed.