[pfx] Postfix stopped logging IP addresses
Wietse, Happy 25th birthday of your creation! I recently upgraded to mail_version = 3.4.23 Postfix no longer logs IP addresses with the connections. What did I break? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix stopped logging IP addresses
On 12/27/2023 1:03 PM, Vince Heuser via Postfix-users wrote: Wietse, Happy 25th birthday of your creation! I recently upgraded to mail_version = 3.4.23 Postfix no longer logs IP addresses with the connections. What did I break? My wild guess is that your chroot environment is incomplete. To fix, turn off chroot in master.cf and restart postfix. http://www.postfix.org/DEBUG_README.html#no_chroot For more help that doesn't include wild guesses, please post the information requested in http://www.postfix.org/DEBUG_README.html#mail Please include your "postconf -nf" and "postconf -Mf", and samples of what postfix logs when mail is received. -- Noel Jones ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SMTP Smuggling, workarounds and fix // Clarification on BDAT
SHORT-TERM WORKAROUNDS A short-term workaround can be deployed now, before the upcoming long holiday and associated production change freeze. NOTE: This will stop only the published form of the attack. Other forms exist that will not be stopped in this manner. * With all Postfix versions, "smtpd_data_restrictions = reject_unauth_pipelining" will stop the published exploit. There are seemingly contradicting statements in various articles if BDAT should be enabled or disabled. https://www.postfix.org/smtp-smuggling.html: The idea is ... to reject BDAT commands. https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/: we're looking for an inbound SMTP server that interprets . as an end-of-data sequence and doesn't support BDAT https://www.csoonline.com/article/1269779/smtp-smuggling-enables-email-spoofing-while-passing-security-checks.html: To be vulnerable to spoofing via Exchange Online messages, an incoming SMTP server needs to meet two conditions instead of one: Not support BDAT and interpret . as an end-of-data sequence. https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2023/2023-292569-1032.pdf: Der Angriff ist mit ... sowie der Nutzung des BDAT-Kommandos, ..., mitigierbar. which roughly translates to: The attack can be mitigated by using BDAT. Can someone clarify? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SMTP Smuggling, workarounds and fix // Clarification on BDAT
On Wed, Dec 27, 2023 at 11:40:56PM +0100, Damian via Postfix-users wrote: > > The attack can be mitigated by using BDAT. > > Can someone clarify? It really does not matter much, but leaving BDAT enabled can help in some cases. It is not necessary to go this deep down the rabbit hole. If both the original server and the downstream incoming server support BDAT, the SMTP smuggling will not succeed, because it depends on the incoming server seeing a non-standard . or . as end of message, but that's a feature of DATA, not BDAT which instead sends explicit block lengths, and does not depend on any magic end of input marker. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SMTP Smuggling, workarounds and fix // Clarification on BDAT
It really does not matter much, but leaving BDAT enabled can help in some cases. It is not necessary to go this deep down the rabbit hole. So what could be smuggled into a Postfix that defines "reject_unauth_pipelining" but does not define "smtpd_discard_ehlo_keywords = chunking"? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SMTP Smuggling, workarounds and fix // Clarification on BDAT
Damian via Postfix-users: > > It really does not matter much, but leaving BDAT enabled can help in > > some cases. It is not necessary to go this deep down the rabbit hole. > > So what could be smuggled into a Postfix that defines > "reject_unauth_pipelining" but does not define > "smtpd_discard_ehlo_keywords = chunking"? It depends on whether your are talking about the BDAT or DATA commands that are used to deliver the message with the smuggled commands and text, or about the smuggled BDAT or DATA commands. The smuggling attack won't work when the sending MTA and receiving MTA support BDAT, and the sending MTA prefers using BDAT over DATA. When the sending MTA chooses to use DATA, the smuggled commands can still use BDAT or DATA. This time, the choice is made by the attacker, and it depends only on the receiving MTA capabilities. With a smuggled DATA command, the attack can trigger a command pipelining violation, because the sending MTA will not wait between sending the smuggled DATA command and the smuggled text (but see notes below). With a smuggled BDAT command, there is no pipelining violation. This is why the current short-term fix recommends to not announce CHUNKING support. Note 1: an attacker can use their own custom MTA that waits after sending the smuggled DATA command, but then they can no longer send the attack from an IP address that passes SPF-based DMARC checks for the sender that they wish to impersonate. Note 2: an attacker can place the smuggled DATA\r\n at the end of a network packet, and cause network congestion in the hope that there will be some delay between receiving the smuggled DATA command and the smuggled text. But that is a blind attack. The sending MTA ignores any error responses that the receiving MTA sends after the "ok" response to the fake end-of-message. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
