[Beowulf] iptables

[Bogdan Costescu]

[ OK, I learnt the hard way that (this version of) pine doesn't do
spell checking on the Subjectline , but what excuse do you have for
not correcting it ? :-) ]

On Thu, 29 Sep 2005, Robert [UTF-8] G. Brown wrote:

> does anybody have any actual benchmark measurements of the
> comparative impact of iptables on code execution rates

Well, benchmarking implies a controlled environment. But remember that
you want to use iptables to protect from the unknown that is the
Internet at large or some evil soul on your closed network - you can't 
control the timing, quantity and size of packets that you receive. 
It's fine that you want to know how much enabling iptables costs in 
the ideal case when there is no mischief, but then how well do you 
know your enemy to predict how often you are far from the ideal case ?

Imagine a cluster node with iptables connected on a campus network (so
high packets per second rate between the attacker and the target). The
cluster node runs a job of user X; but user Y who has root access on a
computer connected to the same campus network decides that X's job
should not finish in time because X took Y's parking place. Then Y
starts a 'ping -f nodeX', or better yet uses pktgen (which running in
kernel space might be more efficient). Even with an iptables setup
that drops the offending packets, the effect is visible and it's far
from the nano- or microseconds that you mention; I chose dropping the
IGMP packet for maximum of efficiency - no response generated as with
REJECT, no connection tracking, no fragment assembly, no costly
copying to user space, easy to separate from other traffic so can be
put close to the first rule.

In my previous message, I didn't take into account an increased number
of interrupts generated by the network card faced with additional
traffic; I just supposed that the card is loaded anyway with useful
trafic, so interrupt rate remains similar between ideal and 'under
attack' situations. If this is not true and the attacker can induce
the generation of a high number of interrupts, then you loose big
time (pun intended).

-- 
Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu at IWR.Uni-Heidelberg.De