Hi, I’m setting up a public wiki using mediawiki and I’d like some help ensuring the server and mediawiki is safely setup before I start sharing it publicly. I installed it on Vultr using the mediawiki app from the Vultr Marketplace. Are there any things I should ensure before publicly sharing the link?

Some things I’ve done so far:

  • I disabled password login to the server so its only possible to login via ssh

  • I made it so I have to approve of any edits to the wiki

  • I still haven’t enabled uploads of files because I want to ensure I only allow jpeg\png uploads.

I’m relatively new to running servers so any tips are highly appreciated.

  • xnx@lemm.eeOP
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Yeah its only possible to login with a key.

    What limits would you set on the firewall?

    From the bit I’ve read people usually say changing the ssh port is mostly “security theatre” is this not fully true?

    • diminou@lemmy.zip
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      For the limit : basically you need to ask yourself how many connection someone if able to do in a second to your server. As an example, my limit is always 15. A bit high but I’m sure I’m not blocking a legitimate one (either from myself or someone else)

      For the ssh port : it’s true, but trust me you’ll be happy to change for something random like 5927 because you’ll have far less bit trying to connect or probe your ip, thus your logs won’t be cluttered!

    • Illecors@lemmy.cafe
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      It would be security theatre if it was done for security. I’m not doing it for security, though - it’s for my sanity when checking the logs. Unrestricted SSH simply attracts too many bots and the failed logins make it impossible to quickly grasp a picture of what’s happening.

      In regards to limits - this is my rule file for iptables on my lemmy instance:

      *filter
      :INPUT DROP [0:0]
      :FORWARD ACCEPT [0:0]
      :OUTPUT ACCEPT [0:0]
      :LOG_DROP [0:0]
      :LOG_ACCEPT [0:0]
      
      -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
      -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 20 --name DEFAULT --mask 255.255.255.255 --rsource -j LOG_DROP
      -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
      -A INPUT -i lo -j ACCEPT
      -A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -m recent --set --name HTTPS --mask 255.255.255.255 --rsource
      #-A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -m recent --update --seconds 600 --hitcount 600 --name HTTPS --mask 255.255.255.255 --rsource -j LOG_DROP
      -A INPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
      -A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
      -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
      -A INPUT -j LOG_DROP
      
      -A LOG_ACCEPT -j LOG --log-prefix "[ACCEPTv4]: " --log-level 7
      -A LOG_DROP -j LOG --log-prefix "[DENYv4]: " --log-level 7
      -A LOG_ACCEPT -j ACCEPT
      -A LOG_DROP -j DROP
      COMMIT
      

      This is very much a WIP, I’m going to implement some ddos protection as soon as I get some spare time.

      • xnx@lemm.eeOP
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Could you explain a bit of what these are doing and why you decided on these rules?