Bug #1860
closed2220005: SURICATA SMTP bdat chunk len exceeded when using SMTP connection caching
Description
I am seeing many of these at various client sites, and they seem to be FPs. Here is a redacted example of an SMTP connection that tripped this alert. Notice that in this example two emails are transmitted in the same tcp/25 connection, separated by the SMTP RSET command. Perhaps the SMTP state tracking in Suricata is getting thrown off by this?
Kevin
DST: 220 REDACTED.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Mon, 8 Aug 2016 13:31:37 +0000 DST: SRC: EHLO smtp.REDACTED SRC: DST: 250-REDACTED.mail.protection.outlook.com Hello [REDACTED] DST: 250-SIZE 157286400 DST: 250-PIPELINING DST: 250-DSN DST: 250-ENHANCEDSTATUSCODES DST: 250-STARTTLS DST: 250-8BITMIME DST: 250-BINARYMIME DST: 250 CHUNKING DST: SRC: MAIL FROM:<REDACTED> SIZE=1665 SRC: DST: 250 2.1.0 Sender OK DST: SRC: RCPT TO:<REDACTED> SRC: DST: 250 2.1.5 Recipient OK DST: SRC: BDAT 1665 LAST SRC: SRC: Received: from REDACTED.org ([REDACTED]) by REDACTED.org with Microsoft SMTPSVC(8.5.9600.16384); SRC: . Mon, 8 Aug 2016 09:31:37 -0400 SRC: Message-ID: <639038.171243982-sendEmail@nagios> SRC: From: "REDACTED" <REDACTED> SRC: To: "REDACTED" <REDACTED> SRC: Subject: ** PROBLEM Service Alert: CRM 2015 - SQL server/System Memory is CRITICAL ** SRC: Date: Mon, 8 Aug 2016 13:31:37 +0000 SRC: X-Mailer: sendEmail-1.56 SRC: MIME-Version: 1.0 SRC: Content-Type: multipart/related; boundary="----MIME delimiter for sendEmail-145818.255216913" SRC: Return-Path: nagios_REDACTED SRC: X-OriginalArrivalTime: 08 Aug 2016 13:31:37.0424 (UTC) FILETIME=[304E7500:01D1F179] SRC: SRC: This is a multi-part message in MIME format. To properly display this message you need a MIME-Version 1.0 compliant Email program. SRC: SRC: ------MIME delimiter for sendEmail-145818.255216913 SRC: Content-Type: text/plain; SRC: charset="iso-8859-1" SRC: Content-Transfer-Encoding: 7bit SRC: SRC: ***** Nagios ***** SRC: SRC: Notification Type: PROBLEM SRC: SRC: Service: System Memory SRC: Host: CRM 2015 - SQL server SRC: Address: REDACTED SRC: State: CRITICAL SRC: SRC: Date/Time: Mon Aug 8 09:31:37 EDT 2016 SRC: SRC: Additional Info: SRC: SRC: CRITICAL: physical memory: Total: 64G - Used: 61.1G (95%) - Free: 2.92G (5%) critical, virtual memory: Total: 128T - Used: 358M (0%) - Free: 128T (100%), paged SRC: bytes: Total: 73.5G - Used: 61.3G (83%) - Free: 12.2G (17%) warning, page file: Total: 73.5G - Used: 61.3G (83%) - Free: 12.2G (17%) warning SRC: SRC: SRC: ------MIME delimiter for sendEmail-145818.255216913-- SRC: SRC: DST: 250 2.6.0 <639038.171243982-sendEmail@nagios> [InternalId=33054068315406, Hostname=REDACTED] 8140 bytes in 0.257, 30.871 KB/sec Queued mail for delivery DST: SRC: RSET SRC: DST: 250 2.0.0 Resetting DST: SRC: MAIL FROM:<REDACTED> SIZE=1671 SRC: DST: 250 2.1.0 Sender OK DST: SRC: RCPT TO:<REDACTED> SRC: DST: 250 2.1.5 Recipient OK DST: SRC: BDAT 1671 LAST SRC: SRC: Received: from REDACTED (REDACTED]) by REDACTED with Microsoft SMTPSVC(8.5.9600.16384); SRC: . Mon, 8 Aug 2016 09:31:37 -0400 SRC: Message-ID: <476871.195339726-sendEmail@nagios> SRC: From: "REDACTED" <REDACTED> SRC: To: "REDACTED" <REDACTED> SRC: Subject: ** PROBLEM Service Alert: CRM 2015 - SQL server/System Memory is CRITICAL ** SRC: Date: Mon, 8 Aug 2016 13:31:37 +0000 SRC: X-Mailer: sendEmail-1.56 SRC: MIME-Version: 1.0 SRC: Content-Type: multipart/related; boundary="----MIME delimiter for sendEmail-839474.540975974" SRC: Return-Path: REDACTED SRC: X-OriginalArrivalTime: 08 Aug 2016 13:31:37.0587 (UTC) FILETIME=[30675430:01D1F179] SRC: SRC: This is a multi-part message in MIME format. To properly display this message you need a MIME-Version 1.0 compliant Email program. SRC: SRC: ------MIME delimiter for sendEmail-839474.540975974 SRC: Content-Type: text/plain; SRC: charset="iso-8859-1" SRC: Content-Transfer-Encoding: 7bit SRC: SRC: ***** Nagios ***** SRC: SRC: Notification Type: PROBLEM SRC: SRC: Service: System Memory SRC: Host: CRM 2015 - SQL server SRC: Address: REDACTED SRC: State: CRITICAL SRC: SRC: Date/Time: Mon Aug 8 09:31:37 EDT 2016 SRC: SRC: Additional Info: SRC: SRC: CRITICAL: physical memory: Total: 64G - Used: 61.1G (95%) - Free: 2.92G (5%) critical, virtual memory: Total: 128T - Used: 358M (0%) - Free: 128T (100%), SRC: paged bytes: Total: 73.5G - Used: 61.3G (83%) - Free: 12.2G (17%) warning, page file: Total: 73.5G - Used: 61.3G (83%) - Free: 12.2G (17%) warning SRC: SRC: SRC: ------MIME delimiter for sendEmail-839474.540975974-- SRC: SRC: DST: 250 2.6.0 <476871.195339726-sendEmail@nagios> [InternalId=84245783514525, Hostname=REDACTED] 7981 bytes in 0.200, 38.785 KB/sec Queued mail for delivery DST: SRC: QUIT SRC: DST: 221 2.0.0 Service closing transmission channel DST:
Updated by Travis Green about 8 years ago
add'l notes from Travis:
- connection reuse is also called SMTP connection caching
- is a feature in postfix and sendmail
Updated by Andreas Herz about 8 years ago
- Assignee set to Anonymous
- Target version set to TBD
Could you reproduce that with a pcap?
And how do you run suricata exactly?
Updated by Kevin Branch about 8 years ago
I am using Suricata under the latest stable version of Security Onion, with no tweaks to Security Onion's default suricata.yaml other than setting HOME_NET. PF_RING is in use, with 2 threads and a 128K slot packet capture ring. This sniff point is a VLAN trunk with 802.1q tagged frames, and suricata.yaml does have "use-for-tracking: true" set under the vlan section.
Kevin
Updated by Victor Julien about 8 years ago
- Description updated (diff)
- Status changed from New to Assigned
- Assignee changed from Anonymous to Victor Julien
- Target version changed from TBD to 70
Updated by Victor Julien over 5 years ago
- Assignee changed from Victor Julien to Philippe Antoine
Updated by Victor Julien over 5 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 5.0beta1