Re: Blacklistd interaction
On 6/5/2019 16:30, Wietse Venema wrote: Lefteris Tsintjelis: On 6/5/2019 12:03, lists wrote: SSHGuard now works for more than ssh. It has hooks for postfix and other services. That is great then! More and much better choices other than log parsers. Fyi, SSHGuard is a logfile parser according to https://www.sshguard.net/ Ty, noted.
Re: Blacklistd interaction
On 6/5/2019 20:07, @lbutlr wrote: On 6 May 2019, at 06:33, Lefteris Tsintjelis wrote: On 6/5/2019 15:14, @lbutlr wrote: On 6 May 2019, at 02:10, Lefteris Tsintjelis wrote: Fail2ban and equivalent log parsers are just too resource hungry, No they aren't. Yes they are. Not on my super powerful 7 year old i5 mail server with a whole 4GB of RAM that I bought for under $300. I'm sure there are people running mail servers on older and lousier hardware, but I'd guess it's not many. messy and more time consuming to maintain Sounds like you are parting some false information others fed you. There is nothing to maintain, and they run silently and take no time at all. Sounds like you never used them but if you say so must be like that I have used both and currently use sshguard. I've never seen either show up on htop when sorting by CPU time. Currently I am using sshguard 51842 root 52 0 6464 1544 S 0.0 0.0 0:00.00 sh /usr/local/sbin/sshguard -b /usr/local/etc/sshguard.blacklist -b 120:/var/db/sshguard/blacklist.db -i /var/run/sshguard 0.0 CPU, 0.0 Mem, 00:00:00 Time Perfect for personal usage and home/small office solution! You should stick with it. Try the same with any log parsers on busy mail servers and let me know how it works out.
Re: Blacklistd interaction
On 2019-05-06 10:26:17 (-0700), @lbutlr wrote: On 6 May 2019, at 11:22, lists wrote: It had been my experience that the firewall uses more resources that SSHGuard. Certainly it uses more memory. But you do not have to use a firewall if that's an issue. /etc/hosts.allow is always an option, and that block is practically free. I'm pretty sure that having the kernel (firewall) drop the packets is a lot more "free" than handing the connection to a userspace process to check /etc/hosts.allow. But on contemporary hardware, the difference is probably impossible to measure except under extreme load. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Blacklistd interaction
It had been my experience that the firewall uses more resources that SSHGuard. Certainly it uses more memory. The thing to bear in mind is what resources will be used if the offending IP address is not blocked. Some of these bots that attack web servers will fire off a hundred useless hacks. The password guessers will hammer postfix all day, but fortunately those attacks are rare. At the moment I just use postfix rate limiting. Original Message From: krem...@kreme.com Sent: May 6, 2019 10:08 AM To: postfix-users@postfix.org Subject: Re: Blacklistd interaction On 6 May 2019, at 06:33, Lefteris Tsintjelis wrote: > On 6/5/2019 15:14, @lbutlr wrote: >> On 6 May 2019, at 02:10, Lefteris Tsintjelis wrote: >>> Fail2ban and equivalent log parsers are just too resource hungry, >> No they aren't. > > Yes they are. Not on my super powerful 7 year old i5 mail server with a whole 4GB of RAM that I bought for under $300. I'm sure there are people running mail servers on older and lousier hardware, but I'd guess it's not many. >>> messy and more time consuming to maintain >> Sounds like you are parting some false information others fed you. There is >> nothing to maintain, and they run silently and take no time at all. > > Sounds like you never used them but if you say so must be like that I have used both and currently use sshguard. I've never seen either show up on htop when sorting by CPU time. Currently I am using sshguard 51842 root 52 0 6464 1544 S 0.0 0.0 0:00.00 sh /usr/local/sbin/sshguard -b /usr/local/etc/sshguard.blacklist -b 120:/var/db/sshguard/blacklist.db -i /var/run/sshguard 0.0 CPU, 0.0 Mem, 00:00:00 Time
Re: Blacklistd interaction
On 6 May 2019, at 11:22, lists wrote: > It had been my experience that the firewall uses more resources that > SSHGuard. Certainly it uses more memory. But you do not have to use a firewall if that's an issue. /etc/hosts.allow is always an option, and that block is practically free. -- I never wanted to do this in the first place.
Re: Blacklistd interaction
On 6 May 2019, at 06:33, Lefteris Tsintjelis wrote: > On 6/5/2019 15:14, @lbutlr wrote: >> On 6 May 2019, at 02:10, Lefteris Tsintjelis wrote: >>> Fail2ban and equivalent log parsers are just too resource hungry, >> No they aren't. > > Yes they are. Not on my super powerful 7 year old i5 mail server with a whole 4GB of RAM that I bought for under $300. I'm sure there are people running mail servers on older and lousier hardware, but I'd guess it's not many. >>> messy and more time consuming to maintain >> Sounds like you are parting some false information others fed you. There is >> nothing to maintain, and they run silently and take no time at all. > > Sounds like you never used them but if you say so must be like that I have used both and currently use sshguard. I've never seen either show up on htop when sorting by CPU time. Currently I am using sshguard 51842 root 52 0 6464 1544 S 0.0 0.0 0:00.00 sh /usr/local/sbin/sshguard -b /usr/local/etc/sshguard.blacklist -b 120:/var/db/sshguard/blacklist.db -i /var/run/sshguard 0.0 CPU, 0.0 Mem, 00:00:00 Time
Re: Blacklistd interaction
Lefteris Tsintjelis: > On 6/5/2019 12:03, lists wrote: > > SSHGuard now works for more than ssh. It has hooks for postfix and other > > services. > > That is great then! More and much better choices other than log parsers. Fyi, SSHGuard is a logfile parser according to https://www.sshguard.net/ Wietse
Re: Blacklistd interaction
On 6/5/2019 15:14, @lbutlr wrote: On 6 May 2019, at 02:10, Lefteris Tsintjelis wrote: Fail2ban and equivalent log parsers are just too resource hungry, No they aren't. Yes they are. messy and more time consuming to maintain Sounds like you are parting some false information others fed you. There is nothing to maintain, and they run silently and take no time at all. Sounds like you never used them but if you say so must be like that ;)
Re: Blacklistd interaction
On 6 May 2019, at 02:10, Lefteris Tsintjelis wrote: > On 6/5/2019 9:42, @lbutlr wrote: >> On 4 May 2019, at 15:52, Lefteris Tsintjelis wrote: >>> Would be great to consider its future adoption and if possible to take it >>> even further to interact with postscreen. >> Why would this be a good thing for postfix to do? >> There are already plenty of tools that generate block lists for the various >> types of firewalls out there, and they do not require patching postfix. >> SSHGuard and Fail2Ban are two that seem to work very well. > > SSHguard is similar but only for ssh, not for postfix. SSHGuard can be used to block anyone who tries to get into your system. It is not limited to SSH. It even can work without a firewall. > Fail2ban and equivalent log parsers are just too resource hungry, No they aren't. > messy and more time consuming to maintain Sounds like you are parting some false information others fed you. There is nothing to maintain, and they run silently and take no time at all. > blacklistd is offering simplicity, central management, extreme speed compared > to any log parser with minimal resources. There is no comparison really > between log parsers and balcklistd or SSHguard. If you say so. I've used both shgiard and fail2ban and have had no complaints or issues once they are configured. And they both offer a variety of configuration options. -- When we woke up that morning we had no way of knowing that in a matter of hours we'd changed the way we were going. Where would I be now? Where would I be now if we'd never met? Would I be singing this song to someone else instead?
Re: Virtual Mailbox Delivery with mixed address classes.
Hi Viktor, On Mon, 6 May 2019, Viktor Dukhovni wrote: In most cases virtual(5) is superior to aliases(5), but you still need it for mailman and pipes, so you'd rewrite those to localhost (or some suitable domain listed in mydestination). Right. Good point. Something to keep in mind. To paraphrase my understanding than: If a domain is not listed in any other class, it needs to be listed in virtual_alias_domains. virtual_alias_maps rewrites are being applied to incoming mail regardless of the class however. Well, it needs to be listed if you want to accept inbound mail and your only choice is rewriting to some underlying domain. Yes, rewriting happens either way. Thanks for confirming. And of course, I'd eventually would like to accept mail at some point after the rewriting. :-) I was hoping to get away from the rewrites. Especially as I'd like people to be able to login to the imap server with their email-address, e.g. u...@example.org. That prevents a lot of confusion on the user side... .invalid would probably make things weird... The recipient envelope has nothing to do with how users log in, or which mailbox they see. Mapping of users to mailboxes is up to the IMAP server. In some cases, you can also rewrite back to the original address via smtp_generic_maps, but it is often not needed, since the IMAP server can perform the relevant mappings. You are correct. Let me rephrase: Ideally I'd like to be able to receive mail and use the same address as an LMTP destination and have delivery work. That way the logic is very simple and people only have to add one entry somewhere rather than multiple entries to keep rewriting in mind. I do believe that is possible... I need to do some tests though with my setup... Preferably on a copy of that mailserver... If a domain has at least one virtual_mailbox user, add it to the virtual_mailbox_domains list and remove it from virtual_alias_domains or relay_domains. And also mydestination. Right. I forgot about that part. That would mean moving my users from local to virtual mailbox delivery should happen first. Add all virtual_mailbox users under the mydestinations domain to the local_recipient_maps for now. At which point, no need for local_recipient_maps for that domain. That's only for domains where all the users are local or aliased. True, once everyone is moved to virtual mailbox, that makes a lot of sense. If I stay with local delivery, I'd probably still need that though. But it seems to me that moving to virtual mailboxes is the right approach actually. In that setup transport_maps would still be consulted, right? Always consulted, unless the final recipient is in a virtual alias domain, in which case the recipient is bounced. Thanks for clarifying. That is already taken into account in my current setup I believe. So the plan now is: 1. Take care of the pipe delivery in /etc/aliases and ensure that they will get mail in the future under e.g. u...@hostname.example.com. Use virtual_alias_maps for that. 2. Migrate the dovecot users currently on local to virtual mailbox delivery. Remove example.com from mydestinations and move it to virtual_mailbox_domains. 3. Migrate other domains with at least one virtual_mailbox user from the current virtual_alias_domains to virtual_mailbox_domains. I think this should work. Thanks a lot for being my sounding board. That was very helpful. There's one thing I noticed though in my setup which would probably be affecting the move from local to virtual mailbox delivery: Right now I have a bunch of mailroutes in the form of either foo -> bar which work fine as example.com is part of mydestinations so mail to f...@example.com gets correctly rewritten to bar and sent onwards to the LMTP socket as b...@host.example.com as append_at_myorigin is set to yes. Due to a configuration error on my part on the Dovecot side that worked fine. I have all users in an SQL database and my SQL query would always return u...@example.com regardless of the input. e.g. u...@host.example.com as a lookup key would return u...@example.com as the dovecot user due to me getting the SQL query wrong... Once I fixed the query I was getting errors about unknown users, because of course u...@host.example.com was an invalid user. u...@example.com would have been the right field. I see multiple ways of fixing that problem: 1. Change the SQL query on the dovecot side to also consider host.example.com a valid domain part. 2. Change append_at_myorigin to no and set append_dot_mydomain to yes. 3. Change my virtual_alias_maps to not use bare usernames (e.g. user) but always fully qualified ones including domain names (e.g. u...@example.com). What would be your preferred solution? 1. would be the easy fix. 2. seems cleaner but I am not sure about any side effects. 3. would be the most work but I fear this might be necessary anyway for moving from local to virtual
Re: Blacklistd interaction
On 6/5/2019 12:03, lists wrote: SSHGuard now works for more than ssh. It has hooks for postfix and other services. That is great then! More and much better choices other than log parsers.
Re: Blacklistd interaction
SSHGuard now works for more than ssh. It has hooks for postfix and other services. Original Message From: le...@spes.gr Sent: May 6, 2019 1:11 AM To: postfix-users@postfix.org Subject: Re: Blacklistd interaction On 6/5/2019 9:42, @lbutlr wrote: > On 4 May 2019, at 15:52, Lefteris Tsintjelis wrote: >> Would be great to consider its future adoption and if possible to take it >> even further to interact with postscreen. > > Why would this be a good thing for postfix to do? > > There are already plenty of tools that generate block lists for the various > types of firewalls out there, and they do not require patching postfix. > > SSHGuard and Fail2Ban are two that seem to work very well. SSHguard is similar but only for ssh, not for postfix. Fail2ban and equivalent log parsers are just too resource hungry, messy and more time consuming to maintain. blacklistd is offering simplicity, central management, extreme speed compared to any log parser with minimal resources. There is no comparison really between log parsers and balcklistd or SSHguard.
Re: Blacklistd interaction
On 6/5/2019 9:42, @lbutlr wrote: On 4 May 2019, at 15:52, Lefteris Tsintjelis wrote: Would be great to consider its future adoption and if possible to take it even further to interact with postscreen. Why would this be a good thing for postfix to do? There are already plenty of tools that generate block lists for the various types of firewalls out there, and they do not require patching postfix. SSHGuard and Fail2Ban are two that seem to work very well. SSHguard is similar but only for ssh, not for postfix. Fail2ban and equivalent log parsers are just too resource hungry, messy and more time consuming to maintain. blacklistd is offering simplicity, central management, extreme speed compared to any log parser with minimal resources. There is no comparison really between log parsers and balcklistd or SSHguard.
Re: Virtual Mailbox Delivery with mixed address classes.
On Mon, May 06, 2019 at 03:47:58AM +0200, Andreas Thienemann wrote: > > If you're not using /etc/aliases or .forward files in any substantive > > way, you could switch to a virtual mailbox domain. > > No .forward files at all. Users do not have local accounts on the machine > anymore, except uucp users of course... > I do use /etc/aliases (and another alias list) for a few mailman redirects > plus a handful of pipe deliveries and some minor redirects... In most cases virtual(5) is superior to aliases(5), but you still need it for mailman and pipes, so you'd rewrite those to localhost (or some suitable domain listed in mydestination). > To paraphrase my understanding than: > > If a domain is not listed in any other class, it needs to be listed in > virtual_alias_domains. virtual_alias_maps rewrites are being applied to > incoming mail regardless of the class however. Well, it needs to be listed if you want to accept inbound mail and your only choice is rewriting to some underlying domain. Yes, rewriting happens either way. > I was hoping to get away from the rewrites. Especially as I'd like people > to be able to login to the imap server with their email-address, e.g. > u...@example.org. That prevents a lot of confusion on the user side... > .invalid would probably make things weird... The recipient envelope has nothing to do with how users log in, or which mailbox they see. Mapping of users to mailboxes is up to the IMAP server. In some cases, you can also rewrite back to the original address via smtp_generic_maps, but it is often not needed, since the IMAP server can perform the relevant mappings. > If a domain has at least one virtual_mailbox user, add it to the > virtual_mailbox_domains list and remove it from virtual_alias_domains or > relay_domains. And also mydestination. > Add all virtual_mailbox users under the mydestinations domain to the > local_recipient_maps for now. At which point, no need for local_recipient_maps for that domain. That's only for domains where all the users are local or aliased. > In that setup transport_maps would still be consulted, right? Always consulted, unless the final recipient is in a virtual alias domain, in which case the recipient is bounced. -- Viktor.
Re: Blacklistd interaction
I like SSHGuard a lot, though I don't let it mess with my email. It is great for keeping the riff raff off of port 22 with very little effort to set up. But now that you mention it, I think SSHGuard would be totally safe to block IP addresses that attempt to use the mail server as a relay. Original Message From: krem...@kreme.com Sent: May 5, 2019 11:43 PM To: postfix-users@postfix.org Subject: Re: Blacklistd interaction On 4 May 2019, at 15:52, Lefteris Tsintjelis wrote: > Would be great to consider its future adoption and if possible to take it > even further to interact with postscreen. Why would this be a good thing for postfix to do? There are already plenty of tools that generate block lists for the various types of firewalls out there, and they do not require patching postfix. SSHGuard and Fail2Ban are two that seem to work very well. -- Love seekest only self to please, To bind another to its delight Joys in another's loss of ease And builds a hell in Heaven's despite!
Re: Blacklistd interaction
On 4 May 2019, at 15:52, Lefteris Tsintjelis wrote: > Would be great to consider its future adoption and if possible to take it > even further to interact with postscreen. Why would this be a good thing for postfix to do? There are already plenty of tools that generate block lists for the various types of firewalls out there, and they do not require patching postfix. SSHGuard and Fail2Ban are two that seem to work very well. -- Love seekest only self to please, To bind another to its delight Joys in another's loss of ease And builds a hell in Heaven's despite!
