From owner-freebsd-net@freebsd.org Tue Sep 15 09:59:42 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 32DB4A04129 for ; Tue, 15 Sep 2015 09:59:42 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward11h.cmail.yandex.net (forward11h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::9c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A640B1E4D for ; Tue, 15 Sep 2015 09:59:41 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from web17h.yandex.ru (web17h.yandex.ru [84.201.186.46]) by forward11h.cmail.yandex.net (Yandex) with ESMTP id CC0F3213B5; Tue, 15 Sep 2015 12:59:16 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web17h.yandex.ru (Yandex) with ESMTP id 01177C216BA; Tue, 15 Sep 2015 12:59:15 +0300 (MSK) Received: by web17h.yandex.ru with HTTP; Tue, 15 Sep 2015 12:59:15 +0300 From: Alexander V. Chernikov Envelope-From: melifaro@ipfw.ru To: O. Hartmann , Kimmo Paasiala Cc: FreeBSD Net In-Reply-To: <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system MIME-Version: 1.0 Message-Id: <1483331442311155@web17h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 15 Sep 2015 12:59:15 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r 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 09:59:42 -0000 15.09.2015, 10:48, "O. Hartmann" : > 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. Well, ipfw(8) rc script might really need some face-lifting, but I wonder what is the source of instability might be. It would be great to hear more details so we can do something to prevent that? > 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 > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"