Security assessment scan against FOG server

  • Moderator

    As part of our internal audit program we are required to scan all internal hosts using a SIEM tool to look for vulnerabilities.

    Here are several that our FOG server triggered. Understand I’m not implying or forcing anything here only raising awareness to the developers.

    1. SSL/TLS: Certificate Expired
    Risk: High
    Application: https
    Port: 443
    The certificate of the remote service expired on 2017-02-04 23:55:05.
    Certificate details:
    subject ...:
    subject alternative names (SAN):
    issued by .:
    serial ....: 00A6
    valid from : 2016-02-05 23:55:05 UTC
    valid until: 2017-02-04 23:55:05 UTC

    I assume this is the SSL certificate used to communicate between the FOG server and the clients. I guess from the clients perspective they don’t care or aren’t checking the validity dates of the certificate in use. Should fog have a process to update this self signed certificate? Maybe something to consider for FOG 2.0?

    1. http TRACE XSS attack
    http TRACE XSS attack
    Risk: High
    Application: http
    Port: 80
    Protocol: tcp
    Vulnerability Detection Result:
    Add the following lines for each virtual host in your configuration file :
       RewriteEngine on
       RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
       RewriteRule .* - [F]
    See also
    Disable these methods.

    I’ve added these rules to the /etc/httpd/conf.d/fog.conf file to change the file to this:

        <Directory /var/www/html/fog/>
            DirectoryIndex index.php index.html index.htm
        RewriteEngine On
        RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
        RewriteRule .* - [F]
        RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
        RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
        RewriteRule ^/(.*)$ /fog/api/index.php [QSA,L]

    I’ll know after the next scan if this fix resolved the issue.

    The rest of the discovered issues were not related to FOG but system management on the FOG server, such as supporting weak SSL and ssh Ciphers and TCP timestamps. Surprisingly using NFS v3 did not set off a violation alert.

  • Senior Developer

    Should add this is for the working-1.5.1 which should become “stable” fairly soon.

  • Senior Developer

    Added the TRACE|TRACK rewrite conditions/rules.

    I think this is good enough to solve this bug report then, as the certificate expiring can be easily redone. This simply takes --recreateKeys | -K to recreate the keys on this server. The CA should expire quite a long time from now and as the CA public cert is used on the clients this would prevent any issues.

    Thanks for reporting and with suggestions to correct!

  • Senior Developer

    @george1421 The client does use a self-signed certificate, but its not part of HTTPS at all. You can use your own SSL certificate for the fog server, as long as host computers see it as valid.

  • Moderator

    @joe-schmitt So fog and/or client did not create this self signed certificate? The server is dedicated to FOG. The concern is mainly around the client stopping top communicate with the FOG server for some unexplained reason. This this is not an issue then I’m good with an expired certificate. I just need to explain it during my audit review.

    I also did find I need to disable sslv2, v3 and v1 for compliance too. That doesn’t (shouldn’t) impact fog. Its only an awareness.

  • Senior Developer

    @george1421 there appears to be some miscommunication about the client’s encryption (perhaps I misspoke at some point and used the wrong terms). The client doesn’t use SSL to encrypt traffic. It does use public key infrastructure though, similar to SSL. So your expired certificate should not be because of the client.

Log in to reply