15.09.2015, 10:48, "O. Hartmann" <ohart...@zedat.fu-berlin.de>: > On Tue, 15 Sep 2015 10:21:21 +0300 > Kimmo Paasiala <kpaas...@gmail.com> wrote: > >> On Tue, Sep 15, 2015 at 10:06 AM, O. Hartmann >> <ohart...@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
