Same source and destination (GW only) Invalid TCP flag combination (Mailformed Packet)

[Chinmaya_Naik]

Dear Team,

Query 1: is this a default protection (Part of the access control policy) ?

Query 2: Why does GW send traffic to its own using Mgmt Port?

Query 3: What is the impact ?

Attack Name: Mailformed Packet
Attack Information: Invalid TCP flag combination
Protection Type: Protocol Animaly
Performance Impact: Very Low
Confidence Level: High
Severity:Medium
Industry reference: CAN-2002-1071
tcp_flags:PUSH-URG
Interface: Mgmt
interface Direction: Inbound
SRC IP: GW (10.10.10.2)
DST IP:GW (10.10.10.2)
Service: TCP/46039 (Destination Port)
Protocol: TCP (6) (6)
Threat Profile: No_protection_503******
Action: Detect

[Chinmaya_Naik]

DearCheckmates Team,

Please help me to clarify .

@Chinmaya_Naik 

[Timothy_Hall]

This is part of the "Packet Sanity" protection in the "Inspection Settings" which are part of the Access Control policy and not Threat Prevention.

My initial take was that this is some kind of interprocess communication on the firewall using ephemeral ports that should have used the loopback/127.0.0.1 interface but used its own Mgmt interface instead.  The protection presumably doesn't like that the TCP flags PSH and URG are set but there is no ACK flag set.  It is not clear to me if this packet was originated by the firewall itself, or is some kind of spoofed packet coming in from the network.  Perhaps others can chime in.

[Lloyd_Braun]

I have seen these packets when a host tries to connect to the same hide NAT address that it is being hide NATted behind. I think it was iPhones trying to connect to each other when I saw it "in the wild."   You may be able to hunt down the original request by matching the destination port with the original post nat source port. *this is assuming you are hide NATting traffic behind your gateway's IP address

[Chinmaya_Naik]

@Lloyd_Braun 

Thanks for the update.

Please clarify more on this.

As per the logs, Gateway is the source and destination also.

Service: TCP/46039 (Destination Port) which is not a registered port. 

As per @Timothy_Hall Sir it's using the Mgmt port which is a question.

I ran the  TCPDUMP with that PORT but no traffic.

Looks like it's one time log generated a few days back.

@Chinmaya_Naik