TurboFloatServer has many open TCP ports.

We are gradually implementing floating license support into our app, and one of the things we did was ask our own main IT guy to install the TFS app on our server and tell us about anything that a client might complain about. I don't have any IT support experience, so I have to accept what he says - especially since he definitely knows what's talking about.

I've already posted a related question regarding VMs and got a reply, so I will not ask that again.

However, our IT guy did spot another problem which he said would cause raised eyebrows on many a site:

"Ive used your script when installing service on <host name> .... As mentioned yesterday, the script has registered a service on Windows platform and created two inbound Windows Firewall exceptions (one for UDP, one for TCP), the exceptions were for the TFS process only, but allowed traffic on /all/ ports, completely disregarding the 8159 port number present in the config file. Might be worth looking into this. As a precaution, I have restricted traffic to port 8159 only on both, the edge firewall as well as local Windows Firewall service."

We found that we couldn't make a connection with that Firewall config, he later had to relax it a lot.

Can you say why TFS needs to open so many ports? Our IT guy says that this leaves us more susceptible to DOS attacks.

On Windows, when you install the service using the -i commandline, we make the TurboFloat Server "firewall" config as easy as possible. Meaning, we don't use the port you specified in the config, because that can change later on. Instead we open up all ports.

If you don't like that, you can restrict the firewall configuration to only use the port you configured (TCP only) and 443 (to re-verify with the licensing servers).

So, TFS only requires 2 ports to be open, and only one of them needs to be multi-directional (meaning it accepts incoming connections).

Short answer: convenience.

Thanks for the reply. I'll pass it to our IT guy.

Reply
Discard post