> Even then it seems that some of them turn up again pretty much > instantly after expiry.
You could update the expire time on each new connection/port scan attempt. This way you could put say 4 days expire time and block these IPs on all ports on all your systems and new connection attempts would update the expire for all the systems. 4 days is because 5 days is a typical timeout for a temporary error for SMTP. It may happen that someone used for 24hs a cloud instance and then got banned by the cloud provider, the IP used for spam/scans/attacks could be reused for another client for a legit activity. So if that new client for the old IP sends to your client some important mail, it's not lost and doesn't generate an undeliverable mail report, it just takes some days to reach the destination (with retries by the origin server). 4 weeks looks excessive for cloud shared IPs. On 30/5/20 07:25, Peter Nicolai Mathias Hansteen wrote: > > >> 30. mai 2020 kl. 11:54 skrev Walter Alejandro Iglesias <w...@roquesor.com>: >> >> The problem is most system administrators out there do very little. If >> you were getting spam or attacks from some IP, even if you report the >> issue to the respective whois abuse@ address, chances are attacks from >> that IP won't stop next week, nor even next month. >> >> So, in general terms, I would refrain as much as possible from hurry to >> expiring addresses. Just my opinion. > > Yes, there are a lot of systems out there that seem to be not really > maintained at all. After years of advocating 24 hour expiry some time back I > went to four weeks on the ssh brutes blacklist. Even then it seems that some > of them turn up again pretty much instantly after expiry. > > All the best, > > — > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. > > > >
