Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 05 Feb 2004 15:14:10 +0100
From:      Uwe Doering <gemini@geminix.org>
To:        freebsd-questions@freebsd.org
Subject:   Re: tcp blackhole and ident
Message-ID:  <40224FB2.9000506@geminix.org>
In-Reply-To: <6.0.2.0.2.20040131074525.00b3fdd8@cheyenne.wixb.com>
References:  <6.0.2.0.2.20040131072955.00b54ee8@cheyenne.wixb.com> <20040131133924.GB48307@happy-idiot-talk.infracaninophile.co.uk> <6.0.2.0.2.20040131074525.00b3fdd8@cheyenne.wixb.com>

next in thread | previous in thread | raw e-mail | index | archive | help
J.D. Bronson wrote:
> At 07:39 AM 1/31/2004, Matthew Seaman wrote:
> 
>> On Sat, Jan 31, 2004 at 07:32:36AM -0600, J.D. Bronson wrote:
>> > I have a question. I setup the following in sysctl.conf:
>> >
>> > net.inet.tcp.blackhole=2
>> > net.inet.udp.blackhole=1
>> >
>> > ..Well this works, but now I have a new issue.
>> > I run sendmail and as such, need to allow TCP 113 into this machine
>> > and yet get CONNECTION REFUSED. - I dont want to run IDENT, but
>> > need to still get the CONNECTION REFUSED...
>>
>> Run ipfw(8) or a similar firewall and set up a rule that sends an ICMP
>> reject whenever it detects an incoming connection on port 113 as part
>> of your firewall configuration.  Eg. something like:
>>
>>     01600 reset tcp from any to me dst-port 113 setup
> 
> Thanks...but I have quite a robust Cisco firewall in place ahead of the 
> freebsd machines...so I dont -need- to run ipfw...Hmmm...

You can achieve this rejection on the application level as well.  Here's 
how:

1. Run inetd with command line options '-wW' to enable libwrap support.

2. Enable inetd's internal auth service with
      auth    stream  tcp     nowait  root    internal

3. Deny auth connections in libwrap's /etc/hosts.allow, like so:
      auth : ALL : severity debug : deny
      ALL : ALL : allow

Now you have something (inetd) bound to port 113, so a connection can be 
established, but it gets dropped immediately due to the libwrap setup. 
This is sufficient to prevent timeouts on the remote end but at the same 
time leaks as little information as possible for an application level 
solution.

    Uwe
-- 
Uwe Doering         |  EscapeBox - Managed On-Demand UNIX Servers
gemini@geminix.org  |  http://www.escapebox.net



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40224FB2.9000506>