HELP! Mysterious socket 843/tcp listening on CURRENT system
O. Hartmann
ohartman at zedat.fu-berlin.de
Tue Sep 15 18:43:12 UTC 2015
Am Tue, 15 Sep 2015 21:08:51 +1000 (EST)
Ian Smith <smithi at nimnet.asn.au> schrieb:
> On Tue, 15 Sep 2015 09:47:57 +0200, O. Hartmann wrote:
> > 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.
>
> Without seeing the ruleset you've chosen to implement, it's impossible
> to speculate on what might be wrong with it. Sanitise where necessary.
I'm now with the box in question and I'm close to give up and get back to PF.
I will attach the ruleset at the end of the message.
>
> > 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.
"crazy" is some kind of understatement ... For starters or those migrating from other
filters, the handbook might be a good starting point. But reading about port 37 when it
comes to NTP let me think twice ... :-(
>
> ipfw(8) is pretty much your only friend - apart from helpful people on
> freebsd-ipfw at 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.
Yes, but there is regarding slightly complex networking (multihomed systems, systems with
NIC and WiFi where WiFi should also serve guests ...). NAT is worse described and I
believe regarding in-kernel NAT, there is something missing, but I will report my
experiences below with the rulesets.
>
> > 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.
The box (CURRENT as of r2878XX) was completely wrecked and inaccessible from the outer
world. My abilities to investigate are limited and the setup isn't as simple: pppoed on
the outbound interface (re0, which gets cloned to tun0 and aquires an IP from the ISP. No
clue how to figure out the ${if_isp} in case of restarting ppp, which leaves me very
often with tun1 or tun2 in case the tun-previous doesn't get destroyed fast enough), a
NIC to the server network, inbound, a WiFi (ath0) NIC for WLAN which is supposed to deal
with two networks, one for the local staff/privileged and one for guests.
>
> > 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?
Well, I was now for several years, more than a decade, with pf. pf is OpenBSD and FreeBSD
utilises an older branch. My thinking is that if FreeBSD is getting more squeezed out of
developers, the effords invested into foreign firewall code might be reduced. On the
other hand, some benchmarks showed that ipfw is superior in many scenarios.
Dealing in the department with ipfw where the host has a single NIC and is part of a
larger network with gateway, DNS and so on, it seemed easy for me to utilise ipfw for my
requirements.
At home and at a special location with a ISP connection via DSL modem, NAT came into play
and things changed dramatically, but that is maybe something that resulted from a big
misunderstanding of mine.
>
> > @delphi: I will give an answer as soon I gain access to the box again.
> >
> > Regards and thanks,
> >
> > oh
>
> Good luck,
>
> Ian
So, here I am.
First, I use a patched original rc.firewall-script:
--- rc.firewall 2015-08-11 23:18:21.673941000 +0200
+++ rc.firewall.local 2015-08-11 23:19:29.827737000 +0200
@@ -543,7 +543,8 @@
;;
*)
if [ -r "${firewall_type}" ]; then
- ${fwcmd} ${firewall_flags} ${firewall_type}
+ #${fwcmd} ${firewall_flags} ${firewall_type}
+ . ${firewall_type}
fi
;;
esac
That makes the original code of rc.firewall being executed, the rc-variables sucked in
and expanded and the additional script then is a #!/bin/sh shebanged script, which has
the following content, see below.
Now some fun parts. The below ruleset seems to be sensitive where the NAT rule is placed.
On local network, either NAT at the end of the ruleset list or at the beginning (as
shown) doesn't matter - but for any outgoing connection, placing it very late (at the
and) is lethal.
Years ago I used ipfw before switching to pf and I recall that if a packet is getting
processed by NATD (means it is diverted), it has to be "reinjected" into the pipeline for
further processing - so any succseeding rule would apply. The only hint I found with the
in-kernel NAT was the OIB
net.inet.ip.fw.one_pass=0|1
Setting this OIB to 0 breaks the ruleset below - no outgoing (real-world IP addresses)
connection is possible. So I stay with 1 and that implies that after the incoming packet
gets processed by NAT and then the ipfw pipe terminates, nothing else then ...
[...]
#!/bin/sh
# ISP interface, identical with firewall_nat_interface, from rc.conf
if_isp=${firewall_nat_interface} #(expands to tun0, given by pppoed)
if_lan0="em0"
# WiFi
if_wlan0="wlan0"
# WiFi guests
if_wlan1="wlan1"
net_local="192.168.0.1/24"
net_wlan="192.168.2.1/24"
net_good="{ 192.168.0.1/24, 192.168.2.1/24 }"
net_guest="192.168.254.1/24"
server_gate="192.168.0.1"
tcp_services="22,80,443,5432,9734"
udp_services=""
icmp_services="0,8"
#################################################################
# Setup in kernel NAT
#################################################################
${fwcmd} nat 1 config if ${if_isp} log reset same_ports \
redirect_port tcp ${server_gate}:22 22 redirect_port tcp ${server_gate}:443 443 \
redirect_port tcp ${server_gate}:5432 5432 redirect_port tcp ${server_gate}:9734
9734
#################################################################
# Bad address table
#################################################################
BAD_ADDRESS_TBL=13
#
${fwcmd} table ${BAD_ADDRESS_TBL} create
${fwcmd} table ${BAD_ADDRESS_TBL} flush
#
${fwcmd} table ${BAD_ADDRESS_TBL} add 192.168.0.0/16 #RFC 1918 private IP
${fwcmd} table ${BAD_ADDRESS_TBL} add 172.16.0.0/12 #RFC 1918 private IP
${fwcmd} table ${BAD_ADDRESS_TBL} add 10.0.0.0/8 #RFC 1918 private IP
${fwcmd} table ${BAD_ADDRESS_TBL} add 127.0.0.0/8 #loopback
${fwcmd} table ${BAD_ADDRESS_TBL} add 0.0.0.0/8 #loopback
${fwcmd} table ${BAD_ADDRESS_TBL} add 169.254.0.0/16 #DHCP auto-config
${fwcmd} table ${BAD_ADDRESS_TBL} add 192.0.2.0/24 #reserved for docs
${fwcmd} table ${BAD_ADDRESS_TBL} add 204.152.64.0/23 #Sun cluster interconnect
${fwcmd} table ${BAD_ADDRESS_TBL} add 224.0.0.0/3 #Class D & E multicast
#
${fwcmd} add deny all from any to "table(${BAD_ADDRESS_TBL})" via ${if_isp}
#################################################################
# Antispoof
#################################################################
${fwcmd} add deny log ip from any to any not verrevpath in
#################################################################
# NAT
#################################################################
#${fwcmd} add nat 1 all from any to any via ${if_isp}
#################################################################
# Reassemble
#################################################################
${fwcmd} add reass all from any to any in
#################################################################
# NAT
#################################################################
${fwcmd} add nat 1 all from any to any via ${if_isp}
#################################################################
# dynamic ruleset
#################################################################
${fwcmd} add check-state
#################################################################
# Established/fragmented
#################################################################
${fwcmd} add deny tcp from any to any established
${fwcmd} add deny tcp from any to any frag
#################################################################
# Allow ISP's DHCP
#################################################################
${fwcmd} add pass log udp from ${if_isp} to any 67 out via ${if_isp} keep-state
${fwcmd} add pass log udp from any to ${if_isp} 67 in via ${if_isp} keep-state
#################################################################
# Local net/guest net
#################################################################
#${fwcmd} add pass all from any to any via ${if_lan0}
#${fwcmd} add pass all from any to any via ${if_wlan0}
#${fwcmd} add pass all from any to any via ${if_wlan1}
#################################################################
# Allow outgoing connections
#################################################################
${fwcmd} add pass tcp from ${net_good} to any setup keep-state
${fwcmd} add pass udp from ${net_good} to any keep-state
${fwcmd} add pass icmp from ${net_good} to any keep-state
#################################################################
# Allow network guests
#################################################################
${fwcmd} add pass tcp from ${net_guest} to any via ${if_isp} setup keep-state
${fwcmd} add pass udp from ${net_guest} to any via ${if_isp} keep-state
${fwcmd} add pass icmp from ${net_guest} to any via ${if_isp} icmptypes 0,8 keep-state
#################################################################
# Traffic to local server
#################################################################
${fwcmd} add pass tcp from any to ${server_gate} ${tcp_services} setup keep-state
${fwcmd} add pass udp from any to ${server_gate} ${udp_services} keep-state
${fwcmd} add pass icmp from any to ${server_gate} icmptypes ${icmp_services} keep-state
#################################################################
# Deny and log everything else
#################################################################
${fwcmd} add deny log all from any to any
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20150915/a3da0027/attachment.bin>
More information about the freebsd-net
mailing list