From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Engelhardt <jengelh@linux01.gwdg.de>
Subject: Re: Defeating NMAP Null scans (and Nessus scans).
Date: Thu, 23 Jun 2005 13:07:46 +0200 (MEST)
Message-ID: <Pine.LNX.4.61.0506231301530.26133@yvahk01.tjqt.qr>
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAsvh50JgMeE+wdUqpg8SwJMKAAAAQAAAA0VU7kwJQ1kSCxnmqi2LTiQEAAAAA@ziemba.net>
	<Pine.LNX.4.61.0506221442160.25356@yvahk01.tjqt.qr>
	<Pine.LNX.4.60.0506221245590.21678@darkstar.sysinfo.com>
	<Pine.LNX.4.61.0506221845160.21055@yvahk01.tjqt.qr>
	<Pine.LNX.4.60.0506221519210.21678@darkstar.sysinfo.com>
Mime-Version: 1.0
Return-path: <netfilter-bounces@lists.netfilter.org>
In-Reply-To: <Pine.LNX.4.60.0506221519210.21678@darkstar.sysinfo.com>
List-Id: <netfilter.vger.kernel.org>
List-Unsubscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>,
	<mailto:netfilter-request@lists.netfilter.org?subject=unsubscribe>
List-Archive: </pipermail/netfilter>
List-Post: <mailto:netfilter@lists.netfilter.org>
List-Help: <mailto:netfilter-request@lists.netfilter.org?subject=help>
List-Subscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>,
	<mailto:netfilter-request@lists.netfilter.org?subject=subscribe>
Sender: netfilter-bounces@lists.netfilter.org
Errors-To: netfilter-bounces@lists.netfilter.org
Content-Type: TEXT/PLAIN; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: "R. DuFresne" <dufresne@sysinfo.com>
Cc: netfilter@lists.netfilter.org


>> > 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