>
> Duh.. Ok,
Yea, I felt the same way when I got up this morning and realized
that my idea about BGD authentication was flawed for a number of reasons.
Not the least of which was that BGP, a routing protocol, rides on TCP.
Thanks to Paul for his patience and persistence in asking me to check the BGB
RFCs! Aw, brainstorming when you're tired... :^)
> we take a PC with a plenty of RAM and customized BSD kernel,
> which works as a packet filter. What we can do with it -- we
> T can teach it to do "spoofing+buffering" of TCP handshakes for
> i a whole network behind it. The following chain of events will
> m take place in time:
> e
> | ------------------- "Acting persons" --------------------------
> |
> | Client "Spoofer" Protected
> V (attacker?) firewall server
>
> 1. Sends SYN to protected Queues SYN as it Knows nothing :)
> server. was destined to it
> (just to another queue?)
> Sends SYN/ACK to client
> claiming to be a server,
> sets a timeout to wait
> for responce.
>
> #if (client is valid)
>
> 2. Continues with TCP Sends SYN to server, Gets 1st SYN
> connection. claiming to be a client. sends SYN/ACK
> to client.
>
> 3. Waits Silently "eats" SYN/ACK Waits
> server sent, caches connection
> as "valid,established" for
> passing it through later on.
> Passed continuation packet
> to server.
>
> 4. Works as usual Passed valid connection Works as usual
> through.
>
> #else /* SYN/flood attack -- queue timeout expired */
>
> 2'. ??? (who cares?) Drops bad SYN away Still knows
> nothing
> #endif
>
OK, this sounds plausible. But lets modify it a bit.
1. Upon the reciept of any new packet containing a request to set up
a connection (SYN), grab the source address, hold the packet,
log the address into a cache, "waiting for reply", and
send a reply (SYN-2).
2. While waiting for an ACK from the source host to your SYN-2,
drop *all* other segments from the source address which do not
have an ACK contained in them. Do not accept any packets
from the source until your SYN-2 is successfully answered.
3. Upon reciept of an ACK to your SYN-2, load source address into
cache, "good addresses", organized by timestamp of intial SYN request
and preform the rest of the connection like any normal transaction.
4. If, after a configurable timeout period (75 sec., say) no ACK is
recieved, put the source address into a 3rd cache, "bad addresses",
log the address and dump all packets from that address.
5. Recap: Addresses will stay in the:
o "Waiting for reply cache" for 75 sec. All segments from this
address will be parsed for an ACK. No transactions can
be made with any addresses in this cache until ACK is recieved.
All non-ACK segments will be dumped.
o If an ACK is recieved, the address is removed from the "Waiting for
reply cache" and placed into the "Good Addresses Cache", where it
will stay for a configurable amount of time (10 mins.). After
this timeout value, based upon timestamp from initial SYN, is
exceeded, the address is purged from cache and must begin
authentication again.
o Addresses which don't provide a valid ACK in 75 sec. will be placed
into the "Bad Adresses Cache" where it will stay for 10 mins. All
segments recieved from an address in this cache will be dumped.
How does this sound? I wonder what kind of performance hit the server would
take?
--Todd
_____________________________________________________________________________
R. Todd Truitt Todd .
Truitt @
evolving .
com
Evolving Systems, Inc.
Follow-Ups:
|
|
