oss-sec mailing list archives
Re: speaking of DoS, openssh and dropbear (CVE-2006-1206)
From: David Hicks <d () hx id au>
Date: Thu, 05 Jan 2012 22:22:21 +1100
iptables (/ip6tables) already allows for rate limiting via the hashlimit match extension. The inbuilt support for source masks makes it easy to progressively block larger subnets if an attacker has control over large subnets with many available IP addresses. Assume that 10.10.0.1 or fd01:2345:6789::1 starts flooding your server with 50 connection requests to SSH per second. iptables/ip6tables (via the hashlimit extension) is configured to prevent more than 3 SSH connection attempts per 15 minutes per IPv4 address (/32) or /64 IPv6 allocation. After the first 3 SYN packets from the attacker, all further SYN packets will be dropped/recorded/whatever until >=15 minutes pass without another SYN packet arriving. It may also be possible to reset any existing connections the attacker has to the server and add the attacker to a temporary blacklist that drops all their traffic. You may also have another rule configured such that no more than 30 SSH connection attempts are allowed per 15 minutes per /24 IPv4 allocation or /48 IPv6 allocation. An attacker that controls 10.10.0.0/24 or fd01:2345:6789::0/48 (not the best example) would no longer be able to utilise a compromised subnet to bypass the more stringent 3 connections/15 minutes rule. It is worth noting that the man page for ip6tables appears to contain an error[1] for the --hashlimit-srcmask argument. The manual indicates values for the mask must range from 0 to 32 bits (correct for IPv4). However values from 0 to 128 seem to be supported[2] if ip6tables is being used. OpenBSD's pf also allows for connection rate limiting with the "max-src-conn-rate" restriction. I haven't investigated how this works in comparison to iptables/hashlimit or whether it can support grouping of addresses sharing a common mask. The question these approaches raise is whether it is advisable to reinvent rate limiting in each and every network daemon. Performing rate limiting at the system/interface level prevents unwanted and expensive context switches to each daemon. Configuration and maintenance is much simpler because administrators don't need to learn 50 different ways to configure rate limiting for each daemon. There is also less risk for bugs to be written into the rate limiting implementation of each daemon. On a technical note, rate limiting requires a small amount of memory (buckets) to store information about recent connections. For this reason, allowing IPv6 rate limiting granularity at the /128 level would be inadvisable as an attacker with /64 addresses could quickly exhaust the table capacity/available memory. The design of the data structures and algorithms for the table need to be very efficient. Taking it down another level, a table that is larger than available L1-L3 cache could further degrade performance ([4] and [5] discuss hash tables and CPU cache). [1] https://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a=blob;f=extensions/libxt_hashlimit.man;h=f90577e77796502fac2ccc368a0863483aad4045;hb=HEAD#l30 [2] https://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a=blob;f=extensions/libxt_hashlimit.c;h=da34cb2218a6bd053c856b288b881f6b97affd87;hb=HEAD#l210 [3] http://www.openbsd.org/faq/pf/filter.html#stateopts [4] http://people.csail.mit.edu/nickolai/papers/metreveli-cphash-ppopp.pdf [5] http://people.csail.mit.edu/nickolai/papers/cphash-tr.pdf
Attachment:
signature.asc
Description: This is a digitally signed message part
Current thread:
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206), (continued)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Solar Designer (Jan 01)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Kurt Seifried (Jan 01)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Eitan Adler (Jan 01)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Kurt Seifried (Jan 02)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Nico Golde (Jan 02)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Solar Designer (Jan 02)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Nico Golde (Jan 03)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Solar Designer (Jan 03)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Kurt Seifried (Jan 03)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Solar Designer (Jan 11)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) David Hicks (Jan 05)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) The Fungi (Jan 05)
- Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Kurt Seifried (Jan 05)