HELP! Mysterious socket 843/tcp listening on CURRENT system

[Alexander V. Chernikov]

15.09.2015, 10:48, "O. Hartmann" <ohartman at zedat.fu-berlin.de>:
> On Tue, 15 Sep 2015 10:21:21 +0300
> Kimmo Paasiala <kpaasial at gmail.com> wrote:
>
>>  On Tue, Sep 15, 2015 at 10:06 AM, O. Hartmann
>>  <ohartman at 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?

> 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"