I'd think source and destination IP is wrong here.
It took me some time to help a user who reported he cannot download a file, we blocked because I could not find his computer with my query for source IP.
We block executabled here.
Other Application filter blocks look OK, eg. accessing blocked applications:
Blocked does not mean, we are terminate the connection. This means the server will still ddos you with the packets, as the server assume, you simply does not ACK them. TCP makes sure, you ACK each and…
App Control and IPS can be applied on both packets (inbound and outbound). And if the pattern match on the packet coming back, it will be shown in the logs as you see.
If you request a download, the data of the file is "coming back from the server" (download). Therefore if the firewall cannot find a download request based on the "get", this packet will be allowed but the IPS/app control will detect a download based on the packets coming back.
But, why when I have an application blocked outgoing am I seeing packets incoming to the Mac air. The application should not get past the firewall rule.
There are certain apps, they call "Give me a File". But the app control is not seeing the file. So it will allow this packet. But if the packets are coming back with the file, IPS/app can collect the data and see, this is a file download and blocks it.
Most likely we are able to block it based on the get request. But sometimes, apps are likely to try to hide this get request.
maybe this is because the file has been "curled"?
it was not a regular web request.
> curl -i http://download.eclipse.org/oomph/products/repository/plugins/org.eclipse.core.contenttype_3.8.0.v20210621-0954.jar> HTTP/1.1 500 Software caused connection abort> Date: Tue, 20 Jul 2021 14:18:06 GMT> Cache-Control: no-cache> Pragma: no-cache> Content-Type: text/html; charset="UTF-8"> Content-Length: 0> Via: HTTP/1.1 forward.http.proxy:3128> Connection: close
and yes, in advanced view I can see the block a bit faster than by the other approaches.