Date: Tue, 15 Sep 2015 21:08:51 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: "O. Hartmann" <ohartman@zedat.fu-berlin.de> Cc: Kimmo Paasiala <kpaasial@gmail.com>, freebsd-net@freebsd.org Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system Message-ID: <20150915201451.L90924@sola.nimnet.asn.au> In-Reply-To: <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <CA%2B7WWSdW_JTL%2BKt_WcaLVDVLhtBnUGkXXNJezvTSkDy4rHLjPw@mail.gmail.com> <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 Sep 2015 09:47:57 +0200, O. Hartmann wrote: > On Tue, 15 Sep 2015 10:21:21 +0300 > Kimmo Paasiala <kpaasial@gmail.com> wrote: > > > On Tue, Sep 15, 2015 at 10:06 AM, O. Hartmann > > <ohartman@zedat.fu-berlin.de> 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. Without seeing the ruleset you've chosen to implement, it's impossible to speculate on what might be wrong with it. Sanitise where necessary. > 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. Yes, the handbook IPFW section is still crazy after all these years, despite ongoing attempts to limit the damage. Best just ignore it. ipfw(8) is pretty much your only friend - apart from helpful people on freebsd-ipfw@freebsd.org - but it is comprehensive and almost always correct, in my 17 years using it, and I'm a long way from an expert. > 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. That needs reporting as a bug; if that's true on 11-CURRENT, it's new. > 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. It's not the right choice unless you're prepared to study how it needs to be used, to the point where you can follow any flows through the ruleset. It's a compiled virtual machine language, suiting some folks better than others, rather than pf (or ipf) higher-level languages. /etc/rc.firewall shows far more sane ways to begin with a secure firewall than those 'stateful at any cost' handbook examples. True, there are few good published examples of using ipfw with nat, statefully, in an easily understood method. Hopefully ongoing work. Do you have some requirement/s that pf could not provide? > @delphi: I will give an answer as soon I gain access to the box again. > > Regards and thanks, > > oh Good luck, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150915201451.L90924>