Hi all, I want IPv6 experience. Our main link at work is Internode, so I can get native IPv6. I want an isolated test net that can talk IPv6 to the internet, without leaking IPv6 into my production network. I think I can do this by simply enabling IPv6 in the bastion's kernel, and dropping IPv6 packets that aren't going between the test net and the internet. Is this safe? Can IPv6 leak into my production net? More details follow ------------------- I have a /24 IPv4 network with Internode. My router (known as Alpha) is a full Ubuntu Lucid server with 4 downstream interfaces (each serving a public /26) and 2 upstream ppp connections. (ppp0 is Internode, ppp1 is an irrelevent backup Exetel link.) | cyber@alpha:~$ ip link | 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 | 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 | link/ether 1c:6f:65:c6:47:46 brd ff:ff:ff:ff:ff:ff | 3: managed: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 | link/ether 00:1b:21:b6:65:99 brd ff:ff:ff:ff:ff:ff | 4: unmanaged: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 | link/ether 00:1b:21:b6:65:98 brd ff:ff:ff:ff:ff:ff | 5: dmz: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 | link/ether 00:1b:21:b6:65:9b brd ff:ff:ff:ff:ff:ff | 6: scratch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 | link/ether 00:1b:21:b6:65:9a brd ff:ff:ff:ff:ff:ff | 518: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3 | link/ppp | 542: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3 | link/ppp IPv6 is disabled in Alpha's kernel. I want to give Alpha an extra network interface called "ip6test" (or rename eth0 above) and have IPv6 passed through (and completely *isolated*) to the network segment connected to that NIC. The top priority is ensuring that Alpha and the 4 IPv4 subnets (managed, unmanaged, dmz, and scratch) all drop IPv6 packets until I've more IPv6 experience. Here's what I *think* is required, but I'm looking for a second opinion: | #!/usr/sbin/ip6tables-apply | *filter | :OUTPUT ACCEPT # Local users/processes are trusted. | :INPUT DROP # Ingress policy is "default deny". | :FORWARD DROP # Routing policy is "default deny". | :PRELUDE - # Best practices for filtered chains. | | ## Quickly handle the essentials of a "default deny" environment. | ## Anything left after this chain implicitly has --ctstate NEW. | -A INPUT -j PRELUDE | -A FORWARD -j PRELUDE | -A PRELUDE -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT | -A PRELUDE -m conntrack ! --ctstate NEW -j DROP -m comment --comment "Same as --ctstate INVALID." | -A PRELUDE -o ip6test -p icmp -j ACCEPT -m comment --comment "For now, only allow ICMP to test network" | -A PRELUDE -i lo -j ACCEPT | | ## YOUR RULES GO HERE | -A FORWARD -o ip6test -p tcp --dport ssh -j ACCEPT -m comment --comment "Allow IPv6 SSH traffic to test network" | | ## Finally, politely reject all other attempts. Omit these to use the | ## chains' default policies (DROP, above) instead. | -A INPUT -j REJECT | -A FORWARD -j REJECT | COMMIT So I expect, having enabled IPv6 in Alpha's kernel, Alpha gets an IPv6 address on ppp0, but due to the above firewall, IPv6 traffic not from/to ip6test will be rejected. Due to the PRELUDE chain, ICMPv6 will be allowed to machines connected to the ip6test interface, all of which I expect toobtain an IPv6 address. The FORWARD chain will allow direct SSH to those machines. Assuming all the above is suitably secure, I then expect to carefully open more IPv6 access up to the ip6test interface for further testing. Further, will I need radvd or similar on Alpha, or will it be good enough to handle that on another box connected to the ip6test interface, or let Internode deal with it? How does this all sound? -- Regards, Matthew Cengia
Hi, IPv6 operation is dependent upon ICMPv6 working (for RA, RS, ND, DAD, PMTUD, ...) So, I think it is essential that you allow ICMPv6 in on ppp0 to Alpha. Also, you will want to allow ICMPv6 in on ip6test to Alpha and allow forwarding of ICMPv6 from ip6test to ppp0. etc etc. === In short, I think you are trying too hard to filter traffic (before you know how it all works), and will likely end up with an IPv6 system that doesn't work, or doesn't work well. I would control traffic by giving ppp0, ip6test, and lo interfaces IPv6 addresses, and not giving IPv6 addresses to the interfaces you do not want to send/receive IPv6 traffic. Alpha won't send IPv6 traffic out the other interfaces if it doesn't have a route pointing out there. Also, without IPv6 enabled, it won't receive IPv6 packets on those interfaces. You probably want to use DHCPv6 Prefix Delegation to communicate with Internode to find your allocated IPv6 prefix (so need to allow some IPv6 UDP in and out on ppp0). How about DNS over IPv6? If you give a test host an IPv6 address, but DNS traffic over IPv6 times out, it could be seconds before the host retries over IPv4. I would recommend running radvd on Alpha, so that hosts on ip6test will learn that Alpha is their default router. John On 12 June 2013 14:27, Matthew Cengia <mattcen@gmail.com> wrote:
Hi all,
I want IPv6 experience. Our main link at work is Internode, so I can get native IPv6. I want an isolated test net that can talk IPv6 to the internet, without leaking IPv6 into my production network.
I think I can do this by simply enabling IPv6 in the bastion's kernel, and dropping IPv6 packets that aren't going between the test net and the internet.
Is this safe? Can IPv6 leak into my production net?
More details follow -------------------
I have a /24 IPv4 network with Internode. My router (known as Alpha) is a full Ubuntu Lucid server with 4 downstream interfaces (each serving a public /26) and 2 upstream ppp connections. (ppp0 is Internode, ppp1 is an irrelevent backup Exetel link.)
| cyber@alpha:~$ ip link | 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 | 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 | link/ether 1c:6f:65:c6:47:46 brd ff:ff:ff:ff:ff:ff | 3: managed: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 | link/ether 00:1b:21:b6:65:99 brd ff:ff:ff:ff:ff:ff | 4: unmanaged: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 | link/ether 00:1b:21:b6:65:98 brd ff:ff:ff:ff:ff:ff | 5: dmz: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 | link/ether 00:1b:21:b6:65:9b brd ff:ff:ff:ff:ff:ff | 6: scratch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 | link/ether 00:1b:21:b6:65:9a brd ff:ff:ff:ff:ff:ff | 518: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3 | link/ppp | 542: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3 | link/ppp
IPv6 is disabled in Alpha's kernel. I want to give Alpha an extra network interface called "ip6test" (or rename eth0 above) and have IPv6 passed through (and completely *isolated*) to the network segment connected to that NIC. The top priority is ensuring that Alpha and the 4 IPv4 subnets (managed, unmanaged, dmz, and scratch) all drop IPv6 packets until I've more IPv6 experience.
Here's what I *think* is required, but I'm looking for a second opinion:
| #!/usr/sbin/ip6tables-apply | *filter | :OUTPUT ACCEPT # Local users/processes are trusted. | :INPUT DROP # Ingress policy is "default deny". | :FORWARD DROP # Routing policy is "default deny". | :PRELUDE - # Best practices for filtered chains. | | ## Quickly handle the essentials of a "default deny" environment. | ## Anything left after this chain implicitly has --ctstate NEW. | -A INPUT -j PRELUDE | -A FORWARD -j PRELUDE | -A PRELUDE -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT | -A PRELUDE -m conntrack ! --ctstate NEW -j DROP -m comment --comment "Same as --ctstate INVALID." | -A PRELUDE -o ip6test -p icmp -j ACCEPT -m comment --comment "For now, only allow ICMP to test network" | -A PRELUDE -i lo -j ACCEPT | | ## YOUR RULES GO HERE | -A FORWARD -o ip6test -p tcp --dport ssh -j ACCEPT -m comment --comment "Allow IPv6 SSH traffic to test network" | | ## Finally, politely reject all other attempts. Omit these to use the | ## chains' default policies (DROP, above) instead. | -A INPUT -j REJECT | -A FORWARD -j REJECT | COMMIT
So I expect, having enabled IPv6 in Alpha's kernel, Alpha gets an IPv6 address on ppp0, but due to the above firewall, IPv6 traffic not from/to ip6test will be rejected. Due to the PRELUDE chain, ICMPv6 will be allowed to machines connected to the ip6test interface, all of which I expect toobtain an IPv6 address. The FORWARD chain will allow direct SSH to those machines.
Assuming all the above is suitably secure, I then expect to carefully open more IPv6 access up to the ip6test interface for further testing.
Further, will I need radvd or similar on Alpha, or will it be good enough to handle that on another box connected to the ip6test interface, or let Internode deal with it?
How does this all sound?
-- Regards, Matthew Cengia
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCgAGBQJRt/imAAoJEHp+N/M7InLoCsYP/3N2ggaKr3lp4Qi1O5NRz/fQ HAu5WniE6q/DOrDK8QUvXxtGlISyT0SutVkSewNrGuyMWutLspoI4c0dTUrm7q9J 7I5tjfOt/3p2lAhrF1PgdV/zmrtdeoyNYCcFOH202cSeitFUqjRc5MSSD1F5RC5o v+bG3ZTBj7gNZy+05oSAMAX2OQsrU6tZRHOJy7jaYWTLcdRjI9jwNIwr7gg/coFf xXO2ZBgcvSGmwkl707oVnJkbMkrM/PgV0UVPCnCcyN4tXLRu7M98OkiNAFnKvu0Q C7kLF65aOC4zBfnCFMUjdN+Cg6Pa3yWuvdkxdE5hW/LbEVGze5jwMEoVsvR8mxxk fC5hIcIkKLUyx6VVv5iSAyqWMnV5jZSzLVjycsSE2GOC2qpucszb5V7oVrEdrUwc G1XZXlcbn+HVLTBidBsQ7NU3KGi7PQXvAgeBiXLVOYYijE9btFlVJflepdBKfxig d6zA46Cf+MIlOb4LPmMhcK37SibPzxTItUqCEvHCevbUKXeHdNLFxOHh+mNNFAJ2 AWAOFKbdPiBsgCah+XRYIMYi/fNEsiz9RWMsRNJGjahmKqBgHer3hdrMWavpNkgM TBV5OCzkvMyr0K4rG4jGmIAudQQoqR18EQdxANUpQxVZ46fWycKqhxUs9BKQsBSb pTMYKe0Lm1NsQd/wnh6n =/F6W -----END PGP SIGNATURE-----
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Hi John, thanks for your response. On 2013-06-12 14:56, John Mann wrote: [...]
I would control traffic by giving ppp0, ip6test, and lo interfaces IPv6 addresses, and not giving IPv6 addresses to the interfaces you do not want to send/receive IPv6 traffic.
Alpha won't send IPv6 traffic out the other interfaces if it doesn't have a route pointing out there. Also, without IPv6 enabled, it won't receive IPv6 packets on those interfaces.
How can I prevent these other interfaces obtaining IPv6 addresses if these are being auto-configured via route advertisements etc.? Assuming that's achievable reliably, I agree this is probably the best way to ensure my primary FR: keeping my downstream IPv4 networks secure.
You probably want to use DHCPv6 Prefix Delegation to communicate with Internode to find your allocated IPv6 prefix (so need to allow some IPv6 UDP in and out on ppp0).
I've not read up on DHCPv6 at all yet, so will need to do so before I can fully understand the ramifications of the above paragraph
How about DNS over IPv6? If you give a test host an IPv6 address, but DNS traffic over IPv6 times out, it could be seconds before the host retries over IPv4.
This is true; as I said though, I'm prepared to open up other access (such as DNS) to ip6test, and DNS would be one of the first candidates.
I would recommend running radvd on Alpha, so that hosts on ip6test will learn that Alpha is their default router.
Right. The upcoming concern is going to be taking sufficient care when configuring IPv6 stuff on Alpha to prevent accidental interruption of the IPv4 traffic. I'll do some more research. I may be able to set up a test system (e.g. using 6to4 upstream of a "test Alpha") just to get the config right before deploying on the production box. -- Regards, Matthew Cengia
Matthew Cengia <mattcen@gmail.com> wrote:
How can I prevent these other interfaces obtaining IPv6 addresses if these are being auto-configured via route advertisements etc.? Assuming that's achievable reliably, I agree this is probably the best way to ensure my primary FR: keeping my downstream IPv4 networks secure.
Let's see if this clarifies the situation. My machine has native IPv6 from Internode. ppp0 is the ADSL link (it's a Traverse Technologies Solos card). DHCPv6 prefix delegation is used to obtain a /56 block of IPv6 addresses and to assign a /64 block to the eth0 interface. I then have radvd configured to send router advertisements out eth0; this entails that every machine on the LAN accessible from eth0 will receive a publicly routable IPv6 address, with my primary host as the gateway. radvd.conf looks like this: interface eth0 { AdvSendAdvert on; prefix ::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; }; Apologies for the indentation - let's fix that. Now obviously, if there were an eth1 interface it wouldn't receive an IPv6 address unless I configured it to do so. Even if I did that, I would have to add an entry to radvd.conf before machines connected to eth1 would start receiving v6 addresses. In case you're interested, in /etc/wide-dhcpv6/dhcp6c.conf is as follows: interface ppp0 { send ia-pd 0; # script "/etc/wide-dhcpv6/dhcp6c-script"; }; id-assoc pd { prefix-interface eth0 { sla-id 0; sla-len 8; ifid 2; }; }; We receive a /56 block from the ISP and assign a /64 to eth0 (with all 0 bits in the network part of the address, i.e., bits 56-64). We then have a host address with 2 as the last digit, and the rest 0 (for historical reasons - I used to have another machine ending in ::1) which served as the router back then. Putting this together we have eth0 with 2001:44b8:412f:6e00::2 and ppp0 with a link local address, and a default route which is in fact the host at the other end of the PPP link (it's point-to-point, after all).
John Mann <john.mann@monash.edu> writes:
I would control traffic by giving ppp0, ip6test, and lo interfaces IPv6 addresses, and not giving IPv6 addresses to the interfaces you do not want to send/receive IPv6 traffic.
IME if you enable IPv6 in the kernel, EVERY up interface will have an IPv6 address (the link-local one, I suppose).
Also, without IPv6 enabled, it won't receive IPv6 packets on those interfaces.
Are you asserting that if IPv6 is enabled in-kernel, but an interface has no IPv6 address, IPv6 traffic arriving on that interface will be dropped on the floor? What about broadcast traffic?
Hi, On 12 June 2013 15:18, Trent W. Buck <trentbuck@gmail.com> wrote:
John Mann <john.mann@monash.edu> writes:
I would control traffic by giving ppp0, ip6test, and lo interfaces IPv6 addresses, and not giving IPv6 addresses to the interfaces you do not want to send/receive IPv6 traffic.
IME if you enable IPv6 in the kernel, EVERY up interface will have an IPv6 address (the link-local one, I suppose).
What happens with interfaces depend upon how they are configured debian v. Red Hat etc etc I just checked on Ubuntu 12.10 --- $ sysctl -a | grep ipv6.*disable net.ipv6.conf.all.disable_ipv6 = 0 net.ipv6.conf.default.disable_ipv6 = 0 net.ipv6.conf.eth0.disable_ipv6 = 0 net.ipv6.conf.eth1.disable_ipv6 = 0 net.ipv6.conf.lo.disable_ipv6 = 0 $ sysctl net.ipv6.conf.eth1.disable_ipv6=1 deleted all IPv6 addresses from eth1, including the link-local addresses.
Also, without IPv6 enabled, it won't receive IPv6 packets on those interfaces.
Are you asserting that if IPv6 is enabled in-kernel, but an interface has no IPv6 address, IPv6 traffic arriving on that interface will be dropped on the floor? What about broadcast traffic?
I am asserting that without IPv6 enabled, any IPv6 packets won't be passed up to the networking stack. But, I'm a networking guy, and my priority is to enable things wherever I can, rather than a security guy, whose priority is to block everything that isn't essential. John
John Mann <john.mann@monash.edu> writes:
$ sysctl -a | grep ipv6.*disable net.ipv6.conf.all.disable_ipv6 = 0 net.ipv6.conf.default.disable_ipv6 = 0 net.ipv6.conf.eth0.disable_ipv6 = 0 net.ipv6.conf.eth1.disable_ipv6 = 0 net.ipv6.conf.lo.disable_ipv6 = 0
$ sysctl net.ipv6.conf.eth1.disable_ipv6=1 deleted all IPv6 addresses from eth1, including the link-local addresses.
Ah, thanks. I remember that was the (Debian-)recommended way to blanket disable IPv6 on a system, before it was added a /proc/cmdline option. That seems like a pretty safe approach.
Trent W. Buck <trentbuck@gmail.com> wrote:
$ sysctl net.ipv6.conf.eth1.disable_ipv6=1 deleted all IPv6 addresses from eth1, including the link-local addresses.
Ah, thanks. I remember that was the (Debian-)recommended way to blanket disable IPv6 on a system, before it was added a /proc/cmdline option. That seems like a pretty safe approach.
Another safe approach, on the router, would be ip6tables -A OUTPUT -o eth1 -j DROP ip6tables -A FORWARD -o eth1 -j DROP ip6tables -A INPUT -o eth1 -j DROP but my IPTables knowledge is hazy - I think the above should be enough to do it however.
participants (4)
-
Jason White -
John Mann -
Matthew Cengia -
trentbuck＠gmail.com