Date: Tue, 15 Sep 2015 12:28:04 +0200 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: "Alexander V. Chernikov" <melifaro@freebsd.org> Cc: Kimmo Paasiala <kpaasial@gmail.com>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system Message-ID: <20150915122804.60c2f5a6@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <1483331442311155@web17h.yandex.ru> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <CA%2B7WWSdW_JTL%2BKt_WcaLVDVLhtBnUGkXXNJezvTSkDy4rHLjPw@mail.gmail.com> <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> <1483331442311155@web17h.yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 Sep 2015 12:59:15 +0300 Alexander V. Chernikov <melifaro@freebsd.org> wrote: > > > 15.09.2015, 10:48, "O. Hartmann" <ohartman@zedat.fu-berlin.de>: > > 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. 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? The syntax and layout of the rc.firewall rc-script is ambigous and confusing. The script added to firewall_type="XXXXXX" in rc.conf is a direct ipfw script containing non-expanded ipfw commands. There is nothing about variable expanding from rc.conf or rc.conf.local. In the logic of the other firewall type, OPEN, WORKSTATION et cetera, one might think the rc.firewall script is utilising the variables set in rc.conf. But nothing so far! For me, that looked more like a logic break of the concept. The people at FreeBSD usually do a great work by defining default values. I like it to use the default settings done by the original rc.firewall script, especially for the loopback device and IPv6 and IPv4 enbaling/disabling. Using "firewall_type=" in rc.conf leaves you alone with a raw, unexpanded script which doesn't make use of the settings in rc.conf. The problems I face are sometimes related to syntax errors when creating ipfw tables - as this is done by the rc.firewall script preventing non-official IP ranges accessing the intranetwork. Somehow I can "service ipfw restart" the original-left-over service when using only type WORKSTATION or so - the scripts handle gracefully the restart, no established connectiong gets dropped off, no errors occur when creating/flushing tables. Using the "wooden" and clumsy firewall_type="" where the added set of rules is a pure ipfw-command script - the problems arise very quickly. > > > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150915122804.60c2f5a6>