From owner-freebsd-hackers  Thu Feb 20 10:42:08 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id KAA28834
          for hackers-outgoing; Thu, 20 Feb 1997 10:42:08 -0800 (PST)
Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA28794
          for <hackers@freebsd.org>; Thu, 20 Feb 1997 10:41:47 -0800 (PST)
Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.8.5/8.8.2) with ESMTP id NAA00331; Thu, 20 Feb 1997 13:40:27 -0500 (EST)
Message-Id: <199702201840.NAA00331@bmcgover-pc.cisco.com>
To: davidn@labs.usn.blaze.net.au
cc: hackers@freebsd.org
Subject: Re: "connection refused"
Date: Thu, 20 Feb 1997 13:40:26 -0500
From: Brian McGovern <bmcgover@cisco.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

I didn't see a reply to this, so I figured I'd toss this answer in the mix...

Wouldn't /sbin/ipfw, and associated kernel options do what you wish? Then
you can build a set of source/destination hosts/network/ports that
will have access to the server socket in question.

Also, ipfw supports a connection refused vs. not bothering to respond. The
later is preferable if you really don't want someone to know the server
is there, rather than knowing the server is there and refusing connections
on that port (makes them more likely to go off to attack another machine
rather that trying to come up with newer ways to find a way in to your
firewalled machine).

	-Brian