|
Hi,
I checked the mailing list and did not find something
such as roadmap or function list of next release. So I
wish I could add some of my ideas if one day we will
have the roadmap.
Like Joe mentioned: it's rather unlikely that this will happen. I took 3
years to update the TODO list ;).
1. user defined scheduler: user can write their own
scheduler to guide the load dispatching
Check out feedbackd and see if you miss something there. I know that
this is not what you wanted to hear but to provide a generic API for
user space deamons to interact directly with a generic scheduler is
definitely out of scope. One problem is that the process of balancing
incoming network load is not an atomic operation. It can take minutes,
hours, days, weeks until you get an equalised load on your servers.
Having a user space doing premature scheduler updates in a short time
interval only asks for trouble regarding peak load bouncing.
2. session persistent extend: I noticed that 3 methods
to extend a session in the mail
http://marc.theaimsgroup.com/?l=linux-virtual-server&m=104467069124909&w=2
And I prefer the first one to extend it again with
the persistent time. So maybe all these implemented
and have control variable to choose one.
I'd have to agree with you here.
3. DOS attack: add functions such as BIG-IP syn check.
http://www.f5.com/solutions/tech/security/
For the RS or the director or both?
I think you are referring to those two marketing features:
SYN Check™ - One type of DoS attack is known as a SYN flood in which an
attack is made for the purpose of exhausting a system’s resources
leaving it unable to establish legitimate connections. The BIG-IP
system's SYN Check feature works to alleviate SYN flooding by sending
cookies to the requesting client on the server's behalf and by not
recording state information for connections that have not completed the
initial TCP handshake. This unique feature ensures that servers only
process legitmate connections and the BIG-IP SYN queue is not exhausted,
and normal TCP communication can continue. The SYN Check feature
complements the BIG-IP Dynamic Reaping feature, in that while the
Dynamic Reaping handles established connection flooding, SYN Check
addresses embryonic connection flooding to prevent the SYN queue from
becoming exhausted.
Dynamic Reaping - The BIG-IP software contains two global settings that
provide the ability to reap connections adaptively. Used to prevent
denial-of-service (DOS) attacks, enterprises can specify a low-watermark
threshold and a high-watermark threshold. The low-watermark threshold
determines at what point adaptive reaping becomes more aggressive. The
high-watermark threshold determines when non-established connections
through the BIG-IP product will no longer be allowed. The value of this
variable represents a percentage of memory utilization. Once memory
utilization has reached this mark, connections are disallowed until the
available memory has been reduced to the low-watermark threshold.
1. SYN Check can be enabled on the RS for all major Unices. For the rest
we have to give in the fact that LVS is a software load balancer and
does not have the possibilites a hardware load balancer has with
regard to doing SYN cookies for other servers. Also limiting the
backlog queue on a per socket basis definitely helps.
2. Dynamic Reaping could very well be brought into conjuction with our
TCP DoS defense mechanism. Read about it at:
http://www.linux-vs.org/docs/defense.html
I have tested F5 BigIP load balancers and I was able to flood the RS
just as well as using LVS. SYN flooding cannot be prevented, it can only
be rate limited. It's a flaw in the TCP protocol which we'll have to
live with. There are a couple of defense mechanisms but non of them can
really distinguish between malicious TCP/SYN and friendly TCP/SYN.
HTH and best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
| 