Combating a possible DoS attack.

The following code, if inserted into the initial Seaside processing, I
would think *should* help guard against a DoS attack.  In this example,
'MemCheckCounter' is a class variable.  I thought I would post this to
see what comments (if any) it generates.

Nevin

*******************

clearCacheIfMemoryUsageIsBig
    "Every 'freq' requests, check and see if the image has grown bigger  
    than 'tooBig' number of bytes, and if so, clear all of the Seaside  
    handlers to release memory, and then garbage collection. Don't make  
    the check any more often than one out of every 'freq' times, just to be
    more efficient. If we don't do this, and if we get a DoS attack, memory
    will otherwise grow until the image hangs."
    | tooBig freq |
    freq _ 25.
    tooBig _ 190000000.
    MemCheckCounter isNil
        ifTrue: [MemCheckCounter _ 0].
    MemCheckCounter _ MemCheckCounter + 1.
    MemCheckCounter > freq
        ifTrue: [MemCheckCounter _ 1.
            (Smalltalk getVMParameters at: 3)
                    > tooBig
                ifTrue: [WADispatcher default entryPoints
                        do: [:ea | (ea respondsTo: #clearHandlers)
                                ifTrue: [ea clearHandlers]].
                    Smalltalk garbageCollect]]
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>>>> "Nevin" == Nevin Pratt <[hidden email]> writes:

Nevin> The following code, if inserted into the initial Seaside processing, I
Nevin> would think *should* help guard against a DoS attack.  In this example,
Nevin> 'MemCheckCounter' is a class variable.  I thought I would post this to
Nevin> see what comments (if any) it generates.

Well, you're trading one kind of DoS for another.  Now someone can
pound on you, and trigger you to reset every continuation, and ruin
everyone's day anyway.

What you need is a bit more smarts... someone coming in from the same
IP for example... a bit harder to fake.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Randal L. Schwartz wrote:
>
>
> Well, you're trading one kind of DoS for another.  

And that would be worse than the alternative?  Or better?
>
> What you need is a bit more smarts... someone coming in from the same
> IP for example... a bit harder to fake.
>
>  

Do you have some suggested code?

Nevin

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I would say that if you're thinking of coding DoS protection in your
Squeak server, it's already way too late. Those types of attacks should
never get this far and should be dealt with on the client facing load
balancers such as BIG-IP and the like. This white paper might shed some
light on the subject,

http://www.f5.com/pdf/white-papers/securing-enterprise-wp.pdf

Cheers,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
same _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside