Tim's Weblog » firewall

ip6tables: ACCEPT icmpv6 before dropping state INVALID

Tim — Thu, 16 Apr 2009 15:30:16 +0000

Spend some hours trying to figure out why our firewall was blocking ipv6 icmp traffic. Apparantly, ipv6 packets start out in state invalid and get valid after some sort of icmp traffic. If anyone can explain it to me, I’d love to hear the details. My guess is that in ipv4, state is somehow set to valid via ARP. Since ipv6 doesn’t use ARP but icmp for neighbour detection, my guess is that you need to accept this before doing any state checking.

Tags: arp, firewall, icmp, invalid, ip6tables, ipv6, nd, neighbour detection, state

IPv6 Tunnel behind Thomson modem, continued

Tim — Wed, 15 Apr 2009 20:34:37 +0000

My coworker is even better than me. After I thought I fixed it, I noticed that the incoming connection is denied if the machine hasn’t had any outgoing ipv6 over the tunnel for a little while. My coworker, Kees, found the solution and implemented it and now it works! Yay!

This is what you need to do (blatantly copied from Kees’ blog):
:expr add name=ipv6 type=serv proto=41 :firewall rule add chain=forward_host_service name=SixXS serv=ipv6 state=enabled action=accept :nat tmpladd intf=Internet type=nat outside_addr=0.0.0.1 inside_addr=192.168.4.4 protocol=6to4 :saveall

Let me know if this helped you too!

Tags: 6to4, DMZ, firewall, ipv6, linux, modem, nat, pointopoint, proto41, sixxs, telnet, thomson

Rate limit incoming ssh connections

Tim — Sun, 06 Jul 2008 14:13:42 +0000

So apparently, there’s a ssh worm in the wild that tries to break into servers by bombarding the ssh daemon with logins. No idea what they think they can achieve with this, since it mostly just takes down the ssh service (for everyone, including themselves). So it’s more annoying and inconvenient (you can’t login) than threatening, in my opinion.

Luckily, there are easy ways to deal with this. We use the following ferm recipe to limit the incoming new ssh connections on source ip basis. Hope this helps someone.

You do the following in the filter table from the input chain. We assume you already allow established connections to pass.

proto tcp dport ssh {
  # Rate-limit incoming SSH connections
  mod state state NEW mod recent name "ssh" {
    set NOP;
    update seconds 300 hitcount 31 REJECT reject-with tcp-reset;
  }

  # allow SSH clients which play nice
  ACCEPT;
}

This will keep track of the number of connections made on the ssh port in the last 300 seconds, per source ip address. If more than 30 connections are made within 300 seconds, they will be rejected. Otherwise, they’re allowed.

This works great for us, but you want to test it before using it in a production environment, of course!

Update: So ipt_recent only allows up to 20 counts. You might want to change the numbers in this recipe a bit to make it work correctly

Update 2: Or even better:

$ cat /etc/modprobe.d/ipt_recent
options ipt_recent ip_pkt_list_tot=31
$ sudo /etc/init.d/ferm stop
$ sudo rmmod ipt_recent
$ sudo /etc/init.d/ferm start

You can check /sys/module/ipt_recent/parameters/ip_pkt_list_tot to see if it changed.

Btw, this all is not my own research, merely transcribing what Bart and Kees researched.

Tags: connection, ferm, firewall, ipt_recent, limit, rate limit, recent, ssh, worm