579
edits
Changes
Jump to navigation
Jump to search
Line 3:
Line 3: − + Line 10:
Line 10: − + Line 25:
Line 25: − + − + + + + + + + + + + + + + + + + + + − If you wish to verify the operation of your IPv6 firewall then try my [http://ipv6.chappell-family.com/ipv6tcptest/ IPv6 firewall checker] (IPv6 Ping response tester and TCP port scanner).+ − + + − ---- − <adsense>1</adsense>+
→Testing your IPv6 Firewall
===General Observations===
===General Observations===
IPv6 firewalls are separate from, and often control network traffic in different ways, to current IPv4 firewalls. IPv4 has evolved from its original flat architecture to involve multiple layers of hierarchy in order to support the burgeoning number of nodes that make up the internet. Not only can the imposed hierarchy offer some security in itself but clients have often relied on their online visibility and security being provided by another node (e.g. an ADSL router). This assumed protection, and the likelihood that it is missing if you connect your client to a foreign (non-home) network, is behind the frequently reported incidents of "coffee shop" wifi attacks.
IPv6 firewalls are separate from, and often control network traffic in different ways to, current IPv4 firewalls. IPv4 has evolved from its original flat architecture to involve multiple layers of hierarchy in order to support the burgeoning number of nodes that make up the internet. Not only can the imposed hierarchy offer some security in itself but clients have often relied on their online visibility and security being provided by another node (e.g. an ADSL router). This assumed protection, and the likelihood that it is missing if you connect your client to a foreign (non-home) network, is behind the frequently reported incidents of "coffee shop" wifi attacks.
* Clients may have globally routable IPv6 addresses
* Clients may have globally routable IPv6 addresses
* Clients may be solely responsible for their own security/firewall protection
* Clients may be solely responsible for their own security/firewall protection (safest to assume this is the case for both IPv6 and IPv4)
* Clients may have more than one active IPv6 address
* Clients may have more than one active IPv6 address
* Clients may frequently change their IPv6 address if using privacy addresses, as per [http://tools.ietf.org/html/rfc4941 RFC4941]
* Clients may frequently change their IPv6 address if using privacy addresses, as per [http://tools.ietf.org/html/rfc4941 RFC4941]
As a consequence of all of the above changes it is imperative that you ''ensure that your IPv6-enabled client devices have their IPv6 firewall enabled'', and it is protecting the services running on your client. It is also advisable to disable any IPv6 services that you do not require (e.g. tunneling protocols that you are not actively using - this is especially applicable to Windows 7 clients).
As a consequence of all of the above changes it is imperative that you '''ensure that your IPv6-enabled client devices have their IPv6 firewall enabled''', and it is protecting the services running on your client. It is also advisable to disable any IPv6 services that you do not require (e.g. tunneling protocols that you are not actively using - this is especially applicable to Windows 7 clients).
One other change IPv6 introduces compared to IPv4 is that additional ICMP traffic flows are necessary for normal protocol signalling whereas it was predominantly used for error-case reporting in IPv4 networks. This requires IPv6 firewalls to admit certain [[ICMPv6_Types_Codes]] in order to handle IPv6 address allocation, neighbour discovery and several other IPv6 processes. For many client devices this will be handled directly by the firewall itself, but if you are developing your own IPv6 firewall then you need to ensure you follow the recommendations in [http://www.ietf.org/rfc/rfc4890.txt RFC4890] which includes an ip6tables packet filter example.
One other change IPv6 introduces compared to IPv4 is that additional ICMP traffic flows are necessary for normal protocol signalling whereas it was predominantly used for error-case reporting in IPv4 networks. This requires IPv6 firewalls to admit certain [[ICMPv6_Types_Codes]] in order to handle IPv6 address allocation, neighbour discovery (IPv6 replacement for ARP) and several other IPv6 processes. For many client devices this will be handled directly by the firewall itself, but if you are developing your own IPv6 firewall then you need to ensure you follow the recommendations in [http://www.ietf.org/rfc/rfc4890.txt RFC4890] which includes an ip6tables packet filter example.
===IPv6 Addresses===
One other observation relates to the selection of an IPv6 address for your host. There are three main IPv6 address allocation approaches:
* Static unicast address allocation
* Stateless Address Autoconfiguration (SLAAC)
* DHCPv6
A full IPv6 address is composed of a network address part (perhaps 64 bits) and a host address part (often 64 bits). Dependant upon the scheme that your host uses you '''may''' be able to freely select the host address part - e.g. when using static address allocation. Despite what you may find written elsewhere you are only safe from IPv6 port scans if the address of your machine is not easily discoverable within its IPv6 subnet. On this basis I suggest that you fight the urge to allocate easy to type/remember addresses (e.g. <network-address-part>::1 and any that use a mix of frequently used hexadecimal addresses that spell words - i.e. 0xdead, 0xbeef, 0xface). Many machines appear to use such allocations in their host address part and if you were writing an IPv6 port scanner then surely addresses using such choices would be the place that you would start scanning? A DNS with suitable Quad-A entries is your friend in this situation.
Other useful links:
* [https://tools.ietf.org/id/draft-ietf-opsec-v6-12.html Operational Security Considerations for IPv6 Networks]
* [https://tools.ietf.org/html/rfc7707 Network Reconnaissance in IPv6 Networks]
===Testing your IPv6 Firewall===
===Testing your IPv6 Firewall===
As well as ensuring that your IPv6 firewall is enabled it is '''''strongly recommended''''' that you actively test that it is correctly protecting your host. I have received feedback from several disgruntled users detailing how their default firewall settings either weren't blocking any IPv6 traffic at all (e.g. some DLINK IPv6 enabled products and certain UK ISP-provided firewalls) or were leaving critical services open for remote access. That is not to say that any of these products are necessarily "broken", or "unfit for purpose", merely that they don't necessarily perform in the same way for IPv6 traffic as they did for IPv4 traffic.
If you wish to verify the operation of your IPv6 firewall then try the [https://ipv6.chappell-family.com/ipv6tcptest/ IPscan IPv6 firewall checker] which checks your machine's IPv6 Ping response and scans a set of UDP ports and user-defined TCP ports.
A '''''starting point''''' for an IPv6 iptables-based firewall can be found in the [[Raspberry_Pi_IPv6_firewall_tester_installation]] section.
This website publishes a Privacy Policy (link at the bottom of every page). Continued use of this website implies your consent to the use of data outlined in the policy.