Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Separate Password for Reading #630

Open
Pheromir opened this issue May 23, 2022 · 8 comments
Open

[Feature Request] Separate Password for Reading #630

Pheromir opened this issue May 23, 2022 · 8 comments

Comments

@Pheromir
Copy link
Contributor

Pheromir commented May 23, 2022

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
Copy link
Owner

Difegue commented May 26, 2022

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
Copy link
Contributor Author

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
Copy link
Owner

Difegue commented May 26, 2022

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
Copy link
Contributor Author

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
Copy link
Owner

Difegue commented Jun 7, 2022

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
Copy link
Contributor Author

Pheromir commented Jun 8, 2022

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
Copy link
Contributor Author

Pheromir commented Jun 12, 2022

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
Copy link
Contributor Author

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants