| Sysop: | Denn |
|---|---|
| Location: | Clearfield, Utah |
| Users: | 20 |
| Nodes: | 15 (0 / 15) |
| Uptime: | 127:10:37 |
| Calls: | 288 |
| Files: | 221 |
| Messages: | 17,495 |
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.
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?
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.
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.
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.
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 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.
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.
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.