Open sangaman opened 6 years ago
More efficient in DDOS protection, because destroys socket at very first packet: https://www.indusface.com/blog/7-best-practices-ddos-protection/
https://github.com/ExchangeUnion/xud/issues/616 describes some banning logic per peer, but not per IP address.
Clear what to do here? @sangaman
Yes but it's not on my short list of things to do, I think pushing it back to a further milestone makes sense.
I think if we want to integrate fail2ban into xud we should refine xud log first. Let P2P peer connection/authentication failure exposed as a log line. And we should be able to configure the loggers level in a separated configuration file (I think winston should support). And we could create a project wiki page to describe the fail2ban integration method.
And I saw the other app filters in fail2ban they expose the peer IP directly in the log. We could do that either but when xud running behind a loader balancer the real IP may be hidden somewhere else. So I think we need to let the log IP exposure logic configurable.
I wasn't thinking of actually using fail2ban, although that's probably an option. I was thinking more along the lines of banning IP addresses and immediately terminating connections with them from within xud.
Very good points @reliveyy . I'm supportive of using fail2ban unless there is a better alternative. We would probably end-up with a log-based analysis anyways because storing all sorts of failed connection attempts elsewhere just for banning purposes seems overkill. Please move ahead @reliveyy
As discussed in https://github.com/ExchangeUnion/xud/pull/883#issuecomment-483217186, this needs a separate PR implementing above fail2ban framework to ban IPs exceeding a certain number of bad requests automatically.
As just discussed with @reliveyy , this needs some further research on how fail2ban can properly read our logs. Since this an advanced ddos/spam prevention, not crucial and moved to post-1.0.0.
Makes sense, we would just need to look into how fail2ban can be configured, and then print a distinct log message when we receive spam or invalid inconnection attempts from a certain IP address.
This also should work with .onion addresses too
Offshoot of #185. We want to be able to ban by IP address when a certain IP address spams us with invalid messages or repeatedly fails to complete the handshake. Since IP addresses change, we need not persist this ban permanently. Rather, we can ban for the duration of an xud session or perhaps set a timer to lift the ban after several days.