I have a pretty simple system I wrote on a whim last night to try and filter out some of the bots/scripts I kept seeing attempt to login. It requires the connecting client press two keys in 15 seconds. If they do not do it, they get disconnected.

Because I wrote that system I suspect that Synchronet's built-in protection cannot catch bad offenders, because for a lot of them there is no "login attempt" to count.

I have read through the security documentation and I do not see any type of "connection attempt" thresholds that can be configured.

If I develop a module to log connection times and IP addresses so I can see how many times an IP attempted to connect in a given amount of time (say the past hour), what would the best way to store that data be?

What data storage and retrieval capability is built into Synchronet that I can leverage from Javascript? Or, does the ability to throttle connection attempts already exist and I am just missing it? I know I saw something about being able
to write and retrieve binary data...but I can't find that for the life of me today.

Re: Automatically blocking connection attempts if they come too quickly
By: fluid to All on Mon Jun 03 2024 02:48 pm

I have a pretty simple system I wrote on a whim last night to try and filter out some of the bots/scripts I kept seeing attempt to login. It requires the connecting client press two keys in 15 seconds. If they do not do it, they get disconnected.

Because I wrote that system I suspect that Synchronet's built-in protection cannot catch bad offenders, because for a lot of them there is no "login attempt" to count.

Correct, you're defeating Synchronet built-in mechanisms for throttling bots.

If you look at login.js, it also automatically limits the inactivity of bot connections (based on lack of ANSI terminal detection) and that timeout is configurable in modopts.ini.

I have read through the security documentation and I do not see any type of "connection attempt" thresholds that can be configured.

Bots generally try to login, so that's the mechanism used (failed login attempts) for counting/throttling - not connections. If something connects and disconnects rapidly, who cares? There is a built-in/configurable limiter for concurrent connections (from the same IP) without login, and that's a useful bot control mechanism too. Have you set the concurrent connection limit?

If I develop a module to log connection times and IP addresses so I can see how many times an IP attempted to connect in a given amount of time (say the past hour), what would the best way to store that data be?

A database with IP addresses as keys, most likely. If you're just talking about logs of connections, then a tab-delimited text files of line-records, or possibly JSONL would work nice.

What data storage and retrieval capability is built into Synchronet that I can leverage from Javascript?

.ini files and JSON are first-class data file formats for Synchronet-JS.

Or, does the ability to throttle connection
attempts already exist and I am just missing it? I know I saw something about being able to write and retrieve binary data...but I can't find that for the life of me today.

The JS File class has methods for reading and writing binary data. I don't think you'd want to do that (store/read binary data) for the use case you're describing.
--
digital man (rob)

Synchronet "Real Fact" #11:
DOVE-Net was originally an exclusive ("elite") WWIVnet network in O.C., Calif Norco, CA WX: 63.2øF, 79.0% humidity, 2 mph W wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Bots generally try to login, so that's the mechanism used (failed login attempts) for counting/throttling - not connections. If something connects and
disconnects rapidly, who cares?

I ran into issues (with 3.19 and before, anyway) where people or bots were hitting the telnet port rapidly and apparently not trying to log in, which meant they were not being throttled.

It would eventually "crash" telnet. I would have expected it to take down
the whole terminal server but SSH would still be working. I would only
find out about it when a user complained that the BBS was down. A recycle
of sbbs would fix it.

So while I would not normally care, I sometimes am forced to. ;)


* SLMR 2.1a * The one who dies with the most toys is dead.
---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

I have not observed this problem (Telnet server not responding while SSH does)
nor heard any reports of it, besides yours. I would expect the use of tools like netstat to help identify the real cause of that issue.

If I can restart synchronet and it goes away, I think that tells me
something.


* SLMR 2.1a * Oh, I see, said the blind man to his deaf wife
---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: Automatically blocking co
By: Dumas Walker to DIGITAL MAN on Tue Jun 04 2024 09:34 am

I ran into issues (with 3.19 and before, anyway) where people or bots were hitting the telnet port rapidly and apparently not trying to log in, which meant they were not being throttled.

It would eventually "crash" telnet. I would have expected it to take down the whole terminal server but SSH would still be working. I would only
find out about it when a user complained that the BBS was down. A recycle of sbbs would fix it.

I did not have this issue specifically, but I had an issue where running telnet on port 23 led to me being unable to connect to my own system while no real users were connected multiple times over the past 3 days.

My solution was the old-school "press escape twice to enter the system" prompt that times out in 15 seconds. I keep track of people that hit that screen. I check for connections for each IP and then see how many times they have connected in the past ten minutes. Anything older than ten minutes gets deleted. If they fail that screen 20 times in ten minutes they get added to ip.can and are effectively banned.

I realize the amount of bots and scripts running these scans is basically endless...but it is keeping nodes freed up about as well as I expected. About half the nodes are occupied by bots, and I have not been blocked yet. So far manual checks of all of the IP addresses in the ip.can file are all Lithuania, Turkey, China, and Russia... The code is a bit messy (I have not really coded for several years)...but so far I am pleased with it.