portscans and blackhole

[Fabian Wenk]

Hello

On 29.01.14 18:24, sa9k063 wrote:
> On 01/29/2014 03:31 PM, Fabian Wenk wrote:
>> system will see this as a “Connection refused”.  By setting the TCP
>> blackhole MIB to a numeric value of one, the incoming SYN segment is
>> merely dropped, and no RST is sent, making the system appear as a
>> blackhole.  By setting the MIB value to two, any segment arriving on
>> a closed port is dropped without returning a RST.  This provides
>> some degree of protection against stealth port scans.
>
> This added to the confusion and thus made me ask. The manpage says
> for both values of net.inet.tcp.blackhole={1,2} that no RSTs are
> sent out.
> Both seem to drop SYNs and suppress sending a RST.
>
> Reading it again, the only conclusion i could get to regarding the
> difference between 1 and 2 would be that for a value of 2, all other
> tcp packets with flags other than SYN are additionally ignored. Is
> this a better way to understand it ?

Yes. I read it this way:
If set to 1, it does drop and not send RST only for SYN packets,
if set to 2, it does drop and not send RST for all packets.

>> So it is possible, that you are hit with something else then SYN
>> packets and should probably set net.inet.tcp.blackhole=2, or even
>> with UDP packets, then also set net.inet.udp.blackhole=1.
>
> this remains as a likely explanation, ie FIN scans etc.
>
>> What output does 'sysctl -a | grep blackhole' show?
>
> it used to be
>
> net.inet.tcp.blackhole: 1
> net.inet.udp.blackhole: 1
>
> since setting the tcp value to 2 no more messages like these popped
> up supporting your line of thought.

Then the behavior does match the man page and how I did 
understand it.


bye
Fabian