How to Deny or Drop Replies in Allowed UDP Sessions

[RHC_Pa2020]

Hi All,

I'm trying to address a hypothetical scenario where some solutions act only as listeners and do not need reply to the sender.
For example, a SIEM system listening on UDP port 514 does not reply to the log sender.

In such a case, we configure rule as follows:
- Source: Log source
- Destination: SIEM server
- Service: UDP/514

However, I’m concerned about a situation where the SIEM could be vulnerable, and an attacker could exploit the fact that all company devices have established sessions with the SIEM. This could allow the attacker to send malicious data back on the same session.

Is there a way to configure the firewall to allow UDP sessions from the sender to the recipient but deny any replies from the recipient within the same session?

I understand this doesn’t make sense for TCP due to the mandatory 3-way handshake, but my question is specifically about UDP.

Thanks!

[reaper]

I'd first look at the likelihood of this happening:

The attacker would need to be able to forge packets that use the same session parameters. Granted, for a sufficiently sophisticated attacker this should not be that difficult.

The next step is that the firewall will perform several checks on the returning packet:

• App-ID where the firewall verifies if the packet being sent matches the expected behavior for the application. if the payload of the attacker's packet does not match the behavior of the app-id, it will be discarded
• Content-ID the returning packet will be scanned by the firewall's content engine and malware/vulnerabilities will be blocked

secondly, you could try to create a custom vulnerability that you set 'server2client' and trigger on any payload?

[RHC_Pa2020]

Thanks Dear,

Yes, the scenario is unlikely.

I don't know if I can create a custom vulnerability that matches any reply from specific server IP on UDP sessions.

Is this possible?!

Or can we override the stateful behavior on specific rule? so the reply for the connection will be already denied!?

[reaper]

you can't change statefulness of the session

i did think of another 2 'creative' hacks:

1. you can attach that destination ip to it's own interface that has it's very own Virtual Router. on your default router you create a route that points to the other VR, but on the other VR you don't create a route back... that might work

2. if you set up policy based forwarding you can punt packets towards your destination to the right interface, and then set a symmetric that points to a sinkhole IP

both are 'hacks' so not entirely sure if they'll work as expected, but it's worth the try if this is important to you