FortiOS update with versions 5.2.14/5.4.12/5.6.10/6.0.5/6.2.1

Fortinet released two "Customer Support Bulletins" (check fortinet support portal) regarding a possible issue with uninterruptible upgrade in FortiGate HA-clusters running version FortiOS 5.2.14 or 5.4.12 or 5.6.10 or 6.0.5 or 6.2.1. Please check the two Customer Support Bulletins before upgrading and plan a possible short downtime for the update.

Securing Layer 2 / Switing Level

Ideas for securing your layer 2 switching infrastructure

No matter if you use Cisco, Extreme Networks, HP or any other vendor, most of them have the same basic security features, which are rarely used, but actually really should be. Here are some ideas, which you should use for ideal protection:

Securing Switch Management Interfaces

• ACLs --> to limit all management interfaces (SSH, SNMP, etc) to very few dedicated ip-addresses
• Use SSH
• Disable telnet
• SNMPv3 AuthPriv AES+SHA
• Disable SNMPv1/v2c
• Disable HTTP/HTTPS
• Delete default users, groups & communities
• Use radius authentication and two local backup-accounts with long passwords (30+ characters), those should be only useable when the radius-servers are not reachable anymore, otherwise they should not work
• Use syslog (reliable & encrypted if possible) --> send these logs to a SIEM and define alerts/SIEM use cases
• Fail2ban or similar login protection
• Use Out-of-band management interfaces
• Think about using serial-to-ip adapters for out-of-band-management, if you have a dedicated seperated out-of-band-mgmt network
• Disable LLDP/CDP/EDP/etc where possible
• Setup IT-Monitoring (PRTG, Icinga2, Nagios,..) and check CPU, RAM, NIC-Utilization & Errors of critial links like LAGs, Uplinks, Mgmt, etc, 802.1x-Auth-Errors-per-Min, Temperature, Fans, Hardware-Status, 
• Setup IT-Monitoring to do negative testing like try to access the switch via Telnet/HTTP/SNMPv1/v2c or SSH/SNMPv3 with default accounts or try to access the switches from a forbidden ip-address (which is not part of the ACL) in order to find possible cfg-errors, holes or cfg mistakes after a switch got replaced, reconfigured or a firmware-update
• Limit Access to VirtualStacking/MultiChassis-Links like MLAG, VSS etc using dedicated ACLs; If possible use internal ip-addresses like 169.254.0.0/16 if you have to use ip-addresses for them

Securing Traffic passing the switches

• Use 802.1x Authentication with certificates from your pki
• Port-Level Traffic Controls and port security mechanisms to provide protection against MAC flooding attacks
• Private VLAN (PVLAN) 
• Access Lists on Switches if necessary, normally done on a firewall
• Spanning Tree Protocol Features 
• Dynamic Host Configuration Protocol (DHCP) Snooping 
• IP Source Guard 
• Dynamic ARP Inspection (DAI) 
• Advanced Integrated Security Features on High-End Catalyst Switches 
• Control Plane Policing (CoPP) Feature 
• CPU Rate Limiters 
• M/BCast Limitations or Warnings 
• Loop Protection as BPDU Guard, Loopguard, ELRP, BCast-Storm-Control, (M/R)STP, Root Guard, etc
• Use VLAN tagging to seperate user-traffic from network traffic like LLDP, (M)STP, OSPF, BGP, BFD, etc. --> Then those protocols are not mixed with user-traffic (example: STP is send untagged while user-traffic is sent tagged)
• Shut down or disable all unused ports on the switch
• Use small subnets, not bigger than /24 for good performance/stability and for small segmentation --> in general: the more segmentation, the better

Not really security related, but I always recommend to use LACP in fast mode for LAGs (let LACPDUs work for you), BFD for faster failover in (dynamic) routing-protocols and protocols like MLAG instead of stacking for better firmware-update-situations (often stacking requires the whole stack-topology to be rebooted). The more you harden your switch infrastructure, the less often they are attackable and the less often you have to update the firmware.