/27 the new /24

Wed Oct 7 20:03:47 UTC 2015

Here is a quick starting point for filtering IPv6 on a Linux host system if
you don't feel comfortable opening up all ICMPv6 traffic:

http://soucy.org/tmp/v6firewall/ip6tables.txt

I haven't really re-visited it in a while, so if I'm forgetting something
let me know.

On Wed, Oct 7, 2015 at 9:13 AM, Stephen Satchell <list at satchell.net> wrote:

> This is excellent feedback, thank you.
>
> On 10/07/2015 04:54 AM, Owen DeLong wrote:
>
>>
>> On Oct 4, 2015, at 7:49 AM, Stephen Satchell <list at satchell.net> wrote:
>>>
>>> My bookshelf is full of books describing IPv4. Saying "IPv6 just
>>> works" ignores the issues of configuring intelligent firewalls to block
>>> the ne-er-do-wells using the new IP-level protocol.
>>>
>>
>> You will need most of the same blockages in IPv6 that you needed in IPv4,
>> actually.
>>
>> There are some important differences for ICMP (don’t break PMTU-D or
>> ND), but otherwise, really not much difference between your IPv4
>> security policy and your IPv6 security policy.
>>
>> In fact, on my linux box, I generate my IPv4 iptables file using
>> little more than a global search and replace on the IPv6 iptables
>> configuration which replaces the IPv6 prefixes/addresses with the
>> corresponding IPv4 prefixes/addresses. (My IPv6 addresses for things
>> that take incoming connections have an algorithmic map to IPv4 addresses
>> for things that have them.)
>>
>
> On my box, I have a librry of shell functions that do the generation,
> driven by parameter tables.  If I'm reading you correctly, I can just
> augment the parameter tables and those functions to generate the
> appropriate corresponding ip6table commands in parallel with the iptable
> commands.
>
> Question: should I still rate-limit ICMP packets in IPv6?  Also, someone
> on this list pointed me to NIST SP800-119, "Guidelines for the Secure
> Deployment of IPv6", the contents of which which I will incorporate.
>
> There is limited IPv6 support in many of the GUIs still,
>> unfortunately, but the command line tools are all there and for the
>> most part work pretty much identically for v4 and v6, the difference
>> often being as little as ping vs ping6 or <command> <args> vs.
>> <command> -6 <args>.
>>
>
> I've not been happy with the GUIs, because getting them to do what I want
> is a royal pain.  For example, I'm forced to use port-based redirection in
> one edge firewall application -- I blew a whole weekend figuring out how to
> do that with the CentOS 7 firewalld corkscrew, for a customer who outgrew
> the RV-220 he used for the application.  At least that didn't need IPv6!
>
> Primarily it involves changing the IPv4 addresses and/or prefixes
>> into IPv6 addresses and/or prefixes.
>>
>
> What about fragmented packets?  And adjusting the parameters in ip6table
> filters to detect the DNS "ANY" requests used in the DDoS amplification
> attacks?
>
> I'm not asking NANOG to go past its charter, but I am asking the
>>> IPv6fanatics on this mailing list to recognize that, even though the net
>>> itself may be running IPv6, the support and education infrastructure is
>>> still behind the curve. Reading RFCs is good, reading man pages is good,
>>> but there is no guidance about how to implement end-network policies in
>>> the wild yet...at least not that I've been able to find.
>>>
>>
>> There is actually quite a bit of information out there. Sylvia
>> Hagen’sIPv6 book covers a lot of this (O’Reilly publishes it).
>>
>
> Um, that would be "books".  Which one do you recommend I start with?
>
> * IPv6 Essentials (3rd Edition), 2014, ASIN: B00RWSNEKG
> * Planning for IPv6 (1st Edition), 2011,  ISBN-10: 1449305393
>
> (I would assume the first, as the NIST document probably covers the
> contents of the second)
>
> There are also several other good IPv6 books.
>>
>
> Recommendations?
>
> "ipv6.disable" will be changed to zero when I know how to set the
>>> firewall to implement the policies I need to keep other edge networks
>>> from disrupting mine.
>>>
>>
>> You do. You just don’t realize that you do. See above.
>>
>
> That's encouraging.  Being able to leverage the knowledge from IPv4 to
> project the same policies into IPv6 makes it easier for me, as I'm already
> using programmatic methods of generating the firewalls.  I expected that
> the implementation of existing applications-level policies would be
> parallel; it's the policies further down the stack that was my concern.
>
> Also, I have a lot of IP level blocks (like simpler Cisco access control
> lists) to shut out those people who like to bang on my SSH front door. I
> believe that people who are so rude as to try to break through dozens or
> hundreds of time a day will have other bad habits, and don't deserve to be
> allowed for anything.  (I have similar blocks for rabid spammers not in the
> DNSBLs, but that's a different story.)  I would expect to maintain a
> separate list of IPv6 subnets, based on experience.
>
> Which brings up another question:  should I block IPv6 access to port 25
> on my mail servers, and not announce a AAAA record for it?  Postfix handles
> IPv6, but I've seen discussion that e-mail service is going to be IPv4 only
> for quite a while.  Should I even enable IPv6 on my mail server at this
> time?  Or is that a question I should post elsewhere?
>
> As an aside, my day job is converting to Python programming, so my first
> Python project may well be the conversion of my existing firewall generator
> into that language.
>
>

-- 
*Ray Patrick Soucy*
Network Engineer I
Networkmaine, University of Maine System US:IT

207-561-3526