Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 May 2001 05:33:10 -0700
From:      Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
To:        Peter Pentchev <roam@orbitel.bg>
Cc:        patl@phoenix.volant.org, Sheldon Hearn <sheldonh@uunet.co.za>, freebsd-security@FreeBSD.ORG
Subject:   Re: ipfw: reset -vs- unreach port 
Message-ID:  <200105281233.f4SCXJE11964@cwsys.cwsent.com>
In-Reply-To: Your message of "Mon, 28 May 2001 13:11:36 %2B0300." <20010528131136.A588@ringworld.oblivion.bg> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <20010528131136.A588@ringworld.oblivion.bg>, Peter Pentchev 
writes:
> On Mon, May 28, 2001 at 12:03:48PM +0200, Sheldon Hearn wrote:
> > 
> > 
> > On Mon, 28 May 2001 00:55:45 MST, patl@Phoenix.Volant.ORG wrote:
> > 
> > > There are a few 'nuisance' TCP services that are normally blocked by
> > > firewalls (e.g., auth [113] and netbios-ns [137])  In the interest
> > > of reducing the delays which would be imposed by simply dropping
> > > those packets, is it better to use 'reset' (send an RST), 'unreach
> > > port' (send a Port Unreachable ICMP message), or 'unreach filter-prohib'
> > > (send a Filter Prohibition ICMP message) ?
> > 
> > Yes.
> 
> Uh.. I think the original poster already considered using one of these
> three better than just dropping the packet on the floor, and his question
> was more like which of the three was better :)
> 
> IMHO, a simple RST would be best - a classic, old-fashioned 'connection
> refused, no one here' reply, almost no indication that it is actually
> a firewall blocking the attempt, no fear of overly-paranoid firewalls
> dropping stray ICMP packets (and causing the same delay due to no response).
> Yes, I know that no one should block *these* types of ICMP, but the sad
> fact is, some ISP's do.

Actually, there is indication that there is a firewall by sending a 
simple RST. If in fact the firewall is dropping all other packets and 
just sending RST for blocked packets destined for port 113, we must 
conclude that there is a firewall blocking access.  If the firewall 
sends a RST to all connection attempts, replies with port-unreachable 
to any UDP packets, and replies to all pings, it will appear that a 
host is connected but not running any services.  Anything other than a 
black hole response to everything would make it easy to deduce that a 
firewall is in the path.  Of course just dropping every blocked packet 
will seem to indicate that there is no host or firewall in the path, 
but you cannot be selective about this.


Regards,                         Phone:  (250)387-8437
Cy Schubert                        Fax:  (250)387-5766
Team Leader, Sun/Alpha Team   Internet:  Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC




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?200105281233.f4SCXJE11964>