Assuming I got your request properly (my Spanish is not spectacular), it seems you want to add the proxy to the mentioned situation.
Because the URL filtering technology included in NGFW is Webroot/BrightTalk, you can perform the request at this link.
Have a good day.
hola muchas gracias por responder, el problema es con los programa, uno de ellos es ultra suft que cuando se ejecuta y se navega en internet, al querer ver los logs en la consola no me muestra nada, en los proxys desde internet si los pude bloquear.
Ultrasurf is an everchanging software which is made to evade blocking devices by changing constantly its behavior.
Hence willing to block it means to risk to be prone to some false positives.
Ultrasurf client connects to a remote proxy server over port 443.
Then it relies on several remote proxies, which seem to change constantly.
As far as I know, starting from version 8.8 Ultrasurf is able to use “anonymous” or non authenticated SSL connections, that are connections where the server does not send its certificate.
This renders the attempt of FW/IPS to decrypt connections vane.
Below please find some recommendations to try to block it using McAfee NGFW:
HTTPS decryption must be configured and enabled, so the firewall can decrypt the connection.
Enable in inspection rules situations like “TLS_Unknown-Session-Id” and “TLS_Client-Syntax-Error ” blocking the connections, to prevent Ultrasurf from connecting to remote servers
Be aware that blocking TLS_Client-Syntax-Error will block all non-standard TLS traffic on port 443. One of the risks is that, for example, Skype sometimes tunnel traffic over port 443 if it can't use other ports...
AFAIK, Ultrasurf client always includes a session id in the TLS Client Hello message: this TLS session id is used to perform a quick handshake.
Blocking the situation "TLS_Unknown-Session-Id" means that FW/IPS will block if it does not have the corresponding session information available.
Again, risk of false positive can happen since you can have TLS inspection started on the engine after the TLS session was established also in "normal" HTTPS traffic. Another case is when engine TLS cache is full.
However, it seems that Ultrasurf never performs a full TLS handshake (the server never sends a certificate).
Therefore blocking "TLS_Unknown-Session-Id" (together with TLS_Client-Syntax-Error) prevents it at least from connecting.
My suggestion is to try the techniques described above while keeping the overall traffic situation monitored, to avoid that a solution to Ultrasurf usage causes impacts on legitimate traffic as well.
Hope it helps, have a nice day.
Some users restrict the outbound port cause in the case of the ultrasurf change the port randomly!