How To: Configure Filebeat to Use a Proxy

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected: 9.2 and later

     

    Overview

    When the IdP doesn't have a direct connection to the internet and can only reach it via a proxy, Filebeat -- which by default communicates directly with us-audit.secureauth.com on port 443 -- needs to be configured to use a SOCKS5 proxy instead. Filebeat cannot use an HTTP proxy (the more common type, typically used by browsers) -- it must be SOCKS5.

     

    Configure Filebeat to Use a SOCKS5 Proxy

    1. Stop the SecureAuth Filebeat service in services.msc.
    2. Open the Filebeat configuration file in a text editor:
    C:\Program Files\SecureAuth Corporation\FileBeat\filebeat.yml
    1. Find the Logstash output section.
    2. Below the commented-out #ssl.certificate_authorities line, insert the following, replacing the IP address and port with the correct values for the environment:
    # SOCKS5 proxy server URL
    proxy_url: socks5://10.10.10.10:8080

    The resulting file should look like this:

    The Logstash output section of filebeat.yml, with the SOCKS5 proxy_url line added below the commented-out ssl.certificate_authorities line.

    1. Save the file and start the SecureAuth Filebeat service.


     

    Special Considerations

    If Filebeat is pointed at an HTTP proxy instead of SOCKS5, the Filebeat log shows Failed to connect to backoff(async(tcp://us-audit.secureauth.com:443)): proxy: failed to read greeting from SOCKS5 proxy. If no SOCKS5 proxy is available, remove the lines added above and instead configure firewalls to allow the IdP direct access to us-audit.secureauth.com on port 443. For the full list of addresses to allow, see SecureAuth's Cloud Services documentation.


     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.