[nycbug-talk] home grown firewall solutions ...
Trish Lynch
trish at bsdunix.net
Mon Mar 13 11:27:44 EST 2006
On Sun, 12 Mar 2006 alex at pilosoft.com wrote:
> On Sun, 12 Mar 2006, Fabian Keil wrote:
>
>> alex at pilosoft.com wrote:
>>
>>> c) it is, however, nontrivial to do this with pf 'keep state', if
>>> that's what you want. if you want to keep state, you need lots of CPU
>>> power and/or memory and/or hackery.
>>
>> Are you sure this is true for PF?
>>
>> Quote from http://kerneltrap.org/node/477:
>>
>> |JA: How does pf performance compare to other stateful packet filters? |
>> |Daniel Hartmeier: In the benchmarks I did and based on the feedback
>> |from people who compared pf with other filters on production machines,
>> |very well, often significantly better. In particular, we found that
>> |keeping state on all connections scales well and is faster than
>> |stateless rule evaluation.
> This is probably the case for non-ddos traffic.
>
> Here's some basic math for you. Line-rate GE traffic is 1.4mpps. In case
> of ddos, this is potentially 1.4M different src/dst pairs per second. To
> be able to statefully filter it, you need to at least keep in memory 30
> seconds worth of traffic - that's 50M flow records. You probably need to
> keep at least 50 bytes of data per flow - that's 2.5G memory requirement
> right there. Now, for each packet coming in, you need to match it with a
> previous flow record. That will take at least 100 comparisons. Each random
> memory access is (say) 2ns. 100 comparisons = 200ns. That means, you can
> match ~5M new flows per second best case. (which is more than you have to,
> but you have to realize you need lots more things to do in than just
> memory lookup to match flow).
>
> Now, you need to expire flows every 30 seconds. (at least this means
> reading through 2.5G every 30 seconds).
>
> Basically...This is hard. Proper solutions would use TCAM to keep the flow
> info.
>
> -alex
>
Or you could start to group flow info as well, instead of keeping state of
individual connections, you could keep state of groups of connections
through certain flows. You can ignore other flows as well, and just simply
drop others on the floor.... or not do anthing at all with them. the trick
is to know what to do with what.... something we deal with on a day to day
basis at one of the largest voice and video chat providers in the world...
If only the device was intelligent enough to decide what to do with these
things :)
-Trish
--
Trish Lynch trish at bsdunix.net
Ecartis Core Team trish at listmistress.org
Key fingerprint = 781D 2B47 AA4B FC88 B919 0CD6 26B2 1D62 6FC1 FF16
More information about the talk
mailing list