AWS Network Firewall能否用Suricata规则基于TLS SNI过滤SMTP over TLS流量

1. TLS SNI过滤逻辑是否适用SMTP over TLS #

适用，只要SMTP客户端在TLS握手阶段携带SNI扩展，无论是隐式TLS（465端口）还是显式STARTTLS模式（587端口），Suricata都可以解析提取SNI字段做匹配，AWS Network Firewall默认支持该能力。

2. 未加全通587端口规则时流量不通的原因 #

你当前的第一条规则匹配逻辑存在疏漏：

587端口的SMTP默认采用显式STARTTLS模式：TCP三次握手完成后，会先通过明文传输SMTP控制命令（EHLO、STARTTLS等），完成协商后才会进入TLS握手阶段。你配置的第一条tls规则加了flow:to_server, established条件，只能匹配TLS握手完成后的已建立流量，无法覆盖前面的明文协商阶段，这部分流量会被默认拒绝策略拦截，所以此前必须加额外规则放行前置的协商流量。

3. 实现仅允许指定FQDN的SMTP访问的配置方案 #

可以通过调整规则顺序和匹配条件，替换原全通587端口的规则，实现精细化管控，参考配置如下：

1. 首先放行STARTTLS明文协商阶段的流量：

pass tcp 172.31.10.11/32 any -> $EXTERNAL_NET 587 (content:"STARTTLS"; nocase; flow:to_server, not_established; msg:"Allow SMTP STARTTLS negotiation"; sid:106; rev:1;)

2. 调整原有TLS SNI放行规则，适配TLS握手阶段匹配：

pass tls 172.31.10.11/32 any -> $EXTERNAL_NET 587 (tls.sni; dotprefix; content:".us-west-2.amazonaws.com"; nocase; endswith; msg:"Allow SMTP TLS to allowlisted FQDN"; flow:to_server; sid:107; rev:2;)

3. 最后添加默认拒绝规则，替换原有全通587端口的规则：

drop tcp 172.31.10.11/32 any <> $EXTERNAL_NET 587 (msg:"Deny other SMTP traffic"; sid:501; rev:2;)

注意事项 #

• 如果使用465端口的隐式TLS SMTP服务，不需要处理STARTTLS协商阶段，直接编写TLS SNI匹配规则即可生效。
• 部分老旧SMTP客户端不支持TLS SNI扩展，这类客户端的流量会被上述规则拦截，需要提前评估业务兼容性。

内容的提问来源于stack exchange，提问作者WesKerT