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.

---
■ Synchronet ■ crisis/line ·∙ [ crisisbbs.net ]

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

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

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

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

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.
--
digital man (rob)

Rush quote #70:
He's got a problem with his power, with weapons on patrol .. New World Man Norco, CA WX: 78.1°F, 56.0% humidity, 6 mph WNW wind, 0.00 inches rain/24hrs

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

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

I use peerblock and then i use a custom blocklist file.
i have a script that i use to add offenders to it also.
the syntax is real simple so i recommend using it.

I dont like synchronet to handle attackers.
it's sort of sissy slapping back at them. I don't want to see the attempts or the system taxed.
---
■ Synchronet ■ ::: BBSES.info - free BBS services :::

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 Wed Jun 05 2024 08:54 am

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.

It tells me that the TCP port was rebound. If the socket is configured for address/port reuse (in ctrl/sockopts.ini), then one could artifically create this exact scenario by starting and stopping a second process (after sbbs) that bound to TCP port 23. It could even be a second instance of sbbs. No "crashing" of the Synchronet telnet server would be required.
--
digital man (rob)

Sling Blade quote #12:
Karl (re hammer): I don't rightly know. I just kinda woke up holding it.
Norco, CA WX: 74.6°F, 67.0% humidity, 9 mph WSW wind, 0.00 inches rain/24hrs

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.

---
■ Synchronet ■ crisis/line ·∙ [ crisisbbs.net ]

Re: Automatically blocking co
By: fluid to Dumas Walker on Wed Jun 05 2024 03:34 pm

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 think the better solution is to use ANSI terminal detection. This is how the login.js auto-reduces the inactivity timeout for bots (which don't support ANSI). It's better to make everything these things transparent to users.
--
digital man (rob)

Steven Wright quote #16:
When everything is coming your way, you're in the wrong lane.
Norco, CA WX: 81.3°F, 55.0% humidity, 13 mph W wind, 0.00 inches rain/24hrs

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.

It tells me that the TCP port was rebound. If the socket is configured for address/port reuse (in ctrl/sockopts.ini), then one could artifically create this exact scenario by starting and stopping a second process (after sbbs) tha
bound to TCP port 23. It could even be a second instance of sbbs. No "crashing
of the Synchronet telnet server would be required.

Hmmmm... which setting would I want to set if I wanted to tell synchronet
not to allow the port to be reused by another process?

Currently, the only two options I have set in sockopts.ini are:

KEEPALIVE = TRUE
TCP_NODELAY = TRUE

I also see that IPV6_V6ONLY = 1 . What does that one do?

I suspect that these are all defaults as I don't remember changing anything
in this ini file, and the modify date is 8/20/2015.

Thanks!


* SLMR 2.1a * If you stomp gripes, do you get whine?
---
■ Synchronet ■ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

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.

A bunch of mine are from China and Russia also. Ukraine and Korea (not
sure which one) also get lots of bans.


* SLMR 2.1a * I still miss my Ex... But my aim _is_ improving!
---
■ Synchronet ■ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: Automatically blocking co
By: Dumas Walker to DIGITAL MAN on Thu Jun 06 2024 09:23 am

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.

It tells me that the TCP port was rebound. If the socket is configured for address/port reuse (in ctrl/sockopts.ini), then one could artifically create this exact scenario by starting and stopping a second process (after sbbs) tha
bound to TCP port 23. It could even be a second instance of sbbs. No "crashing
of the Synchronet telnet server would be required.

Hmmmm... which setting would I want to set if I wanted to tell synchronet not to allow the port to be reused by another process?

On Linux, that'd be REUSEADDR = FALSE

Currently, the only two options I have set in sockopts.ini are:

KEEPALIVE = TRUE
TCP_NODELAY = TRUE

I also see that IPV6_V6ONLY = 1 . What does that one do?

From https://www.man7.org/linux/man-pages/man7/ipv6.7.html

IPV6_V6ONLY (since Linux 2.4.21 and 2.6)
If this flag is set to true (nonzero), then the socket is
restricted to sending and receiving IPv6 packets only. In
this case, an IPv4 and an IPv6 application can bind to a
single port at the same time.

If this flag is set to false (zero), then the socket can
be used to send and receive packets to and from an IPv6
address or an IPv4-mapped IPv6 address.

The argument is a pointer to a boolean value in an
integer.

The default value for this flag is defined by the contents
of the file /proc/sys/net/ipv6/bindv6only. The default
value for that file is 0 (false).

I suspect that these are all defaults as I don't remember changing anything in this ini file, and the modify date is 8/20/2015.

Yes, looks like defaults.
--
digital man (rob)

This Is Spinal Tap quote #26:
David St. Hubbins: They were still booing him when we came on stage.
Norco, CA WX: 80.9°F, 57.0% humidity, 9 mph WNW wind, 0.00 inches rain/24hrs