Home > Security > Disabling SSH connections on ipv6

Disabling SSH connections on ipv6

I was parsing through some of the logs on my new server tonite and I saw some unsuccessful ssh connection on ipv6. I thought I would mention quickly how you can disable listening on ipv6.

ListenAddress

The /etc/ssh/sshd_config file configures how your ssh daemon should run. By default it is likely listening on 0.0.0.0 (all ipv4 addresses) and :: (all ipv6), which is defined by two lines:

#ListenAddress 0.0.0.0
#ListenAddress ::

To configure your server to *not* listen on ipv6 you can remove that line. Now it might appear a bit confusing that the line we’re removing is commented out. That means its not reading that line, right? In this case it is displaying one of the default settings. I have altered my file to only listen on my public facing ipv4 address by removing the “::” listing, and specifically defining an ip instead of “0.0.0.0″.

Another solution which was brought to my attention by a comment is outlined here:

AddressFamily any # default
AddressFamily inet # IPv4 only
AddressFamily inet6 # IPv6 only

By defining the AddressFamily type that we want to use we can listen on both ipv4 and ipv6, just ipv4 or just ipv6. Find the line above in your config and define the AddressFamily you would prefer to listen on.

Once you update these lines you’ll need to restart your ssh service.

sudo /etc/init.d/ssh restart

Also, as a second measure you can firewall ipv6. I’ll be posting a firewall tutorial soon, but the below single command will block all incoming traffic on ipv6:

sudo ip6tables -P INPUT -j DROP

Categories: Security Tags: ,
  1. January 12th, 2008 at 13:55 | #1

    man sshd_config(5) has a simpler solution:
    AddressFamily any # default
    AddressFamily inet # IPv4 only
    AddressFamily inet6 # IPv6 only

  2. January 12th, 2008 at 14:27 | #2

    Or just disable ipv6 module :

    add in /etc/modprobe.d/blacklist

    blacklist ipv6

  3. Martijn
    January 13th, 2008 at 04:51 | #3

    Blacklisting ipv6 will break your system, especially as ipv6 adoption rates are growing.

    The best thing is to treat ipv6 like ipv4: create appropriate firewall rules (using ip6tables, which works exactly the same as iptables) and hosts.allow/deny entries.

    I don’t know if “fail2ban” recognises IPv6, but if it doesn’t I think that’s a bug that should be fixed :)

  4. January 15th, 2008 at 20:16 | #4

    Use ip6tables to set the “policy” (default action when no rule matches).

    ip6tables -P INPUT -j DROP

    Similar to your suggestion, but more correct in iptables terms.

    Also, unless you have an IPv6 tunnel established, why even bother?

  5. admin
    January 17th, 2008 at 14:08 | #5

    @Lonnie – thanks for the suggestion. I have updated the post to use the POLICY vs the INPUT chain as suggested, as it is probably the more correct method.

  6. cwd
    January 19th, 2008 at 14:37 | #6

    I strongly recommend using the AllowUsers directive to limit SSH logins to only a few (non-system) accounts:

    AllowUsers fredf barneyr

    But by far the coolest ssh security measure I’ve ever used is the following rc.local script gleaned from the Internets:

    In /etc/rc.local, put the following lines:

    # Flush any existing rules
    /sbin/iptables -F
    /sbin/iptables -X

    # Watch for attempts to connect to SSH
    /sbin/iptables -I INPUT -p tcp \
    –dport 22 -i eth0 -m state \
    –state NEW -m recent –set

    # If more than three connections in
    # 60 seconds, block them
    /sbin/iptables -I INPUT -p tcp \
    –dport 22 -i eth0 -m state \
    –state NEW -m recent \
    –update –seconds 60 –hitcount 4 \
    -j DROP

    # Report the settings
    /sbin/iptables -L

    [Note: I'm not an iptables GURU, so I cannot give any guarantees, but this works for me and automatically stops the robot SSH login attempts after four tries.]

  7. anon
    December 12th, 2008 at 11:21 | #7

    The correct firewall command is:

    sudo ip6tables -A INPUT -j DROP

  8. October 7th, 2009 at 16:37 | #8

    On the last step, I should restart my sshd service right ? something like…

    /etc/init.d/sshd restart