SANS ISC: Followup to IPv6 brute force and IPv6 blocking - Internet Security | DShield

• SANS Site Network
  • Current Site
  • 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 blacklistd 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

I will be teaching next: Malware Reverse-Engineering Challenge - Community SANS Seattle FOR610

For a long time now I've been successfully using iptables "-m recent" as a means for limiting access from strangers. "-m recent --rcheck --seconds 90 --hitcount 1" gives a would be hacker one try to login every 90 seconds or so. That tends to put a severe hitch in their attempts to crack into the system. A distributed attack can still be a problem. But that's true with fail2ban and other such scripted solutions.

I like this technique's tidiness as it's all part of iptables itself not any externally mounted script reading logs. And it's only a minor irritant if I typo my password when on the road. I do this for ssh, pop3s, and imaps access.

{^_^}