David Maxwell wrote:

>On Sun, 14 Nov 2004, Dmitri Nikulin wrote:
>  
>
>>>NetBSD's method was given high praise.
>>>      
>>>
>>Weird, maybe nmap's algorithms just aren't right for this kind of thing. 
>>    
>>
>
>I'm not sure I follow you - in the last 24 hours, you posted nmap output
>showing NetBSD as being rated with the highest category of sequence
>number patterning that nmap has.
>  
>
Really? I saw a lot of 9's in FreeBSD. That must be an nmap feature... 
999999999 not necessarily being the best, just looking like it.
Oh well, thanks for that clearup. My mistake indeed.

>  
>
>>Okay, features that still make sense after all discussion:
>>
>>-Blackholing (even if only to save packet filtering efforts)
>>    
>>
>
>Do you mean something other than this?
>
>http://mail-index.netbsd.org/netbsd-help/2002/12/27/0021.html
>  
>
Other: in FreeBSD it's (something like) net.inet.tcp.blackhole and 
net.inet.udp.blackhole. These make non-listening ports NOT return 
ICMP/RST messages saying they're not open, instead pretending it never 
got a request. Thusly a machine can open a port solidly in the packet 
filter and have it be just as 'stealthly' until a service is listening, 
at which point you want it to be open anyway. I relied on this kind of 
thing for very temporary port openings (e.g. MSN file transfers) without 
losing the anonymity of a non-responding machine.
You can emulate this by dropping certain packets on their way out, but 
compared to the graceful 'if' solution at the code level, it seems a bit 
hackish.

>>-TTY snooping
>>    
>>
>
>That's a curiousity for me, but I'm not convinced it's a critical
>feature.
>
>  
>
Well of course not critical, else by definition NetBSD would be 'dead' 
now, and so would every non-FreeBSD system out there. It is still a 
feature that has a lot of uses, the least of which are security-related.