>> > turns on those detections and rejections within the kernel, as well as >> > perhaps adding a rule or two to DROP INVALID packets they should be >> > covered, should they not? And thus with far less resource over head as >> > extensive rules in their ruleset? >> >> That depends on what you want. > > what we want is for the firewall to be imune to invalid packets generated by > these kinds of scans, yes? to not give out port information when hits with I do not give out port information. At least, I do not give correct port information, which is just as much gain. > REJECT is the ind way to end a connection and does not slow an automated > scanner one bit, while a DROP lets that attack tool keep the socket open on Read closely. It uses -m random to switch between REJECT/DROP. Try that rulesets and then nmap yourself with "nmap -r localhost -p 1-2500". Count the time, and compare to a pure DROP based approach. (iptables -F; iptables -P INPUT DROP; nothing more) > it;s end and tries to wait for feedback from the other end, and thus slows or Surprisingly no. The REJECT/DROP mix confuses nmap more than a plain DROP. See above. > stops the scanner in t's tracks, if not totally for each attepted connection to > each port for its timeout period. That to me is the way I want my firewall to > respond to bogus script kiddies hitting me with their messing little scanners > as they play and try to learn the processes that should put their lame little > butts in jail and cost mom and dad tons of cash for rasing little deamons in > the first place <smile>. > > Of course, perhaps I'm incorrect in my analysis, and open to pointers to my > misunderstanding of the processes. Jan Engelhardt -- | Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen, | Am Fassberg, 37077 Goettingen, www.gwdg.de
