As we know, network based firewalls will filter based on information such as source IP, source port, etc. But they won't know what program on the source machine is generating that traffic.

Complementing a network based firewall there may be a host-based firewall installed on local machines, responsible for controlling which programs are allowed network access. In some cases, these firewalls are configured to block by default.


Malware/rogue software could disable the firewall rules on the local machine and exfiltrate data. Since the network firewall is running on a remote device, it couldn't disable that. But it wouldn't need to, as the network firewall would not know what binary on the source IP has generated that traffic.


From a high-level view, it would seem the easiest solution to this problem would be to have a remote network based firewall capable of application level filtering (e.g. block all outgoing traffic from test.exe). But on a lower-level view it's not too easy.

I've done a few searches around network-based application firewalls but I can't seem to find much on it.

So I'm wondering if anyone's come across this before and has seen any examples?

The possible solutions I can think of would involve potentially writing a network procotol based driver to add the source application into the packet header (or a hash of the source application for added security), and then writing a sort of advanced iptables to inspect the packets for the source program field. There would be a lot of factors to consider, such as integrity checking of the source path (i.e. to check whether the malware has not simply altered the packet to make it appear to originate from a trusted application).

Any insight would be appreciated, thanks.

  • Deep Packet Inspection will allow a firewall to classify the traffic type and the application that typically generates it. – schroeder May 12 at 15:03
  • Do you care what the "source application" is? That appears to be your focus, but that seems like an X/Y approach. What's your goal? What result do you want? – schroeder May 12 at 15:05
  • My goal is essentially to prevent unauthorised data exfiltration from malicious processes running on the system. I'd look to whitelist trusted processes that I know require an internet connection but block even trusted ones that have no good reason to access the internet (principle of least privilege). – Synthetic Ascension May 12 at 15:28
  • And you're assuming that data exfiltration happens using unique, unknown, or unusual processes? – schroeder May 12 at 19:22
  • That would be the assumption yes (bar injecting code into other processes). – Synthetic Ascension May 13 at 15:09

... have a remote network based firewall capable of application level filtering (e.g. block all outgoing traffic from test.exe).

The phrase "application level filtering" is usually used with a different meaning than yours, i.e. filtering on the application protocol level (web, mail, ...) and not on the level of a specific application program.

The exact program which caused the traffic is only known on the host where it is running but is not known inside the network. So no direct filtering can be done based on this inside the network. One could maybe associate the data seen in the network with a specific application instance running on the host if one would have some agent on the host though. But in this case one would run into the same problem as with having a host base firewall, i.e. that one cannot fully trust the host because it might be compromised.

| improve this answer | |

You cannot find a solution because what you want doesn't make sense: for an external device to know the name of the process that sent the traffic without a locally installed agent to verify or communicate this.

The OSI model explains this to you: once the data is on the network, the network doesn't have all the application layer data that you want to make this determination. test.exe is lost in the data that is transmitted because it is irrelevant to the network, it is only relevant to the local machine.

  • There are many solutions that have local agents that do look at the process used and allow or block based on that info
  • There are solutions that try to identify anomalies in the traffic, but they cannot determine the process that sent it
  • Deep packet inspection (DPI) can analyse the traffic and look for mismatches to identify traffic that appears to be masked as approved traffic

Sure, you could re-write the OSI model or protocols or include custom metadata, and in the past, various vendors have tried playing with protocols like that, but it doesn't end well.

The better approach is to solve the problem where you have leverage: if you want to identify data being exfiltrated, then just look for data being exfiltrated at the perimeter. You don't need the process info for that. If, instead, you want to identify malicious processes, then look for those. Don't try to jam the 2 ideas together and miss the obvious gaps, like approved processes exfiltrating data...

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.