This will only help if you're getting multiple attempts from one subnet,
but I've been able to use fail2ban to block IP ranges instead of single
IPs. You just have to be careful or you may block more IPs than you
want. I recommend setting fail2ban to NOT start up on boot while testing
in case you lock yourself out. You can reboot your VM to regain access.
Create a custom action file
cp action.d/iptables-multiport.conf
action.d/iptables-multiport-subnet.local
Comment out the default ban and unban lines, and replace them with
these:
actionban = <iptables> -I f2b-<name> 1 -s `echo <ip> | sed -e
"s/\([0-9]*.\)\([0-9]*.\)\([0-9]*.\)\([0-9]*\)/\1\2\30\/24/"` -j
<blocktype>
actionunban = <iptables> -D f2b-<name> -s `echo <ip> | sed -e
"s/\([0-9]*.\)\([0-9]*.\)\([0-9]*.\)\([0-9]*\)/\1\2\30\/24/"` -j
<blocktype>
Then in your jail.local, you add this to the specific jail you want to
block subnets on. I don't recommend using this as the default for all
jails.
banaction = iptables-multiport-subnet
On 2019-04-02 8:30 am, Ron Wheeler wrote:
There does not seem to be a completely foolproof and easy to manage
solution.
In my case, I modified the fail2ban time in jail to block the IP for
days rather than hours and did a close look at the expressions defining
the bad attempts to be sure that I got all (I hope) of the cases that
were appearing.
They will run out of compromised sites/IPs at some point.
If you notice that the blocked IPs show entire class C blocks that are
in countries where you do not really care about serving, you can
manually block the entire class C at the outside edge of your firewall
until someone that you actually want to let in complains.
If you have sshd running, that is another critical service to watch.
Everything is under attack all the time and the huge amount of money
spent by G7 governments on cybersecurity is not having any noticeable
reduction in this annoyance.
Sorry for the short rant but we should not have to waste so much energy
and bandwidth on this given the billions (pick a currency) that are
being spent.
I am afraid that it is mostly spent on training people who were not
recruited with the right skills and going to international conferences
to talk about how serious the problem is.
Ron
On 4/2/19 8:10 AM, James Brown wrote: Thanks Esteban. I have fail2ban
installed. Unfortunately each attempt comes from a different IP (botnet
I presume). I'm finding this all the time now, so fail2ban seems to be
no longer much use.
Was just hoping there was a Postfix or Dovecot setting I could use to
ignore these submission attempts.
James.
On 2 Apr 2019, at 7:43 pm, Esteban L <este...@little-beak.com> wrote:
You will need to install fail2ban to ip block failed attempts.
As you have correctly assumed, a malicious person is trying to hack
into you mail server.
Fail2ban is a required application now and days.
On April 2, 2019 8:57:06 AM GMT+02:00, James Brown
<jlbr...@bordo.com.au> wrote:
Not sure if this is a Dovecot or Postfix issue we use Dovecot for
authentication for Postfix. Mailboxes are stored in MySQL.
Have noticed this today:
auth-worker(42777): Info: sql(cont...@com.au,127.0.0.1): unknown user
(given password: someone123)
Also i...@com.au etc.
They are coming through on port 465.
Obviously my domain is not 'com.au' - how can I stop these attempts
from even being considered?
I did update to Postfix 3.4.5 yesterday. Running Dovecot 2.3.5.
Thanks,
James.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
