<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>So all regular operation does is raise the bar; it is no (and can
be no) guarantee.<br>
</p>
<div class="moz-cite-prefix">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>
</div>
<div class="moz-cite-prefix">
<p>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.</p>
<p>Naturally since I put in the extra code, it's been fine...
Maddening.</p>
<p>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>
</p>
</div>
<blockquote type="cite"
cite="mid:6105ae9d-d3b8-b6d6-e390-01d10576b4e0@softjar.se">
<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>
<br>
<blockquote type="cite">------------------------------------------------------------------------
<br>
<br>
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>
<br>
<blockquote type="cite">------------------------------------------------------------------------
<br>
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">------------------------------------------------------------------------
<br>
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>
<br>
Hello Everyone,
<br>
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.
<br>
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.
<br>
</blockquote>
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>