579
edits
Changes
Jump to navigation
Jump to search
Line 3:
Line 3: − + Line 38:
Line 38: − + − 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 hexadecimal addresses that spell words - 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 you would start scanning? A DNS with suitable Quad-A entries is your friend in this situation.+ + + + + Line 47:
Line 51: − + − − A '''''starting point''''' for an IPv6 iptables-based firewall can be found in my [[Raspberry_Pi_IPv6_firewall_tester_installation configuration guide.]] − − This website publishes a [http://ipv6.chappell-family.com/html/privacy_policy.html Privacy Policy.] Continued use of this website implies your consent to the storage of data outlined in the policy. + − ---- − <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.
* DHCPv6
* DHCPv6
A full IPv6 address is composed of a network address part (perhaps 64 bits) and a host address part (often 64 bits).
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]
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.
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 my [http://ipv6.chappell-family.com/ipv6tcptest/ IPv6 firewall checker] which checks your IPv6 Ping response and scans a set of user-defined TCP ports.
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.