BIG-IP device hardening???

Hi - I have a TMOS hardening guide (which I extracted from an SE under pain of death) which I have reproduced below with the exception of a few not terribly useful diagrams. I think it's pre-v10 as it suggests not using the management interfaces which I don't think you can do when running an HA pair?

I really think they should release an 'official' branded hardening deployment guide with each major release and have it available to all on the website!!

Anyway here it is;-

NOTE: THIS IS NOT MINE I COPIED IT FROM F5.

BIG-IP Architecture

BIG-IP is designed to be secure; both the hardware and software architectures are designed to provide the highest level of security. The Switch Module connects to the PVA (Packet Velocity ASIC), F5’s custom-engineered L4 load balancing ASIC. The PVA is directly connected to the Switch Module and traffic that can be handled in the PVA never goes any further. Traffic enters through the switch into the PVA, where the appropriate logic and transformations are applied and the traffic is sent back out through the Switch Module. For traffic which is not handled by the PVA (which includes all traffic for the Application Security Module), it is simply passed to the next layer, which is our primary traffic management processing complex called the TMM (Traffic Management Microkernel). TMM handles all of the BIG-IP Local Traffic Management functionality such as load balancing, compression, SSL, iRules, packet filters, etc. (with the exception of L4-only load balancing, which can be handled in either the PVA or TMM). The TMM can also have several optional hardware acceleration modules such as SSL, FIPS, and Compression and has entirely dedicated hardware (CPU, memory, peripherals). TMM is also responsible for delivering traffic to the Linux subsystem as necessary.

The Linux subsystem is where BIG-IP management processes are run. This includes SSH for secure command-line access, an HTTPS web server for secure Web GUI access, SNMP, NTP, and a variety of other services. Other functions handled in Linux are health checks, configuration management, and logging. Some software modules, such as the Application Security Module (ASM), and our Global Traffic Manager (GTM) are also hosted on the Linux subsystem. These modules are tightly integrated with the TMM so as to provide accelerated performance, and complementary functionality.

Connected to the Linux subsystem is the Management Processor (SCCP – Switch Card Control Processor). This is another dedicated system-within-a-system that provides “lights out” management and other supporting functions for the TMM, such as managing the L2 switch and over-the-network re-installation.

There are two network entry points; one is the Switch Module (the Ethernet ports on the front of the unit), and the other is the LAN Interface which connects to the Management Processor; these are two paths that can potentially provide access to administrative services on the Linux subsystem. As discussed above, the TMM is in the path between the Switch Module and Linux, so the TMM is an enforcement point which can limit access to the Linux subsystem. For example, TMM can limit which ports are seen as “open” on each administrative IP address (Self IP), regardless of what may actually be open on the Linux system. Further, TMM has a full Packet Filter engine that can be used to limit access to Linux in a very granular way. By default, BIG-IP is configured to allow a few default services such as SSH and HTTPS on it’s internal VLAN, and is configured to allow no access via the external VLAN; configuration of this will be discussed later.

The main entry point to access any part of BIG-IP is the Switch Module, and access through the switch can be controlled by TMM in a highly granular manner. Access through the Management Port (mgmt port) is considered trusted, and no access controls can be applied; this is an important consideration when designing BIG-IP into your network. If you have a trusted and secure management-only network, this is where the Management Port would be connected. If you do not have a trusted and secure management network, it’s recommend that the management port is not used, access being gained only through the switch ports and the serial console.

Five Steps to Better Security

1. Set ‘allow none’ on all Self IPs and only administer the BIG-IP using the Management Port. Setting ‘allow none’ on each Self IP will block all access to administrative IP addresses except for the Management Port. Access to individual ports can be selectively enabled, but this is not recommended in a secure environment.

    

2. Packet Filters: If selective access to individual ports is required on a Self IP, they can be further controlled at a very granular level using Packet Filters:

    

3. Disable all non-required services. Stopping services which may not be in use, such as SNMP (snmpd), NTP (ntpd) and iQuery (big3d) will completely shutdown the daemons, and they will not be started again unless re-enabled. Services which may not be required in some implementations might be present in order to allow other F5 products to be loaded at a later date, such as Global Traffic Manager, and some services are included in preparation for future integration of existing standalone products, such as FirePass. These services can be removed if required, but this should be done in consultation with F5. It is F5’s considered opinion and recommendation that the security hardening detailed inthis guide is sufficient to negate the need to remove non-required services. Note that ifservices are removed, they will need to be removed again following a software upgrade. For a layer of security when using the Management Port, the hosts.allow and hosts.deny configuration files can be used. When accessing BIG-IP through the switch ports, it is easiest to use Self IP allow controls, and Packet Filters to secure access. For Management Port-only, you restrict services such as SNMP to specific known hosts: the hosts.allow and hosts.deny files can be edited manually via the command line (additional information can be found by invoking the ‘man’ command for each of these files):

    

   ----------- /etc/hosts.allow CUT HERE -----------

    

   You MUST always allow ssh access for 127.2.0.1!

   big3d: ALL sshd : ALL 127.2.0.1 snmpd : 127. ----------- /etc/hosts.allow CUT HERE ----------- ----------- /etc/hosts.deny CUT HERE ----------- sshd : ALL EXCEPT 127. snmpd : ALL EXCEPT 127. ALL : ALL ----------- /etc/hosts.deny CUT HERE ----------- Popular services that can be protected by tcpd are:

    

   • mysqld
   • mysqld_safe
   • ntpd
   • snmpd
   • sshd

*NOTE: Although services protected by hosts.allow and hosts.deny will be protected against invalidated access and requests, they will not block the open ports from appearing open to external connection requests, such as network port scans.

1. Secure NTPD to work only as a client: By default, NTPD includes a configuration file that is built for both server and client operation. In a client-only environment, where BIG-IP will just be using the NTP protocol for client time synchronization, the configuration file can be cleaned up to allow access only to the appropriate servers. An example follows which configures NTPD as a client to the NTP server named “ntpserver.example.com”.

    

   ----------- /etc/ntp.conf CUT HERE ----------- restrict default ingore restrict ntpserver.example.com server ntpserver.example.com driftfile /var/lib/ntp/ntp.drift logfile /var/log/ntp.log ----------- /etc/ntp.conf CUT HERE -----------

    

*NOTE: By default, NTPD binds to all available interfaces; there is no way to prohibit this. By restricting access only to and from the known time server, NTPD will reject invalidated requests.

Might be worthwhile mentioning to them that v11 onwards is ICSA firewall certificated too IIRC.

H

If they start asking questions about how to lock down access to it:

sol13092: Overview of securing access to the BIG-IP system http://support.f5.com/kb/en-us/solutions/public/13000/000/sol13092.html

Thanks All!

Here is a solution article on the topic of securing access to the BIG-IP: http://support.f5.com/kb/en-us/solutions/public/13000/000/sol13092.html?sr=20495246