2

I want to reserve certain port numbers on a VM host for use by the VMs themselves.

Is there a mechanism by which the host can exclude those ports from being allocated to processes not related to the VMs by looking them up in a list or checking them against preset rules?

If some other software requests a port without checking with the host it should find it blocked as though it is in use.

The VMs themselves are also software running on the host so I guess they could be blocked themselves, so it should be more of a system reserving certain ports for some particular utilities used by the VM manager to allocate those ports.

It could also be relevant for docker containers.

Update: The VMs share the IP address with the host, and some incoming ports need to be forwarded to services running on the VMs or the containers. I don't know if the outgoing ports need to be reserved unless they will interfere with the listening services. I guess the iptables rules can distinguish them, or not.

Improve this question
7
  • 3
    It would help immensely if you would specify whether you mean incoming or outgoing ports; whether the VM has its own IP or if it shares an IP with other VMs and/or the physical host (guessing that it does, but an explicit acknowledgement would lend focus); and why you think this is necessary. Commented Nov 11, 2024 at 9:15
  • @JimL The VMs share the IP address with the host, and some incoming ports need to be forwarded to services running on the VMs or the containers. I don't know if the outgoing ports need to be reserved unless they will interfere with the listening services. I guess the iptables rules can distinguish them, or not. Commented Nov 11, 2024 at 9:33
  • I edited your post to reflect that additional information. Commented Nov 11, 2024 at 9:37
  • I'm not really seeing what's the real concern here to be frank. First of all if your VM host has DNAT rules that forwards traffics destined at certain ports to the VM, then in case anything running on the VM host listen to those ports as well, they will effectively be "hidden" by the DNAT rules, meaning that the processes will be able to listen on the ports but they will not receive traffics, until/unless the DNAT rules are removed. Commented Nov 12, 2024 at 11:31
  • As for the SNAT/MASQUERADE, it will retain the source port picked by the VM unless it is being used by the host or you instruct it not to in the rule. Just like the mapping between the IPs, "conntrack" will "remember" the mapping between the ports and "reverse DNAT" will take care of the replies for the VM. Commented Nov 12, 2024 at 11:34

2 Answers 2

Reset to default
2

Is there a mechanism by which the host can exclude those ports from being allocated to processes not related to the VMs by looking them up in a list or checking them against preset rules?

Sure, with seccomp or generally linux security modules like apparmor or SELinux, you can set rules who can open which port.

Improve this answer
3
  • 1
    Aren't there other utilities that are less intellectual taxing than apparmor and SELinux? These utilities are not known for their simplicity and ease of use. Commented Nov 11, 2024 at 16:55
  • 1
    You can write your own eBPF filters and hook syscalls. I'm not sure that would be "less intellectually taxing"; I don't think this is extremely complicated. Commented Nov 11, 2024 at 16:57
  • 3
    OK I give up. Where can I find a gentle introduction to the topics like seccomp, apparmor and selinux in this particular area? I'll give it a shot and go with if it doesn't turn out to be too "intellectually taxing". As a hobbyist I gave up on SELinux and AppArmor years ago when they frustrated my ability to change system configurations without giving me any useful information as to what was going on. I had to work out myself that they were the most likely culprits. It is so annoying when you've done everything right and things are not working, and you don't why. Commented Nov 12, 2024 at 22:24
2

The organizations where I've worked have used agreements made between application development teams to designate which TCP port number(s) used by each of the applications. The server OS does not enforce the port->applocation mapping, the app configurations are simply written to follow the agreements. The documentation for the agreements has usually been a wiki page or sometimes a document in whatever code doco system the dev teams use.

That's because plain Linux - I.e., Linux without SELinux or Apparmor security systems - has no mechanism for designating ports for use by a particular application and preventing other applications from binding/listening to the ports.

You can't avoid the intellectual tax involved in coordinating ports among multiple applications and multiple servers. The only choice you have is whether you want to invest your time/effort in the configuration of the security layers provided with Linux or invest your time/effort in the coordination among your development teams.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.