Date: Tue, 15 Sep 2015 20:40:04 +0200 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: Ian Smith <smithi@nimnet.asn.au> Cc: Kimmo Paasiala <kpaasial@gmail.com>, freebsd-net@freebsd.org Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system Message-ID: <20150915204004.196bccb0.ohartman@zedat.fu-berlin.de> In-Reply-To: <20150915201451.L90924@sola.nimnet.asn.au> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <CA%2B7WWSdW_JTL%2BKt_WcaLVDVLhtBnUGkXXNJezvTSkDy4rHLjPw@mail.gmail.com> <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> <20150915201451.L90924@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/qbHkjmReRi98Voaow1Ut3Nn
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Am Tue, 15 Sep 2015 21:08:51 +1000 (EST)
Ian Smith <smithi@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@gmail.com> wrote:
> >=20
> > > 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 tro=
uble
> > > > 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 o=
ut 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 outs=
ide world.
> > > >
> > > > Anyone any suggestions?
> > > >
> > > > Thanks in advance,
> > > > Oliver
> > >=20
> > > As delphij@ noted it's most likely something that uses rpcbind(3). W=
hy
> > > are your filter rules allowing unknown ports to be open to the
> > > internet? Don't you have a default deny policy in place?
> >=20
> > Hello.
> > Many thanks for the fast response.=20
> >=20
> > I switched recently from PF to IPFW and utilise in-kernel NAT via liba=
lias. I
> > think the "wooden" concept of rules made me penetrate the IP filter an=
d 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 fro=
m 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 bunc=
h of
> > filterings walls I create.
>=20
> Without seeing the ruleset you've chosen to implement, it's impossible=20
> 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 P=
F.
I will attach the ruleset at the end of the message.
>=20
> > 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.
>=20
> Yes, the handbook IPFW section is still crazy after all these years,=20
> 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 por=
t 37 when it
comes to NTP let me think twice ... :-(=20
>=20
> ipfw(8) is pretty much your only friend - apart from helpful people on=20
> freebsd-ipfw@freebsd.org - but it is comprehensive and almost always=20
> 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 describ=
ed and I
believe regarding in-kernel NAT, there is something missing, but I will rep=
ort my
experiences below with the rulesets.
>=20
> > At the moment I have no access to the box since IPFW and it's reload/r=
estart
> > mechanism (etc/rc.d/ipfw) seems to be very instable when restartet too=
often.
>=20
> 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 fro=
m the outer
world. My abilities to investigate are limited and the setup isn't as simpl=
e: pppoed on
the outbound interface (re0, which gets cloned to tun0 and aquires an IP fr=
om the ISP. No
clue how to figure out the ${if_isp} in case of restarting ppp, which leave=
s 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 sup=
posed to deal
with two networks, one for the local staff/privileged and one for guests.
>=20
> > I did it serveral times with moderate delays of several seconds or min=
utes
> > inbetween and now the box is "gone". Checking with nmap, port 22/tcp
> > sometimes is open, then closed again. This is also very weird.
> >=20
> > IPWF seems not to be right choice, even if it is FreeBSD native.
>=20
> It's not the right choice unless you're prepared to study how it needs=20
> to be used, to the point where you can follow any flows through the=20
> ruleset. It's a compiled virtual machine language, suiting some folks=20
> better than others, rather than pf (or ipf) higher-level languages.
>=20
> /etc/rc.firewall shows far more sane ways to begin with a secure=20
> firewall than those 'stateful at any cost' handbook examples.
>=20
> True, there are few good published examples of using ipfw with nat,=20
> statefully, in an easily understood method. Hopefully ongoing work.
>=20
> 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 OpenB=
SD and FreeBSD
utilises an older branch. My thinking is that if FreeBSD is getting more sq=
ueezed out of
developers, the effords invested into foreign firewall code might be reduce=
d. 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 utilis=
e 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.
>=20
> > @delphi: I will give an answer as soon I gain access to the box again.
> >=20
> > Regards and thanks,
> >=20
> > oh =20
>=20
> Good luck,
>=20
> 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-variable=
s 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 r=
ule is placed.
On local network, either NAT at the end of the ruleset list or at the begin=
ning (as
shown) doesn't matter - but for any outgoing connection, placing it very la=
te (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 th=
e pipeline for
further processing - so any succseeding rule would apply. The only hint I f=
ound with the
in-kernel NAT was the OIB
net.inet.ip.fw.one_pass=3D0|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 in=
coming packet=20
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=3D${firewall_nat_interface} #(expands to tun0, given by pppoed)
if_lan0=3D"em0"
# WiFi
if_wlan0=3D"wlan0"
# WiFi guests
if_wlan1=3D"wlan1"
net_local=3D"192.168.0.1/24"
net_wlan=3D"192.168.2.1/24"
net_good=3D"{ 192.168.0.1/24, 192.168.2.1/24 }"
net_guest=3D"192.168.254.1/24"
server_gate=3D"192.168.0.1"
tcp_services=3D"22,80,443,5432,9734"
udp_services=3D""
icmp_services=3D"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_g=
ate}:443 443 \
redirect_port tcp ${server_gate}:5432 5432 redirect_port tcp ${serv=
er_gate}:9734
9734
#################################################################
# Bad address table
#################################################################
BAD_ADDRESS_TBL=3D13
#
${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 p=
rivate IP
${fwcmd} table ${BAD_ADDRESS_TBL} add 172.16.0.0/12 #RFC 1918 p=
rivate IP
${fwcmd} table ${BAD_ADDRESS_TBL} add 10.0.0.0/8 #RFC 1918 p=
rivate 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 f=
or docs
${fwcmd} table ${BAD_ADDRESS_TBL} add 204.152.64.0/23 #Sun cluste=
r 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_i=
sp}
#################################################################
# 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} kee=
p-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 k=
eep-state
${fwcmd} add pass udp from any to ${server_gate} ${udp_services} keep-st=
ate
${fwcmd} add pass icmp from any to ${server_gate} icmptypes ${icmp_servi=
ces} keep-state
#################################################################
# Deny and log everything else
#################################################################
${fwcmd} add deny log all from any to any
--Sig_/qbHkjmReRi98Voaow1Ut3Nn
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJV+GYEAAoJEOgBcD7A/5N8hugH/0E4z5+C84vKmRoseY9JTKIP
SJ2asWoe/otpqokofmXyIEuetKE5/fzOjf42cDRu9Yr3fgB1lqoHfL6XJy6Gx+v1
bUVqiVDiBYmChYgCt0LmSKC0fTU0wDihqeyaAfiQqMZMTsUvRRU8K8ARfzCQgtYQ
MaDPQCryilfPUX4RynC2k3sg8vobTPqwDGU5xYt3tgpcQow0SBwxGh6GabX/FBo2
MkqqxHcvjQ+fC4uTC7Cg93c7r8fXf6metlzLtG9Rsjp3jZGcyxY+opjuYPQaCbuO
9+LtRv+fTsfslVEPlUm4tmAdpTA/sy5sHJ3DESBfAU5KHb60rMcpcBROJfUYiZw=
=Y6wF
-----END PGP SIGNATURE-----
--Sig_/qbHkjmReRi98Voaow1Ut3Nn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150915204004.196bccb0.ohartman>