Files
geedge-jira/md/OMPUB-1226.md
2025-09-14 21:52:36 +00:00

204 lines
6.4 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 【WMS-UTR】smtp/pop3/imap监测日志中decoded as为mail的日志仅占一半且fromto地址解析比例低
| ID | Creation Date | Assignee | Status |
|----|----------------|----------|--------|
| OMPUB-1226 | 2024-04-14T16:09:33.000+0800 | 刘洋 | 已关闭 |
---
[~liuyang] 洋姐监测邮件的策略中配置了smtp、pop3、imap三种协议
!image-2024-04-14-14-35-49-524.png|width=530,height=338!
统计了20240414 10:53:06~10:54:01共100000条mail的监测日志
* decoded as成mail的有58298条其余解码为base/http/ssl。
* mail协议中出现mail from/to等邮箱地址的数量统计如下
!image-2024-04-14-14-35-22-882.png!
日志见附件的压缩文件**yangwei** commented on *2024-04-15T09:59:51.732+0800*:
导出的100000条监测日志中decode_as分布如下
* MAIL 58298
* BASE 41687
** app识别结果均为pop,imap,smtp
** server 端口分布如下:
***
||server port||sessions||app||
|25|36020|smtp:36020
imap:1|
|110|2956|pop3|
|143|2709|smtp:4
imap:2705|
|587|1|smtp|
|80|1|smtp|
*
** 上述端口均为mail常用服务端端口初步推测decode_as为BASE的原因同https://jira.geedge.net/browse/TSG-19842
* HTTP 3
** app识别结果均为http.imap或者http.pop3
** UA均为 python-socks/2.3.0推测为http代理
* SSL 12
** app识别结果均为pop3.ssl或者imap.ssl应该均为STARTLS
 
---
**yangwei** commented on *2024-04-15T17:42:13.527+0800*:
Decode_as为BASE的分析
* 对于app识别为mail(in smtp, pop, imap)decode_as为BASE的会话通过在京版网关下发server port in (25,110,143,587) and ip_protocol==tcp的监测策略并开启packet capture3小时记录106个会话Decode AS分布如下
** BASE 37 占比34.9%
** MAIL 69 占比65.69%
*** C2S单向流 35041占比53%
*** S2C单向流 24占比0.03%
* 进一步分析BASE的会话app识别结果如下
** !image-2024-04-15-17-42-18-348.png|width=745,height=164!
** app识别为VPN的会话结果无误原因为VPN服务使用常见邮件端口。
** app识别为imap的会话典型的传输内容如下
** !image-2024-04-15-17-42-26-655.png|width=1748,height=250!
** 上图会话传输的内容为qqmail服务器的欢迎greeting消息客户端与服务端握手成功后服务端主动返回其支持的功能Capabilities包括不同的认证方法和命令扩展。
** 上述会话周期性出现被第三方DPI识别为imap并在app字段标注但由于未传输mail日志相关字段decode_as将被标注为BASE。
* 分析decode_as的会话传输的内容如下
** !image-2024-04-15-17-48-17-008.png|width=609,height=273!
** 上述会话decode_as会被标注为MAIL但是mail_xx字段全部为空原因是mail decoder在出现STARTTLS后会主动通知firewall插件该状态但并未出现已定义的相关日志字段。
{*}修改建议{*}参照SSL新增mail.starttls flags日志字段用于标注MAIL会话中STARTTLS的行为
---
**niuxiang** commented on *2024-04-16T02:01:16.917+0800*:
UTR现场MAIL数据包下载地址
https://de.files.gdnt-cloud.com/d/712121426ea244bcaf40/
---
**yangwei** commented on *2024-04-16T11:25:56.027+0800*:
现场返回两个pcapng数据包功能端处理后结果如下
*数据包 10164_port25.pcapng 259.7MB*
* TCP会话12670
** c2s 11347 89.5%
** s2c 971 7.5%
** bidirectional 2.7%
* 有效传输数据会话(包数>3,字节数>5:5775
** *c2s* 4936 *85.5%*
** *s2c* 549 *9.5%*
** *bidirectional* 290 *5%*
* 解析为SMTP 5017, 占有效传输数据会话 86.8%
** *STARTTLS* 1298 *占SMTP会话 25.8%*
** 含MAIL_FROM_CMD 3410占SMTP会话67.9%
** 含MAIL_FROM 248, 占SMTP会话 4.9%
** 含MAIL_TO_CMD 3328占SMTP会话 66.3%
** 含MAIL_TO 246, 占SMTP会话 4.9%
*** 含MAIL_FROM_CMD但是不含MAIL_FROM传输内容如下
*** SMTP命令行交互后被服务端RST
*** !image-2024-04-16-12-16-06-915.png|width=859,height=218!
** *无上述MAIL字段 309占SMTP会话 6%*
*** 无mail收发件人字段传输的内容如下
**** SMTP 单向流 客户端发起EHLO
**** !image-2024-04-16-11-35-08-052.png|width=988,height=183!
**** SMTP双向流
**** !image-2024-04-16-11-36-32-762.png|width=573,height=189!
 
*数据包 10164_port25port110port143.pcapng 303.7MB*
* TCP会话17963
** c2s 16363 91%
** s2c 1221 6.9%
** bidirectional 379 2.1%
* 有效传输数据会话(包数>3,字节数>5:8343
** *c2s* 7315 *87.6%*
** *s2c* 684 *8.2%*
** *bidirectional* 344 *4.2%*
* 解析为MAIL 6714, 占有效传输数据会话 80.4%
** *STARTTLS* 2124 *占MAIL会话 31.6%*
** 含MAIL_FROM_CMD 3758占MAIL会话55.9%
** 含MAIL_FROM 123, 占MAIL会话 1.8%
** 含MAIL_TO_CMD 3681占MAIL会话 54.8%
** 含MAIL_TO 122, 占MAIL会话 1.8%
** {*}不含上述MAIL字段{*}会话832占MAIL会话 *12.3%*
*** 无mail收发件人字段传输的内容如下
**** pop3 单向流,仅传输用户名密码
*** !image-2024-04-16-12-00-35-035.png|width=1375,height=322!
*** IMAP单向流客户端登入登出
*** !image-2024-04-16-12-03-25-954.png|width=834,height=186!
 
*初步结论*
* 监测mail日志中decode as为base的原因
** 对于MAIL.STARTTLS会话当前监测日志中Decode As会被填充为BASE结合Application识别结果可以判断
** 现场采样的数据包STARTTLS会话比例在25%~30%
* decode as为MAIL但是收发件人为空的原因
** Decode As为MAIL的会话存在正常交互但是不传输MAIL收发件人信息的行为按捕包+采样统计约占MAIL会话的10%~12%
** 日志中仅包含MAIL_FROM_CMD不包含MAIL_FROM的情况通常为命令行交互过程中未进入到传输MAIL内容的流程即被服务端中止
** 单向流情况下单侧不包含MAIL收发件人信息
*** SMTP S2C侧
*** POP和IMAP C2S侧
---
## Attachments
**55173/image-2024-04-14-14-35-22-882.png**
---
**55172/image-2024-04-14-14-35-49-524.png**
---
**55280/image-2024-04-15-17-42-18-348.png**
---
**55279/image-2024-04-15-17-42-26-655.png**
---
**55281/image-2024-04-15-17-48-17-008.png**
---
**55323/image-2024-04-16-11-35-08-052.png**
---
**55324/image-2024-04-16-11-36-32-762.png**
---
**55326/image-2024-04-16-12-00-35-035.png**
---
**55325/image-2024-04-16-12-03-25-954.png**
---
**55327/image-2024-04-16-12-16-06-915.png**
---
**55175/monitor_event20240414055548.rar**
---