From 1 week until now I got 4 spam attacks. The attacker is the same, because the emails sent are iqual.
The technique is also the same, they use an email account (compromissed password) and send emails through smtp server.
When I detect the attack, i do:
1. identify the compromised account 2. Change password from the compromised account 3. Stop qmail 4. Clear queue with qmail-remove 5. Start qmail
The problem is that they already used 4 diferent domains since the first attack. So, here is my problem, how do they discover the passwords?! How can I solve this problem? I have hundreds of emails accounts and can't change it all.
So on our server, fail2ban got itself in a mess. Tried various things to fix, to no avail, so figured I'd just do a fresh install of it. There was minimal customisation to it that I couldn't re-do.
Note I'd already rm'd /etc/fail2ban - as on previous attempts, the files in here didn't appear to be restored to their defaults. So I figured removing the directory would force this to happen (Whether this was wise I'm not sure!) ;-)
So, following instructions here: [URL] .... I now get the following:
# wget http://kb.sp.parallels.com/Attachments/kcs-36245/fail2ban.gz # gunzip fail2ban.gz # mv fail2ban /etc/init.d/fail2ban # chmod 755 /etc/init.d/fail2ban # ll /etc/init.d/fail2ban /etc/fail2ban/fail2ban.conf ls: cannot access /etc/fail2ban/fail2ban.conf: No such file or directory -rwxr-xr-x 1 root root 2141 Aug 15 2014 /etc/init.d/fail2ban
I then uninstall/reinstall with # /usr/local/psa/admin/bin/autoinstaller
(Have tried via the web interface too)
I then get:
# ll /etc/init.d/fail2ban /etc/fail2ban/fail2ban.conf ls: cannot access /etc/fail2ban/fail2ban.conf: No such file or directory -rwxr-xr-x 1 root root 2141 Aug 15 2014 /etc/init.d/fail2ban
i.e., no change..
and if I go to the fail2ban settings in Plesk, I get:
I'm missing files that the existing crontab requires. There are results on Google for it, but since the parallels' forum upgrade, all the Google links are dead...
The missing crons in question are:
/bin/sh: /usr/local/psa/libexec/modules/watchdog/cp/clean-events: No such file or directory /bin/sh: /usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats: No such file or directory /bin/sh: /usr/local/psa/libexec/modules/watchdog/cp/clean-sysstats: No such file or directoryClick to expand...
Is it enough to restore the full server backup via the web interface of Plesk to get everything running fine after a reinstall, or is there something else I should do ? I have all kind of backups (server, domains, customers). My server is running Plesk 12 on Ubuntu 12, and I think I will have Ubuntu 14 on the new installation. My backups are on a server on the same local network than my server.
I am a new user of Plesk 11.5.30 struggling to understand how qmail is configured.
I intend to install ezmlm to work with qmail but the installation guide assumes that the qmail installation is set up per LWQ (Life with qmail - see URL....
For example the following are quotes from LWQ:All of qmail's system configuration files, with the exception of the .qmail files in ~alias, reside in /var/qmail/control.A series of configuration files resides under /var/qmail/users.
The qmail sendmail, which is normally in /var/qmail/bin/sendmail, usually replaces .None of these directories exist. So where are all these configuration entities?
I have issue with qmail server. I want to update ssl certificate and for this i have replaced older servercert.pem with new servercert.pem file in /var / qmail/ control/. and restart service of qmail using qmailctl restart.But after updating this certificate my web browser still showing older certificate details.
We are seeing intermittent slow responses from SMTP on a RHEL6 server running Qmail on Plesk 11.5. The response is being measured from a remote Zabbix server.
The response time seems to be slow (>10s) for a period of 2-3 minutes and then returns to normal (<1s). All other services continue to be ok during the period of slowness.
The server_args line in /etc/xinetd.d/smtp_psa already contains "-Rt0" and all the DNS servers in /etc/resolv.conf are resolving properly.
From looking at the maillog file the server was receiving about 35 SMTP connections a minute at the time of the slowdown. We have the server configured to use 2 x RBL's.
I wonder if we are hitting a limit on the maximum amount of SMTP connections. The file /var/qmail/control/concurrencyincoming does not exist so, according to the Qmail manual, there shouldn't be a limit on the number of incoming SMTP connections.
I'm using Plesk 11.5.50 CentOS 6.5 64bit with Qmail. I have installed a SSL certificate on mail server "mail.company.tld" and is running successfully with smtp/pop3/imap4 daemon. Every user agent uses "mail.company.tld" for smtp/pop3/imap4. The qmail name is "mail.company.tld" (file me). The server has about 300 domains and 1000 accounts.
Now we want to add a new SSL certificate, called "mail.newcompany.tld", and use it only for certain domains. I would like to know if is possible to use the new SSL "mail.newcompany.tld" for a specific mail domain without using the old SSL "mail.company.tld" that isn't expired yet. From Plesk Panel I haven't found a section for using the SSL for a specific mail domain.
I have a server(godaddy) with plesk. It was all working well till 8 - 10 days ago. I didnt notice it one week later where I started receiving a lot of failed mail notices. Then on investigation, there were more then 50K spam mails in the mail queue and the mails that were supposed to be sent(registration, forgot password) were also held up in the queue. I found the source of the spam and fixed that.
Also I cleared the mail-queue. Now when I try to send out a test message, it still gets held up in the mail queue. But I can send a test mail to the same domain (email@example.com). All new user registration mails are also held up and this is greatly affecting the site.
Domains are simply not showing in the controlpanel. We can see the subscriptions but its empty under the button 'Domains'. Newly created sites as well as migrated sites do not show.
Before we created or migrated a site to the server we changed psa.conf HTTPD_VHOSTS_D /home/httpd/vhosts This is a legacy from our old servers and never has been a problem. I suppose this is not related, but just thought I should mention it.
The second problem with this server is that when we toggle the mailservice in 'Services management' the button reacts but does not change the state of qmail. It just keeps running. What can be wrong with this fresh installation?
Smtp service (qmail) stops responding on port 25: # time telnet localhost 25 Trying 127.0.0.1... quit quit Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. quit quit Connection closed by foreign host.
real 4m10.629s user 0m0.000s sys 0m0.002s
After server restart or sometimes apache stop or ixnetd restart its responding for a some random time, and then again it stops to respond. Plesk panel show it as stopped but qmail itself running in memory, and does other its work, it just stops responding at port 25, or responds with a huge delay.
I've tried change it to postfix, reconfigured with mchk, repaired with repair.sh -r, disabled and uninstalled parallels antivirus, antispam, dnsbl, disabled firewall, disabled smtp lock. Checked apache, dns. Enabled submission port which works when 25 port doesnt, but i need working 25 port.
Nothing solves problem, its just stops responding after some random time. There is no errors on maillog.
I think this problem occured after recent plesk microupdate, because i didn't do anything to server configuration in last months.
This article says it might be dnsbl [URL] .... but it disabled(from plesk panel) on my server, maybe there is way to focefully kill any relation to dnsbl?
Plesk info: OS Red Hat Enterprise Linux Server 5.9 (Tikanga) Panel version 11.5.30 Update #50, last updated at May 18, 2015 05:21 PM The system is up-to-date; last checked at May 17, 2015 10:56 PM
update: xinetd restart is definitely brings smtp alive, but it goes off after random period of time (5min ~ couple hours)
So one of my domains is getting a dictionary attack. It is a popular domain and "big deal" it happens all the time. Well, this time it is the most ruthless distributed dictionary attack I have ever seen.
Today marks the one week period and emails are flooding in 10 to 15 a second (of course none of them ever get delivered). It is like hail pounding on a thin tin roof and the denial/logging alone has the server load at least quadrupled!
Oh yeh, the best part. I have a beautiful list of over 7,000 banned IP addresses (and growing every minute, now THATS DISTRIBUTED!).
What steps do I need to take to uninstall Parallel Plesk 11 for Windows. Then Reinstall Parallel Plesk 11 for Windows. Because my "File Manager" got corrupted, my download link timesout and I need this fixed.
We've been seeing sluggish performance on our mail gateways, and so I started doing some digging in the logs. It looks like we are filling up with messages like:
2007-05-16 12:22:16 Connection from [xx.xx.xx.xx] refused: too many connections
We have our max connections set to 20 (total, not host-specific) in exim4. So I started tailing the logs, and sure enough, we are getting bombarded with requests to firstname.lastname@example.org coming from all over the map. The requests are getting denied of course, but that doesn't help the connection issue since they are consuming all of them, preventing real mail (for the most part) from getting through.
What is the proper way to deal with something like this? I could certainly just up the max connections value from 20 to 40 or 50 or whatever, but I'm not sure what kind of performance impact that will have on the rest of the traffic going through our gateways.
Since the spam attempts are coming from all over the place, it doesn't seem like I can just firewall out a few addresses and be done with it.
This particular rack is a cluster of web and database servers behind two gateway boxes, which handle the mail traffic (so this problem is on the gateways, the actual mail server itself sits behind the gateways and never actually sees these fake emails).