What is the best way to implement fail2ban blocking for login? Some documentation on this would be great!
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:
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:
runserver command)/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 -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.
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:
runservercommand)/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.