3 ms·

I write application servers for a living, mostly for Python but previously for other languages. Nobody, nobody, writes application servers with the intent of h

I write application servers for a living, mostly for Python but previously for other languages. Nobody, nobody, writes application servers with the intent of having them exposed to the public internet. Even if they're completely memory safe, we don't do DOS protections like checking for reasonable header lengths, rewriting invalid header fields, dropping malicious requests, etc. Most application servers will still die to slowloris attacks. [1] We don't do this because it's a performance hog and we assume you're already reverse proxying behind any responsible front-end server, which all implement these protections. We don't want to double up on that work. We implement the HTTP spec with as low overhead as possible, because we expect to have pipelined HTTP/1.1 connections from a load balancer or other reverse proxy. Your application server, Gunicorn, Twisted, Uvicorn, whatever, does not want to be exposed to the public internet. Do not expose it to the public internet. [1]: https://en.wikipedia.org/wiki/Slowloris_(cyber_attack) https://en.wikipedia.org/wiki/Slowloris_(cyber_attack)

mr_person 2y ago
As someone who designs load-balancer solutions for a living I cannot agree with this more. I likewise assume that all servers are insecure, always, and we do not want them exposed without a sane load balancer layer. Your server was probably not made to be exposed to the public internet. Do not expose it to the public internet.
koakuma-chan 2y ago
> We don't do this because it's a performance hog and we assume you're already reverse proxying behind any responsible front-end server What application servers have you written? I have never seen an application server readme say DON'T EXPOSE DIRECTLY TO THE INTERNET, WE ASSUME YOU USE REVERSE PROXY.
- nickelpro 2y ago
  Most of them have a disclaimer in their deployment or tutorial docs, some with more strong language than others. Again, nothing bad happens if you don't, we don't write memory vulnerabilities into these servers. You are just far more vulnerable to DOS attacks. * "We strongly recommend using Guincorn behind a proxy server" [1] * "As a general rule, you probably want to: ... run behind Nginx for self-hosted deployments." [2] * "A reverse proxy such as nginx or Apache httpd should be used in front of Waitress." [3] For some, like uWSGI, they don't even want to talk HTTP (uWSGI supports its own protocol) and it's just assumed you're using a dedicated webserver to talk to public traffic. [4] [1]: https://docs.gunicorn.org/en/latest/deploy.html https://docs.gunicorn.org/en/latest/deploy.html [2]: https://www.uvicorn.org/deployment/ https://www.uvicorn.org/deployment/ [3]: https://flask.palletsprojects.com/en/stable/deploying/waitress/ https://flask.palletsprojects.com/en/stable/deploying/waitre... [4]: https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django...
SahAssar 2y ago
> Nobody, nobody, writes application servers with the intent of having them exposed to the public internet For rust, go, lua (via nginx openresty) and a few others this is a viable path. I probably wouldn't do it with node (or bun or deno), python, or similar but there are languages where in certain circumstances it is reasonable and might be better.
- nickelpro 2y ago
  For Go, net/http is not something you should expose to the public internet, there's no secret sauce in there. It will just die to the first person to hit it with a slowloris or other DOS attack. Same with the common C++ options like boost.beast unless you're writing the logic yourself (but why bother? Just reverse proxy). I'm unfamiliar with the common rust frameworks for http, but find it unlikely the situation is very different.
  - badmintonbaseba 2y ago
    boost.beast also only talks HTTP/1.1 AFAIK, so if you want HTTP/2 or /3 on your frontend then you must put it behind a reverse proxy anyway.
p_ing 2y ago
Of course, don't expose to the public Internet. Also don't expose plain text traffic to the internal corpnet where most attack originate from.

mr_person 2y ago

As someone who designs load-balancer solutions for a living I cannot agree with this more. I likewise assume that all servers are insecure, always, and we do not want them exposed without a sane load balancer layer. Your server was probably not made to be exposed to the public internet. Do not expose it to the public internet.

koakuma-chan 2y ago

> We don't do this because it's a performance hog and we assume you're already reverse proxying behind any responsible front-end server What application servers have you written? I have never seen an application server readme say DON'T EXPOSE DIRECTLY TO THE INTERNET, WE ASSUME YOU USE REVERSE PROXY.

nickelpro 2y ago
Most of them have a disclaimer in their deployment or tutorial docs, some with more strong language than others. Again, nothing bad happens if you don't, we don't write memory vulnerabilities into these servers. You are just far more vulnerable to DOS attacks. * "We strongly recommend using Guincorn behind a proxy server" [1] * "As a general rule, you probably want to: ... run behind Nginx for self-hosted deployments." [2] * "A reverse proxy such as nginx or Apache httpd should be used in front of Waitress." [3] For some, like uWSGI, they don't even want to talk HTTP (uWSGI supports its own protocol) and it's just assumed you're using a dedicated webserver to talk to public traffic. [4] [1]: https://docs.gunicorn.org/en/latest/deploy.html https://docs.gunicorn.org/en/latest/deploy.html [2]: https://www.uvicorn.org/deployment/ https://www.uvicorn.org/deployment/ [3]: https://flask.palletsprojects.com/en/stable/deploying/waitress/ https://flask.palletsprojects.com/en/stable/deploying/waitre... [4]: https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django...

SahAssar 2y ago

> Nobody, nobody, writes application servers with the intent of having them exposed to the public internet For rust, go, lua (via nginx openresty) and a few others this is a viable path. I probably wouldn't do it with node (or bun or deno), python, or similar but there are languages where in certain circumstances it is reasonable and might be better.

nickelpro 2y ago
For Go, net/http is not something you should expose to the public internet, there's no secret sauce in there. It will just die to the first person to hit it with a slowloris or other DOS attack. Same with the common C++ options like boost.beast unless you're writing the logic yourself (but why bother? Just reverse proxy). I'm unfamiliar with the common rust frameworks for http, but find it unlikely the situation is very different.
- badmintonbaseba 2y ago
  boost.beast also only talks HTTP/1.1 AFAIK, so if you want HTTP/2 or /3 on your frontend then you must put it behind a reverse proxy anyway.

p_ing 2y ago

Of course, don't expose to the public Internet. Also don't expose plain text traffic to the internal corpnet where most attack originate from.