[wolrah]

They can't get in but they can still fill my logs up, so fail2ban cuts them off after a few failures.

Also by collecting data on the IP addresses that are triggering fail2ban I can identify networks and/or ASes that disproportionally host malicious traffic and block them at a global level.

[tptacek]

Why bother logging them at all? What is this doing for you? You can't meaningfully characterize attacker traffic this way. They'll come from any AS they want to.

[wolrah]

> Why bother logging them at all? What is this doing for you?

Logging both successful and failed requests is important for troubleshooting my systems, especially the client-facing ones (a subset of which are the only ones that are accessible to the open internet), and failed authentication attempts are just one sort of request failure. Sometimes those failures are legitimate client systems where someone misconfigured something, and the logs allow me to troubleshoot that after the fact. That it can also be fed to fail2ban to block attackers is just another benefit.

> You can't meaningfully characterize attacker traffic this way. They'll come from any AS they want to.

Obviously in a world full of botted computers, IoT devices, etc. it's true that an attacker can hypothetically come from anywhere, but in practice at least from the perspective of a small service provider I just don't see that happen. I'm aware that you are involved with much larger scale operations than I'm likely to ever touch so perhaps that's where our experiences differ. No one's targeting my services specifically, they're just scanning the internet for whatever's out there and occasionally happen to stumble upon one of my systems that needs to be accessible to wherever my clients happen to bring their devices.

Sure, I see random domestic residential ISP addresses get banned from individual servers from time to time, but I never see the organized attacks I see which are usually coming from small hosting providers half way around the world from my clients. I have on multiple occasions seen fail2ban fire off rapidly sequential IP addresses like xxx.xxx.xxx.1 followed by xxx.xxx.xxx.2 then xxx.xxx.xxx.3, or in other cases a series of semi-random addresses all in the same subnet, which then triggers my network block and magically they're stopped instead of just moving on to another network. If I were to be packet sniffing on the outside of the relevant firewall I'm sure I'd see another address in the blocked network trying to do its thing but I've never looked.

[Capricorn2481]

> You can't meaningfully characterize attacker traffic this way. They'll come from any AS they want to

I'm not totally following what Fail2Ban has to do with Wireguard. Are we talking strictly about homelabs you don't expose to the internet?

Because I have a homelab I can connect to with Wireguard. That's great. But there are certain services I want to expose to everybody. So I have a VPS that can connect to my homelab via Wireguard and forward certain domain traffic to it.

That's a safe setup in that I don't expose my IP to the internet and don't have to open ports, but I could still be DDOS'd. Would it not make sense for me to use Fail2Ban (or some kind of rate limiting) even if I'm using Wireguard? I can still be DDOS'd.

[hrimfaxi]

Don't compliance regimes like NIST 800-53 require logging access attempts, whether successful or not, and especially for privileged users?

[akerl_]

> To balance monitoring and auditing requirements with other system needs, event logging requires identifying the subset of event types that are logged at a given point in time. For example, organizations may determine that systems need the capability to log every file access successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance.

It's possible that some compliance regimes exist that mandate keeping logs of all unsuccessfully authentication attempts. There's surely a compliance regime out there that mandates every possible permutation of thing.

But the far more common permutation, like we see with NIST, is that the organization has to articulate which logs it keeps, why those logs are sufficient for conducting investigations into system activity, and how it supports those investigations.

[hrimfaxi]

I was thinking of:

> The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are usually temporary and automatically release after a predetermined, organization-defined time period.

https://csf.tools/reference/nist-sp-800-53/r5/ac/ac-7/

[akerl_]

That’s almost always going to be a setting in your IDP, not based on log capture/retention.

The IDP will have some settings for max fails before lockout, and apply it by counting.

[hrimfaxi]

A centralized IDP that touches every service is not mandated by NIST though. So while you are right that an IDP can handle that, the organization may not have the IDP integrated with a given system and you will still need compensating controls or mitigations. Outright incredulity over logging failed access attempts is surprising.