Re: connect then disconnect; backscatter?
On 2021-04-18 00:25, Wietse Venema wrote: Even with SASL turned off you will see that some bots try SASL auth. But with SASL turned they can't use this to verify passwords. http://www.postfix.org/SASL_README.html it could imho be dokumented not to make it global in this howto / manual googled how to and nearly all homepages dont tell anything what to do in master.cf :(
Re: connect then disconnect; backscatter?
li...@lazygranch.com: > > You should enable SASL auth in master.cf NOT main.cf, and ONLY for > > a service that needs SASL auth. > > > > Otherwise you're turning it on for the server-to-server port (25) > > where it is not doing any good. > > > > Wietse > > > > OK now it makes sense to comment out the line in the main.cf. I knew > sasl had to be enabled somewhere. As it turns out I had put all the > lines in master.cf for the submission 587 but neglected to comment out > this line in the main.cf. > > I did a reload/restart and the mail still works. I will give that > spammer an hour and see what shows up. The password guesser would hit > the server about every 20 minutes. All my passwords are high entropy 20 > characters computer generated. Even with SASL turned off you will see that some bots try SASL auth. But with SASL turned they can't use this to verify passwords. Wietse
Re: connect then disconnect; backscatter?
On Sat, 17 Apr 2021 17:03:51 -0400 (EDT) Wietse Venema wrote: > li...@lazygranch.com: > > I do have "smtpd_sasl_auth_enable = yes" and I use port 587. Before > > I comment out that line, here is the general area of my main.cf > > dealing with sasl. I cut out my rbls but otherwise this is what I > > use. Any other problems? > > You should enable SASL auth in master.cf NOT main.cf, and ONLY for > a service that needs SASL auth. > > Otherwise you're turning it on for the server-to-server port (25) > where it is not doing any good. > > Wietse > OK now it makes sense to comment out the line in the main.cf. I knew sasl had to be enabled somewhere. As it turns out I had put all the lines in master.cf for the submission 587 but neglected to comment out this line in the main.cf. I did a reload/restart and the mail still works. I will give that spammer an hour and see what shows up. The password guesser would hit the server about every 20 minutes. All my passwords are high entropy 20 characters computer generated. Thanks to all.
Re: Trusting postfix client certs for relaying
Dan Mahoney (Gushi): > All, > > The dayjob has a number of machines out in the wild that need to be able > to send mail (mostly from cron jobs) home to the mothership. Not all have > controllable reverse DNS. It's an issue with donated colo and transit. > Doing a bunch of tunnels would work but it's a really stupid answer. > > We'd like to use client-certs as an auth mechanism. We're already > deploying trusted client certs for use with puppet, so we have a full CA > setup already in place. If we trust any cert signed by our puppetmaster's > CA (which uses a root/intermediate/leaf setup for signing) we should be > golden. > > However, reading the postfix docs > (http://www.postfix.org/TLS_README.html#server_vrfy_client) , I see > warnings that one should not use permit_tls_all_clientcerts for something > like that. If an outside client were to connect with (say) a let's > encrypt cert configured as a client cert (which we may want to *validate*, > but *not permit for relaying*, that cert would allow relay) > > It seems that There are knobs that let you list *individual certs* for > allowing trusted relaying, but not *individual ca's*. > > Is there any way around this? Yes: handle that traffic with a dedicated smtpd instance that only trusts your internal root. Postfix check_ccert_access currently supports matches based on certificate fingerprint and public key fingerprint. The other available attributes, issuer name and subject name, are too soft for security decisions. Wietse
Re: connect then disconnect; backscatter?
li...@lazygranch.com: > I do have "smtpd_sasl_auth_enable = yes" and I use port 587. Before I > comment out that line, here is the general area of my main.cf dealing > with sasl. I cut out my rbls but otherwise this is what I use. Any other > problems? You should enable SASL auth in master.cf NOT main.cf, and ONLY for a service that needs SASL auth. Otherwise you're turning it on for the server-to-server port (25) where it is not doing any good. Wietse
Re: connect then disconnect; backscatter?
On Sat, 17 Apr 2021 14:35:37 +0200 Benny Pedersen wrote: > On 2021-04-17 09:58, li...@lazygranch.com wrote: > > I am getting a lot of these: > > > > Apr 17 07:27:10 mydomain postfix/smtpd[21897]: connect from > > mone183.secundiarourous.com[141.98.10.183] > > Apr 17 07:27:11 mydomain postfix/smtpd[21897]: disconnect from > > mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 > > commands=2/3 > > https://docs.iredmail.org/enable.smtp.auth.on.port.25.html > > have you enabled sasl on port 25 ? > > dont do this if you have > > its a common mistake > > smtpd_sasl_auth_enable = yes is not ment for being in main.cf > > sorry if i read auth=0/1 incorrect I do have "smtpd_sasl_auth_enable = yes" and I use port 587. Before I comment out that line, here is the general area of my main.cf dealing with sasl. I cut out my rbls but otherwise this is what I use. Any other problems? --- unknown_client_reject_code = 550 # SASL smtpd_sasl_type = dovecot broken_sasl_auth_clients = yes smtpd_helo_required = yes smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_non_fqdn_recipient, check_client_access hash:/etc/postfix/client_checks, check_sender_access hash:/etc/postfix/sender_checks, reject_rbl_client SOMERBLS, check_policy_service unix:private/policy smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, reject_unknown_reverse_client_hostname, check_client_access hash:/etc/postfix/spamsources smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_unknown_address, check_sender_access hash:/etc/postfix/spamsources smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_policy_service unix:private/policy
Re: Trusting postfix client certs for relaying
Dnia 17.04.2021 o godz. 11:56:54 Dan Mahoney (Gushi) pisze: > > The dayjob has a number of machines out in the wild that need to be > able to send mail (mostly from cron jobs) home to the mothership. > Not all have controllable reverse DNS. It's an issue with donated > colo and transit. Doing a bunch of tunnels would work but it's a > really stupid answer. I don't fully understand why do you need *relaying* in your scenario. Can't they just send emails to address located on your "mothership" server? In that case you have a scenario of simple incoming mail, no relaying at all. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Trusting postfix client certs for relaying
All, The dayjob has a number of machines out in the wild that need to be able to send mail (mostly from cron jobs) home to the mothership. Not all have controllable reverse DNS. It's an issue with donated colo and transit. Doing a bunch of tunnels would work but it's a really stupid answer. We'd like to use client-certs as an auth mechanism. We're already deploying trusted client certs for use with puppet, so we have a full CA setup already in place. If we trust any cert signed by our puppetmaster's CA (which uses a root/intermediate/leaf setup for signing) we should be golden. However, reading the postfix docs (http://www.postfix.org/TLS_README.html#server_vrfy_client) , I see warnings that one should not use permit_tls_all_clientcerts for something like that. If an outside client were to connect with (say) a let's encrypt cert configured as a client cert (which we may want to *validate*, but *not permit for relaying*, that cert would allow relay) It seems that There are knobs that let you list *individual certs* for allowing trusted relaying, but not *individual ca's*. Is there any way around this? -Dan Mahoney -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC FB: fb.com/DanielMahoneyIV LI: linkedin.com/in/gushi Site: http://www.gushi.org ---
Re: connect then disconnect; backscatter?
Hello, On Sat, 17 Apr 2021, Francesc Peñalvez wrote: Is it possible to identify which password smtp is trying to use? if so I would like to know how With dovecot, you can set: auth_verbose = yes auth_verbose_passwords = plain When I'm bored, I run: #!/bin/sh grep "given password: " /var/log/dovecot.info \ | sed -E 's/.+\(given password: (.+)\)$/\1/' \ | sort \ | uniq -c \ | sort -rn to see which passwords are commonly tried (top #1 is "123456") Cheers.
Re: Policy Server Development
On Fri, 16 Apr 2021, post...@ptld.com wrote: On 04-16-2021 1:04 pm, Wietse Venema wrote: As Viktor noted, each smtpd(8) process makes its own connection to a policy service. Then, an smtpd(8) process will reuse its own policy service connection, not a connection that belongs to a different smtpd(8) process. Okay, if im understanding, the expected behavior is it is supposed to be one new spawn for each client connection/event? So the answer im looking for is my script should self terminate when it detects the client (postfix) disconnect? Is that the expected behavior, there are no other clues given by postfix to the policy server when it's no longer needed? We presume that your listener, conceptually speaking, is spawning a thread / process for every new (source(address,port),dest(address,port)) tuple it sees. Put that out of your mind. Logically we're in the context of a /connection/, represented by that tuple. Within that connection multiple commands could be sent, or not: don't hang up prematurely. However: they might say "goodbye" or not. If the other end of the connection decides to hang up, there should be some notification to your process and your read should terminate with some special condition (read coming back empty, "end of file" flag, ...) or exception; if that happens, assume they're not coming back, no need to say "goodbye" yourself. It's never a good idea to assume that the network is reliable. ;-) (I'm sure you've double and triple-checked that you're not leaving something unread or unwritten, and flushing all output buffers if that's what it takes.) -- Fred Morris
Re: logging failed AUTH (was: connect then disconnect; backscatter?)
On Sat, Apr 17, 2021, Wietse Venema wrote: > Francesc Pe?alvez: > > Is it possible to identify which password smtp is trying to use? if so I > > would like to know how This seems to be a common request hence several people submitted patches for sendmail to identify at least the account: 8.16.1/8.16.1 2020/07/05 Log user= for failed AUTH attempts if possible. Based on patch from Packet Hack, Jim Hranicky, Kevin A. McGrail, and Joe Quinn. > Postfix does not know how SASL protocols work. It passes the Feel free to take a look at the code - it's not universal, but it seems to cover most of what people want. -- Note: I will most likely not reply to mails that - use HTML - top post - quote more than necessary
Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes
Demi Marie Obenour: > On 4/15/21 11:00 AM, Wietse Venema wrote: > > Demi Marie Obenour: > >> Would the following be a good idea? > > [a bunch of port-dependent behavior] > > > > That is all good and well, but this needs to be made configurable. > > > > I boldly assume this will use the xxx_tls_wrapper_mode parameters, > > instead of replacing them with some totally different mechanism. > > I don?t particularly care about the mechanism. Since this already > exists, using it is obviously preferable to writing a new one. > > > Possible options: > > > > smtpd_tls_wapper_mode = > > Something that depends on an inbound port which is defined > > in master.cf. As of Postfix 3.3, the read-only "service_name" > > parameter contains the first field of a master.cf entry, > > in the form of a port, service-name, host:port, host:service-name, > > or UNIX-domain pathname. Extracting or matching the port > > or service-name portion is beyond what is currently possible > > with Postfix conditional parameter expansions. From a > > security standpoint, using this information is OK because > > master.cf is writable by the super-user only, and because > > the Postfix master daemon is a trusted process. > > > > smtp_tls_wrapper_mode = > > Something that depends on an outbound port or service-name > > that is specified in a delivery request in a next-hop > > destination as host:port or host:service-name (this is based > > on information from default_transport, relayhost, transport_maps, > > or the sender-dependent versions of those). Basically, > > this would make parameter evaluation dependent on data in > > a delivery request. There is prior art for doing this in > > the local delivery agent in very limited cases: luser_relay, > > forward_path, and command_execution_directory. That had to > > be implemented very carefully to avoid security problems. > > > > So based on this we need > > > > 1) SMTP server: Add support to match the port or service name in > > in the service_name parameter (new parameter evaluation code, > > non-trivial), OR: make the port or service name available as another > > parameter (new code in daemon library, trivial and safe). In both > > cases, make the smtpd_ls_wrapper_mode default value port dependent. > > Exactly. This introduces no new opportunities for attack, as it does not involve new information flows. It is now a matter of cost versus benefit. Time spent on this cannot be spent on something else. > > 2) SMTP client: Postpone the evaluation of smtp_tls_wrapper_mode > > until after a delivery request is received, add support for > > request-dependent $parameter expansion in smtp_tls_wrapper_mode, > > and make that bullet-proof. Doing this for smtp_tls_wrapper_mode > > can be made safe; doing this for more SMTP client parameters would > > require a much more extensive security analysis. > > From my perspective, SMTP + STARTTLS is equivalent to SMTPS, except > that they use different port numbers and the latter uses fewer > round-trips. Obviously, downgrade from TLS to no TLS is bad, but > switching between SMTP + STARTTLS and SMTPS is fine. > > That said, this appears to be more complicated than I thought it > would be. Do you consider the extra complexity (and attack surface) > justified? Maybe. If smtp_tls_wrapper_mode is made port-dependent, then it can be safe as long as the destination has already been validated as a legitimate service name or TCP port number. Other request attributes would be harder to validate, and that could lead down a slippery slope. Forgetting to turn on smtp_tls_wrappemode is a low-probability mistake in what is now a rarely-used feature. And the error message is better (connection timed out while waiting for server greeting) than in the missing smtpd_tls_wrappermode case (lost connection after unknown, too many errrors). So the effort is non-trivial and the benefit is small. Wietse
Re: Postfix : corrupted SMTP transactions?
Jaroslaw Rafa: > Dnia 16.04.2021 o godz. 17:30:43 Bill Cole pisze: > > two current OS/distro 'families' of the 6 that I've checked have the > > same 465/tcp entry, and only Debian has 'submissions' as the primary > > name. None include it as an alias. All except MacOS have smtps as > > either the primary name or an alias. > > We can just use port number in the Postfix master.cf file, then > there will be no problem, right? As described in "man 5 master" or http://www.postfix.org/master.5.html > (I am actually running another smtps instance on a nonstandard > port on my server, and use just port number in master.cf, so I > guess the same applies for standard ports) As /etc/sevices is dpending on platform and version, the solution is to make Postfix less dependent on that file. Well-known services such as submission, smtps, lmtp, and smtp, aren't going to move to a different TCP port. Therefore, I'm thinking of adding a new parameter. A default setting as below should go a long way. known_tcp_ports = submission = 587, smtps = submissions = 465, smtp = 25, lmtp = 24 This would work only for Postfix code, not for code in non-Postfix libraries. Wietse
Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes
On 4/15/21 11:00 AM, Wietse Venema wrote: > Demi Marie Obenour: >> Would the following be a good idea? > [a bunch of port-dependent behavior] > > That is all good and well, but this needs to be made configurable. > > I boldly assume this will use the xxx_tls_wrapper_mode parameters, > instead of replacing them with some totally different mechanism. I don’t particularly care about the mechanism. Since this already exists, using it is obviously preferable to writing a new one. > Possible options: > > smtpd_tls_wapper_mode = > Something that depends on an inbound port which is defined > in master.cf. As of Postfix 3.3, the read-only "service_name" > parameter contains the first field of a master.cf entry, > in the form of a port, service-name, host:port, host:service-name, > or UNIX-domain pathname. Extracting or matching the port > or service-name portion is beyond what is currently possible > with Postfix conditional parameter expansions. From a > security standpoint, using this information is OK because > master.cf is writable by the super-user only, and because > the Postfix master daemon is a trusted process. > > smtp_tls_wrapper_mode = > Something that depends on an outbound port or service-name > that is specified in a delivery request in a next-hop > destination as host:port or host:service-name (this is based > on information from default_transport, relayhost, transport_maps, > or the sender-dependent versions of those). Basically, > this would make parameter evaluation dependent on data in > a delivery request. There is prior art for doing this in > the local delivery agent in very limited cases: luser_relay, > forward_path, and command_execution_directory. That had to > be implemented very carefully to avoid security problems. > > So based on this we need > > 1) SMTP server: Add support to match the port or service name in > in the service_name parameter (new parameter evaluation code, > non-trivial), OR: make the port or service name available as another > parameter (new code in daemon library, trivial and safe). In both > cases, make the smtpd_ls_wrapper_mode default value port dependent. Exactly. > 2) SMTP client: Postpone the evaluation of smtp_tls_wrapper_mode > until after a delivery request is received, add support for > request-dependent $parameter expansion in smtp_tls_wrapper_mode, > and make that bullet-proof. Doing this for smtp_tls_wrapper_mode > can be made safe; doing this for more SMTP client parameters would > require a much more extensive security analysis. From my perspective, SMTP + STARTTLS is equivalent to SMTPS, except that they use different port numbers and the latter uses fewer round-trips. Obviously, downgrade from TLS to no TLS is bad, but switching between SMTP + STARTTLS and SMTPS is fine. That said, this appears to be more complicated than I thought it would be. Do you consider the extra complexity (and attack surface) justified? > Wietse Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: connect then disconnect; backscatter?
li...@lazygranch.com: > Apr 17 07:27:11 mydomain postfix/smtpd[21897]: disconnect from > mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3 Wietse: > They send quit after sending EHLO and AUTH (which failed). I use > the regexp "auth=./" to identify password-guessing bots. Francesc Pe?alvez: > Is it possible to identify which password smtp is trying to use? if so I > would like to know how Postfix does not know how SASL protocols work. It passes the client's input to a SASL backend (Cyrus SASL library or Dovecot auth server). Maybe they can log what is going on. Wietse
Re: connect then disconnect; backscatter?
Is it possible to identify which password smtp is trying to use? if so I would like to know how El 17/04/2021 a las 14:13, Wietse Venema escribió: li...@lazygranch.com: I am getting a lot of these: Apr 17 07:27:10 mydomain postfix/smtpd[21897]: connect from mone183.secundiarourous.com[141.98.10.183] Apr 17 07:27:11 mydomain postfix/smtpd[21897]: disconnect from mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3 They send quit after sending EHLO and AUTH (which failed). I use the regexp "auth=./" to identify password-guessing bots. Wietse smime.p7s Description: Firma criptográfica S/MIME
Re: connect then disconnect; backscatter?
On 2021-04-17 09:58, li...@lazygranch.com wrote: I am getting a lot of these: Apr 17 07:27:10 mydomain postfix/smtpd[21897]: connect from mone183.secundiarourous.com[141.98.10.183] Apr 17 07:27:11 mydomain postfix/smtpd[21897]: disconnect from mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3 https://docs.iredmail.org/enable.smtp.auth.on.port.25.html have you enabled sasl on port 25 ? dont do this if you have its a common mistake smtpd_sasl_auth_enable = yes is not ment for being in main.cf sorry if i read auth=0/1 incorrect
Re: connect then disconnect; backscatter?
li...@lazygranch.com: > I am getting a lot of these: > > Apr 17 07:27:10 mydomain postfix/smtpd[21897]: connect from > mone183.secundiarourous.com[141.98.10.183] > Apr 17 07:27:11 mydomain postfix/smtpd[21897]: disconnect from > mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3 They send quit after sending EHLO and AUTH (which failed). I use the regexp "auth=./" to identify password-guessing bots. Wietse
Re: Postfix : corrupted SMTP transactions?
Dnia 16.04.2021 o godz. 17:30:43 Bill Cole pisze: > two current OS/distro 'families' of the 6 that I've checked have the > same 465/tcp entry, and only Debian has 'submissions' as the primary > name. None include it as an alias. All except MacOS have smtps as > either the primary name or an alias. We can just use port number in the Postfix master.cf file, then there will be no problem, right? (I am actually running another smtps instance on a nonstandard port on my server, and use just port number in master.cf, so I guess the same applies for standard ports) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
connect then disconnect; backscatter?
I am getting a lot of these: Apr 17 07:27:10 mydomain postfix/smtpd[21897]: connect from mone183.secundiarourous.com[141.98.10.183] Apr 17 07:27:11 mydomain postfix/smtpd[21897]: disconnect from mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3 Googling mone183.secundiarourous.com indicates it is a bad actor for the most part. Before I mess with my main.cf, is this a reasonable approach to limit this server: https://www.backscatterer.org/?target=usage Specifically --- SAFE MODE with Postfix: Edit /etc/postfix/main.cf: smtpd_recipient_restrictions = ... check_sender_access dbm:/etc/postfix/check_backscatterer ... Create new file: /etc/postfix/check_backscatterer: <> reject_rbl_client ips.backscatterer.org postmaster reject_rbl_client ips.backscatterer.org Execute following commands: postmap /etc/postfix/check_backscatterer postfix reload for changes to take effect. - I would replace dbm with hash. Can you have more than one check_senser_access line since I have one for the RBLs.
