Hacker News Reader

Comment by nousermane | Hacker News Reader

Honestly, I don't understand why people make reporting abuse so hard/labour-intensive.

It is trivial to record netflow data (and most networks do that already), and then verify incoming abuse reports against those records.

View on HN

Because processing abuse tickets is hard and labor intensive. If reporting abuse to a host lead to shutdowns as swiftly as YouTube DMCA it would become a denial of service attack method. Or the abuse ticket queue would be flooded and it would take even longer to cut off bad actors. Cloud services are notorious for abuse traffic. If they were required to raise KYC requirements it might mean the end of $5/mo. VPS. Finally hosting services have an inherent conflict of interest between making money selling service and cancelling someone's account for abuse.

the counterpoint is that the antagonists can abuse the reporting mechanisms, so some friction is necessary

is there a chance of forming some kind of a community fail2ban blocklist? I guess trusting the contributors and admins is the hard part here and that’s why spam lists are a double edged sword?

As someone else mentions, CrowdSec can do just that. It's FOSS and can act as a modern Fail2Ban replacement that can detect all sorts of attacks - in this case ssh bruteforce/slow brute force attacks - and shares very basic information about those attacks (source ip, timestamp, which attack) with everyone else. So in that way everybody using CrowdSec are helping each other out. More information at https://crowdsec.net. Disclaimer: I am head of community at CrowdSec so feel free to ask me any questions you may have here or join our Discord at https://dicord.gg/crowdsec.

Thank you! super cool! how do you solve the trust issue? (e.g. someone reporting their competitor ips as attackers, or whitelisting false positives/appeals)

The CrowdSec folks have something similar to that:

https://crowdsec.net/ https://github.com/crowdsecurity/crowdsec

peter hessler had an interesting system where the blacklists were distributed via bgp. It sounds weird at first but the more I think about it the more it makes sense. delivering routes(or in this case anti routes) is bgp's core mission.

Unfortunately he shut down his bgp spam route sender last year.

http://www.bgp-spamd.net/

That's basically what DNS RBLs are.

Well that and sane people just disable password auth. fail2ban is a 90s sysadmin solution to a nonexistent problem.

Fail2Ban can do more than SSH. Any log that can be parsed and has a useful remote IP can work.

I have it scanning my Ubiquiti NVR logs, I modified Tomcat to log the remote IP from my reverse proxy. If anyone tries to log into my NVR three times then Fail2Ban adds the IP to a permanent blocklist on my OpnSense firewall and then HAProxy kills the TCP connection. They can't even ping after that.

IP reputation is a problem wider then just SSH password brute-forcing - see HTTP(S) brute-force example elsewhere in this thread.

Perhaps VPS providers should monitor for things like huge volumes of outgoing SSH login attempts, the same way they monitor for crypto mining.

Reply on news.ycombinator.com