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@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@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