Cirruscan we open login f5 through http and block https? so will not get SSL error.
We are having link load balancer. And during security audit in our company we are shown SSL vulnerablity on public IPs on f5. Looking into the risks it seems to be only SSL certificate error? any suggestion.
EmployeeWhat was the exact nature of the vulnerability? Was it due to the default self-signed certificate the device creates during installation? If so, this can be replaced with a CA-signed cert of your choice.
To create new certificates for use with a CA see here but if you're using GTM/Link Controllers/iQuery, you'll want to make sure the device certificate made available to all other BigIPs.
I recommend browsing through the support articles previously linked to ensure any unique configurations do not break due to replacing the device certificate.
EmployeeAll 3 vulnerabilities are due to the device self-signed cert created by the BigIP during setup. This can be replaced with a CA-signed cert, this can be a purchased public cert or an internal CA; any self-signed cert will fail your security test. The link I sent earlier will provide those instructions. You'll want to make sure the cert you create of course matches the FQDN/Device name of the BigIP and then you should be able to pass those vulns.
The F5 support site has a lot of good information on creating these certificates depending on what type of module config your using.
https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-4-0/12.html
CirrusI would think the security team would have more issue with you sending configuration information via plain-text HTTP than via HTTPS, even if the certificate is self-signed. Do you need to reach this F5 via the public IPs? For my publicly facing interfaces, I put the "allow-service none" parameter on the self-IPs so that the F5 doesn't allow any in-band management traffic on those interfaces. I'd consider that a best practice for any interfaces that you don't need to use for F5 management (keep in mind that config-sync/failover interfaces require the "allow-service default" so service traffic can pass between units.)
Employee
EmployeeAre the IP addresses in question behind a firewall? If not, I would say you have a bigger security problem brewing. You should not be able to connect to any of the Self IP addresses, or the Management address, over HTTPS or SSH, from outside of your organization. If you can, you should look at configuring port lockdown on the IPs.
Hi, Link Controller is using iQuery on TCP/4353 for inter device communication regarding the GTM related part of the configuration.
For this purpose you have the port lockdown settings on your external self IP addresses and perhaps floating self IPs still configured to "allow all" or "default". This opens as well TCP/443 and the WebUI becomes available on these interfaces as well. I highly recommend to configure ACLs on your external routers to prevent everything but DNS to hit the external self IPs including the floating self IP. Link controller (at least as far as I remember) is using some automatism to build the GTM related configuration part. And for this it used to be required to work with open service ports on the external self IPs. Not a good idea in my opinion. Once your Link Controllers work as expected it makes sense to trace the inter device communication by TCPDUMP and to customize the port lockdown settings for the external self IPs asap. Be aware, that changed settings for the floating IP may not be synchronized (version dependent) and verify this setting on both machines. One more thing regarding device certificates. It´s best practice to create long lasting (3650 days) self signed device specific device certs instead of using the default (localhost.localdomain) certificate. Keep in mind these certs are used both as client and server certificates ("purpose" attribute). If you plan to get these certs signed by a CA it need to keep these requested attributes. Changing device certs afterwards will break the iQuery communication as you will notice in /var/log/gtm. It will be necessary to re-import the replaced certs by using the "
bigip_addbigip_add
CirrusThanks everyone for valuable suggestion.
I have done port lockdown on public IP interfaces of link controller. Now seems issue resolved.
NimbostratusHello,
I am getting (SSL Certificate - Signature Verification Failed Vulnerability) only for the cert in which there are multiple subjects (Subject Alternative Name) ...this specific cert is used to multiple stage envs ( it's like a bundle)...
any idea if there is anything special I need to do for this cert to pass the scan?