-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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). - -- Nikolai Lusan Email: niko...@lusan.id.au -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmXMuycACgkQ4ZaDRV2V L6TAeQ//ayU+LqxfKuDFp88+mhY0WoeXgFCvoveVY4oeKatoJrclP1Vy9FxBvI2R nHjYQ7IA8TYKAs3Wfc906XU/qf1InSsTchy978wn3+AmB/WtqYCAf7j95w0v9c6H yh7VahNuYolsxXjtq2zJ8YqiHHcOSpq9FhjzzwnFpO3qVKCul03swk3GYGUrPzLA +9cj3aBRPwNa+8uiki9ENXZvFbPNhUbSIxQsXs8zeY+H4H4qHLguovfCADkYutA1 TMuGOhdBDwXGsxfKVnfdQAZurhIwQuw+ZSv5j9X3tkJEUOcyNGvTqvuT82xc8FNX ZjhZvorMIBsn5ZVMA1WKQzeXAMgzvvg0DszW1475VmrPe+fzU2uYiWL0bpQ+wrr/ nll80NnJVcR7B2s4d9jp2/HXOxX4ohbqzuHsuVOlrxLfTixPJBI2JNqkbyS7/D2A 407akkOdE8Vm0msU4cp1lRqNNN4pxBSxWiAZLtGX9l1JYhDQJq0QHVqN8F6C9rOT g9kqX+vOtGVFiHWmjPWM5NOU7tsZmX0aghy6eErdtwvghd1ayQc040KRqRNRNYZ6 JAMTbbcMRGnDEbNFzZsG+BMr4dJ826dFn1DS6uUPjYaXmYmwVWHAX7XrLieHOM84 pgXRJjPhdxDPIsBwu8ytpxsYaYZ0AZ3tCZYH5HnF07AJnSeZxfk= =f9Z/ -----END PGP SIGNATURE----- _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
