<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>These are all excellent points. I think that one key take-away
for all here is that external security is not an on/off matter,
but rather requires some amount of (sometimes complex) analysis to
see what risks are worth managing and what a proposed control
actually does do to mitigate the risk. What also must not be
overlooked is whether the solution itself exposes an additional
attack surface or whether the failure mode is worse. A nagging
thought of any distributed controls analysis must be, "What did I
miss?"<br>
</p>
<p><font size="+1"><tt>root</tt></font> access is perfect example of
this; I had completely ignored multitenancy. Perhaps that's not
surprising given that these are hobby systems and my user
populations number in the single digits, all either behind a
firewall or connecting through a VPN. However, it is surprising
given that the systems software I hack on Tops-20 extensively
assumes a multi-user environment.</p>
<p>So Yes, if you've you got roots running around, grabbing ports
comes into scope, which could be Bad. Yet this invokes my
standard <font size="+1"><tt>root</tt></font> rant. <font
size="+1"><tt>root</tt></font>, along with <font size="+1"><tt>setuid/setguid</tt></font>,
is quite possibly one of the worst security ideas I know of. The
only equivalent bad idea I can think of offhand is <font
size="+1"><tt>[1,4]</tt></font> under Tops-10 and maybe <font
size="+1"><tt>JACCT</tt></font>. Certain implementations of the
POSIX interface (such as the OMVS segment under z/OS) have
actually eliminated root.<br>
</p>
<p>I myself don't have <font size="+1"><tt>root</tt></font> users.
Anywhere. It's just me. On the shared systems (Tops-20), I've
modified the access control job to implement such functionality as
necessary. One odd case of this is implementing <font size="+1"><tt>nice/renice</tt></font>
in the <font size="+1"><tt>EXEC</tt></font>; you need to have
enabled <font size="+1"><tt>Wheel</tt></font> or <font size="+1"><tt>Operator</tt></font>
capability in order to use <font size="+1"><tt>SPRIW%</tt></font>
to set yourself into the <font size="+1"><tt>dregs</tt></font>
queue. This seemed counter-intuitive, so if my <font size="+1"><tt>ACJ</tt></font>
is running, it catches the <font size="+1"><tt>SPRIW%</tt></font>
and allows you to put yourself into <font size="+1"><tt>dregs</tt></font>.
So the monitor changes are done, but the <font size="+1"><tt>EXEC</tt></font>
changes are not. Sigh...<br>
</p>
<div class="moz-cite-prefix">The rate limiting is a good idea;
they'll do something about your local Ethernet not being flooded.
However, if the DoS is against all ports on the external IP
interface or somehow that NAT'ing router gets saturated, you are
still effectively offline.</div>
<div class="moz-cite-prefix">
<p>My belief is that <font size="+1"><tt>'*'</tt></font> would
not have fixed this particular situation. The receiving router
was getting packets on a port for which it had no forwarding
rule, so those got dropped. <font size="+1"><tt>'$'</tt></font>
stomps the outgoing port back to the configured port, so the
right thing happens. This suggests that the port was getting
mangled between the router and bridge, probably by the router.<br>
</p>
</div>
<div class="moz-cite-prefix">I put the extra instrumentation in so
that I had some good solid data to report to the router vendor in
order to open a trouble ticket. Naturally, I haven't seen a
single blessed thing since doing this; all packets are
unremarkable. Not even a whiff of a stomp. Maddening...<br>
</div>
<blockquote type="cite"
cite="mid:d56ff100-2c69-9fa6-2be7-b6ea52995350@softjar.se">
<hr width="100%" size="2">On 10/12/20 4:49 AM, Johnny Billquist
wrote:<br>
<br>
From my point there is a problem. I know that systems with many
users who do not have root access is becoming less common, but for
that situation, if you just allow a connection from any port,
anyone on such a machine can then make the connection, and get
some kind of access to your network. I'm not particularly fond of
such an opening up in general.
<br>
<br>
IP spoofing can be used to just inject packets, but you will
normally not get anything back, so it's a bit more limited in use.
But there is always compromises. I don't want to go with full
blown encryption and so on, nor TCP, so that's an open attack
vector for DoS at at least. But if someone wants to DoS HECnet
then fine. Nobody will die if HECnet isn't working for a while.
The bridge also rate limits packets, so they will not be able to
kill my local ethernet.
<br>
<br>
And the point of the NAT changing port numbers on packets is that
it does it in both directions. If it were to do it in only one
direction, it have broken network connectivity in general, and
nothing works anymore. I doubt that is very common. So no, I would
say that normally, with the '*' prefix, your traffic will then
work just as expected.
<br>
(Think of a simple thing like DNS. It uses UDP, sends out queries
and expects packets back on the same port. NAT can certainly sit
between, and change the source port of outgoing packets, but it
then have to also change the destination port on incoming packets,
so that in the end, for both sides, it appears as if the NAT thing
wasn't there, or else you wouldn't even have DNS).
<br>
<br>
Johnny
<br>
<blockquote type="cite">
<hr width="100%" size="2">On 2020-10-12 04:21, Thomas DeBellis
wrote:
<br>
<br>
Yes, I thought about the security very carefully and decided
that, depending on the failure, there is no increase in attack
surface and no increase in the ramifications of failure mode as
a result of attack.
<br>
<br>
In the case of a machine being NAT'ed and behind a firewall, it
is only going to get packets forwarded for a particular port, so
there is no change in attack surface of the Internet facing IP
address.
<br>
<br>
By the time the packet gets to the attacked machine, assuming
there are no other external ports being forwarded and you are
still restricting on IP address, then the traffic is likely
coming from one place and therefore that control remains as good
as it was; no comments on how 'good' good is... What I'm trying
to say here is that if an attacker is going to lie about the
port, you really can't rule out an IP spoof.
<br>
<br>
So all regular operation does is raise the bar; it is no (and
can be no) guarantee.
<br>
<br>
The problem with the '*' prefix is that if you sent the packets
back with a corrupted received port, then they effectively
vanish because the transmitting firewall has only been
configured with a forwarding rule for a particular port. The '$'
prefix forces the received port to get overwritten with the
configured port if it is corrupted; counts are tallied either
way; I also save the last overwritten port.
<br>
<br>
The thing to do would have been to snoop the traffic on the
local Ethernet from another machine to see what the actual port
was; this would rule out any kind of OS corruption. However, I
think that unlikely because one of the things I tried was
compiling and running the bridge under Linux and Mac OS X which
have slight different bpf interfaces. Swift did find some minor
things to become annoyed about which gcc did not comment on;
nothing of any real significance.
<br>
<br>
Naturally since I put in the extra code, it's been fine...
Maddening.
<br>
<br>
I personally had never seen such port smashing before, but I
don't remember how long I've been doing port forwarding and to
what extent. Any server that is listening on a port will never
see packets with smashed ports. However, usually what I run is
IPsec to trusted sites because I don't want NAT'ing getting in
the way.
<br>
<blockquote type="cite">
<hr width="100%" size="2">On 10/11/20 7:24 PM, Johnny
Billquist wrote:
<br>
<br>
While I don't think we ever figured out what was changing
ports, it is a well known behavior of NAT routers that the can
change the source port of UDP packets. It is often possible to
configure things in such a way that it don't happen, but you
need to know where it happens first, before that can be done.
<br>
<br>
I actually have had, for many years, a solution in the bridge
to work around this, if ever needed because it is outside of
the control of either party. I thought I had mentioned it, but
maybe I haven't.
<br>
The character '*' before a hostname means that the entry will
accept packets from any port from the remote machine, and
packets sent back will be sent to the same port packets are
coming in on.
<br>
<br>
But it's a noticeable decrease of security that I'm not too
happy about, so I tend to try and make people figure out how
to configure their NAT first.
<br>
<br>
Johnny
<br>
<blockquote type="cite">
<hr width="100%" size="2">On 2020-10-11 22:39, Thomas
DeBellis wrote:
<br>
<br>
That reminds me of something else. I had been using
Johnny's bridge for a number of months, when all of the
sudden, I got some decidedly odd behavior.
<br>
<br>
While my router was dutifully forwarding the correct port to
the right machine, by the time the bridge got a hold of the
port, the port had gotten overwritten by ... somebody ...
Bob and I spent some trying to figure out what was going on;
the typical stuff, reboot this, re-power that, what has
changed? (absolutely nothing!!)
<br>
<br>
I couldn't figure it out and after 'a while' became very
annoyed (not that it takes much). I modified the bridge to
have a different prefix character ('$') in the bridge
stanza. This causes the bridge to stomp the correct port
in, always. There is some extra logic to count packets
where the port had to be overwritten and display it, Etc.
<br>
<br>
So that all worked. And to look at the counts, sometimes an
override is necessary and then there are the other times.
Lately, it hasn't, viz:
<br>
<br>
0: purgatorio 0.0.0.0:0 (Rx: 977(1107) Tx: 558 Fw: 419
(Drop rx:
<br>
688)) Active: 1 Throttle: 0(015)
<br>
1: legato aa.bb.cc.dd:_4711_[Ov: 0, Nov: 560, Lst: 0
(Rx: 558(560)
<br>
Tx: 419 Fw: 558 (Drop rx: 2)) Active: 1 Throttle: 0(167)
<br>
<br>
I doubt anybody else has ever had this, but if you do, then
speak up. Meanwhile, I'll get my changes back to Johnny.
<br>
<blockquote type="cite">
<hr width="100%" size="2">This reminds me - I had ROUT20
on Hecnet for months - first on Linux then on FreeBSD -
worked great with Bob Armstrong at the other end. I took
it off due to reasons I do not remember fully - but was
probably when Bob discovered something when we were trying
DDCMP ... maybe Bob or Paul remembers more?
<br>
<br>
<br>
To be honest, I have never actually looked at PyDECnet!
But I should again acknowledge that you have provided me
with invaluable help and insight.
<br>
---
<br>
Supratim Sanyal, W1XMT
<br>
39.19151 N, 77.23432 W
<br>
QCOCAL::SANYAL via HECnet
<br>
<blockquote type="cite">
<hr width="100%" size="2">On 10/10/20 4:50 PM, Paul
Koning wrote:
<br>
<br>
I'll have to look at your work, have not done that in a
long time.
<br>
<br>
My 2 cents worth: we're aiming at different things. I
set out to build a full DECnet implementation in Python,
with emphasis on supporting all the parts of the
architecture in a very straightforward way. Efficiency
was very much a secondary consideration. As it happens,
the performance is not bad, adequate for a lot of
purposes.
<br>
<br>
A C based implement such as you did is somewhat harder
to write, but much more efficient. For anyone who is
running on a slow machine, or under heavy load, your
work is likely to be the right answer. Also, of course,
if you want to run on a machine where Python is not
available or not efficient.
<br>
<br>
paul
<br>
<blockquote type="cite">
<hr width="100%" size="2">On Oct 10, 2020, at 5:11 AM,
Rob Jarratt<a class="moz-txt-link-rfc2396E" href="mailto:robert.jarratt@ntlworld.com"><robert.jarratt@ntlworld.com></a> wrote:
<br>
<p>Hello Everyone,
</p>
<p> As some of you may be aware, I have been writing
my own DECnet router. Since the last formal release
a few years ago I have added a few things, the
details are herehttps://github.com/rjarratt/Route20.
These were all on the Dev branch, which I know a few
people have tried. I have been running the Dev
branch for a long time myself, so I am sure it is
stable. All I have done really is make the current
Dev branch “official” by merging it to the master
branch.
</p>
<p> I know Paul has been much more active than me
lately on this front, so I am probably a bit behind,
but if anyone would like to take a look that would
be great.
</p>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>