12 Oct
2020
12 Oct
'20
4:21 a.m.
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.
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.
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.
So all regular operation does is raise the bar; it is no (and can be no)
guarantee.
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.
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.
Naturally since I put in the extra code, it's been fine... Maddening.
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.
------------------------------------------------------------------------
On 10/11/20 7:24 PM, Johnny Billquist wrote:
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.
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.
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.
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.
? Johnny
------------------------------------------------------------------------
On 2020-10-11 22:39, Thomas DeBellis wrote:
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.
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!!)
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.
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:
??? 0: purgatorio 0.0.0.0:0 (Rx: 977(1107) Tx: 558 Fw: 419 (Drop rx:
??? 688)) Active: 1 Throttle: 0(015)
??? 1: legato aa.bb.cc.dd:_4711_[Ov: 0, Nov: 560, Lst: 0 (Rx: 558(560)
??? Tx: 419 Fw: 558 (Drop rx: 2)) Active: 1 Throttle: 0(167)
I doubt anybody else has ever had this, but if you do, then speak
up.? Meanwhile, I'll get my changes back to Johnny.
> ------------------------------------------------------------------------
>
>
> 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?
>
>
> 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.
> ---
> Supratim Sanyal, W1XMT
> 39.19151 N, 77.23432 W
> QCOCAL::SANYAL via HECnet
>
>> ------------------------------------------------------------------------
>>
>> On 10/10/20 4:50 PM, Paul Koning wrote:
>>
>> I'll have to look at your work, have not done that in a long time.
>>
>> 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.
>>
>> 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.
>>
>> ????paul
>>> ------------------------------------------------------------------------
>>>
>>> On Oct 10, 2020, at 5:11 AM, Rob
>>> Jarratt<robert.jarratt at ntlworld.com>? wrote:
>>>
>>> Hello Everyone,
>>> ? 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.
>>> ? 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.
>>
>>