Difegue / LANraragi

Web application for archival and reading of manga/doujinshi. Lightweight and Docker-ready for NAS/servers.
https://lrr.tvc-16.science
MIT License
2.19k stars 154 forks source link

[Feature Request] Separate Password for Reading #630

Open Pheromir opened 2 years ago

Pheromir commented 2 years ago

Please describe your suggestion, and the problem it'd solve. I think it would be useful to have a separate password for reading the mangas/doujins (if No-Fun mode enabled), without granting access to the administrative area. That way you can share your library with some people without having to worry about them changing anything they're not supposed to.

Difegue commented 2 years ago

There's been a few requests for this already -- My answer was always to just slap HTTP basic auth on top of the server with nginx/apache instead of using no-fun mode, but I agree it's not the most flexible thing.

Pheromir commented 2 years ago

My answer was always to just slap HTTP basic auth on top of the server with nginx/apache instead of using no-fun mode

Theoretically possible, didn't think about that, but sadly there is no direct way to add basic auth to a reverse proxy entry in Synology DSM (at least as far as I know, without modifying some files via ssh that could be overwritten by synology at any time).

btw, is there any log entries about failed logins, so you could use fail2ban to prevent bruteforce or is there any other bruteforce prevention? Didn't see anything in that direction, which might be something that could be implemented together with this (I can also make a new issue for that, if you want to)

Difegue commented 2 years ago

There's no logging for failed attempts IIRC since the password page is fairly simple, but that could easily be added in. (Probably no need for a separate issue)

As for bruteforce prevention, there's nothing in place -- If adding logging would help building a solution with fail2ban or something similar I'll gladly help 🤝

Pheromir commented 2 years ago

As for bruteforce prevention, there's nothing in place -- If adding logging would help building a solution with fail2ban or something similar I'll gladly help 🤝

Guess that could be used to build some fail2ban config/jail, but I don't have much experience with that. If I'm successful with that, I can share the configuration, so that it could be added to the documentation (or smth like that)

Difegue commented 2 years ago

I've added said basic logging to get started:
image I haven't tested the IP address part too much so it might be inaccurate, we'll see.

Pheromir commented 2 years ago

Cool, will look into this soon. Unfortunately my NAS is currently nuked and I'm waiting for new HDDs to set it up again. Might be interesting how the IP gets handled if you're using an reverse proxy (if you didn't test that)

Pheromir commented 2 years ago

I haven't tested the IP address part too much so it might be inaccurate, we'll see.

Without any modifications, the IP will be an internal docker ip (only if using docker of course) - but it seems to work if the ENV Var MOJO_REVERSE_PROXY=1 is set. ([2022-06-12 02:19:34] [LANraragi] [warn] Failed login attempt with password 'fqefqef' from 172.23.0.1 vs [2022-06-12 02:26:40] [LANraragi] [warn] Failed login attempt with password 'grewrgerg' from 192.168.2.101) Obviously you also need to access the logfile, so you need another mounted directory in docker

my current docker-compose.yml for this looks like this (you can ignore the build stuff, as I build the image myself to use alpine 3.12 instead of 3.14):

version: '3.3'
services:
    lanraragi:
        container_name: lanraragi
        restart: unless-stopped
        image: pheromir/lanraragi
        build:
            context: ./LANraragi-dev
            dockerfile: ./tools/build/docker/Dockerfile
        ports:
            - '8011:3000'
        volumes:
            - './LANraragi-data/content:/home/koyomi/lanraragi/content'
            - './LANraragi-data/database:/home/koyomi/lanraragi/database'
            - './LANraragi-data/logs:/home/koyomi/lanraragi/log'
        environment:
            - LRR_UID=1000
            - LRR_GID=100
            - TZ=Europe/Berlin
            - MOJO_REVERSE_PROXY=1

Didn't test any banning with fail2ban yet, but I can share my jail config if I am successful. The config might be a bit specialized to my setup though.

Pheromir commented 2 years ago

My configuration is customized to work with my NAS (using a fail2ban docker-container) with banning through cloudflare using this fail2ban-action: https://github.com/fail2ban/fail2ban/blob/master/config/action.d/cloudflare.conf

This might have to be adapted to a more general config to be put into the documentation, but as I've never done this before and I don't have another system to test, I'm not able to provide a general config. Maybe someone else is smart enough for this.

fail2ban/jail.d/lanraragi.conf:

[lanraragi]
enabled = true
port = 3000,80,443
chain = DOCKER-USER
filter = lanraragi
logpath = /lanraragi/lanraragi.log
action = iptables-allports[name=lanraragi]
         cloudflare

the logpath has to be adapted to the path where the lanraragi.log file is available


fail2ban/filter.d/lanraragi.conf:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*Failed login attempt with password '.*' from <ADDR>$
ignoreregex =

grafik

Funfact: Having your local ip address banned from your NAS sucks. Using ssh with my phone too.

My only "problem" is that fail2ban cries because the timestamps in the lanraragi.log do not match the current time (2h difference, even through env var TZ=Europe/Berlin is set on both containers). Fail2ban still works, so not veeeery important (at least to me)