this post was submitted on 23 Aug 2023
14 points (100.0% liked)

Selfhosted

40394 readers
210 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
14
Need help ensuring my public mediawiki is safe before launch (lemm.ee)
submitted 1 year ago by [email protected] to c/[email protected]
21 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

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

Also, isn't bruteforcing an SSH key near to impossible?

[–] [email protected] 1 points 1 year ago

There are 2 extra chains - to log a connection and accept it, and to log a connection and drop it. I've only used log and accept for testing.

The default action on input chain is also changed to drop.

SSH port gets connection attempts counted - 20 connections within 10 minutes from the same IP and it goes to log and drop. I could just drop it, but for now I feel immense satisfaction knowing that some bot is waiting for timeout instead of attempting the next username/pass.

I've tried a similar thing with https because lemmy.world was dosing me. It did work, but I've now commented it out since Lemmy software has become more robust. Lemmy.world still sucks from my, as an instance owner, perspective, but it no longer bombards me periodically.