Paperless: Fail2ban for login

Created on 12 Aug 2019  Â·  6Comments  Â·  Source: the-paperless-project/paperless

What is the best way to implement fail2ban blocking for login? Some documentation on this would be great!

Most helpful comment

While I'm not opposed to the idea of adding more security to the login process, I want to stress that I wrote most of the code in this project and there's no way in hell I'd host it on a public-facing server.

I suppose if you're:

  • running Paperless via gunicorn (and not the typical way via the runserver command)
  • and encrypting all of your documents
  • and storing your secrets as environment variables and not in /etc/paperless.conf (the default)

... you'd be ok, though you'd still have all of those documents OCR'd into a database that's effectively clear text. You can use PostgreSQL with strong credentials and a cert, but at the end of the day, that text is stored in the clear.

Of course, if you're not storing anything of consequence, it's not really a problem. It's just that given that Paperless was written to handle personal documents, I'd hate for people to get the impression that adding a feature like this makes it a Good Idea to host it somewhere untrusted like the open internet.

All 6 comments

fail2ban should be implemented outside paperless. This is implemented at
the OS level and not here in Paperless.

On Mon, Aug 12, 2019 at 4:05 AM yungdan1 notifications@github.com wrote:

What is the best way to implement fail2ban blocking for login? Some
documentation on this would be great!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/the-paperless-project/paperless/issues/557?email_source=notifications&email_token=AAM5SMX6QQVNH5RIO7RLIJ3QEE7WTA5CNFSM4ILADXSKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HEV5EJA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAM5SMXLEKPHUDXXWKWXTCDQEE7WTANCNFSM4ILADXSA
.

If you mean the web-frontend login, then you'd have to look into django's authentication. I'm not up-to-date on django's auth, but you can probably do this by writing a custom authentication backend. https://docs.djangoproject.com/en/2.2/topics/auth/customizing/

Here is a blog post about how to integrate fail2ban with django auth. Generally you need to get an IP address for an unsuccessful login. I don't think that paperless logs IP addresses on unsuccessful login, but you should be able to check that for yourself:

  • locate the log file for paperless
  • try to login with incorrect password
  • look at the log file and see if it logs the ip address

The blogpost above shows how to patch django/paperless to output IP addresses, which you can then configure fail2ban to search for.

django-axes does exactly that. It logs all login attempts in the database, and you can configure it to block a user after N failed attempts for T amount of time. Though OP seemed to ask specifically about fail2ban, so I'm not sure if this is relevant! The blog post mentioned by @syntonym is easier to implement (few changes to paperless, only on logging part), and integrable with other solutions.

While I'm not opposed to the idea of adding more security to the login process, I want to stress that I wrote most of the code in this project and there's no way in hell I'd host it on a public-facing server.

I suppose if you're:

  • running Paperless via gunicorn (and not the typical way via the runserver command)
  • and encrypting all of your documents
  • and storing your secrets as environment variables and not in /etc/paperless.conf (the default)

... you'd be ok, though you'd still have all of those documents OCR'd into a database that's effectively clear text. You can use PostgreSQL with strong credentials and a cert, but at the end of the day, that text is stored in the clear.

Of course, if you're not storing anything of consequence, it's not really a problem. It's just that given that Paperless was written to handle personal documents, I'd hate for people to get the impression that adding a feature like this makes it a Good Idea to host it somewhere untrusted like the open internet.

There is also the option to have authentication by some other means than paperless.

  • ssh: You can proxy connections through ssh by using ssh -L PORT1:your.paperless.domain:PORT2 which then tunnels connections made to PORT1 on your local host to PORT2 of your.paperless.domain. You need to authenticate with the ssh server, which is well known and battle tested.
  • vpn e.g. wireguard or openvpn: Only listen on the vpn network, not on the internet. You need to authenticate the vpn, which should hopefully be designed for security.
  • nginx (or other proxies): You actually have a few options there:

    • http basic auth (only use with https, otherwise passwords will be sent in plaintext)

    • client certificates (probably very secure, but often a bit of a hassle to set up)

    • restrict to specific ip addresses

  • use extra application for authentication, for example keycloak, but there are probably thousands of them. Make sure you trust them (more then paperless/to be audited for security).
Was this page helpful?
0 / 5 - 0 ratings

Related issues

eonist picture eonist  Â·  7Comments

ovv picture ovv  Â·  5Comments

ddddavidmartin picture ddddavidmartin  Â·  8Comments

blackwood picture blackwood  Â·  3Comments

totti4ever picture totti4ever  Â·  6Comments