Thousands of ssh probes

[Ian Smith]

On Sat, 6 Mar 2010, Matthew Seaman wrote:
 > On 06/03/2010 06:33:53, Ian Smith wrote:
 > > In freebsd-questions Digest, Vol 300, Issue 10, Message: 6
 > > On Fri, 05 Mar 2010 16:07:29 +0000 Matthew Seaman <m.seaman at infracaninophile.co.uk> wrote:
 > >  > On 05/03/2010 15:51:52, Randal L. Schwartz wrote:
 > >  > > The spamtrap is a shiny object for spam, and anything that goes there gets
 > >  > > blocked for an hour from hitting the low port.  I presented this at a
 > >  > > conference once.
 > >  > 
 > >  > Having an IPv6-only high-mx seems to terminally confuse most spambots...
 > > 
 > > I understand why IPv6 would confuse them, but don't follow why higher 
 > > numbered MXs would be more attractive to them in the first place?
 > > 
 > > Are they assuming a 'secondary' MX will be more likely to accept spam?
 > 
 > Yes.  Generally a high-numbered MX is more trusted than the run-of-
 > the-mill internet by the actual mail server (lowest numbered MX)[*], so
 > forwarding between MXes tends to bypass chunks of anti-spam
 > protection.  The high-numbered MX itself is usually a pretty low
 > importance system at a location remote from all the rest of the mail
 > servers, so it tends to have less effective anti-spam protection.  Thus
 > spammers ignore the normal MX priority rules and just attempt to inject
 > spam through the highest numbered MX, because it is more likely to get
 > through.

Makes sense.  Since I wrote that, some repressed memories surfaced ..

 > On the whole, I don't see the value in having a high-numbered MX to
 > dumbly accept, queue and forward messages like this. It doesn't really
 > add any resilience: the SMTP protocol is intrinsically all about store
 > and forward, and if a message cannot be delivered immediately, the
 > sending side will keep it in a queue for up to 5 days anyhow.  Low
 > priority MXes make some sense for load shedding, but realistically as
 > part of a cluster of servers at one site.  If you want resilience
 > against network outages, then you're going to have to provide a
 > resilient solution for /reading/ the e-mails too, and that's a whole
 > different ball game.

Indeed.  About 10 years ago when we ran a few domains on a 56k modem 
link with a secondary MX on $bigisp, woke up one day to find we were 
being DoS'd by some 90,000 big email from some marketing outfit via the 
unfiltered secondary MX.  Had to cancel that on the spot to chuck them 
away or spend days doing nothing else; haven't bothered using one since.

 > 	Cheers,
 > 
 > 	Matthew
 > 
 > [*] Even if the low-priority MXes are treated as untrusted, you've still
 > got the whole backscatter problem to consider.

Yea; another nightmare system 'inherited' had a qmail frontend accepting 
everything thrown at it, even for invalid usernames, passing it to a 
backend system to sort and sift through it and yes, generate something 
like 95% backscatter, mostly bound for nowhere.  Talk about shooting 
yourself in the foot .. still getting resultant tryhard attempts 18 
months after getting sendmail going - spambots have long memories!

Thanks for the clear explanation,

Ian