Are you watching for brute force attacks on IPv6?
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
| Reverse-Engineering Malware: Malware Analysis Tools and Techniques | Coral Gables | Nov 18th - Nov 23rd 2024 |
Comments
Currently producing an invite-only IPv6 threat intel feed.
Joe Klein
@joeklein
jsklein@gmail.com
Anonymous
Jan 18th 2018
6 years ago
Joe
Anonymous
Jan 18th 2018
6 years ago
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.
Anonymous
Jan 18th 2018
6 years ago
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).
Anonymous
Jan 20th 2018
6 years ago