On Wed, 21 Jan 2015, Janis Kracht wrote to mark lewis:   
      
   >> Any tips or suggestions as to a way to limit/avoids telnet login   
   >> attacks on BBBS?   
      
   > they're scripts looking for unpatched telnet servers or those that    
   > they can run a dictionary attack against using the lists of usernames    
   > and passwords they have gathered...   
      
    JK> Yes, agree there.  These logins that Jeff mentions have been    
    JK> happening here as well... most times they don't attempt to    
    JK> login... just connect, then sprout another node, disconnect, & on    
    JK> and on. They sometimes come in droves     
      
   yeah, they seem to be botnets the way they hit and the wide range of IPs they   
   use all at the same time... they may be looking for shellshock capabilities or   
   even other output from the initial connection that they can use to determine   
   what type of system they are connected to... you know? from the telnet banner   
   like we can also get from ftp... the one that tells a few things about the   
   telnet or ftp server like the version and maybe even the OS...   
      
   > most are likey to be botnets since those folks over there seem to    
   > prefer to run pirated OSes which can't or won't be patched... then    
   > again, many over there probably don't even know they've been hacked    
   > and taken over...   
      
   > i've found the best protection is in the perimeter firewall using an   
   > active response system that blocks connections based on the traffic    
   > they transmit...   
      
    JK> Do you mean block out say ip ranges? Outside of that I can't    
    JK> figure out how to deal with this since it's now not only china,    
    JK> but korea, today I saw a number of them from Mexico ... geez.   
      
   blocking ranges is one way but that list can get very large very fast and then   
   you have to maintain it somehow to remove IPs that have been sold or allocated   
   to other areas as well as adding in new ones... i used to do this but then   
   found myself spending 10+ hours a day trying to manage it... not good...   
   that's when i turned to my firewall's IDS (snort) and a custom application   
   that reads the IDS alert file... based on the alerts, the custom application   
   will issue a block command on the firewall to block and drop the offending   
   IP's connection... we use drop so they are wasting resources waiting on a   
   response that will never come... this vice a reset which tells them we're   
   rejecting them... reset is the nice way but we're not going to be nice to   
   these guys...   
      
   so anyway, i've been able to get back to developing this custom app and have   
   switched it from sending commands to iptables to add and remove the blocked IP   
   to using ipset for the same thing... iptables is like a huge bucket stack   
   where the rules are consulted from the top down and every rule is consulted   
   all the way to the bottom of the stack unless there's one higher up that   
   matches the inputs... if you have several thousand rules, it can take some   
   time to get through them... with ipset, the IPs are stored in a set and   
   iptables only needs to consult one rule instead of hundreds or thousands...   
      
   so anyway, this custom app finds an alert that it is configured to see as   
   offensive... when it does, it records the time and date along with the IDS   
   rule that triggered the offense... it stores this information along with an   
   expiry time and date that is set X time in the future plus an additional   
   random amount to thwart probing to determine when the blocks are removed...   
   the IP is added to the list of blocked IPs in the firewall rules and we move   
   on to the next alert entry...   
      
   if an IP keeps offending, each offense adds more time to the expiry pushing it   
   out further each time... if they keep offending, they will continue to be   
   blocked with the blocking time getting longer and longer... they are blocked   
   form /ALL/ accesses... not just the service they commited the initial offense   
   on...   
      
   the app makes a round through all its entries to see if the expiry time has   
   arrived and/or been passed... if it has, the offending IP is removed from the   
   blocking list and its records are cleaned up...   
      
   i've had new sysops get themselves blocked because they ran a portscan against   
   my IP and my system effectively disappeared from their scope :lol:    
      
   i have found this app to be the best way for my needs... mainly because i   
   don't have to manage a huge list of thousands or hundreds of thousands of IP   
   and the main thing is that only those who commit an offense are blocked... if   
   you don't try to access a non-existant SQL server, you won't get blocked... if   
   you don't try to use some wordpress hack to try to break into my server or do   
   an SQL injection into my database, you won't get blocked...   
      
   i've got custom rules that will block an offending IP when my SMTP server   
   responds to it that its traffic is being denied because it is spam... those   
   guys don't get the chance to hammer away on the SMTP server... i've got custom   
   rules that look for root, admin, administrator and similar trying to log in on   
   telnet, ftp, pop3, imap and even web pages... they're all blocked quite   
   handily...   
      
   i see it like this... living in an apartment complex, if someone comes by and   
   rattles your doorknob to see if the door is open, they're up to no effin' good   
   so they get blocked... before i had to clear my lists during some testing, i   
   had one system that had been in my block list for over 9 months... they came   
   about once every couple of hours probing the different SQL server ports...   
   they are listed as a known "bad apple" in several lists... my IDS has several   
   thousand rules... some of them are address specific while others look for   
   certain behavoirs and traffic contents... it'll even raise an alert just for   
   looking up a (eg) darktech or dyndns address... i just have to tune the IDS   
   and my app for my network's traffic... once that's done, it is all pretty much   
   automated and i only need to maybe tweak it when some new rules come out that   
   hamper my network's traffic on the 'net...   
      
   this app? it is written completely in perl at this time but i'm considering   
   porting it to free pascal and compiling it to a true binary... mostly for   
   speed in processing and certainly during its shutdown procedures... it saves   
   its records during shutdown so that blocks will last over a system reboot...   
   the problem here is that *nix, in its infinite wisdom, will kill an app during   
   shutdown if it hasn't existed in a few seconds and that's not good for this   
   particular situation...   
      
   so anyway, that's my baby that i've been working on and maintaining outside of   
   fidonet for several years now ;)   
      
   )\/(ark   
      
    * Origin:  (1:3634/12)