Dear Noel and Mark,
Thanks for your input!
After thinking about the ipv6 network configuration pros and cons, I
decided to go for the ULA for my internal network and use the /64
creating static ips for my WAN. To get a set of ULA addresses I logged to:
http://www.simpledns.com/private-ipv6.aspx
All BIND configurations and Apache for the virtual hosts are working
good so far. Ipv6 does connect direct using the OS X System Preferences
Network Interface. I am going step by step and waiting to see if
everything will be fine as the time runs. The good thing about ipv6 is
that it free us to assign ips for every possible thing you can put your
hands on out there. Mark, sorry, I did laugh when you said that my ISP
should give me a /56 or /48. If with /64 I have plenty of addresses, I
have no idea what I would do with /56 or /48. Probably I would open one
ISP for myself and start to sell ips. Looks like we are thinking in
gazillions now. That is very good! I am one happy cow now!
On 8/4/13 7:17 PM, Noel Butler wrote:
On Sun, 2013-08-04 at 13:28 -0700, Eduardo Bonsi wrote:
Hello Everyone,
I have some questions about ipV6 transition and DNS configuration!
I am preparing to make my transition to a dual stack ipv4, ipv6 and I
have some concerns in regards to the security of the network since ipv6
do not have NAT. My ISP gave me a Global
2602:000:000:000:000:000:000:000/64 Range and I can just turn on ipV6 on
the router and set the network to automatic on the computer and I am
connected through what they call a SLAAC ipV6 automatic conf network,
that runs using the machine MAC address in which I am not very happy to
adopt. I well know there is a way to mask the MAC address to random
addresses as a security measure but I am still not happy about it.
Beside, there are all the BIND DNS configuration that needs to be routed
or I am stack with a slow broke SLAAC connection that it works, but not
to the level of the a DNS Server that I want to achieve. Therefore, as a
network design after analyzing my options, I have decided to use the
static ipv4, ipV6 deployment approach that uses my ipV6 with the 3 last
bit of the ipv4 NAT addresses already in place. This static option does
not expose the machine MAC addresses. However the addresses are directed
connected through ipV6 bypassing the NAT environment. On BIND, the only
change I have in the named.conf file is the,
listen-on-v6 { any; };
listen-on-v6 ::1 and your dns server ipv6 address
Therefore, here are my questions:
1. I am open to ideas or anything you think is best choosing the best
internal network design for ipV6.
Static IP assignments on your LAN, as far as your ISP is concerned they
will just route your /64 via your routers IP. sure you can do auto
assignments, but I think if they are servers its best to do static.
2. Since this static ipV6 deployment lacks the non-rotatable NAT
environment, what are the security measures to take on BIND in regards
to the recursive issues on ipV6?
with ipv6, no more do you have security by accident (NAT) if you have a
/64 your router will route for all, forget all the bad habits of the
lazy ipv4 days, now you need to configure access lists on your router,
but also play it safe and configure firewalls on each machine,
especially if they are winblows boxes
3. Are there any other security issues that should I considerate?
Don't be over aggressive with filtering, you do not mention the OS, but
if its linux -
ip6tables -P INPUT DROP
ip6tables -P OUTPUT ACCEPT
ip6tables -P FORWARD DROP
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -s fe80::/10 -j ACCEPT
ip6tables -A INPUT -d ff00::/8 -j ACCEPT
ip6tables -A INPUT -p tcp -m tcp --dport 22 -m state --state INVALID,NEW
-j LOG
ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
... insert ACCEPT's for your lan and whatever other ipv6 addresses you
need with full access here...
ip6tables -A INPUT -p udp -d you:ipv6:dns:server:address --dport 25 -j
ACCEPT
ip6tables -A INPUT -p tcp -d you:ipv6:dns:server:address --dport 25 -j
ACCEPT
and.. importantly..
ip6tables -A INPUT -p icmpv6 --icmpv6-type 1 -j ACCEPT # Destination
unreachable
ip6tables -A INPUT -p icmpv6 --icmpv6-type 2 -j ACCEPT # Packet too big
ip6tables -A INPUT -p icmpv6 --icmpv6-type 3 -j ACCEPT # Time exceeded
ip6tables -A INPUT -p icmpv6 --icmpv6-type 4 -j ACCEPT # Parameter
problem
ip6tables -A INPUT -s your:gateway:ip -p icmpv6 --icmpv6-type 135 -j ACCEPT
ip6tables -A INPUT -s your:gateway:ip -p icmpv6 --icmpv6-type 136 -j ACCEPT
You *will* need the above accepts regardless since your default policy
is DROP, if not, you may find ipv6 reachable problems, in fact, you may
not even be able to connect outbound without types 135/136 (neighbour
discovery)
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Eduardo Bonsi
System - Network Admin
beart...@pacbell.net
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
