Hi, Following this thread has been quite intriguing. Interesting conversation indeed.
On a similar topic but probably more focused on addressing root cause (which in mind is just passwords = the devil of security) and the inherent insecurities with using them. I’m very interested in what options / solutions (if any) exist that allow you to use a passwordless approach to authenticating your users against imaps/pop3/smtps/submission services (tls encrypted of course) acknowledging that it’s extremely unlikely to address abuse of the non-auth enabled smtp listener so won’t rid the server of ‘all noise’ or ‘hacking attempts’ nor address lower level exploit/attacks (network/protocol level etc). Do any solutions exist today? I suspect the issue isn’t so much what you can do server side as possibilities are near endless but constraint is email client support which in my mind is the primary issue? Is that a reasonable conclusion? I’m guessing what I’m asking is if there’s an open source solution that doesn’t require you to pay Microsoft or others extraordinary amounts of money just to get some smart protection? I see security as a right for users so open source way to craft an architecture that provides this as an option for users who opt-in would be pretty cool (eventually becoming the normal longer term) Keen to hear thoughts on this as I suspect if you can architect a solution that allows users to opt for passwordless approach to auth’ing with a long term desire and goal to phase out password use, then it seems like a pretty epic win for I loving the security of the internet as a whole longer term. Large scale providers with perhaps millions of users = ok tough luck that’s gonna be a real challenge, legendary feat if can accomplish it in practice :) May not be the appropriate thread or ask these questions but thought if there were solutions available for such a solution, perhaps that may go a long way to helping answer what can be done to secure the servers from these types of attacks :) I’m much more inclined personally to tackle root cause and remove the issue completely but acknowledge that it may be a panacea and utopian mind set and may not = reality or not readily work in more scenarios than what issues it’s trying to address. Feasibility question(s) really. Thanks Andrew > On 27/04/2022, at 2:00 PM, lists <li...@lazygranch.com> wrote: > > > https://www.reddit.com/r/postfix/ > > Well there is a subreddit for postfix. News to me but I just joined it. > > I do my best to stay out of these "conversations" on the listserv and reserve > my posts for when I am really stumped. > > But since I am posting put me in the firewall geofence crowd. I have done > this for a two years now and it vastly reduces the hacking on my server. I > block all email ports other than 25 from countries I have no plan on > visiting. This is really only practical for a personal email server. I also > have a list of data centers that I give the same treatment. > > I see the snowshoe hackers on my web server and I assume they are on my email > but I don't read the postfix logs as often. I haven't seen a hacker hammer my > server in a long time. It is all snowshoe these days. > > I am not a fan of fail2ban or sshguard on my low powered VPS. I find > dynamically adding IPs to the firewall is a high CPU usage event. It may be a > consequence of having a huge list of IP space to block. My assumption is > firewalld has to add the IPs in an efficient to search manner and arranging > the table/database is CPU intensive. It would send the VPS to 100%. (My > personal data center blocking list is about 40k lines of CIDRs.) I was > choking the server adding IPs for what would otherwise be a low impact event. > Sometimes I think a VPS is lower CPU power than a R Pi. > > Firewalld itself is a very low CPU usage program once the table/database is > established. It does use a fair amount of RAM which again must be related to > the table/database it creates. > > I have no fear of my passwords being breached. It is a personal server so > every password was created by me and all are generated by an algorithm to > achieve high entropy. I've been using 20 characters as a standard since that > seems to work on most websites as well. They are SHA512 on the server. > > Regarding setting up postfix and Dovecot it is best to follow a guide. This > is what I used: > https://blog.andreev.it/?p=1975 > It isn't complete as far as postfix goes but I implement features I find > discussed on the postfix listserv as they come up. I doubt I could just read > the man pages for postfix and Dovecot to set up an email server. Too many > options. > > Back to lurker mode. > > From: t...@leding.net > Sent: April 26, 2022 12:45 PM > To: le...@spes.gr > Cc: postfix-users@postfix.org > Subject: Re: password security > > Good feedback - typically I’d have some comments but since we’ve wandered a > fair bit off the reserve here, I will refrain. If anyone wants to continue > this at Reddit or somewhere else more appropo, let me know… > > On 26 Apr 2022, at 11:56, Lefteris Tsintjelis wrote: > > On 26/4/2022 20:11, Antonio Leding wrote: > > “…I'm just saying it's [F2B] not a solution to modern brute-force attack on > passwords/accounts….” > > It’s actually staggering that you say this because of how incredibly > inaccurate this statement is… > > Presume someone goes brute-force against a PostFix server via v6 only - so > tons of addresses at their disposal. And let’s also presume that the defender > has F2B tuned to allow no more than 2 attempts. > > We know that brute-force is all about attempts per unit time, right? Yes - > ok, so then let’s presume the attacker tunes their stack with a very low TCP > wait time - somewhere around 1s. OK, fine, so after 2 rapid attempts, the > attacker will get blocked and they will wait 1s before moving on to the next > IP - rinse - repeat. > > The reality here is the attacker is essentially stuck in the mud against F2B. > And because they want to maximize their attempts per unit time, they will > move on once they realize someone is actively blocking their traffic. > > They never moved on from here > > In my real-world use-case, I had over 200K daily password attempts prior to > F2B and 2 weeks after implementation, that number dropped to below 1 per day. > > 1-2 per IP per day here. They adopt and tune accordingly. It has been > happening and still does for many years now no matter what even with F2B. > Even once a day coming from a few thousand IPs is still a few thousand > attempts even with IP blocking set at 1 day blocking per IP. > > Blocking an IP is the single cheapest most effective thing one can do re: > undesired traffic. Are there “better” solutions? Sure but what is “best” is a > subjective determination and always depends on the use-case. And for almost > all use-cases, blocking IPs is a solid tool… > > IP blocking is one of the best ways but F2B is limited to each firewall's > capabilities and you deal with thousands of IPs. If you want something more > permanent and use F2B then firewall will reach its limits sooner or later. > > Changing the authentication method to anything that does not accept PLAIN > TEXT may also be another good way to deal with it that may work. By doing > that only I have actually seen some attacks to completely stop. > > F2B is a nice but limited solution to this problem. The best way, I > personally found so far besides the password authentication method, is by > setting smtpd_delay_reject to no (very important this step) and use my own > home made and maintained DNSBL service as early as possible to restrict those > attacks in a very permanent way from a few mail servers at the same time. > CIDR blocking also works very well and fast with DNSBL in case of net blocks > and huge IP blocks like IPv6 or IPv4 even and you also have central > management of the black/white list. This has the advantage that does not give > any info to the attacker other than his IP is blocked and stops the attack as > early as possible but also limits the possibilities of a successful attack > down to almost nothing. > > Lefteris
