Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If somebody has a stolen credential, they aren’t going to be brute forcing at all. Likewise that CVE wouldn’t be attacked by a brute force attack.

But I see you’ve backpedaled to this being about log noise, not security.



Threat detection is a higher security priority than prevention in my experience.

One may believe whatever they like, as both our intentions are clear friend.

Have a wonderful day =3


It's weird to assign them comparatively like that but also, what does that have to do with fail2ban?

The roving spam it blocks are not threats, and stolen credentials aren't going to be detected by it.


In general, bots/worms/clowns will first check if a host/router is already infected or vulnerable to a shim. Thus, tripwires on those checks or URI often auto-ban infected/hostile hosts before a scan fully escalates to a successful payload. Note, people don't want a VM delta-snapshot of their zero-day around for automated analysis.

99.98% of hostile traffic simply reuse already published testing tools, or services like Shodan to target hosts.

One shouldn't waste resources guessing the motives behind problem traffic. =3


You're just sort of loosely interweaving unrelated comments?

You're back on prevention instead of detection, but also no: an attacker with valid creds isn't going to run other checks first before using them.

And yes: by volume, most attacks on the internet are just spam reusing published tools and IP lists. And that traffic is zero percent risky unless your auth is already busted.


> And that traffic is zero percent risky unless your auth is already busted

Well it's a waste of our time and resources. I'm not just going to let people make 100 requests per second for no reason?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: