Ok would like to help and I DO understand the issue at hand.
It took me with custom programming 5 years of tinkering to get to what i
have today.
So a few questions / comments ??
Are you running an sql database or just user-db (local) to do the lookups ?
sql gives you some major flexability on how to track and ignore ip
blocks etc etc etc upon logins.
Issues to consider (I will explain the system i wrote for SCOM.CA as I
went though a lot to get here and you like most are probably
experiencing the same hack attempts.)
Note I am not trying to get off topic but you need to think about stuff
like this through a bit.
You also have to consider people trying to send through postfix as it is
the same issue in reverse.
Under SCOM I do the following (only meant to be a guideline):
1. i have a common syslogger running that ALL logging goes through.
2. I then have conditions against anything being logged that will
trigger an event.
3. The event triggered in your case would be seeing a line like
auth: sql(t...@dereilanatureinn.ca,220.194.140.110,
<5H72HLPfTp/cwoxu>): unknown user
pop3-login: Disconnected: Connection closed (auth failed, 1 attempts
in 3 secs): user=<edri...@scom.ca>, method=PLAIN, rip=110.44.124.224,
lip=65.39.148.18
there are other conditions but you get the idea.
Ok from here it starts getting complicated.
The idea is to keep the rift raft out and allow good users in.
Easier said then done.
I track all bad logins from all bad ip addresses and then run a seperate
database table that tracks that.
the ip address that gets tracked lands in two places,
the firewall tables (which for me are global)
&
the user in my database.
if a user is unknown (example above) then at least the first condition
will catch a bad hack attempt based on ip. Most hack attempts by ip
address usually keep sending common login names (like admin, ftp,
ftpuser etc etc) hoping to match to a common account.
for the user (which is relative here) i let 30 attempts go by every 30
minutes and 500 per month, after which the user is blocked via auth in
sql and will have to call to get unlocked. Usually the ip address is
blacklisted before the username is so its not that much of a deal.
afterwhich it becomes part of the user query to lock out the userfrom
anywhere as they are obviously getting hacked.
when an ip is doing the hacking then i count using the same formula and
then blacklist it internal to all of my servers (thus a database makes
it earier to track)
I run freebsd and thus use pf firewall, iptables can do the same with
the same info you just need to build the tables and uodate them. (i
update mine every 10 minutes, i find pf does this quicker on large
lables (like 10,000 blocked) )
Now for the issue at hand that you are asking about:
I am sure that the c programming could be patched along the line to do
exactly what you are asking,
However Issues that pop up.
so you hang up on the connection, they will probably just login again
anyways which means without tracking the ip & username stats and
updating accordingly it will really not change anything at the end of
the day.
In my experience I see people / servers etc constantly hacking my side
and what i generally described above turned out to be the only real fix,
and not even really that guarenteed to work!
I do get ip's that get blacklisted by accident (i do the whole class 'c'
as the 'c' block is usually all the same guy) but i get a good one maybe
every few months, usually when i block it there are not many complaints
after that.
I know the above is complicated, fyi i track postfix's sasl auth's as
well but in that case to get a username & ip address on one syslog line
i had to patch the sasl auth c file to get a log entry that was useable.
Postfix simply will NOT provide the info on one line.
Between both of the conditions above the server's remain fairly useable
and secured.
the CSF firewall option below IS valid but i find you need to track IP
address & username or you end up blocking stuff you dont want to
also on another note IPV6 (at least in canada) is becoming a pain for isp's
many cable companies, dsl providers etc are assigning an ipv6 address
and then converting it to ipv4 on the way out the door from their
networks using double natting ?
Issue is you can have 10,000 people all sharing that same ip address and
if you block it then that will prevent other 'good' people from logging
in, again back to tracking the username in this case gives you an out if
the hacker is just using a list obtained elsewhere on the net.
Food for thought.
Happy Monday !!!
Thanks - paul
Paul Kudla
Scom.ca Internet Services <http://www.scom.ca>
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3
Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
Email p...@scom.ca
On 5/23/2022 3:26 PM, dovecot-boun...@dovecot.org wrote:
On 2022-05-23 20:11, Lloyd Zusman wrote:
I'm running dovecot 2.2.13 under Debian 8.
I'd like to force an immediate TCP socket disconnect after any imap
login attempt that fails.
Right now, if invalid credentials are supplied during an imap login,
the client can keep retrying logins with different credentials.
However, I want to prevent that from occurring by causing the socket
connection to be closed as soon as there is any failed login attempt.
I haven't been able to find any dovecot configuration setting which
could control this behavior, but I'm hoping that I just missed
something.
Thank you very much for any suggestions.
--
hippo...@gmail.com
Take a hippopotamus to lunch today.
Hi there,
Try CSF firewall. Make sure to enable Login Failure Detection and Max
Retries Per X Minutes, and notice with such option set, it will
permenantly block the IP addresses that exceeds maximum login failures
in the specified interval.
Anyhow, my personal recommendation in terms of security, its to use web
mail and limit login attempts per minutes and for higher security, setup
a VPN and disallow access to the web mail except through the VPN.
Good luck.
Zakaia.
