Comment on Sharing Jellyfin

• Codilingus@sh.itjust.works ⁨2⁩ ⁨weeks⁩ ago

  Think of it as more modular.

  I personally used Traefik, but only because I’m a masochist and it would be useful to know in IT workplace.

  Traefik + CrowdSec + CowdSec Traefik Bouncer.

  Traefik handles the traffic, and said traffic has to get a green light from CrowdSec + Bouncer before it can go anywhere.

  The concept of CrowdSec is honestly super awesome.

  source

  • possiblylinux127@lemmy.zip ⁨2⁩ ⁨weeks⁩ ago

    Is Taefik really that good? It seems crazy complex

    source

    • Codilingus@sh.itjust.works ⁨2⁩ ⁨weeks⁩ ago

      It’s designed to scale. Plus it’s nifty to be able to add ~3 tags to a docker container and then it’s instantly online and ready to be used.

      source
• Jakeroxs@sh.itjust.works ⁨2⁩ ⁨weeks⁩ ago

  Crowdsec is what stops the intrusion.

  source

  • possiblylinux127@lemmy.zip ⁨2⁩ ⁨weeks⁩ ago

    Crowdsec won’t protect against a security vulnerability

    source

    • Jakeroxs@sh.itjust.works ⁨2⁩ ⁨weeks⁩ ago

      It will if it detects the requests and blocks them

      source

      • possiblylinux127@lemmy.zip ⁨1⁩ ⁨week⁩ ago

        Only if it is from a known bad IP

        Also the vulnerability may be in something needed for client functionality.

        source
• greyfox@lemmy.world ⁨1⁩ ⁨week⁩ ago

  Depending on how you setup your reverse proxy it can reduce random scanning/login attempts to basically zero. The point of a reverse proxy is to act as a proxy, as a sort of web router, and to validate that the http requests are correctly formatted.

  For the routing depending on what DNS name/path the request comes in with it can route to different backends. So you can say that app1.yourdomain.com is routed to the internal IP address of your app1, and app2.yourdomain.com goes to app2. You can also do this with paths if the applications can handle it. Like yourdomain.com/app1.

  When your client makes a request the reverse proxy uses the “Host” header or the SNI string that is part of the TLS connection to determine what certificate to use and what application to route to.

  There is usually a “default” backend for any request that doesn’t match any of the names for your backend services (like a scanner blindly trying to access your IP). If you disable the default backend or redirect default requests to something that you know is secure any attacker scanning your IP for vulnerabilities would get their requests rejected. The only way they can even try to hit your service is to know the correct DNS name of your service.

  Some reverse proxies (Traefik, HAproxy) have options to reject the requests before the TLS negation has even completed. If the SNI string doesn’t match the connection just drops it doesn’t even bother to send a 404/5xx error. This can prevent an attacker from doing information gathering about the reverse proxy itself that might be helpful in attacking it.

  This is security by obscurity which isn’t really security, but it does reduce your risk because it significantly reduces the chances of an attacker being able to find your applications.

  Reverse proxies also have a much narrower scope than most applications as well. Your services are running a web server with your application, but is Jellyfin’s built in webserver secure? Could an attacker send invalid data in headers/requests to trigger a buffer overflow? A reverse proxy often does a much better job of preventing those kinds of attacks, rejecting invalid requests before they ever get to your application.

  source
• possiblylinux127@lemmy.zip ⁨2⁩ ⁨weeks⁩ ago

  It protects against vulnerabilities in layer 3 of the OSI model. It is the thing that gets hit from the outside while the back end is hidden away. This makes some attacks much harder.

  source