5 Apr
2019
5 Apr
'19
8:18 p.m.
Hi,
This is a partial repeat of another message addressed to individuals.
Sorry I've been incommunicado. To cut a long story short, a car crashed into our local
exchange and completely demolished it. Our internet routing failed over to 4G (dynamically
allocated IP address ironically) so our source IP addresses have changed. This should not
have affected email because we have failover there too. Due to a slight misconfiguration,
this didn't happen properly. I've only just noticed with a whole load of messages
bouncing back to me from our email server.
So, as a result, at least until end of Sunday, I won't be able to accept incoming
DECnet over TCP connections to our fixed addresses. I notice that area 46 is connected via
31. PIVAX0 on 29.200 is currently connectionless though.
Incidentally, gmail doesn't seem to care about SPF configuration (or is yet to see my
updated value) and so is treating mail to it from me via a backup route as spam and
blocking it. This may fix itself shortly.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Johnny Billquist
Sent: 04 April 2019 23:32
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Minimal Requirements
On 2019-04-04 15:28, Paul Koning wrote:
So far that's mostly what we have, yes.
I have from time to time considered maybe adding a password on the link, as DECnet do
support that.
But so far, there has never been a single instance of someone actually trying to connect
some unknown node with DECnet on any link of mine. But it is most likely just because
pretty much any remote script-kid just have no clue that DECnet even exists, what to do
with it, or anything else.
Also, the worst I think anyone could do would just be disrupting DECnet.
But maybe someone else can think of anything else potentially interesting someone could do
by hijacking a circuit.
My biggest issue with those link passwords in RSX is that I think I can only have one
password, and it will be applied to all links. And I also think that maybe I had to turn
it on on all links if I turn it on on any.
But if people are willing to experiment some, we could test enabling it.
For the bridge, though, it requires that both ends are known. No wildcard connections
allowed.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Apr 4, 2019, at 7:53 AM, Supratim Sanyal
<supratim at riseup.net> wrote:
On 4/4/19 6:12 AM, Keith Halewood wrote:
Does that mean anyone can connect to HECnet without any authentication? Or is DECnet
node init authentication used?
"Security by obscurity" only goes so far. Is it good enough for HECnet?
Hi,
I'm pretty sure that a TCP listen doesn't care who connects to it on VAX
Multinet. UDP is a different matter.
For example, there's a listener device set up with a 1.1.1.1 address on DUNE here.
PIVAX0 connects to it from a completely different address. I use access controls on the
router to restrict just who is allowed to connect to it.
If you want I can set up another incoming line/circuit and you can connect to it. I'm
in area 29 FYI.
I have listeners waiting on 0.0.0.0. Yes, MULTINET does not seem to care what address
connections come in from.