[Dovecot] need to block user by IP address (tried denyhosts, xinetd, iptables etc)
Hi,
I am kind of restricted to using packaged versions of software due to company policy, and we have f12 on our mail server with dovecot-1.2.15-2.fc12.i686 package.
we have recently had some brute force attacks on the pop3 and imapd and this results in many processes being used for login attempts.
Our dovecot is hosted on a Virtual Private Server which restricts access to IPTABLEs and also make a limit on the number of processes that can be running
So I can't restrict the attackers IP addresses via IPTABLES, as we don't have access to that. I can't really patch dovecot as we are reliant on the distro packages.
I spent some time trying to get dovecot to run under xinetd but had no luck, and I read some reports that it was not possible using recent versions.
I was hoping some advice on what avenue I should proceed with to automatically block brute force attacks on the dovecot server, (that dont use iptables)
Thanks,
Tom
Tom put forth on 11/9/2010 8:53 PM:
we have recently had some brute force attacks on the pop3 and imapd and this results in many processes being used for login attempts.
Our dovecot is hosted on a Virtual Private Server which restricts access to IPTABLEs and also make a limit on the number of processes that can be running
So I can't restrict the attackers IP addresses via IPTABLES, as we don't have access to that. I can't really patch dovecot as we are reliant on the distro packages.
Dovecot isn't iptables. It is an IMAP/POP3 server. It implements basic user account security. Preventing DOS or other attacks is not its job. That is the job of the kernel. There are many reasons why applications don't duplicate kernel functionality, and most should be obvious to anyone who thinks on the matter for a few moments. I'm not going to bother listing them here.
You went cheap and/or didn't research the provider/features, and now are feeling the sting. Find a new VPS provider, or upgrade to one of their packages that allows access to iptables so you can run fail2ban. I don't think you're going to be able to make headway here with Dovecot.
Some lessons are, unfortunately, learned best the hard way. :(
-- Stan
On Tue, Nov 9, 2010 at 9:21 PM, Stan Hoeppner stan@hardwarefreak.com wrote:
Tom put forth on 11/9/2010 8:53 PM:
we have recently had some brute force attacks on the pop3 and imapd and this results in many processes being used for login attempts.
Our dovecot is hosted on a Virtual Private Server which restricts access to IPTABLEs and also make a limit on the number of processes that can be running
So I can't restrict the attackers IP addresses via IPTABLES, as we don't have access to that. I can't really patch dovecot as we are reliant on the distro packages.
Dovecot isn't iptables. It is an IMAP/POP3 server. It implements basic user account security. Preventing DOS or other attacks is not its job. That is the job of the kernel. There are many reasons why applications don't duplicate kernel functionality, and most should be obvious to anyone who thinks on the matter for a few moments. I'm not going to bother listing them here.
You went cheap and/or didn't research the provider/features, and now are feeling the sting. Find a new VPS provider, or upgrade to one of their packages that allows access to iptables so you can run fail2ban. I don't think you're going to be able to make headway here with Dovecot.
Some lessons are, unfortunately, learned best the hard way. :(
-- Stan
Stan's right, dovecot can't do much about the attack. But it's not time to surrender just yet.
Do you have access to the routing table? If you can run a "route add ..." command, you can null-route the attacker (either route them to localhost or "blackhole" if your OS supports that).
If you can install fail2ban, you can fairly easily change its action to something other than iptables.
Maybe someone else has other suggestions...
-- Noel Jones
I'm not a proponent of fail2ban as I think going straight to the horse's mouth is wiser (keep it all in iptables in the first place). I agree with Stan that your VPS provider is on the wal-mart list. If no other solution avails, code up a quick little ditty that does the actual socket listen. If the incoming IP matches an allow list, hand it off to dovecot as an exec(), if not, deal with it as you see fit - normally, dropping the packet on the floor.
-david
Quoting David Ford david@blue-labs.org:
I'm not a proponent of fail2ban as I think going straight to the horse's mouth is wiser (keep it all in iptables in the first place).
I'm not a fan of fail2ban (tail/grep a log file, really?) but there are other options which do this kind of thing "better" and still allow iptables/routing to handle the issue.
I agree with Stan that your VPS provider is on the wal-mart list. If no other solution avails, code up a quick little ditty that does the actual socket listen. If the incoming IP matches an allow list, hand it off to dovecot as an exec(), if not, deal with it as you see fit - normally, dropping the packet on the floor.
That is a fine solution, if it meets their "package" requirements. If not, then something like pam_shield or a similar package may due. But even then, those types of packages may not meet the site's packaging requirements.
I can't believe a company with a packaging requirement run a Fedora though. That seems incongruous to me... Seems like they only have half a clue...
-david
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
On 11/09/2010 10:59 PM, Eric Rostetter wrote:
Quoting David Ford david@blue-labs.org:
I'm not a proponent of fail2ban as I think going straight to the horse's mouth is wiser (keep it all in iptables in the first place).
I'm not a fan of fail2ban (tail/grep a log file, really?) but there are other options which do this kind of thing "better" and still allow iptables/routing to handle the issue.
if i establish a rate limit in iptables, then accounting and reaction never makes it to userspace. horribly more expensive, especially at the occurance of a DoS attack. unfortunately not an option in Tom's case.
I agree with Stan that your VPS provider is on the wal-mart list. If no other solution avails, code up a quick little ditty that does the actual socket listen. If the incoming IP matches an allow list, hand it off to dovecot as an exec(), if not, deal with it as you see fit - normally, dropping the packet on the floor.
That is a fine solution, if it meets their "package" requirements. If not, then something like pam_shield or a similar package may due. But even then, those types of packages may not meet the site's packaging requirements.
I can't believe a company with a packaging requirement run a Fedora though. That seems incongruous to me... Seems like they only have half a clue...
agreed. a VPS should be fully functional. that's what 'VPS' implies. not almost-but-not-quite-VPS.
participants (5)
-
David Ford
-
Eric Rostetter
-
Noel J
-
Stan Hoeppner
-
Tom