Forum - How Secure for IPv6 in all layers? :: SixXS

How Secure for IPv6 in all layers?

Shadow Hawkins on Tuesday, 20 April 2010 06:23:38

I heard IPv6 has no security, is this really true? Actually how secure for IPv6 as compared with IPv4? Have the present firewalls, routers, and anti-virus programs already IPv6 enabled? If not any roadmap or actions should be taken to achieve these all and move IPv6 forward before address exhausting.

How Secure for IPv6 in all layers?

Jeroen Massar SixXS Staff

on Tuesday, 20 April 2010 15:37:22

I heard IPv6 has no security, is this really true?

Depends on the context, but generally there is no 'security' at the IP layer. The moment one properly deploys IPSEC one has a bit of 'security'.

Actually how secure for IPv6 as compared with IPv4?

Exactly the same. There is IPSEC for IPv4 and for IPv6.

Have the present firewalls, routers, and anti-virus programs already IPv6

enabled? If not any roadmap or actions should be taken to achieve these

all and move IPv6 forward before address exhausting.

Some tools have, some not. Contact the vendor you prefer for the details. And do ask them about feature parity, as sometimes they just minimally support it. Again, it all depends on what kind of 'security' you are looking for.

How Secure for IPv6 in all layers?

Carmen Sandiego on Friday, 07 May 2010 01:08:13

Any OS worth it's salt has the same firewall capabilities for IPv6 as for IPv4. By default, just block all UDP and TCP ports unless the connection is initiated from the inside. Then allow the few well-written programs that you trust to have incoming connections. I basically just allow ssh, smtp (postfix), www (thttpd) on the TCP side, ntp and dns (named/bind) on the UDP side and a fallback to TCP for named.

How Secure for IPv6 in all layers?

Jeroen Massar SixXS Staff

on Friday, 07 May 2010 08:25:38

And then I send an SCTP packet, or heck, just RAW IP, while your host is vulnerable to exactly that packet. Firewalls and IDS's only fend off what you know, not what the evil people will actually try to do to you. Also, how exactly do you know what ports are being used for DNS? Outbound DNS queries go over port 53, incoming too, thus you just allow TCP&UDP for port 53 in either way? Cool, then I'll just connect to your SSH port with a source port of 53, presto.... Also, if you are port blocking and you explicitly block a port that a program gets to use (eg your mail server makes a connection from port 6000 to port 25 on the remote box) then if you block that port 6000 your server suddenly fails.... Or did you enable connection tracking so that those 'blocked' ports are suddenly open? Too many scenarios where evil people can bypass your silly policies. Best suggestion: don't run (and heck, even install) applications that you don't use, don't let them listen on IP addresses that you don't want to listen on. Oh, and don't forget to figure out which programs are going to dial out. For that matter an executable based firewall where you say "this executable (with this hash) can have inbound and/or outbound connections" is a rather good firewall, albeit per-host. Windows has a built-in firewall which does exactly that; next to the per-port thing, but you don't need it because of this.

How Secure for IPv6 in all layers?

Carmen Sandiego on Friday, 07 May 2010 10:33:25

Let me give you a lightly edited version of my ip6tables file for reference. # Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p ipv6-icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i eth1 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 587 -j ACCEPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT -A FORWARD -p ipv6-icmp -j ACCEPT -A FORWARD -i lo -j ACCEPT -A FORWARD -i eth1 -j ACCEPT -A INPUT -j REJECT --reject-with icmp6-adm-prohibited -A FORWARD -j REJECT --reject-with icmp6-adm-prohibited COMMIT The topology is eth0 is the outside interface, eth1 is the inside interface and sit1 is the tunnel interface. Both the tunnel and the outside interface are filtered by the same rules. Eth1, the inside ethernet gets a free pass. Everything is blocked on input and open on output by default. Sending weird unexpected protocols like SCTP or IP w/o a higher level to this box shouldn't be a problem (barring bugs in the iptables code). I don't really care what the outgoing port for DNS is. It should be something chosen at random from the ephemeral range. The destination is of course port 53, but I never force it to be 53 on the originating side. That would be silly and allow for easy spoofing of an answer. Feel free to connect to port 22 from any address you want. It is wide open. If ssh can't defend itself from a frontal attack, we have no business running it. I configure it such that all the ssh authentication methods other than RSA2 are turned off. An attacker would need to guess the 1k RSA key to get any joy. That attack isn't nearly as easy as guessing a un*x password. Passwords aren't allowed for over-the-net logins, only for console logins. I don't understand the question about 6000/tcp to 25/tcp. I don't block port 25/tcp. They are free to connect from any port at their end to 25/tcp that they want. Again, this is postfix. If there is an attack, postfix very good about using many small powerless processes that would limit exposure even if there was a buffer overflow or something. And yes, the return packets are allowed via stateful storage. I don't see how one can get usable security without that. Does that make sense? Does is still look insecure to you?

Please note Posting is only allowed when you are logged in.