My next class:

Are you watching for brute force attacks on IPv6?

Published: 2018-01-09. Last Updated: 2018-01-16 17:13:57 UTC
by Jim Clausing (Version: 1)
4 comment(s)

For a number of years, I've had a personal blog that for the last 2 or 3 years has been pretty much dormant. A few years ago, I found a deal for a VPS instance for $5/month and decided to host my blog there using WordPress. One of the nice feature of this particular VPS setup is that it has good IPv6 connectivity, so I registered the IPv6 address in DNS. I use fail2ban to protect ssh against brute forcing, but I wanted to also protect my WordPress site, so I configured it to log all authentication attempts so that I could have fail2ban watch that log. For much of the last year, I've noticed something really odd. The vast majority of attempts against my WordPress site have come over IPv6. Here is a typical summary from the log (thank you logwatch, note, the IPs have NOT been changed to protect the guilty).

    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2001:41d0:2:3ca::: 3 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2403:cb00:cb02:101:100:211:51:0: 1 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f128:22:4121:312:18:412:2500: 1 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:100b::7b:929a: 2 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:100f::76c:545a: 1 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:104b::fc5:7e49: 2 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:110b::6c5:436f: 1 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:115b::40e:3c25: 3 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:115b::b4d:cc90: 5 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:6000::36d:2f48: 1 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:6:a066::c55:8af1: 3 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2a03:6f00:1::5c35:72f5: 2 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 64.13.192.15: 1 Time(s)

We've talked for years about IPv6 and it is a growing percentage of the traffic on the internet, but we haven't really heard about many attacks over IPv6. Clearly, many of the attacks that occur over IPv4 can happen over IPv6 once the bad guys determine that it is worth the effort. Apparently, there are some folks out there who have decided that attacking WordPress is worth the effort. I don't know what kind of ROI (return on investment) they are getting out of it yet, but attacks over IPv6 are only going to increase as we move forward, so we'd better be building up our monitoring and defenses to meet the challenge.

What do you think? Are you monitoring IPv6 to the same extent as IPv4? Are you seeing attacks over IPv6? If so, what? Let us know in the comments or via our contact page.

---------------
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
 
Community SANS Minneapolis FOR610 Minneapolis, MN
Mar 5, 2018 -
Mar 10, 2018

Community SANS
 
Community SANS Columbia FOR610 Columbia, MD
Mar 26, 2018 -
Mar 31, 2018
4 comment(s)
My next class:

Comments

I have been watching IPv6 attacks since 2001, and yes they have been increasing. Over that time I have seen IPv6 tunnel attacks, malware, dual stack botnets, ddos attacks, phishing and direct host attacks. Currently, I run a large dual-stack honeypot network, watching attackers perform all 12 types of IPv6 scanning which target dual-stack and IPv6 only devices.

Currently producing an invite-only IPv6 threat intel feed.

Joe Klein
@joeklein
jsklein@gmail.com
I had to reimplement the ideas embedded in fail2Ban several years ago as a Golang application. I included the concept of network allocation blocking, based on the source IPv6 address allocation by the provider, and mapping IPv6 and IPv4 addresses, allowing me to block both at the same time.

Joe
I think you're maybe reading too much into this?
As adoption grows, a lot of resolvers and tools have grown accustomed to the no-no of forcing an A record to be found. E.g. even ping nowadays doesn't even distinct between ping(4) and ping6 anymore.

All OS's and all resolver libraries I know will, by default, resolve IPv6 addresses if the connectivity and the records are there. Failing any one of those two conditions will make it fall back to IPv4.

You saw this very well on the IPv6 days they held as well, and I've seen it happen customer side too; as soon as you enable IPv6, suddenly the majority of your internet traffic becomes IPv6. Why? The big names all do dual stack these days, and all that traffic switches to IPv6 as soon as the connectivity is there.

So my guess is 'they' are just targeting www.yourdomain.com without explicitly specifying address family (which usually doesn't matter in these kinds of attacks anyway), and doing that on their IPv6 enabled VPS'es/links.
For a blog is there *any* need for standard users to authenticate; or only you when you need to update it?
If it's only you then block access to the admin pages (within the webserver config, reverse proxy/L7 firewall) from anything but localhost.
If you need to admin remotely use SSH port forwarding, and MFA/public key login to SSH.
Then you could control SSH access at a network firewall level; as any collateral damage isn't blocking access to the blog, only to a service that standard users don't need.

If standard users do need to authenticate then MFA is the way to go;
You'll never be able to fully describe the possible sources of malicious traffic without collateral damage:
blocking a network mask is assuming that the entire network is malicious; could just be one bad (or zombie) host (eg. at a university/college campus).
Trying to block a unique host, outside of network context by using a wildcard mask on the last 64-bits (the mac address) can be defeated by IPv6 privacy extensions temporary addresses.
Then there are VPNs, TOR, open-proxies.... etc.

I'm a frequent user of TOR and an exit node, and it's amazing how much of the internet doesn't work properly (esp. all of cloudflare) because it's assumed that TOR connections are inherently malicious.

IP addresses aren't a valid proxy for identity (or intent).

Diary Archives