Re: [Fwknop-discuss] fwknop, denial-of-service and throughput

[Michael R. <mb...@ci...>]

On Feb 03, 2009, Mark V wrote:

> Hi Mike,

Hi Mark -

> Apologies for not following up sooner.
> I just saw your blog entry confirming that fwknop's SPA is a great fit
> with Amazon's EC2.  Thanks for posting those details.
> 
> Strictly, unrelated, but triggered by the same train of thought:
> It seems, to a non-guru, that adding fwknop to a server can relieve it
> of any load/fragility associated with Denial-of-Service type attacks -
> fair comment?
> That is, I assume libpcap's 'default-drop' uses negligible
> system-resources (cpu, etc).
> If so, this makes me wonder if it is feasible to use fwknop as a
> general security layer in multiple user/connection settings.

That is an interesting theory, and I think the benefit would depend on
several factors.  It is true that a default drop stance implemented by
iptables generally uses minimal resources since it's code it hooked
directly into the kernel networking stack and has a good design, but
libpcap can be made to negate these benefits.  That is, if the pcap
filter (for fwknopd this is set by the PCAP_FILTER variable with a
default of "udp port 62201") is overly broad and the data that is
captured (say, every packet with a broad filter) is sent through a
CPU-intensive operation such as regex matching or a decryption routine,
then default-drop with iptables is not buying much.  On a machine that
is being heavily pounded over the network just the act of copying packet
data from the kernel to a userspace application can be significant -
this an area that intrusion detection systems try to optimize (see the
PF_RING patch to libpcap for example).

Now, if whatever application that is being protected by fwknop and a
default-drop packet filter is itself very expensive even for
non-authenticated users (or some such), then using fwknop can help quite
a bit as you suggest.

Either way, I would recommend using a restrictive pcap filter for a
single port, and maybe even changing this port to something other than
the default.  Then just use the --Server-port argument on the fwknop
command line.

> I see that ldap support is in the todo file, but I wonder if you, or
> anyone else, has an idea of what fwknop's current 'accept' throughput
> figures are like.
> E.g. Take the EC2 configuration: How many connections/sec could be
> accepted before the network, cpu, etc. is saturated?  Given ldap would
> add a latency this current figure might indicate an upper bound for
> the multiple user/ldap case.

Although quantifying this would be tricky, the good news is that when it
comes to connections that are established after an SPA packet is
validated, parts of the system that are utilized the most are the
iptables connection tracking code and the kernel stack itself.  These
components have a proven track record of good performance, so the
limiting factor might be in processing large numbers of SPA packets.
Perhaps I should extend the test suite to try and get some performance
metrics.  Beyond this, using interfacing with ldap would add additional
overhead.

Thanks,

--Mike


> Of course this approach is more suited to cases where some client
> application handles the SPA-knock in the background and then makes the
> real server connection.
> 
> Regards
> Mark
> 
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Fwknop-discuss mailing list
> Fwk...@li...
> https://lists.sourceforge.net/lists/listinfo/fwknop-discuss