Well, this is annoying. After setting up my blog, checking out the variety of log files the web server generates, I have to find out that my WordPress instance is subject to a slow but constant brute force attack, trying to weasel its way into the administration interface.
Yeah, this is why we can’t have nice things.
Late September, my Internet service provider finally enabled native IPv6 to all their customers that are using their newest DSL modem. I figured that might be a nice venue for access control for the next few years.
The current advantage of using IPv6 right now is the rather low usage and penetration of it. This brings sort of an aspect of security through obscurity. The majority of end users, whose computers usually make up botnets, are still running IPv4 due to lack of support by their ISPs and also modem hardware. By restricting access to various parts of a webserver to IPv6 only addresses, you’re essentially taking the wind out of the sails of various attackers.
Additionally, address assignments in IPv6 are purely hierarchical. Starting from continental address registries with their own prefixes, they’re assigning sub-prefixes to service providers who again distribute sub-sub-prefixes to companies and end users. This allows for easy filtering at a continental, as well as service provider level. The chaotic address allocations with IPv4 made it hard to set up such filters, because you had to go out and figure out all the different allotments a certain service provider may use to create a proper whitelist. At least if you’re sitting on a dynamic IP address at home, anyway, and don’t want to lock yourself out occasionally.
Security measurements I’ve currently taken on my own dedicated box consists of configuring SSH to listen on IPv6 only (its logfiles are blowing up, too), plus additional ip6tables rules restricting all SSH access to addresses originating from my provider’s network only, blackholing everything else.
ip6tables -P INPUT -DROP ... ip6tables -A INPUT -s 2a02:a000::/26 -p tcp --dport 22 -m state --state NEW -j ACCEPT
And furthermore, I configured Apache to do something similar to various parts of the WordPress blog of mine. For one blocking access to the wp-login.php script, and for another, block all of the /wp-admin directory. While this returns 403 errors instead of blackholing the requests, at least no one’s getting to POST any whacky data to the scripts.
<Files wp-login.php> Order allow,deny Allow from 2a02:a000::/26 </Files> <Directory /web/tomservoeu/wp-admin> Order allow,deny Allow from 2a02:a000::/26 </Directory>
As long IPv6 traffic remains a fraction of the total Internet traffic, there’s a huge barrier of entry to pass. Given how old the IPv6 protocol is right now and what effort and time it took to get initial deployments started, I’d wager there are a few years this can act as an effective barrier.
And even if at some point all traffic were IPv6, there’s still an effective filter running, locking access to a single network only, containing the potential pool of botnet zombies a damn lot.
Of course, this doesn’t mean you shouldn’t harden your servers and stop installing patches and updates.
Because screw hackers…