SANS ISC: Followup to IPv6 brute force and IPv6 blocking

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

My diary earlier this week led to some good discussion in the comments and on twitter. I want to, first off, apologize for not responding as much or as quickly as I would have liked, I've actually been ill most of this week since posting the previous diary (and signing up for this slot as handler on duty). Having said that, the discussion got me thinking about fail2ban (and denyhosts) and how I've used them over the years, which brings me to a number of points I'd like to make and some further discussion I hope we can have. As rightly pointed out, I am sure that the brute forcing I am seeing is not from any scanning but because I setup an IPv6 address in DNS for my wordpress site and the preference for IPv6 over IPv4 if both DNS returns both.. In fact, the attempts to login as 'jim' show that they have at least scraped some content off the site so they thought they could guess at a valid username (in fact, 'jim' is not a valid username on the site, but that is their problem, not mine).

• One suggestion that I got on twitter was to look at blocklistd from BSD-land. This looks interesting, but I'm primarily using Linux at the moment and don't really feel like doing the porting (though if someone else does let me know, I'll be happy to publicize it here). I still need to look further into how it works, but it looked like it required some modification of the daemons in question to support it and this would be a bit of a problem.
• There were also a number of folks on twitter who suggested various rate-limiting schemes using pf or ipfw (or iptables/ip6tables), but that doesn't really solve my problem. I could certainly do that, but I don't necessarily want to limit legit users, I just want to slow/stop the brute forcing attempts. That's why I started using denyhosts way back when and switched over to fail2ban when denyhosts stopped being actively maintained. With fail2ban, as long as I can parse a log file that shows authentication failures, I can then block them for a certain amount of time (and I have a secondary process that if you get banned by fail2ban too often, I move you to a permanent block list and don't worry aobut you ever again). I can do this for all sorts of services, not just ssh, I also use it for SASL (SMTP/TLS and IMAPS) as well as Wordpress (as described in my earlier diary).

All of this, though, I fear shows my IPv4 mindset. I've been using IPv4 for 30+ years and perhaps I'm just trying to force IPv6 into my IPv4 worldview. 

• A question raised by several commenters (on twitter, I believe), is at what level do you want to do that sort of filtering in IPv6? Given that a single host could a huge number of IPv6 addresses (in theory, larger than the entire IPv4 address space), it doesn't make sense to just block a single IPv6 address, we actually probably need to block some block of addresses (perhaps a /64), but how do we decide that?
• Is there a better way to handle this problem in IPv6?

Another commenter on the previous diary was  someone who has reimplemented fail2ban and expanded it to handle IPv6 (and prefixes), this is actually something I'd love to dig further into. 

So, am I thinking about this all wrong? Is there a better way to do this? Should I not bother trying to slow/stop brute forcing and migrate all my authentication to PKI (public key infrastructure) or MFA (multi-factor authentication)? Let me know what you think in the comments, via our contact page, or on social media.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

Join me to learn about Malware Analysis

Upcoming Courses Taught By Jim Clausing

Type	Course / Location	Date
Community SANS	FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques Community SANS Minneapolis FOR610 Minneapolis, MN	Mar 5, 2018 - Mar 10, 2018
Community SANS	FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques Community SANS Columbia FOR610 Columbia, MD	Mar 26, 2018 - Mar 31, 2018