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
signature.asc
Description: Digital signature
_______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
