On 10/26/07, Ashley M. Kirchner <ashley@xxxxxxxxxx> wrote: > Neil Cherry wrote: > > I'm betting you're responding with a reset or something. Maybe it > > would be a good idea to show us you're rules (you can make up > > the IP's but keep them consistent). > That would not be consistent then. I used to reset in the past, and > traffic wasn't anything like it is now that I drop. I'd sent a rest, I > might get two or three more packets and then it would go silent. Now > that I'm dropping packets (and trust me when I say I'm dropping it, I've > had others try and I'm sniffed it myself, they're being dropped), > traffic seems to have gotten worse. It's almost like, because I'm not > sending a reset back, which would cause the sender to now have to read > that packet and see that it's a reset, now they're just going into > oblivion, so there's no more processing on their end, so why not keep > sending? At least, that's my thinking. If I send a reset (or port/host > unreachable), they have to process that before continuing...now they don't. When the remote node starts a connection, it sends an initial SYN packet to you. When you receive it, you normally would send a SYN/ACK back to acknowledge the connection. The remote host then knows you have received it. If you reject the packet, the remote host is told that your host is up, but the port is closed. If you drop the packet, the remote host thinks that the packet may have been lost. It will repeatedly send SYN packets at every increasing intervals until it reaches a timeout. The timeout is specified by the software, but could be as much as three minutes or more. Decent spamming s/w would give up quickly, but that may not be the case. Dropping the SYN packets doesn't cost you anything (unless they're all in your log files, but you could rate limit them). It does, however, force the thread on the remote host to sit idle until it gives up. Personally, I take a tiny bit of enjoyment out of knowing that I've taken up a tiny bit of their time.
