Date: 05 Jul 1999 14:57:43 +0200 From: Dag-Erling Smorgrav <des@flood.ping.uio.no> To: "N.N.M" <madrapour@hotmail.com> Cc: jcarlos@bahianet.com.br, freebsd-security@FreeBSD.ORG Subject: Re: IDENTD Message-ID: <xzpk8sfuud4.fsf@flood.ping.uio.no> In-Reply-To: "N.N.M"'s message of "Mon, 05 Jul 1999 04:30:28 PDT" References: <19990705113029.28794.qmail@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"N.N.M" <madrapour@hotmail.com> writes: > 2) Can it be consequnced: it is basically better to block the all > conncetions we want, by using "reject" instead of "deny"? Based on what you > said (and I read about), using "reject" decreases the further re-attemting > conncetions, so it will decrease the unusable and unwanted traffic as well. > Is it right? Depends how paranoid you are, and how exposed you are. If you block, clients will sit around waiting for an answer until they time out (normally after 75 seconds, I think). If you reject, they'll get an immediate negative reply and give up at once. So, from the client's POV, reject is better. On the other hand, if you get flooded (syn flood, port scan, whatever), a reject rule will generate large amounts of ICMP traffic which not only eats local resources but may bring down your upstream routers if the attacker spoofs his source address (you're sending out ICMP packets to zillions of invalid addresses, and the router blows up trying to find out where to send them). You can avoid these problems to a certain degree by using a traffic shaper (altq, dummynet) to impose a rate limit on outgoing SYN+ACK (easier on the router) and SYN cookies to avoid keeping a list of received SYNs (easier on yourself). DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpk8sfuud4.fsf>