Hey g00r00,

Would it be possible, upon sysop login, to trigger some sort of dialog to add the detected IP to the IP whitelist?

This would avoid me accidentally locking myself out when traveling. :)

Thanks!

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: monterey bbs (21:1/168)

You can do it now, without any scripting too.

(DD) Exec Door "echo %4 >><path to whitelist>"

If you want the Yes/No prompt, just add that in above it and put it your
logon menu script. Be sure to set acs to s255 so no one else gets the
question, or if you're generous, let all your users self-whitelist... ;)

-roovis

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: w0pr.win (21:4/165)

You can do it now, without any scripting too.

(DD) Exec Door "echo %4 >><path to whitelist>"

Oh shit, I'm totally gonna package this up as a mod with a proper file_id.diz and release it :P

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: monterey bbs (21:1/168)

You can do it now, without any scripting too.

(DD) Exec Door "echo %4 >><path to whitelist>"

Oh shit, I'm totally gonna package this up as a mod with a proper file_id.diz and release it :P

It is released under GPL3. ;]

-roovis

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: w0pr.win (21:4/165)

Would it be possible, upon sysop login, to trigger some sort of dialog
to add the detected IP to the IP whitelist?

This would avoid me accidentally locking myself out when traveling. :)

You could echo it to the whitelist file (its just a line by line text file) but thats kind of sloppy since you'd be adding the same IP every time you logged in and itd just create a bloated text file.

I think this is a good option to have somewhere and relatively easy to implement so lets do it!

Maybe I can make it a user flag "Whitelist Login IP" that would always whitelist the IP for users who have that flag set? Would that work for everyone? Or should it be a global setting somewhere? Maybe a menu command that went ran it would whitelist the IP?

Here is what I am thinking at the moment: A login settings option that is "Auto Whitelist: Yes/Per User" and if its set to Yes it will whitelist everyone that logs in, if its set to Per User it will only whitelist if the user flag is set.

Hows that sound? Or do you have other ideas of how it should be done?

--- Mystic BBS v1.12 A45 2020/02/17 (Windows/64)
* Origin: Sector 7 (21:1/108)

Here is what I am thinking at the moment: A login settings option that
is "Auto Whitelist: Yes/Per User" and if its set to Yes it will
whitelist everyone that logs in, if its set to Per User it will only whitelist if the user flag is set.

What would remove the whitelist entries? If one is in the habit of traveling
a lot eventually your whitelist is going to get pretty long.
Maybe you could track the IP that was last used, and if it is different unwhitelist the previous entry and whitelist the new?

|07E|10m|07b|10a|07l|10m|07e|10d |12-----------------------------------------------------
|09Black Lodge Research BBS |11blacklodgeresearch.org:4022
|11fsx|08Net: |0721:4/166 |11sci|08Net: |0777:1/133

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: Black Lodge Research BBS (21:4/166)

Here is what I am thinking at the moment: A login settings option tha is "Auto Whitelist: Yes/Per User" and if its set to Yes it will whitelist everyone that logs in, if its set to Per User it will only whitelist if the user flag is set.

What would remove the whitelist entries? If one is in the habit of traveling a lot eventually your whitelist is going to get pretty long. Maybe you could track the IP that was last used, and if it is different unwhitelist the previous entry and whitelist the new?

If you are auto whitelisting all of your users then it probably wouldn't hurt to just delete the whitelist from time to time and let Mystic rebuild it as they log in.

Mystic does already save the users known User IP, hostname, and country of origin when a user logs out of Mystic. The last known should be available at the point where its auto whitelisting and I could have it try to remove the last known IP before it adds it if that is something people think is beneficial.

But it also means that the IP would be removed when maybe its an IP you wanted to keep in there, like your home IP would be removed because that was your last login prior to your travel. Or your work IP is removed because it was your last login location. I am trying to think of any downsides to doing it this way.

--- Mystic BBS v1.12 A45 2020/02/17 (Windows/64)
* Origin: Sector 7 (21:1/108)

But it also means that the IP would be removed when maybe its an IP you wanted to keep in there, like your home IP would be removed because that was your last login prior to your travel. Or your work IP is removed because it was your last login location. I am trying to think of any downsides to doing it this way.

And then be re-added when you logged in the first time from home.

I honestly don't really use the whitelist much I have only had 1 user get blocked and it was because they were using SSH directly and didn't know they had to hit enter key immediately to get the connection to work so had tried several times in a row. As time goes by this may become more of an issue but so far it hasn't been.

I suppose it really depends on which is worse, having entries in your
whitelist that might not be you or your user (like some hotel, or internet cafe, vpn endpoint, etc) or having a user get potentially blacklisted.

A blacklisted user will probably complain, but nobody is ever going to
complain about being in a whitelist.

This is probably not a feature I would use anyway, but interesting to think about :)

|07E|10m|07b|10a|07l|10m|07e|10d |12-----------------------------------------------------
|09Black Lodge Research BBS |11blacklodgeresearch.org:4022
|11fsx|08Net: |0721:4/166 |11sci|08Net: |0777:1/133

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: Black Lodge Research BBS (21:4/166)

On 18 Feb 2020 at 02:44p, Embalmed pondered and said...

I honestly don't really use the whitelist much I have only had 1 user get blocked and it was because they were using SSH directly and didn't know

Not following this thread closely, but from a HUB point of view,
whitelist.txt is a godsend.

--- Mystic BBS v1.12 A45 2020/02/16 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 02-18-20 04:58, ryan wrote to g00r00 <=-

Hey g00r00,

Would it be possible, upon sysop login, to trigger some sort of dialog
to add the detected IP to the IP whitelist?

This would avoid me accidentally locking myself out when traveling. :)

I simply login over ZeroTier. Gives me a static IP, better security and NAT timeouts don't nuke my SSH session unexpectedly. :)


... Free are those who dream dreams.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 02-18-20 07:30, roovis wrote to ryan <=-

You can do it now, without any scripting too.

(DD) Exec Door "echo %4 >><path to whitelist>"

If you want the Yes/No prompt, just add that in above it and put it
your logon menu script. Be sure to set acs to s255 so no one else gets
the question, or if you're generous, let all your users
self-whitelist... ;)

That's cool! :)


... Hypochondria is the only disease I haven't got.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

Hows that sound? Or do you have other ideas of how it should be done?

I like the idea of keeping it as a menu command, which /can/ be placed in the login sequence, but this way we can select to lock it down to specific access levels.

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: monterey bbs (21:1/168)

whitelist.txt is a godsend.

What about auto-whitelisting IPs associated with FTN connections?

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: monterey bbs (21:1/168)

I simply login over ZeroTier. Gives me a static IP, better security and NAT timeouts don't nuke my SSH session unexpectedly. :)

I can't have zerotier on my work laptop which is what I take when traveling :)

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: monterey bbs (21:1/168)

On 18 Feb 2020 at 10:27p, ryan pondered and said...

whitelist.txt is a godsend.

What about auto-whitelisting IPs associated with FTN connections?

I see this is available now in A45 :)

To be honest it's not something I'll likely use much for the BBS but to be
able to manually put in connections who have static IP addressees into a
Mystic system running as a HUB is something I do a lot of. It helps the node
a lot and saves a few lockouts.

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

What about auto-whitelisting IPs associated with FTN connections?

That is a great idea. If an IP successfully authenticates via binkp it would
be whitelisted.

|15frank |08// |15netsurge
|07disksh0p|08!|07bbs |08% |07bbs.diskshop.ca |08% |07mystic goodness |11SciNet |03ftn hq |08% |07https://scinet-ftn.org

--- Mystic BBS v1.12 A45 2020/02/12 (Linux/64)
* Origin: % disksh0p!bbs % bbs.diskshop.ca % SciNet ftn hq % (21:4/154)

What about auto-whitelisting IPs associated with FTN connections?

That is a great idea. If an IP successfully authenticates via binkp it would be whitelisted.

I'd tweak that just a bit by setting up a whitelist lease. The whitelist is good for 30 days after a successful authentication. If you don't connect for
30 days, the whitelist goes. This would autoclean the whitelist in case of dynamic IP addresses.

Cheers!

|15 ▀ ▐ |15StackFault |08<|03.|11.|15P|11h|03EN|11o|15M|11.|03.|08>
|11 ▌ ▀ |11The Bottomless Abyss BBS
|03 ▀ ▌▀ |03ssh|08.|072222 |08/ |03telnet|08.|072023 |08/ |03https
|08 ▄■▐ |08bbs|07.|08bottomlessabyss|07.|08net

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: The Bottomless Abyss BBS * bbs.bottomlessabyss.net (21:1/172)

I'd tweak that just a bit by setting up a whitelist lease. The whitelist is good for 30 days after a successful authentication. If you don't connect for 30 days, the whitelist goes. This would autoclean the whitelist in case of dynamic IP addresses.

I was thinking of something similar for auto-banned ip addresses. Let them decay and increase in length of permanence as repeat violations accrue.

Something like, 1st ban ... 3 day ban, 2nd ban, a week, third ban a month... etc.

--- Mystic BBS v1.12 A45 2020/02/18 (Linux/64)
* Origin: w0pr.win (21:4/165)

I'd tweak that just a bit by setting up a whitelist lease. The whitelist is good for 30 days after a successful authentication. If you don't connect for 30 days, the whitelist goes. This would autoclean the whitelist in case of dynamic IP addresses.

+1 to that

|07E|10m|07b|10a|07l|10m|07e|10d |12-----------------------------------------------------
|09Black Lodge Research BBS |11blacklodgeresearch.org:4022
|11fsx|08Net: |0721:4/166 |11sci|08Net: |0777:1/133

--- Mystic BBS v1.12 A45 2020/02/18 (Linux/64)
* Origin: Black Lodge Research BBS (21:4/166)

On 02-18-20 22:28, ryan wrote to Vk3jed <=-

I simply login over ZeroTier. Gives me a static IP, better security and NAT timeouts don't nuke my SSH session unexpectedly. :)

I can't have zerotier on my work laptop which is what I take when traveling :)

Good point. :)


... Judged by 12 people that weren't smart enough to get out of jury duty.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 02-19-20 11:37, StackFault wrote to Netsurge <=-

What about auto-whitelisting IPs associated with FTN connections?

That is a great idea. If an IP successfully authenticates via binkp it would be whitelisted.

I'd tweak that just a bit by setting up a whitelist lease. The
whitelist is good for 30 days after a successful authentication. If you don't connect for 30 days, the whitelist goes. This would autoclean the whitelist in case of dynamic IP addresses.

I second this. I was concerned about a whitelist getting out of hand due to dynamic IPs. The expiry would solve that problem.


... Alert: Scanner shows Sysop in the area. Look innocent!!
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

On 02-19-20 11:05, roovis wrote to StackFault <=-

I'd tweak that just a bit by setting up a whitelist lease. The whitelist is good for 30 days after a successful authentication. If you don't connect for 30 days, the whitelist goes. This would autoclean the whitelist in case of dynamic IP addresses.

I was thinking of something similar for auto-banned ip addresses. Let
them decay and increase in length of permanence as repeat violations accrue.

That's an interesting idea.


... She kept saying I didn't listen to her, or something like that.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

To be honest it's not something I'll likely use much for the BBS but to
be able to manually put in connections who have static IP addressees
into a Mystic system running as a HUB is something I do a lot of. It
helps the node a lot and saves a few lockouts.

It doesn't work for the BINKP but I certainly can expand it to do so!

I'll make a note of it.

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/64)
* Origin: Sector 7 (21:1/108)

On 19 Feb 2020 at 08:51a, g00r00 pondered and said...

To be honest it's not something I'll likely use much for the BBS but be able to manually put in connections who have static IP addressees into a Mystic system running as a HUB is something I do a lot of. It helps the node a lot and saves a few lockouts.

It doesn't work for the BINKP but I certainly can expand it to do so!

I'll make a note of it.

It's not something I feel needs to be added, rather I was just making the observation that being able to add IPs in for known systems to avoid them
from being blocked when they were keenly fidopolling a HUB was helpful.

I've only been doing this when I know a node had a static IP. I guess adding something more automated in this regard for nodes with dynamic IP that successfully poll could be helpful. But given that dynamic IPs come and go I think I read somewhere others suggesting some sore of self expiring process
to remove older dross may be important else risk an ever ballooning whitelist.

So In short, don;t make this feature a priority on my account :) I think there's other things that would be more further up your TO-DO that others
will have contributed :)

A45 seems solid. Only errors at Agency were from two days ago

2020.20.02 20:33:30 MYSTIC 001 Cannot write to c:\bbs\mystic\data\chat1.dat. Code=2, PID=118280
2020.20.02 20:33:30 MYSTIC 001 Cannot write to c:\bbs\mystic\data\chat1.dat. Code=2, PID=118280
2020.20.02 20:33:30 MYSTIC 001 Cannot write to c:\bbs\mystic\data\chat1.dat. Code=2, PID=118280

No issues at the HUB at this stage. Do you want some logs to scroll through?

I did note a couple of minor things

Hatching files from within Mystic file editor is not being logged


------------------- Node 1 (Mystic v1.12 A45 2020/02/18)
2020.02.22 06:34:49 Connect from local (local)
2020.02.22 06:34:49 Set time left 30 TE=424
2020.02.22 06:34:53 Avon logged in
2020.02.22 06:34:53 First login today, setting time to 999
2020.02.22 06:34:53 Set time left 999 TE=1393
2020.02.22 06:34:53 Setting time left to 999
2020.02.22 06:35:11 File search: "LAST"
2020.02.22 06:35:44 File DIR editor
2020.02.22 06:40:50 User logged off
2020.02.22 06:40:50 Shutting down

No hatching being requested after File Dir Editor

But it did the business when MUTIL ran

+ Feb 22 06:38:04 Process: Toss FDN/TIC Files
+ Feb 22 06:38:04 Waiting for BUSY nodes
+ Feb 22 06:38:04 Scanning Hatches
+ Feb 22 06:38:04 Hatching: xq-ilc123.zip from Mystic BBS Utils, Mods etc.
+ Feb 22 06:38:04 Tossing to 21:1/114

[snip]

+ Feb 22 06:38:05 Tossing to 21:1/209
+ Feb 22 06:38:05 Results: 0 import, 68 toss, 1 hatch, 0 bad in 0.28s


I also noticed that running a file announcement using PostTextFiles generates messages with a tearline that does not show build date.

- Feb 22 06:41:01 EXEC PostTextFiles
+ Feb 22 06:41:01 Process: Post Messages
+ Feb 22 06:41:01 Post: 3 Subj: Hatched Files
+ Feb 22 06:41:01 Post: 9 Subj: Hatched Files
+ Feb 22 06:41:01 Results: Posted 2 Msgs in 0.00s

when it lands at 1/101 Agency I see

--- Mystic BBS v1.12 A45 (Windows/32)
* Origin: fsxNet HUB (21:1/100)

but if I post a standard echomail message from 1/100 I see the following at 1/101

This is a test to check a tearline

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: fsxNet HUB (21:1/100)

so yeah, minor thing, but my OCD picked it up :)

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

is good for 30 days after a successful authentication. If you don't connect for 30 days, the whitelist goes. This would autoclean the whitelist in case of dynamic IP addresses.

It would but it would also remove IP addresses that you actually want to manually whitelist too. I am not sure that would even really be a problem though if you're using automatic whitelist but if you're not it certainly would.

It would also require me to change the format of the whitelist out of a single line text file to something that you couldn't manage easily because it'd have to be associated with (probably) a Unix time stamp value.

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/64)
* Origin: Sector 7 (21:1/108)

2020.20.02 20:33:30 MYSTIC 001 Cannot write to c:\bbs\mystic\data\chat1.dat. Code=2, PID=118280

Yeah this is really weird. Let me know if you notice this again. The code=2 means the file doesn't exist and there should never be a situation where chatx.dat is deleted while a user is still online...

Mystic creates it on startup and removes it on close, so how it got removed in those circumstances is a mystery at the moment.

It used to be that Mystic would just recreate it, but that was causing some potential race conditions that could cause ghost nodes when I was doing load testing on MIS. So now it doesn't and instead spits an error out.

--- Mystic BBS v1.12 A45 2020/02/18 (Windows/64)
* Origin: Sector 7 (21:1/108)

I'd tweak that just a bit by setting up a whitelist lease. The whitel is good for 30 days after a successful authentication. If you don't connect for 30 days, the whitelist goes. This would autoclean the whitelist in case of dynamic IP addresses.

It would but it would also remove IP addresses that you actually want to manually whitelist too. I am not sure that would even really be a
problem though if you're using automatic whitelist but if you're not it certainly would.

Yes, this is certainly something to keep in mind.

It would also require me to change the format of the whitelist out of a single line text file to something that you couldn't manage easily
because it'd have to be associated with (probably) a Unix time stamp value.

That value could be used for both purposes. A value of 0 would be permanent while a non-zero (epoch for example) would be the expiration. It would also require you to update the file to extend the expiration on successful BinkP connection and so on. I understand this is not a simple change but it would
add some value.

Cheers!

|15 ▀ ▐ |15StackFault |08<|03.|11.|15P|11h|03EN|11o|15M|11.|03.|08>
|11 ▌ ▀ |11The Bottomless Abyss BBS
|03 ▀ ▌▀ |03ssh|08.|072222 |08/ |03telnet|08.|072023 |08/ |03https
|08 ▄■▐ |08bbs|07.|08bottomlessabyss|07.|08net

--- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
* Origin: The Bottomless Abyss BBS * bbs.bottomlessabyss.net (21:1/172)