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

Fail2ban addition #1672

Closed
dan1elhughes opened this issue Jan 1, 2020 · 9 comments
Closed

Fail2ban addition #1672

dan1elhughes opened this issue Jan 1, 2020 · 9 comments
Labels

Comments

@dan1elhughes
Copy link

@dan1elhughes dan1elhughes commented Jan 1, 2020

Is your feature request related to a problem? Please describe.
After deploying the server, the first thing I did was SSH in and install fail2ban, to block IPs which failed to SSH into the server.

Describe the solution you'd like
Include a simple playbook which installs a basic fail2ban SSH configuration.

Describe alternatives you've considered
Rely on existing publickey protection for SSH.

Additional context
None

@dan1elhughes

This comment has been minimized.

Copy link
Author

@dan1elhughes dan1elhughes commented Jan 1, 2020

I'm happy to have a go at this, but would like to know if it'd be considered before putting the time in. Love the project. 😸

@TC1977

This comment has been minimized.

Copy link
Contributor

@TC1977 TC1977 commented Jan 2, 2020

This is a good time to point out that SSH is wide open to the world by default. Even if you close off cloud provider firewalls (which can't be done on Lightsail for instance), it's also wide open to any connected WireGuard/IPsec clients. Although an attacker can't get in without the private key, you're still vulnerable to DDOS attacks.

@davidemyers

This comment has been minimized.

Copy link
Contributor

@davidemyers davidemyers commented Jan 2, 2020

PR #1636 moves the SSH port from 22. That should help reduce the probes.

@dan1elhughes

This comment has been minimized.

Copy link
Author

@dan1elhughes dan1elhughes commented Jan 3, 2020

@TC1977

Although an attacker can't get in without the private key, you're still vulnerable to DDOS attacks.

Wouldn't fail2ban mitigate exactly this, by banning the IP? 🙂 It drops them earlier in the process from my understanding, at the firewall level instead of processing their auth and failing there.

@dan1elhughes

This comment has been minimized.

Copy link
Author

@dan1elhughes dan1elhughes commented Jan 3, 2020

@davidemyers Would you (collectively) consider also having fail2ban? Or is moving the port be considered sufficient?

@TC1977

This comment has been minimized.

Copy link
Contributor

@TC1977 TC1977 commented Jan 4, 2020

@TC1977

Although an attacker can't get in without the private key, you're still vulnerable to DDOS attacks.

Wouldn't fail2ban mitigate exactly this, by banning the IP? 🙂 It drops them earlier in the process from my understanding, at the firewall level instead of processing their auth and failing there.

Yes, that's my point exactly.

@davidemyers

This comment has been minimized.

Copy link
Contributor

@davidemyers davidemyers commented Jan 4, 2020

Wouldn't fail2ban mitigate exactly this, by banning the IP?

WireGuard doesn't log failed connection attempts and I don't see a filter for strongSwan in the fail2ban source so I don't think it would help an AlgoVPN for protocols other than SSH.

Algo has its own custom set of firewall rules so there would need to be testing to confirm that fail2ban's rules don't conflict.

Would you (collectively) consider also having fail2ban? Or is moving the port be considered sufficient?

It's not up to me, I just wanted to point out that something was already in the works to cut down on SSH probes.

Also, #1548 was recently implemented to remove sshguard, which is similar to fail2ban, from Google Cloud instances. If you add fail2ban you must take care that it doesn't start doing any banning until the necessary SSH keys are put in place by cloud-init or whatever takes care of it on a particular cloud provider.

@dan1elhughes

This comment has been minimized.

Copy link
Author

@dan1elhughes dan1elhughes commented Jan 5, 2020

I don't think it would help an AlgoVPN for protocols other than SSH

Agree! Sorry, poor clarification on my part - I do mean purely for SSH 🙂

Oh that's super interesting that an SSH blocking feature has been considered and removed already. I'm afraid I wouldn't be confident enough in my cloud-init knowledge to confidently state that adding fail2ban would or wouldn't impact that 🤔

@jackivanov

This comment has been minimized.

Copy link
Collaborator

@jackivanov jackivanov commented Jan 7, 2020

Fail2ban adds no security enhancements in current implementation

@jackivanov jackivanov closed this Jan 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.