I'd like to start helping out here

[Berin Loritsch <bl...@d-haven.org>]

One of the things that I believe this projects need is a good security 
model and load
shedding system.  Having worked both with SEDA style systems and Java 
security,
I believe I can lend a decent helping hand here.

The immediate need that I would have for this system is to deny access 
or allow access
from specific addresses.  I do envision something where this list can be 
dynamically
managed so that when someone is trying to do a DoS attack on Eve the 
address slips
into the deny list and the current requests get purged from the system.  
But first things
first--I just want to be able to deny a configured IP through the SEDA 
layer (which
will enable that).

-- 

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
                - Rich Cook

Re: I'd like to start helping out here

[Berin Loritsch <bl...@d-haven.org>]

Trustin Lee wrote:

>Thank you Berin first of all!
>
>SEDA currently lacks of traffic throttling.  Do you have any
>experience on this topic?  If so it would be very very nice. :)
>  
>

In Sandstorm they use EnqueuePredicate objects to handle that.  My D-Haven
Event package has a RateLimitingEnqueuePredicate.  As long as you don't
use lossy methods to enqueue the events you can exert some "back pressure"
to slow things down a bit.

-- 

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
                - Rich Cook

Re: I'd like to start helping out here

[Trustin Lee <tr...@gmail.com>]

Thank you Berin first of all!

SEDA currently lacks of traffic throttling.  Do you have any
experience on this topic?  If so it would be very very nice. :)

-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

Re: I'd like to start helping out here

[Alex Karasulu <ao...@bellsouth.net>]

Berin Loritsch wrote:

> One of the things that I believe this projects need is a good security 
> model and load
> shedding system.  Having worked both with SEDA style systems and Java 
> security,
> I believe I can lend a decent helping hand here.
>
Excellent!  I think Trustin is the guy to discuss these details with.  
Good to have you helping out.

Alex

Re: I'd like to start helping out here

[Enrique Rodriguez <er...@apache.org>]

Berin Loritsch wrote:
> Enrique Rodriguez wrote:
>> Berin Loritsch wrote:
>> Detection of both of these scenarios should be encapsulated in the 
>> Kerberos ProtocolProvider, but with denial performed as close to the 
>> wire as possible.
>>
>> Additionally, Kerberos admins should be able to clear denied Clients 
>> via management interface, so there should be a way to notify of a 
>> cleared address, too.  This usually happens due to misconfigured clients.
>>
> I personally would start with a windowed blackout time.

Sounds good.  I agree a windowed blackout time should be default.  The 
misconfiguration scenario I describe is a special case, when an admin 
setting up a client makes a mistake and it is specific to configuring 
Kerberos.  Waiting 20 minutes would be a huge inconvenience and 
restarting the services may not be acceptable.

-enrique

Re: I'd like to start helping out here

[Berin Loritsch <bl...@d-haven.org>]

Enrique Rodriguez wrote:

> Berin Loritsch wrote:
>
>> The immediate need that I would have for this system is to deny 
>> access or allow access from specific addresses.
>
>
> Great idea.  I would like to request that ProtocolProviders have a way 
> to notify the SEDA frontend that a Client is problematic.  There are 
> at least two scenarios in the Kerberos and Changepw protocols where 
> the Kerberos services may detect this.
>
> 1)  Replay attacks, where the Authenticator is compared against a 
> replay cache.
>
> 2)  ClientAddresses, where Kerberos credentials are issued for use 
> from specific IP address(es).
>
> Detection of both of these scenarios should be encapsulated in the 
> Kerberos ProtocolProvider, but with denial performed as close to the 
> wire as possible.
>
> Additionally, Kerberos admins should be able to clear denied Clients 
> via management interface, so there should be a way to notify of a 
> cleared address, too.  This usually happens due to misconfigured clients.
>
I personally would start with a windowed blackout time.  For example, 
when something is
exposed to the big internet (like HTTPD), there is always some idiot who 
wants to break your
system.  Now it is not all 200 users behind the same gateway that is the 
problem, but one.  If you deny access from the IP address it would be 
reasonable to deny access for a period of say 20 minutes and then start 
allowing again.

However, the concept is similar.  Something is blocked out until 
something else clears it.

Once the facility is made, the question then comes how to wire things so 
that the accept/deny block can get the change in information.  If SEDA 
is exposed, or there is a command queue of sorts, then we don't really 
have much to worry about.

I'll start looking into this.

-- 

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
                - Rich Cook

Re: I'd like to start helping out here

[Enrique Rodriguez <er...@apache.org>]

Berin Loritsch wrote:
> The immediate need that I would have for this system is to deny access 
> or allow access from specific addresses.

Great idea.  I would like to request that ProtocolProviders have a way 
to notify the SEDA frontend that a Client is problematic.  There are at 
least two scenarios in the Kerberos and Changepw protocols where the 
Kerberos services may detect this.

1)  Replay attacks, where the Authenticator is compared against a replay 
cache.

2)  ClientAddresses, where Kerberos credentials are issued for use from 
specific IP address(es).

Detection of both of these scenarios should be encapsulated in the 
Kerberos ProtocolProvider, but with denial performed as close to the 
wire as possible.

Additionally, Kerberos admins should be able to clear denied Clients via 
management interface, so there should be a way to notify of a cleared 
address, too.  This usually happens due to misconfigured clients.

-enrique