• 0 Posts
  • 244 Comments
Joined 2 years ago
cake
Cake day: June 9th, 2023

help-circle

  • Besides that, security by obscurity is the worst possible form and barely qualifies as security at all.

    In fact security by obscurity is not security at all. In this case it should be authenticated or to the very least to actually use a random string like a uuid. But, changing the root path does prevent it from exploiting. Not perfect but a temporary solution.

    It’s also another place where the Jellyfin devs leave their users to their own devices when it comes to securing the server against malicious actors.

    Another place? What else? You mean setting up you own server? That is in fact your responsibility.




  • Based on you screenshot from the NPM Dashboard there seems to be something wrong. In the setup window you show that you forward the traffic with http and port 80, in the dashboard screenshot you forward the traffic with https and port 80.

    Just skip http and self signed certificates all together. Modern Browsers make it a pain to use non https sites. A simple domain setup with dns acme challenge is a little bit of a hassle but worth the hour(s) of invested time. Especially with npm were it is a set and forget option.

    Does pihole support wildcard dns entries yet? To my knowledge the gui only supports single entries so that you have to enter every subdomain manually in pihole that you want to have forwarded. Workaround would be to use a dnsmasq config file or use something else like addguard.



  • ShortN0te@lemmy.mltoSelfhosted@lemmy.worldJellyfin over the internet
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    3 months ago

    And which one of those are actually vulnerabilities that are exploitable? First, yes ofc unauthenticated endpoints should be fixed, but with those there is no real damage to be done.

    If you know the media path then you can request a playback, and if you get the user ids then you can get all users. That’s more or less it.

    Good? No. But far from making it a poor choice exposing it.



  • ShortN0te@lemmy.mltoSelfhosted@lemmy.worldJellyfin 10.11 RC1 Released
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    3 months ago

    … and may also break compatibility with previous 10.Y releases if required for later cleanup work.

    If you read through the whole paragraph, it is clear that they mean the compatibility of previous jellyfin versions.

    Also, again:

    Note however that the 10.Y.Z release chain represents the “cleanup” of the codebase, so it should be accepted that 10.Y.Z breaks all compatibility,

    That means that the code is not cleaned up with that release.

    If you would release 11 before the code is considered cleaned up, you would basically break your own defined versioning convention. That is best decided by the active maintainers.


  • ShortN0te@lemmy.mltoSelfhosted@lemmy.worldJellyfin 10.11 RC1 Released
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    3 months ago

    Consider the 10.y.z simply to be 0.y.z and everything works out.

    Jellyfin inherited a lot of shitty code and architecture from emby. They simply cannot guarantee anything across patches until it is sorted out.

    imho much better then releasing major version after major version because the break stuff regularly.








  • Do you want to prevent brute forcing or do you want to prevent the attack getting in?

    If you want to prevent brute forcing then software like fail2ban helps a little, but this is only a IP based block, so with IPv6 this is not really helpfull against a real attack, since rotating IP addresses is trivial. But still can slow down the attacker. Also limiting the amount of sessions and auth tries does significantly slow down the attacker.

    If you just want to not worry about it set strong passwords, and when it is a multi user system where other ppl might access it, configure Public Key Auth so you can be sure the other users have strong passwords (or keys in this case) to authenticate.

    With strong passwords or keys it is basically impossible to brute force your way in with ssh.


  • ShortN0te@lemmy.mltoSelfhosted@lemmy.worldDo I really need a firewall for my server?
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    8
    ·
    edit-2
    6 months ago

    You do not even need a port based firewall when the server is open on the internet.

    When you configure the software to not have unnecessary open ports over the internet connected interface then a port based firewall is providing zero additional security.

    A port based firewall has the benefit that you can lock everything down to the few ports you actually need, and do not have to worry about misconfigured software.

    For example, something like docker circumvents ufw anyway. And i know ppl that had open ports even tho they had ufw running.