On Oct 10, 2020, at 5:55 PM, Rob Jarratt <robert.jarratt at ntlworld.com> wrote: 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. My principal aim was to make it portable to as many machines as possible. Not only from a language point of view but also from a resources point of view. For both those reasons C is indeed a better language. So, yes, I think my implementation is likely to work on a wider range of machines. I have not written it to be particularly fast though, my implementation is quite na?ve in many respects, because I wanted to keep it simple. I do want to support more parts of DECnet, but time is the usual enemy here. Regards Rob

------------------------------------------------------------------------ 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 here https://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. > >

------------------------------------------------------------------------ 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

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. >>>> >>>> >

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?"

root 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. So Yes, if you've you got roots running around, grabbing ports comes into scope, which could be Bad.? Yet this invokes my standard root rant. root, along with setuid/setguid, is quite possibly one of the worst security ideas I know of.? The only equivalent bad idea I can think of offhand is [1,4] under Tops-10 and maybe JACCT.? Certain implementations of the POSIX interface (such as the OMVS segment under z/OS) have actually eliminated root. I myself don't have root 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 nice/renice in the EXEC; you need to have enabled Wheel or Operator capability in order to use SPRIW% to set yourself into the dregs queue. This seemed counter-intuitive, so if my ACJ is running, it catches the SPRIW% and allows you to put yourself into dregs. So the monitor changes are done, but the EXEC changes are not.? Sigh...

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.

My belief is that '*' 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. '$' 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.

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...

> ------------------------------------------------------------------------ > On 10/12/20 4:49 AM, Johnny Billquist wrote: > > 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. > > 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. > > 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. > (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). > > ? Johnny >> ------------------------------------------------------------------------ >> On 2020-10-12 04:21, Thomas DeBellis wrote: >> >> 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. >>>>>>>