Hello Marc!

04 Jul 15 22:55, Marc Lewis wrote to Matt Bedynek:

 ML> This system takes many hundreds of "hits" per day on port
23. Bombing 
 ML> runs trying to get to "root" access... Dead ended by OS/2
and VModem 
 ML> that answers port 23.  I look at the bombers and sometimes end up 
 ML> putting an entire /24 or /16 into the firewall config, depending on 
 ML> where they're coming from. The config on the BBS machine itself is 
 ML> now over 300 rules long.  It's astounding to watch some moron hitting 
 ML> the port over and over and over and over trying to break into the 
 ML> system... And then jumping to a different IP and starting the same 
 ML> nonsense all over again.  Idiots.  ;-\  Very annoying but ultimately 
 ML> harmless because of the system itself.  

One will always see such behavior when running popular services on standard
ports (i.e. 21(ftp), 22(ssh), 23(telnet), and ect).  The best way to avoid
it is to change your port (i.e. 2222, 2323) because those running search
mechanisms typically confine their searches to ports less than 1024
(priviledged ports).  This reduces scan overhead when they are scanning
tens of thousands of addresses.   Most such attaches are not directed and
are only looking for low hanging fruit.  Systems running easily exploitable
services with weak passwords.   I suspect when they encounter a bbs they
have the slightest idea what to do.   When I ran my SSH service on port 22
I would see the step further (tens of thousands of login attempts per day).
 Most were directed at the root user which was disabled.  Once I changed
the port these dropped to near zero.

IPv6 will actually solve much of this even if services remain listening on
their default ports.  IPv6 address space is so large that it takes
considerable time to conduct a simple uphost scan.

 ML> Same stupidity with the POP3 server on a different machine (also 
 ML> OS/2) with thousands of user name and password attempts.  What they 
 ML> don't realise is the way it's set up, even if they could somehow 
 ML> guess a user name and come up with that user's password, they'd still 
 ML> be "up the creek without a paddle in a sinking canoe." 
Not too many 
 ML> e-mail clients can negotiate APOP, so let'm try and crack the 20 
 ML> some-odd character random character passwords plus the salt.
 ML> It's amazing to look at the log file.

It is like fishing.  Cast a line in the water and eventually you get a
bite.  For these dictionaries are used to crack passwords.  The only
guessing is in the username.  Believe it or not these work quite well when
the work is distributed among hundreds of compromised zombie hosts.   If
you can change your pop server port it is recommended to close that hole
entirely.

Regards,

Matt

---