From owner-freebsd-net@freebsd.org Tue Sep 15 07:48:00 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F9E5A03676 for ; Tue, 15 Sep 2015 07:48:00 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3131289 for ; Tue, 15 Sep 2015 07:48:00 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1Zbky6-0017A6-8F>; Tue, 15 Sep 2015 09:47:58 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1Zbky6-000glR-0Q>; Tue, 15 Sep 2015 09:47:58 +0200 Date: Tue, 15 Sep 2015 09:47:57 +0200 From: "O. Hartmann" To: Kimmo Paasiala Cc: FreeBSD Net Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system Message-ID: <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 07:48:00 -0000 On Tue, 15 Sep 2015 10:21:21 +0300 Kimmo Paasiala wrote: > On Tue, Sep 15, 2015 at 10:06 AM, O. Hartmann > wrote: > > Hopefully, I'm right on this list. if not, please forward. > > > > Running CURRENT as of FreeBSD 11.0-CURRENT #3 r287780: Mon Sep 14 13:34:16 > > CEST 2015 amd64, I check via nmap for open sockets since I had trouble > > protecting a server with IPFW and NAT. > > > > I see a service (nmap) > > > > Host is up (0.041s latency). > > Not shown: 998 filtered ports > > PORT STATE SERVICE > > 843/tcp open unknown > > > > and via sockstat -l -p 843, I get this: > > ? ? ? ? tcp4 *:843 *:* > > > > I double checked all services on the server and i can not figure out what > > daemon or service is using this port. The port is exposed throught NAT (I > > use in-kernel NAT on that system). > > This service is accessible via telnet host-ip 843: > > > > Trying 85.179.165.184... > > Connected to xxx.xxx.xxx.xxx. > > Escape character is '^]'. > > > > > > Well, I feel pants-down right now since it seems very hard to find out what > > service is keeping this socket open for communications to the outside world. > > > > Anyone any suggestions? > > > > Thanks in advance, > > Oliver > > As delphij@ noted it's most likely something that uses rpcbind(3). Why > are your filter rules allowing unknown ports to be open to the > internet? Don't you have a default deny policy in place? Hello. Many thanks for the fast response. I switched recently from PF to IPFW and utilise in-kernel NAT via libalias. I think the "wooden" concept of rules made me penetrate the IP filter and expose it to the outer world. The mysterious port 843/tcp isn't the only one that is exposed, NFS is also. I have rules that block all incoming trafiic from the exposed-to-the-internet interface and should allow all traffic on the inside and local interfaces. The rulesets I utilised work so far on machines without NAT (department, bureau, etc.). The moment NAT comes into play I do not understand the way IPFW works - it seems to blow a whole into any bunch of filterings walls I create. But that is an other issue and it is most likely due to the outdated documentation (that doc still uses port 37 for NTP purposes and referes to the outdated divert mechanism using natd, see the recent handbook). The internet is also full of ambigous examples. At the moment I have no access to the box since IPFW and it's reload/restart mechanism (etc/rc.d/ipfw) seems to be very instable when restartet too often. I did it serveral times with moderate delays of several seconds or minutes inbetween and now the box is "gone". Checking with nmap, port 22/tcp sometimes is open, then closed again. This is also very weird. IPWF seems not to be right choice, even if it is FreeBSD native. @delphi: I will give an answer as soon I gain access to the box again. Regards and thanks, oh