I was wondering, If there is a (private) application or service deployed at example.com:5000, how can someone prevent undesired requests to that port ?

I was thinking about a solution were the credentials for the user should be sent in the first request to the application and it should then answer back with some session token (like a cookie?) that you can attach to each one of your following requests. Maybe another security measure could be to use fail2ban with the application logs.

Furthermore, is there any library to easily implement something similar in NodeJS, Python, Java or C++ (or any other) ?


closed as too broad by AndrolGenhald, Steffen Ullrich, forest, Teun Vink, Jacco Feb 26 at 9:11

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Are you looking for something like Port Knocking? – Euphrasius von der Hummelwiese Feb 18 at 20:21
  • 3
    The application should handle authentication and authorization. This is unrelated to which port the application runs on. "How do I handle authentication and authorization in X language" is far too broad a topic. – AndrolGenhald Feb 18 at 20:42
  • 1
    I was wondering, If there is a (**private**) application or service deployed at example.com:5000, how can someone prevent undesired requests to that port ? Why not iptables -A INPUT -p tcp --dport 5000 --source [your IP here] -j ACCEPT in a global DROP policy? – Nomad Feb 19 at 12:08

Just use what the existing infrastructure provides. On a Active Directory system, you can use the provided facilities to know the AD authenticated owner of the calling process. If you can build your system on top of HTTPS use one of the numerous HTTP authentication scheme, including SSO ones.

If you have no underlying infra and are restricted to raw sockets, the first question is whether IP knowledge is enough for your security requirements. If it is not, you will need an authentication step.

The next question is whether the network can be fully trusted (no spying possibility). If the answer is no, you should use TLS or rely on shared secrets and exchange hashes of the secret and of a nonce ala APOP way. The most secure way is with no doubt TLS but unfortunately it may not be the simplest one...

And to answer your last question, I know no established library or protocol outside HTTP/HTTPS or AD.


If you're using an established protocol, such as ssh or http or whatever, use an/the established authentication scheme for that protocol (and, for network protocols that aren't inherently secure, use a secure transport such as TLS). If you're using a custom protocol, first ask yourself why you are doing this (the network and CPU overhead of something like JSON via HTTPS are almost certainly worth spending to get the developer convenience of working with a well-established toolset) and if you decide you absolutely must do it, tunnel it through TLS (or DTLS or some other secure protocol, if you must) anyhow, and then either do a standard require-credentials-and-issue-session-token auth or use TLS client certificates (mostly a matter of how much control you'll have over clients and how easy it needs to be to add new users).

To be clear, though: all of this is for how you authenticate a user. You cannot ever meaningfully restrict what clients connect to your server; it is a fool's errand to try. Anything that your client can do, I can clone in my own client. Just authenticate the users.

Not the answer you're looking for? Browse other questions tagged or ask your own question.