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