On 2/14/24 8:07 AM, Nikolai Lusan via Postfix-users wrote:
On Wed, 2024-02-14 at 11:34 +0100, Matus UHLAR - fantomas via Postfix-
users wrote:
>> On Wed, 2024-02-07 at 12:15 -0500, Viktor Dukhovni via Postfix-users
>> wrote:
>>> I prefer to have logs that record what I'm blocking. With
>>> firewall
>>> rules there's not sufficient forensic evidence left behind.
> On 14.02.24 19:11, Nikolai Lusan via Postfix-users wrote:
>> Here's a tip - try the 'LOG' target before you DROP/DENY/REJECT (I
>> prefer REJECT with an ICMP host/port unreachable for _all_ ports on
>> my
>> side of the link).
> Unfortunately it only provides IP you have banned, not from/to mail
> addresses.
Depending on how convoluted a setup you want you could potentially drop
in some tcpdump scans targeted at submission/smtp for the IP's in
question - I'm not saying it's an easy fix, but it may just give you the
information you want ... the packets are there in the network stack it's
just what you do with them before you assign an iptables/nftables action
to them. There is a whole heap of power in the network stack, and
how/where you can route things to mess with them before a firewalling
decision is made (granted this has to be done on the mail host, and you
have to have the resources there to deal with it - potentially having a
couple of equally weighted MX servers could spread the load and get the
job done rather than adding extra RAM/CPU to an existing mail host or
MX).
> However I also implemented it because of too many attacks on servers..
Having been a sysadmin around the traps since the mid-to-late 1990's I
have seen many an attack on servers - it comes with the territory, you
run a service and some goon is going to try and exploit it. For example
no matter how securely you configure an ssh server you are going to see
people running distributed attacks trying to login as root (and a whole
heap of other usernames - I find my ssh [attempted] auth logs to be a
source of amusement, sometimes, when I'm not getting all "I'm going to
track you down and stab you in "interesting" ways 🙂. Submission and
IMAPS services have become another one of these things (most of the SMTP
attacks are boring and easily dealt with using basic one line scripts)
but I have found a decent set of fail2ban regexes with a low threshold
for failure and a long ban time severely reduces the volume of these
attacks, and a permanent "throw the packets on the floor" approach for
repeat offenders doesn't hurt either.
We all get attacks, I have only had one instance where a SYN attack
actually rendered a server unusable (it was a web server and because of
commercial arrangements I couldn't kill it at and edge router) -
admittedly it was an HTTP[S] server, the code being used for the attack
was lifted directly from a java text book, and the attacker was using
his home connection to do this - suffices to say a reboot into the
remote rescue console allowed me to make the server usable for
legitimate clients in a short period of time, and reporting to the ISP
(plus a little spite on my part) made the outcome for the little punk
not so great.
One thing nobody has addressed is reporting to the upstream providers
for these attackers. WHOIS is a wonderful tool, and so is traceroute and
it's variants, get the information contact the ISP/hosting company
and/or it's upstream providers and hint a some reporting to SORBS or
other blacklisting sites and you might just get them shutdown outside
your network. Nobody wants to have to jump through the hoops to get off
a blacklist. Also (unless you want the connections made to your hosts)
having your upstream potentially block IP's at it's edge routers might
have the desired effect (note I am only talking about connections made
from specific IP's the you know to be carrying only attack payloads - if
it is shared hosting then contacting the operator of the shared host
will probably get you the outcome you want ... I know I have been on the
receiving end of this, I was admining a hosting company that allowed
"walk-up" hosting and someone chose a Friday evening to sign up with
their own domain to the CPANEL machine and proceed to spam the shite out
of things for about 2 days until something hit our support ticketing
system that alerted us to this, at which point we killed the account and
set about trying to restore the reputation of our IP because not to do
so would have killed a heap of legitimate business for us).
Running any kind of service on the open internet is going to invite some
level of attacks, it's why we do internal security (I met Wietse at a
security conference almost 20 years ago). But security is an ongoing
process, and if you get targeted by the "wrong" people you may need to
take extreme measures to keep your service running - even if it means
you can't collect all the data on the attack you would like to have. The
best you can do is keep evolving the measures you use to reject attacks,
hope that the hosts at the other end can recognise that their attempts
aren't getting though, and hence discontinue their anti-social
behaviour. All this while trying not to make your own servers generally
anti-social (I'm currently "educating" a team from my local government
as to why their email setup is anti-social, and their website just
inadequate).
_______________________________________________ > Postfix-users mailing list -- postfix-users@postfix.org > To
unsubscribe send an email to postfix-users-le...@postfix.org
I have a habit of cutting the source code and forwarding it with the
email to abuse@xxx.
But it does not seem to work, in fact I have often notice an increase.
--john
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
