On 09/06/2018 12:46 PM, André Paulsberg-Csibi (IBM Consultant) wrote:
That is really sad , I have also seen similar issue with other "firewalls" like checkpoint and such with DHCP RELAY , because the DHCP always use port 67 for both source and destination port in those cases . I do not think we can blame the FIREWALL itself for this as it is supposed to protect system from some of this , it is more "bad" design to reuse the port for another request .
This does actually seem to be a race condition in the firewall. There are two packets as part of the same flow but the second gets processed concurrent with the first without proper synchronization.
The client isn't doing anything wrong here. Historically DNS clients would use the same source port for _every_ request, the reason they don't anymore is the Kaminsky attack for which source port randomization is used as a mitigation. But reusing the same random source port for concurrent requests to the same server doesn't give an attacker much if anything there, so the client is doing a reasonable optimization and avoids having to open and close two sockets instead of one.
You would get the same problem with anything that sends two packets right away. Not many other things do this (except by coincidence of just having two simultaneous requests), but it's definitely a bug in the firewall if it can't handle it when it happens.
As for what to do about it, could CONNMARK work here? Suppose you queue everything without a particular connection mark and then set that mark on everything somewhere later in processing than where you queue it, so that all the packets that are part of an existing flow are marked and not queued. The question is whether there is anywhere to put the queue rule which is after it's possible to identify that the flow has a particular connmark but before the packet is dropped.
