On Dec 4, 2015, at 9:06 AM, Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk>
wrote:
On 04/12/2015 16:32, Steve Atkins wrote:
What I'm thinking of is having the option of the software reporting failed
login IPs 'home' to a central server here, which other installations can
query through a DNS lookup, but I'm still pondering whether that would help
or hinder (the extra load of reporting & querying may override the load of
dealing with the failed logins). If two or more of our software
installations receive failed login attempts from the same IP address within
a day or so of each other, the chances are it's a bot.
If it's a bot then 95%+ of the traffic it emits is malicious, so neither
detecting it nor using the data are limited to solely email login attempts -
meaning the effort can be shared and the benefits multiplied. It'd be
interesting to compare those addresses against the XBL, as one example.
Just for fun, I've looked at the logs of one of our customer's servers (based
in the UK).
The last few days have seen some login attempts for unknown users. Note that
these were login attempts for SMTP, IMAP4, LDAP and POP3... There were even
some login attempts to our own custom service. It has a similar initial
banner to POP3 (but is on a totally different port, and is most certainly not
POP3), so I guess the crackers thought it was POP3 on a different port, which
is interesting, as that must mean they're port scanning as well as it's not a
standard port.
The first few source IP addresses were:
46.183.217.136 (datacentre in Latvia somewhere?) - listed in XBL (CBL)
85.255.235.110 (Vodafone, UK "strategic"?) - listed in PBL and XBL (CBL)
85.255.232.62 (Vodafone, UK "strategic"?) - listed in PBL
94.117.180.221 ("The Cloud Networks", UK) - not listed
193.189.117.150 (Delorian Internet Services, Poland) - listed in SBL and XBL
(CBL)
94.3.210.188 (Sky Internet, UK) - listed in PBL
and many, many more
Obviously we can't block logins from the PBL, but it looks like it may help
if we have the option of checking login attempts against the XBL. It won't
block everything, but it shouldn't harm. We do use the XBL for spam
filtering, but I must admit that I hadn't thought about using it for checking
logins.
The CBL docs say it shouldn't be used for blocking logins, but it may be
useful to instantly block IPs which are on the CBL and also make a failed
attempt to login, rather than giving them a few attempts as we normally do.
But, given that our software is used by businesses for themselves, it may be
OK to let them just use the CBL(XBL) outright to block logins, as they can
easily change it if they need to, unlike if it's a huge MSP.
It'd be an additional data source to consider, for sure. But pay close
attention to Chris's comments about what the CBL/XBL lists and the behaviour to
expect from those nodes, and be very aware of corporate farms of windows boxes
behind a single NAT IP.
(I think we're drifting quite a long way from SMTP, let alone where this thread
started, though :) ).
Cheers,
Steve
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp