My problem with one email account is not incoming / outgoing spam, that I could manage. It's the Brute Force attempts. My csf and cphulk take care of the attemps already, BUT its like 10 attemps per second from VERY different IPs.
So only solution I can think of is temprorarily disabling / suspending the said email account. But I cant find a way to do this via whm linux or cpanel.
Apparently it's already a feature request for whm/cpanel: https://features.cpanel.net/topic/disable-email-account
The only thing i found close to a solution was this: http://cpanelplesk.com/disabling-an-email-account-in-cpanelwhm/
But I dont know if It would work, and if its the right way to do this. Any opinions ?
You can not disable/suspend any single mail account on cpanel server, As per the above URL you can prevent outgoing email from the single account. But you are getting invalid login attempts issues so that will not help you on this.
Related
I have been trying to figure out how to programmatically check if a gmail account exists. Almost all searches lead to validation services like xverify or EmailOversight where you validate any email address on a cost per request basis.
What I am interested in is a way to do that directly, without a middleman. In other words, how do these validation services do it? Seems like there should be some sort of an API that google provides for those guys to ping to see if an email address is valid.
Please note that I am not interested in checking the syntax of an email address. So I am not looking for some kind of a regex solution.
Also, what I have tried is connecting to gmail.com MX record domains (e.g. alt3.gmail-smtp-in.l.google.com) and trying to extract the validity of an email address by running simple SMTP commands. Essentially what this article suggests: https://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/
But I cannot do that for any kind of volume. Gmail will start blocking your connection attempt after a certain number of connections. So that method is not scalable. That's why I feel like there has got to some other way.
*******ADDED*********
Here is why this question is different from How to check programmatically a email is existing or not
That post provides only one solution, and it's one I have already tried - using SMTP commands. Google will NOT allow to do that on any kind of scale. If I only had to validate a few emails, then that would be a sensible solution, but if I have 10,000, it is not.
I have installed GLPI 0.90.1 on a CentOS 7.
After more and more problems, everything was going right, but I tried to configure an IMAP mailbox on it in order to create tickets from mail.
The first time I collected my mail (for test), it works well. The ticket is created.
But the second time I tried (maybe 20 minutes later),
I get an error :
"connexion bloked" (translated, because I'm french).
I thought it came from Gmail, but the configs were good, and I didn't change anything.
On Glpi, I do not understand my error messages in the .log.
So I come here to find answers.
If you need more informations, tell me.
Maybe you must enable allow less secure apps to access account on your Gmail account.
Related: What are the dangers of allowing “less secure apps” to access my Google account?
"less secure apps" refers to applications that send your credentials directly to Gmail
I have 2 Windows 2008 R2 boxes running in Microsoft Azure. My ASP.NET 4.0 site (let's imagine it's running at "example.com") has a standard Contact Us form.
When a user sends a Contact Us message, I use System.Net.Mail and SmtpDeliveryMethod.Network to deliver mail to an IIS6 SMTP server running on each box, which sends the mail to a Google Apps "enquiries#example.com" account, using the email address the user entered into the Contact Us form as the "From" address.
This was working beautifully for a year until I checked it today, and found this error in a .BDP file in the \Badmail folder:
550-5.7.1 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been blocked. Please visit http://www.google.com/mail/help/bulk_mail.html to review our Bulk Email Senders Guidelines.
Obviously Google upped their anti-spam strategies in the last 6 months - last time it worked was Feb 2013 (yeah, we don't get much mail luckily... yet).
I've read the Bulk Senders Guidelines linked above, but they're not really suited to my use case. My case is not sending emails from our server to users of our site (I simply use the Gmail API and send from our enquiries#example.com for that), but rather to collect users' enquiries so that we can easily respond by clicking Reply in that inbox.
I am looking for the easiest solution here. In response to the ones in Google's Bulk Senders Guidelines:
Use a consistent IP address to send bulk mail: I already do, doesn't seem to help
Reverse DNS: Godaddy, my domain and DNS provider doesn't seem to support them: http://support.godaddy.com/groups/domains-management-and-services/forum/topic/how-do-i-setup-reverse-dns/ Anyone know if there's a way?
Use the same address in the 'From:' header on every bulk mail you send: This is totally not my use case. I'll have different From headers in every email
SPF record: I think this only works if I am sending From ...#example.com every time. Is that right? My feeling is SPF doesn't help me here. Would love someone to enlighten me.
DKIM: This looks hellishly complicated, but I'll pursue it if someone thinks it can work in this case. Specifically is it OK that the From address doesn't match the "signing domain"? Anyone got any good "how to" links? And will this be sufficient for Google to un-blacklist me?
Sendgrid: Azure's preferred mail sending app. This means signing up, code changes, testing, and unknowns like "does Sendgrid allow any From address? It's non-trivial, and I'd like to avoid this, but again, will go there if it's what people think is the sanest option.
As a general answer to your questions, sending email on behalf of many different domains from one IP (e.g. example.net, example.org, and ex.co from 10.0.0.1) is generally seen as spammy behavior (and therefor not recommended).
Your points 1-5 only apply if you're sending from one domain. rDNS, SPF, and DKIM only improve delivery for one IP to one domain (in a generally 1:1) relationship.
Generally, the best way to avoid getting marked as spam in a situation like this is to set the From email as a consistent one that you actually control (e.g. enquery-sender#example.com), and then setting the Reply-To as the entered address (e.g. enquirer#someprovider.com). This way you consistently send from one domain, while still getting the benefit of replies going to the message originator (for example LinkedIn does it this way). Doing this will allow you to setup rDNS, SPF, and DKIM with benefit.
That said, if you decide that you don't want to use the recommended Reply-To method, you can use SendGrid to send from any arbitrary domain. It should not require any significant code change (just switching your current SMTP credentials to SendGrid's).
Disclaimer: I am a SendGrid employee.
In some cases, you might want to block hacker from your system by using IP addresses.
However, sometime it is more difficult due to existent of ISP proxy.
From the view of system, we see many traffic/connection/burceforce/wrong password from same IP meanwhile it could be a HTTP proxy or IPv6 gateway or similar. But it might not smart enough to tell is that normal or abnormal.
What's the suggested way to block those bad access without degrade user experience(e.g. too many captcha) to whom are innocent?
Don't know if you consider this "Degrading user experience" But you can code MAX_TRIES for the login to give the user only few tries -to login then if all tries are wrong he is blocked from logging for a while- to prevent Brute forcing the login.
And for other connection you can install mod_bw for apache then limit the connection limit per IP using this htaccess command
MaxConnection all 3
You should limit the login rate for each UserId.
After X mistakes, you can block a UserId till the user will reply to a special e-mail. This way, the user will also know that someone is trying to log into his account.
You can map source IP address into a specific country, and allow a user to log-in only from a predefined list of countries (user selection).
You can temporarily block a group of IP addresses (for example 172.16.254.*) if there are many false attempts from the same group. Many hackers just change the last octet.
i'd like to prevent bots from hacking weak password-protected accounts. (e.g. this happend to ebay and other big sites)
So i'll set a (mem-) cached value with the ip, amount of tries and timestamp of last try (memcache-fall-out).
But what about bots trying to open any account with just one password. For example, the bot tries all 500.000 Useraccounts with the password "password123". Maybe 10 will open.
So my attempt was to just cache the ip with tries and set max-tries to ~50. The i would delete it after a successful login. So the good-bot would just login with a valid account every 49 tries to reset the lock.
Is there any way to do it right?
What do big platforms do about this?
What can i do to prevent idiots from blocking all users on a proxy with retrying 50 times?
If there is no best practice - does this mean any platform is brute-forceable? At least with a hint on when counters are resetted?
I think you can mix your solution with captchas:
Count the number of tries per IP
In case there are too many tries from a given IP address within a given time, add a captcha to your login form.
Some sites give you maybe two or three tries before they start making you enter a captcha along with your username/password. The captcha goes away once you successfully log in.
There was a relatively good article on Coding Horror a few days ago.
While the code is focused on Django there is some really good discussion on the best practice methods on Simon Willison’s blog. He uses memcached to track IPs and login failures.
You could use a password strength checker when a user sets their password to make sure they're not using an easily brute-forced password.
EDIT: Just to be clear, this shouldn't be seen as a complete solution to the problem you're trying to solve, but it should be considered in conjunction with some of the other answers.
You're never going to be able to prevent a group of bots from trying this from lots of different IP addresses.
From the same IP address: I would say if you see an example of "suspicious" behavior (invalid username, or several valid accounts with incorrect login attempts), just block the login for a few seconds. If it's a legitimate user, they won't mind waiting a few seconds. If it's a bot this will slow them down to the point of being impractical. If you continue to see the behavior from the IP address, just block them -- but leave an out-of-band door for legitimate users (call phone #x, or email this address).
PLEASE NOTE: IP addresses can be shared among THOUSANDS or even MILLIONS of users!!! For example, most/all AOL users appear as a very small set of IP addresses due to AOL's network architecture. Most ISPs map their large user bases to a small set of public IP addresses.
You cannot assume that an IP address belongs to only a single user.
You cannot assume that a single user will be using only a single IP address.
Check the following question discussing best practices against distibuted brute force and dictionary attacks:
What is the best Distributed Brute Force countermeasure?