TZUTC: -0500   
   MSGID: 272.fido-bbbsengl@1:3634/12 22aed78e   
   REPLY: 1:282/1031.0 66cd3fa3   
   PID: Synchronet 3.17c-Linux  Feb 14 2020 GCC 7.4.0   
   TID: SBBSecho 3.10-Linux r3.151 Feb 14 2020 GCC 7.4.0   
   CHRS: ASCII 1   
   NOTE: FSEditor.js v1.103   
     Re: All nodes busy?   
     By: Jeff Smith to All/kim Heino on Sun Feb 16 2020 02:03:06   
      
      
    JS> I currently have the 22 node version of BBBS Toy-4. Since upgrading   
    JS> to the current version I have noticed that I frequently (At least   
    JS> once a day) run out of available nodes. I don't recall noticing   
    JS> this issue with previous versions of BBBS. I use iptables to help   
    JS> manage port access. Recently I have reconfigured bbbsd to run   
    JS> using all non-standard ports to see if that would affect my bust   
    JS> port issue. It didn't seem to make a difference. Is there   
    JS> something I am missing? Has anyone else had a problem with busy   
    JS> nodes with BBBS?   
      
   there is a new wave of bots attempting to recruit buggy routers into their   
   botnet(s)... just ask my IDS/IPS* about it ;)   
      
   but seriously, can you shorten your timeout on login for inactivity? if they   
   don't know what to do, they will sit at the login prompt until they or you   
   time out... the faster you can time them out, the faster you can get your   
   nodes freed back up for real users...   
      
   another thing you might be able to do is to drop/block IPs that connect more   
   than X times in Y seconds... some BBSes have this capability and i use it in   
   my IDS/IPS as well... for example, this rule from my IDS/IPS detects 5 TCP   
   SYNs within 60 seconds and raises an alert which triggers a block of the   
   connecting IP...   
      
   alert tcp $EXTERNAL_NET any -> $HOME_NET 23 (msg:"Rapid TELNET \   
     Inbound - Possible Brute Force Attack"; flags: S; \   
     detection_filter: track by_src, count 5, seconds 60; \   
     classtype:unsuccesful-user; sid:100000020; rev:3;)   
      
   i highly recommend running an IDS/IPS package on one's perimeter firewall if   
   they can... it takes some time to tune it for one's network traffic but once   
   that is done, there's little to do other than sit back, watch the nefarious   
   trash on the outside beat on the door trying to get in, and laugh at them... i   
   should also note that our setup does not use any database logging/monitoring   
   techniques with our IDS/IPS... doing this does allow for deeper analysis of   
   alerted network traffic but in our case, we haven't seen a need for such in   
   our case...   
      
      
   * https://en.wikipedia.org/wiki/Intrusion_detection_system   
      
      
   )\/(ark   
   --- SBBSecho 3.10-Linux   
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)   
   SEEN-BY: 1/120 123 14/6 18/0 90/1 103/705 116/116 123/0 25 50 150   
   SEEN-BY: 123/170 755 135/300 153/7715 154/10 30 40 700 203/0 221/0   
   SEEN-BY: 221/6 227/114 201 400 229/426 452 1014 240/5832 249/206 317   
   SEEN-BY: 261/38 280/464 5003 292/854 300/4 317/3 322/757 342/200 396/45   
   SEEN-BY: 423/120 712/848 770/1 2452/250 3634/0 12 15 27 50 119   
   PATH: 3634/12 154/10 280/464 229/426