Since putting fail2ban in place, nearly all of the brute force password attacks have been out of China, a handful from Viet Nam.
The IP 126.96.36.199 has just been banned by Fail2Ban after
5 attempts against SSH.
Here are more information about 188.8.131.52:
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
% Information related to '184.108.40.206 - 220.127.116.11'
inetnum: 18.104.22.168 - 22.214.171.124
descr: CHINANET jiangsu province network
descr: China Telecom
descr: A12,Xin-Jie-Kou-Wai Street
descr: Beijing 100088
remarks: This object can only be updated by APNIC hostmasters.
remarks: To update this object, please contact APNIC
remarks: hostmasters and include your organisation's account
remarks: name in the subject line.
status: ALLOCATED PORTABLE
changed: firstname.lastname@example.org 20050624
role: CHINANET JIANGSU
address: 260 Zhongyang Road,Nanjing 210037
remarks: send anti-spam reports to email@example.com
remarks: send abuse reports to firstname.lastname@example.org
remarks: times in GMT+8
changed: email@example.com 20090831
changed: firstname.lastname@example.org 20090831
changed: email@example.com 20090901
changed: firstname.lastname@example.org 20111114
person: Chinanet Hostmaster
address: No.31 ,jingrong street,beijing
changed: email@example.com 20070416
changed: firstname.lastname@example.org 20140227
% This query was served by the APNIC Whois Service version 1.69.1-APNICv1r0 (WHOIS1)
This mornings maintenance activity has been concluded. All NFS relationships between servers are now back to version 4 so mandatory locking is functioning again.
I will be rebooting various servers tonight in order to switch NFS back to version 4 which now appears to be fixed in CentOS 6.5.
NFS version 4 supports mandatory locking, provides better overall performance, and can mutually co-exist with firewalls allowing for greater system security.
Clam-AV has been updated on all servers and the queues flushed so mail is no longer backed up in queue with the exception of mail destined to sites that are currently down.
There is a new virus propagating that until just now, clam-av was unaware of, and as a result there may be copies in your INBOX.
If you have an e-mail with an attachment eskimo.com.zip, DO NOT OPEN THE ZIP ATTACHMENT.
Two of three servers now have updated clam-AV database and will no longer accept this virus but I am having problems with a third server that is so choked with viruses I can’t get command line responses to update clam-AV.
This has caused outgoing mail to get stuck in queue, presently the two servers that are working are cleared and I am working on getting this one to update and clear itself.
Tonight’s maintenance work is done. Tomorrow I will be taking down Debian and UUCP as well as a number of servers that are replicated and thus won’t affect service. Other than Debian and UUCP, all of the service affecting work is done for the night.
I will be rebooting and taking machines down for imaging tonight shortly after midnight. I should be finished by approximately 2AM.
This is necessary to install kernel upgrades that fix a possible privilege escalation exploit in the kernel as well as to image the machines after adding fail2ban so that if a restoration is necessary at some point, that will get included in the restoration.
In short, these outages will enable us to make some improvements in site security as well as to backup some recently put in place.
Comcast is now accepting mail. There is no longer any mail stuck in queue, all outbound mail that was queued is now delivered.
I have been able to confirm via the mail log, that today mail is going through to Yahoo, ATT/SBC Global, and Frontier.
Comcast is presently blocking for reasons unknown. I’ve applied to their feedback program so I will receive e-mails of any spam they receive from us, and have submitted a response on their unblock form.
Today, I received a bunch of bounces from applications for accounts on my Photo Gallery (CopperMine) from Yahoo addresses.
I deleted all of these that were still in queue and disabled account creation in CopperMine.
So this probably hasn’t helped our stance from Yahoo’s perspective, though it would be nice if they’d actually communicate. It would also be helpful if they’d reject messages with the correct code, permanent rejections should use 5xx not 4xx as Yahoo is using. Using the latter means people won’t find out there is a problem until a bounce happens perhaps weeks later, and it eats up a lot of mail resources unnecessarily on both ends.
Anyway, per their best practices pages, I’m working on getting DKIM and DMARC installed. Not that either of these would have prevented a single spam since the spams were sent with hacked accounts, (and it’s not as if Yahoo hasn’t had their own problems with hacked accounts) and thus would have been signed as legitimate if these things had been in place, and really SPF, which is in place, serves the same purpose.
I tried e-mailing email@example.com but just got referred to the same web page that doesn’t work. Tried calling, just got referred to the same page that doesn’t work.
If anybody knows how to reach an actual human being at Yahoo that might actually care that they’re blocking legitimate e-mail, please let me know.