I known that the server got protected but the real user got state DoS when "max-src-states 20" is enabled. All the state of this rule is created by the DoS tool, user cann't establish a new real state. Otherwise the DoS tool will fulfill all the possible state pool - another DoS to gateway and user. BTW, "max-src-conn-rate 10/1" is not useful because no connection is established. This could verified by issue "pfctl -sS -vvv": 192.168.10.4 -> 0.0.0.0 ( states 20, connections 0, rate 0.0/60s ) age 00:00:06, 0 pkts, 0 bytes, filter rule 0
pfctl -ss -vvv all tcp 192.168.10.33:80 <- 192.168.10.4:35060 PROXY:SRC [0 + 1] [1679241634 + 1129253694] age 00:00:16, expires in 00:00:14, 0:0 pkts, 0:0 bytes, rule 0, source-track id: 45c9359500027b31 creatorid: db231153 all tcp 192.168.10.33:80 <- 192.168.10.4:56179 PROXY:SRC [0 + 1] [1201053090 + 2358678080] age 00:00:16, expires in 00:00:14, 0:0 pkts, 0:0 bytes, rule 0, source-track id: 45c9359500027b32 creatorid: db231153 .. What is the solution? Frank 2007/2/7, Daniel Hartmeier <[EMAIL PROTECTED]>:
On Wed, Feb 07, 2007 at 04:47:00AM +0800, frank hu wrote: > So my question is why PF create state while the first 3-way handshakes > didn't complete? What is right usage of synproxy rule to protect port > from DoS attack? That's what synproxy does, by design. It does protect the recipient from seeing packets (and allocating resources) before the handshake is complete, but at the cost of itself allocating some resources (the state entry). The state entry will not pass packets through to the real recipient before the handshake is complete, but merely holds the information needed to verify the handshake with the client is valid. Daniel
