Nginx – Name-Based Virtual Hosts on IPv6

With IPv6, I don't think there is a perfect solution. But there are a number of things to consider:

• ISPs will likely give out /64 subnets to individual customers. (There will be enough to go around.)
• Workplaces will likely have at least one /64 per office.
• ISPs offering strictly point-to-point links may choose use to use prefixes between /64 and /126. (See why they aren't using /127 in general) This would probably be either a short-sighted ISP, or one who wants to charge more for a full /64. There is really no reason that each endpoint (which could be a full customer network) should not be a /64.
• Assuming most IPv6 end-user subnets will be on a /64, one could look at bit 6 in the interface identifier (see section 3.2.1 of RFC 4941) to check if it was likely generated based on a globally unique identifier (MAC address). This isn't foolproof, obviously. But if this bit is set, likely indicates that the address was generated from a MAC address. So one could block IPv6 addresses based on the last 64 bits, and users could be blocked no matter which subnet they come from. (Maybe best to use this as a "hint" since MAC addresses, while supposed to be globally unique, in practice aren't always. Plus they are easily spoofed. But anyone savvy enough to go to the trouble would probably find it easier to grab a /64 and get 2^64 unique addresses anyway.)
• If privacy addresses are in use... not much to do except block that one address for a short time. It'll likely change soon anyway. Factor in the network part of the /64 at this point, but be wary since you might be blocking someone's entire corporate office.

I would say that the best way would be to look first at individual addresses, then factor in the last 64 bits of the address, and patterns of abuse from particular /64 subnets in order to implement a blocking strategy. To summarize:

• Start by blocking individual /128 IP addresses (like you probably do today with IPv4)
• If you notice a pattern of abuse from a non-privacy address in the last 64 bits of an address, use that as a strong indicator in your blocking algorithm. Someone could be hopping between ISPs or subnets. (again, be careful with this since MACs are not necessarily unique - someone could be spoofing to exploit your algorithm) Also, this would only work against abusers who don't know how IPv6 works. ;-)
• If you notice a pattern of abuse from a particular /64, block the entire /64 with a good error message so the offending network's administrator can do whatever work needs to be done on his/her end.

Good luck.

I'm already doing this, and have been for some time, using munin and a custom plugin I wrote myself, which gets data from iptables audit rules. It's running on a C6 box so you should be able to fork-lift it into place if no-one has any better ideas. It's not the simple one-liner you wanted, but it's working, and produces data like these:

The plugin is simple enough, it just takes data from two flat files created in /var/tmp:

#!/bin/bash
#
# (c) Gatekeeper Technology Ltd., 2013
# May be used under the terms of GPLv3 or, at your discretion, any later version

if [ "$1" = "config" ]; then

    echo 'graph_title Network Throughput'
    echo 'graph_category network'
    echo 'graph_info This is the total throughput on the NIC since the beginning of the calendar month, or the last reboot, whichever was mo
st recent.'
    echo 'graph_vlabel bytes'
    echo 'graph_args --logarithmic'
    echo 'in4.label       in v4'
    echo 'in4.colour      ff0000'
    echo 'out4.label      out v4'
    echo 'out4.colour     00ff00'
    echo 'in6.label       in v6'
    echo 'in6.colour      aa0088'
    echo 'out6.label      out v6'
    echo 'out6.colour     00aa88'
    echo 'total.label     total'
    echo 'total.colour    0000ff'
    exit 0
fi

out=`head -3 /var/tmp/audit.out.counts | tail -1 | awk '{print $2}'`
echo "out4.value $out"
in=`head -3 /var/tmp/audit.in.counts | tail -1 | awk '{print $2}'`
echo "in4.value $in"

out6=`head -3 /var/tmp/audit.out.v6.counts | tail -1 | awk '{print $2}'`
echo "out6.value $out6"
in6=`head -3 /var/tmp/audit.in.v6.counts | tail -1 | awk '{print $2}'`
echo "in6.value $in6"

total=$(($in+$out+$in6+$out6))
echo "total.value $total"

The crontab entry that makes them looks like this:

# output the audit rule counts for munin purposes
* * * * *  /sbin/iptables  -L AUDIT-I -n -x -v > /var/tmp/audit.in.counts
* * * * *  /sbin/iptables  -L AUDIT-O -n -x -v > /var/tmp/audit.out.counts
* * * * *  /sbin/ip6tables -L AUDIT-I -n -x -v > /var/tmp/audit.in.v6.counts
* * * * *  /sbin/ip6tables -L AUDIT-O -n -x -v > /var/tmp/audit.out.v6.counts
# and zero the counts once a month
0 0 1 * *  /sbin/iptables  -Z AUDIT-I
0 0 1 * *  /sbin/iptables  -Z AUDIT-O
0 0 1 * *  /sbin/ip6tables -Z AUDIT-I
0 0 1 * *  /sbin/ip6tables -Z AUDIT-O

and the iptables rules are made with the following /etc/sysconfig/iptables rules:

:AUDIT-I - [0:0]
:AUDIT-O - [0:0]
# audit input traffic
-A INPUT -i eth0 -j AUDIT-I
 [ALL OTHER INPUT RULES APPEAR HERE, AFTER THE AUDIT RULE]
# audit outbound traffic
-A OUTPUT -o eth0 -j AUDIT-O
 [ALL OTHER OUTPUT RULES APPEAR HERE, AFTER THE AUDIT RULE]
# AUDIT rules
-A AUDIT-I -p all
-A AUDIT-O -p all

The reason crontab is involved is to stop the munin plugin needing to run with root privileges; if you didn't mind it doing that, you could have the plugin get the packet counts directly, by invoking iptables itself.

The counts don't survive a reboot (hence the extra drop down to zero in the graph above), but if you have your server set up to save iptables rules and packet counts on reboot, this wouldn't affect you.