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.
thank you. this is a web request the XG webfilter sees:
2021-07-22 13:50:47Web filtermessageid="16001" log_type="Content Filtering" log_component="HTTP" log_subtype="Allowed" status="" fw_rule_id="251" user="" user_group="" web_policy_id="4" web_policy="" category="Information Technology" category_type="Acceptable" url="">download.eclipse.org/.../org.w3c.dom.svg_1.1.0.v201011041433.jar" content_type="" override_token="" response_code="" src_ip="172.internalIP" dst_ip="184.108.40.206" protocol="TCP" src_port="51162" dst_port="80" bytes_sent="220" bytes_received="0" domain="download.eclipse.org" exception="" activity_name="" reason="" user_agent="curl/7.58.0" status_code="500" transaction_id="" referer="" download_file_name="" download_file_type="" upload_file_name="" upload_file_type="" con_id="2333631424" app_name="" app_is_cloud="0" override_name="" override_authorizer="" used_quota="0"
this requests are then blocked by Application Filter because of executable not allowed.
I want this blocked but analyzing is just difficult and tricky.
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.
Logviewer --> Advanced View --> Search for the IP (not as Destination or Source, instead search for the IP as a String). Should show the web allowing it, but App blocking it.
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.
I still don't understand why two blocked applications download more data than when they are not blocked. The connection requests should not get past the XG outgoing.
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 every packet. The client cannot ACK a packet, which does not reach him, as the firewall blocks it. Therefore the Server assume, you did not get the packet. It will retransmission those packets all the time, resulting into a big junk of data before the server finally realize, there is nobody to ACK the packets.
Block or deny should mean the application does not leave the XG, does not advertise itself or your network to the world and leave your XG and network open to security attacks. The aim is to reduce the size of the exposure footprint to the world.
If the packets can be identified and blocked on the way in then the same rules should applied to the packets on the way out.
Maybe I am taking a too simplistic approach to application security?