Apply BGP Route Map for Numbered VPN Tunnel Interface Between AWS and SonicWall

11/16/2023

Description

This article details how to configure a Site-to-Site VPN between AWS and SonicWall using Tunnel interface and Applying a Route map to influence the incoming and outgoing traffic.

 Below is the Schema used for the VPN  tunnel configuration between SonicWall and AWS.

  • Configuring the VPN Policy 
  • Configuring the Tunnel Interface 
  • Configuring the BGP routing
  • Configuring the Route-map
Image
IP Addresses used in this article  
   
 Site A (NSA 6650)AWS
WAN IPX1:  10.20.1.2X2: 10.30.1.210.6.220.6510.6.210.2
Tunnel IP192.168.5.1192.168.6.1192.168.5.2192.168.6.2
Local Network172.16.32.0/24172.16.31.0/24
Peer Network(VPN)172.16.31.0/24172.16.32.0/24
BGP AS NUMBERAS  65530AS 65532//65531

Cause

A route map can utilize access-lists, prefix-lists, as-path access lists, and community lists to create an effective route policy.

Resolution

STEP 1: Go to Manage | VPN | Base Settings and click on Add. The VPN Policy window is displayed.

General tab:

Policy type: Tunnel Interface

Auth method: IKE using Preshared Secret

Local/Peer IKE ID: IPv4 Address

Note: When configuring a Numbered Tunnel Interface VPN, do not select “Allow Advance Routing” in the VPN Policy Advance tab. This option is use for Unnumbered Tunnel Interface with Advance Routing only.

Image
Image

 NOTE: The Proposals tab must be identical on the Tunnel Interface VPNs for both appliances and should Bind with X1 and X2.

STEP 2: Configuring the Tunnel Interface.

Go to Manage | Network | Interfaces, under Add Interface field, select VPN Tunnel Interface to create the VPN tunnel interfaces on both appliances.

Image

STEP 3: Configure BGP using CLI.

Config terminal

config#  routing  / Enter to Routing Module

(config-routing)#  bgp / Enter to BGP module

ARS BGP> configure terminal / Enter configure mode

ARS BGP(config)> router bgp 65530/ Set up AS number on SonicWALL

ARS BGP(config-router)> neighbor 192.168.5.2 remote-as 65532 / Configure neighbor connection

ARS BGP(config-router)> neighbor 192.168.6.2 remote-as 65531 / Configure neighbor connection

ARS BGP(config-router)> neighbor 192.168.5.2 soft-reconfiguration inbound

ARS BGP(config-router)> neighbor 192.168.6.2 soft-reconfiguration inbound

ARS BGP(config-router)> network 172.16.32.0/24/ Advertise your network

STEP 4: Configure BGP using CLI and Sending the  outgoing traffic via Tunnel  1 and receiving  the incoming traffic via Tunnel 1.

ARS BGP(config-router)> neighbor 192.168.5.2 route-map to31 in

ARS BGP(config-router)> neighbor 192.168.6.2 route-map to32 out

ip prefix-list 1 to31 permit 172.16.31.0/24 

ip prefix-list 1 to32 permit 172.16.32.0/24 

!

route-map to31 permit 10

match ip address prefix-list to31

set Local-preference 200

!

route-map to32 permit 10

match ip address prefix-list to32

set as-path prepend 1000 1000 1000 1000

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/apply-bgp-route-map-for-numbered-vpn-tunnel-interface-between-aws-and-sonicwall/190110123222176/

Sonicwall SonicOS API to restart the SonicWall using Postman and cURL

03/28/2023

Description

SonicOS API provides an alternative to the SonicOS Command Line Interface (CLI) for configuring selected functions. SonicOS API is disabled by default in SonicOS. 

To use the SonicOS API, you must enable it, either through the SonicOS Management Interface or from the CLI.
SonicOS API is supported on all platforms on GEN7 and running SonicOS 6.5.4 and higher for GEN6.

Resolution

Resolution for SonicOS 7.X

This release includes significant user interface changes and many new features that are different from the SonicOS 6.5 and earlier firmware. The below resolution is for customers using SonicOS 7.X firmware.

  1. ENABLING THE API MODULE ON THE FIREWALL UI.Login to the SonicWall management UI. Navigate to Device | Settings | Administration | Audit/SonicOS API  section. Enable the option ‘Enable SonicOS API’ and ‘Enable RFC-2617 HTTP Basic Access authentication’ options.
    Image

  2. LIST OF APPLICABLE APIS:Navigate to MANAGE | API and click on the link https://SonicOS-api.sonicwall.com. Swagger will prepopulate your SonicWalls’s IP, MGMT Port, and Firmware so it can give you a list of applicable APIs.
    Image

  3. LOGIN TO THE FIREWALL USING POSTMANThe following 3 steps need to be performed for every API request in Gen7 devices.

     NOTE: https://IP-address:port/– Replace this with your SonicWall’s Public or private IP address with the right management port number (If the management port is 443, you can directly use https:// followed by the IP address without the port number too).

    a) The HTTP method should be POST and we need to use the URL: https://192.168.168.168/api/sonicos/auth
    Under the authorization tab, select Basic Auth and mention the correct admin credentials.
    Image

    b) Under the settings tab, turn OFF the Enable SSL certificate verification if the firewall uses a self-signed certificate for management.
    Image


    c) Under the headers tab, include application/Json as the value for keys Accept and Content-type.
    Image 


    d) The Gen 7 devices are token-driven. Use the {“override” : true} under the body to override any older tokens. This is used only during login.
    After this, click on the Send button and then you can see the response in the section below. The response should contain a message: “success”.

    Image


    e) After this, click on the Send button and then you can see the response in the section below. The response should contain a message: “success”.

    Log in
    cURL code:
    curl --location --request POST 'https://192.168.168.168/api/sonicos/auth' \--header 'Accept: application/Json' \--header 'Content-Type: application/Json' \--header 'Authorization: Basic YWRtaW46cGFzc3dvcmQ=
    --data-raw '{"override" : true}'

    Command Output should contain a string: “success”: true

  4. Restart command
    Restart can be pushed in 2 ways: now or later. There is nothing in the body of the API call as you will notice in the screenshot below.
    1. Restart now
      Restart now
      cURL code:
      curl -L -X POST 'https://192.168.168.168/api/sonicos/restart' \
      -H 'Content-Type: application/Json' \
      -H 'Accept: application/Json' \
      -H 'Authorization: Basic YWRtaW46cGFzc3dvcmQ=' \
      -d ''

    2. Restart in ___ minutes/hours/days/
      If the plan is to restart after some time, you can schedule that. Please ensure you log out after the command since there is a waiting period. 
      You can make other configurational changes, but it should be noted that you ‘commit’ the changes as a restart can clear off the pending configuration if not saved.
      Restart in

      You may change the URL to suit your requirement. The number that you use should be an unsigned integer (UINT32) with values ranging from 0 to 4,294,967,295. For example, it can be made 
      ../restart/in/2/days
      ../restart/in/24/hours

      cURL code:

      curl -L -X POST 'https://192.168.168.168/api/sonicos/restart/in/10/minutes' \
      -H 'Content-Type: application/Json' \
      -H 'Accept: application/Json' \
      -H 'Authorization: Basic YWRtaW46cGFzc3dvcmQ=' \
      -d ''

  5. Log out the SonicWall with API

    Log out

    cURL command:
    curl -L -X DELETE 'https://192.168.168.168:443/api/sonicos/auth' \
    -H 'Authorization: Basic YWRtaW46cGFzc3dvcmQ='

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.

  1.  Enabling the API Module on the firewall UI
    Login to the SonicWall management UI. Navigate to MANAGE | Appliance | Base Settings and scroll down to SonicOS API section. Enable the option ‘Enable SonicOS API’ and ‘Enable RFC-2617 HTTP Basic Access authentication’ options.
    Image
  2. List of applicable APIs
    Navigate to MANAGE | API and click on the link https://SonicOS-api.sonicwall.com. Swagger will prepopulate your SonicWalls’s IP, MGMT Port, Firmware so it can give you a list of applicable APIs.
     TIP: You are free to choose Swagger, Postman, Git bash, or any application that allows API calls, if you are using a Linux based operating system you can execute cURL from the terminal. For this article I am using Git bash on Windows.
    Image
    Image
  3. LOGIN TO THE FIREWALL USING POSTMANThe following 3 steps need to be performed for every API request in Gen7 devices.

     NOTE: https://IP-address:port/– Replace this with your SonicWall’s Public or private IP address with the right management port number (If the management port is 443, you can directly use https:// followed by the IP address without the port number too).

    a) The HTTP method should be POST and we need to use the URL: https://192.168.168.168/api/sonicos/auth
    Under the authorization tab, select Basic Auth and mention the correct admin credentials.
    Image

    b) Under the settings tab, turn OFF the Enable SSL certificate verification if the firewall is using a self-signed certificate for management.
    Image


    c) Under the headers tab, include application/Json as the value for keys Accept and Content-type.
    Image 


    d) The Gen 7 devices are token-driven. Use the {“override” : true} under the body to override any older tokens. This is used only during login.
    After this, click on the Send button and then you can see the response in the section below. The response should contain a message: “success”.

    Image


    e) After this, click on the Send button and then you can see the response in the section below. The response should contain a message: “success”.

    Log in
    cURL code:
    curl --location --request POST 'https://192.168.168.168/api/sonicos/auth' \--header 'Accept: application/Json' \--header 'Content-Type: application/Json' \--header 'Authorization: Basic YWRtaW46cGFzc3dvcmQ=
    --data-raw '{"override" : true}'

    Command Output should contain a string: “success”: true

  4. Restart command
    Restart can be pushed in 2 ways: now or later. There is nothing in the body of the API call as you will notice in the screenshot below.
    1. Restart now
      Restart now
      cURL code:
      curl -L -X POST 'https://192.168.168.168/api/sonicos/restart' \
      -H 'Content-Type: application/Json' \
      -H 'Accept: application/Json' \
      -H 'Authorization: Basic YWRtaW46cGFzc3dvcmQ=' \
      -d ''

    2. Restart in ___ minutes/hours/days/
      If the plan is to restart after some time, you can schedule that. Please ensure you log out after the command, if there is a waiting period. 
      You can make other configurational changes, but it should be noted that you ‘commit’ the changes as a restart can clear off the pending configuration if not saved.
      Restart in

      You may change the URL to suit your requirement. The number that you use should be an unsigned integer (UINT32) with values ranging from 0 to 4,294,967,295. For example, it can be made 
      ../restart/in/2/days
      ../restart/in/24/hours

      cURL code:

      curl -L -X POST 'https://192.168.168.168/api/sonicos/restart/in/10/minutes' \
      -H 'Content-Type: application/Json' \
      -H 'Accept: application/Json' \
      -H 'Authorization: Basic YWRtaW46cGFzc3dvcmQ=' \
      -d ''

  5. Log out the SonicWall with API

    Log out

    cURL command:
    curl -L -X DELETE 'https://192.168.168.168:443/api/sonicos/auth' \
    -H 'Authorization: Basic YWRtaW46cGFzc3dvcmQ='

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/sonicos-api-to-restart-the-sonicwall-using-postman-and-curl/230328031651313/

How to Set Up a VLAN

Diego Asturias UPDATED: July 11, 2023


If you want to improve your network security and performance, learning how to set up a VLAN properly is all you need. Virtual LANs are powerful networking tools that allow you to segment your network into logical groups and isolate traffic between them.

In this post, we will go through the steps required to set up a VLAN in your network. We will configure two switches along with their interfaces and VLANs, respectively.

So, let’s dive in and learn how to set up VLANs and take your network to the next level.

Table of Contents

  • What is a VLAN?
  • Preparing for VLAN configuration
    • Our Lab
    • Network Diagram
  • How to set up a VLAN on a Switch?
    • Let’s connect to the Switch
    • Configure VLANs
    • Assign switch ports to VLANs
    • Configure trunk ports
  • Extra Configuration to Consider

What is a VLAN?

Before we go deep into learning how to set up a VLAN and provide examples, let’s understand the foundations of VLANs (or Virtual Local Area Networks).

In a nutshell, VLANs are logical groupings of devices that rely on Layer 2 addresses (MAC) for communication. VLANs are implemented to segment a physical network (or large Layer two broadcast domains) into multiple smaller logical networks (isolated broadcast domains).

Each VLAN behaves as a separate network with its own broadcast domain. VLANs help prevent broadcast storms (extreme amounts of broadcast traffic). They also help control traffic and overall improve network security and performance.

Preparing for VLAN configuration

Although VLANs are usually left for Layer 2 switches, in reality, any device (including routers and L3 switches) with switching capabilities and support of VLAN configuration should be an excellent fit for VLANs. In addition, VLANs are supported by different vendors, and since each vendor has a different OS and code, the way the VLANs are configured may slightly change.

Furthermore, you can also use specific software such as network diagramming and simulation to help you create network diagrams and test your configuration.

Our Lab

We will configure a popular Cisco (IOS-based) switch for demonstration purposes. We will use Boson NetSim (a network simulator for Cisco networking hardware and software) to run Cisco IOS simulated commands. This simulation is like you were configuring an actual Cisco switch or router.

Network Diagram

To further illustrate how to set up a VLAN, we will work on the following network diagram. We will configure two VLANs in two different switches. We will then configure each port on the switches connected to a PC. We will then proceed to configure the trunk port, which is vital for VLAN traffic.

Network Diagram

Network diagram details

  • S2 and S3 (Switch 2 and Switch 3) – Two Cisco L2 Switches connecting PCs at different VLANs (VLAN 10 and VLAN 20) via Fast Ethernet interfaces.
  • VLANs 10 and VLAN20. These VLANs configured in L2 switches (S2 and S3) create a logical grouping of PCs within the network. In addition, each VLAN gets a name, VLAN 10 (Engineering) and VLAN 20 (Sales).
  • PCs. PC1, PC2, PC3, and PC4 are each connected to a specific L2 switch.

How to set up a VLAN on a Switch?

So now that you know the VLAN configuration we will be using, including the number of switches, VLAN ID, VLAN name, and the devices or ports that will be part of the configuration, let’s start setting up the VLANs.

Note: VLAN configuration is just a piece of the puzzle. Switches also need proper interface configuration, authentication, access, etc. To learn how to correctly connect and configure everything else, follow the step-by-step guide on how to configure a Cisco Switch. 

a. Let’s connect to the switch

Inspect your hardware and find the console port. This port is usually located on the back of your Cisco switch. You can connect to the switch’s “console port” using a console cable (or rollover). Connect one end of the console cable to the switch’s console port and the other to your computer’s serial port.

Note: Obviously, not all modern computers have serial ports. Some modern switches come with a Mini USB port or AUX port to help with this. But if your hardware doesn’t have these ports, you can also connect to the switch port using special cables like an RJ-45 rollover cable, a Serial DB9-to-RJ-45 console cable, or a serial-to-USB adapter. 

  • Depending on your switch’s model, you can configure it via Command Line Interface (CLI) or Graphical User Interface (GUI). We will connect to the most popular user interface: The IOS-based CLI. 
  • To connect to your switch’s IOS-based CLI, you must use a terminal emulator on your computer, such as PuTTY or SecureCRT.
  • You’ll need to configure the terminal emulator to use the correct serial port and set the baud rate to 9600. Learn how to properly set these parameters in the Cisco switching configuration guide.
  • In the terminal emulator, press Enter to activate the console session. The Cisco switch should display a prompt asking for a username and password.
  • Enter your username and password to log in to the switch.
connect to the switch

b. Configure VLANs

According to our previously shown network diagram, we will need two VLANs; VLAN 10 and VLAN 20.

  • To configure Layer 2 switches, you need to enter the privileged EXEC mode by typing “enable” and entering the password (if necessary).
  • Enter the configuration mode by typing “configure terminal.”
  • Create the VLAN with “vlan <vlan ID>” (e.g., “vlan 10”).
  • Name the VLAN by typing “name <vlan name>” (e.g., “name Sales”).
  • Repeat these two steps for each VLAN you want to create.

Configuration on Switch 2 (S2)

S2# configure terminal

S2(config)# vlan 10

S2(config-vlan)# name Engineering

S2(config-vlan)# end

S2# configure terminal

S2(config)# vlan 20

S2(config-vlan)# name Sales

S2(config-vlan)# end

Use the “show vlan” command to see the configured VLANs. From the output below, you’ll notice that the two new VLANs 10 (Engineering) and 20 (Sales) are indeed configured and active but not yet assigned to any port.

Configure VLANs

Configuration on Switch 3 (S3)

S3# configure terminal

S3(config)# vlan 10

S3(config-vlan)# name Engineering

S3(config-vlan)# end

S3# configure terminal

S3(config)# vlan 20

S3(config-vlan)# name Sales

S3(config-vlan)# end

Configuration on Switch 3 (S3)

Note: From the output above, you might have noticed VLAN 1 (default), which is currently active and is assigned to all the ports in the switch. This VLAN, also known as native VLAN, is the default VLAN on most Cisco switches. It is used for untagged traffic on a trunk port. This means that all traffic that is not explicitly tagged with VLAN information will be sent to this default VLAN. 

Now, let’s remove those VLAN 1 tags from interfaces Fa0/2 and Fa0/3. Or in simple words let’s assign the ports to our newly created VLANs.

c. Assign switch ports to VLANs

In the previous section, we created our VLANs; now, we must assign the appropriate switch ports to the correct VLANs. The proper steps to assign switch ports to VLANs are as follows:

  • Enter configuration mode. Remember to run these commands under the configuration mode (configure terminal).
  • Assign ports to the VLANs by typing “interface <interface ID>” (e.g., “interface GigabitEthernet0/1”).
  • Configure the port as an access port by typing “switchport mode access”
  • Assign the port to a VLAN by typing “switchport access vlan <vlan ID>” (e.g., “switchport access vlan 10”).
  • Repeat these steps for each port you want to assign to a VLAN.

Let’s refer to a section of our network diagram

network diagram

Configuration on Switch 2 (S2)

S2(config)# interface fastethernet 0/2

S2(config-if)# switchport mode access

S2(config-if)# switchport access vlan 10

S2(config)# interface fastethernet 0/3

S2(config-if)# switchport mode access

S2(config-if)# switchport access vlan 20

Configuration on Switch 2 (S2)

Use the “show running-configuration” to see the new configuration taking effect on the interfaces.

Configuration on Switch 3 (S3)

S3(config)# interface fastethernet 0/2

S3(config-if)# switchport mode access

S3(config-if)# switchport access vlan 10

S3(config)# interface fastethernet 0/3

S3(config-if)# switchport mode access

S3(config-if)# switchport access vlan 20

Configuration on Switch 3 (S3)

A “show running-configuration” can show you our configuration results.

show running-configuration

d. Configure trunk ports

Trunk ports are a type of switch port mode (just like access) that perform essential tasks like carrying traffic for multiple VLANs between switches, tagging VLAN traffic, supporting VLAN management, increasing bandwidth efficiency, and allowing inter-VLAN routing.

If we didn’t configure trunk ports between our switches, the PCs couldn’t talk to each other on different switches, even if they were on the same VLAN.

Here’s a step by step to configuring trunk ports

  • Configure a trunk port to carry traffic between VLANs by typing “interface <interface ID>” (e.g., “interface FastEthernet0/12”).
  • Set the trunk encapsulation method (dot1q). The IEEE 802.1Q (dot1q) trunk encapsulation method is the standard tagging Ethernet frames with VLAN information.
  • Configure the port as a trunk port by typing “switchport mode trunk”.
  • Repeat the steps for each trunk port you want to configure.

Note (on redundant trunk links): To keep our article simple, we will configure one trunk link. However, keep in mind that any good network design (including trunk links) would need redundancy. One trunk link between switches is not an optimal redundant solution for networks on production. To add redundancy, we recommend using EtherChannel to bundle physical links together and configure the logical link as a trunk port. You can also use Spanning Tree Protocol (STP) by using the “spanning-tree portfast trunk” command.

Let’s refer to our network diagram

network diagram

Configuration on Switch 2 (S2)

S2(config)# interface fastethernet 0/12

S2(config-if)# switchport trunk encapsulation dot1q

S2(config-if)# switchport mode trunk

S2(config-if)# exit

Configuration on Switch 2 (S2)

Configuration on Switch 3 (S3)

S3(config)# interface fastethernet 0/24

S3(config-if)# switchport trunk encapsulation dot1q

S3(config-if)# switchport mode trunk

S3(config-if)# exit

Configuration on Switch 3 (S3)

Note: You can use different types of trunk encapsulation such as dot1q and ISL, just make sure both ends match the type of encapsulation.

Extra Configuration to Consider

Once you finish with VLAN and trunk configuration, remember to test VLAN connectivity between PCs, you can do this by configuring the proper IP addressing and doing a simple ping. Below are other key configurations related to your new VLANs that you might want to consider.

a. Ensure all your interfaces are up and running

To ensure that your interfaces are not administratively down, issue a “no shutdown” (or ‘no shut’) command on all those newly configured interfaces. Additionally, you can also use the “show interfaces” to see the status of all the interfaces.

no shutdown command

b. (Optional) enable inter-VLAN

VLANs, as discussed earlier, separate broadcast domains (Layer 2) — they do not know how to route IP traffic because Layer 2 devices like switches can’t accept IP address configuration on their interfaces. To allow inter-VLAN communication (PCs on one VLAN communicate with PCs on another VLAN), you would need to use a Layer 3 device (a router or L3 switch) to route traffic.

There are three ways to implement inter-VLAN routing: an L3 router with multiple Ethernet interfaces, an L3 router with one router interface using subinterfaces (known as Router-On-a-Stick), and an L3 switch with SVI.

We will show a step-by-step on how to configure Router-On-a-Stick for inter-VLAN communications. 

  • Connect the router to one switch via a trunk port.
  • Configure subinterfaces on the router for each VLAN (10 and 20 in our example). To configure subinterfaces, use the “interface” command followed by the VLAN number with a period and a subinterface number (e.g., “interface FastEthernet0/0.10” for VLAN 10). For example, to configure subinterfaces for VLANs 10 and 20, you would use the following commands:

> router(config)# interface FastEthernet 0/0

> router(config-if)# no shutdown

> router(config-if)# interface FastEthernet 0/0.10

> router(config-subif)# encapsulation dot1Q 10

> router(config-subif)# ip address 192.168.10.1 255.255.255.0

> router(config-subif)# interface FastEthernet 0/0.20

> router(config-subif)# encapsulation dot1Q 20

> router(config-subif)# ip address 192.168.20.1 255.255.255.0

  • Configure a default route on the router using the “ip route” command. This is a default route to the Internet through a gateway at IP address 192.168.1.1. For example:

> router(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.1

c. Configure DHCP Server

To automatically assign IP addresses to devices inside the VLANs, you will need to configure a DHCP server. Follow these steps:

  1. The DHCP server should also be connected to the VLAN.
  2. Configure the DHCP server to provide IP addresses to devices in the VLAN.
  3. Configure the router to forward DHCP requests to the DHCP server by typing “ip helper-address <ip address>” (e.g., “ip helper-address 192.168.10.2”).

Final Words

By following the steps outlined in this post, you can easily set up a VLAN on your switch and effectively segment your network. Keep in mind to thoroughly test your VLAN configuration and consider additional configuration options to optimize your network for your specific needs.

With proper setup and configuration, VLANs can greatly enhance your network’s capabilities and 10x increase its performance and security.

Source :
https://www.pcwdld.com/how-to-set-up-a-vlan/

Sonicwall How do I troubleshoot license error for firewalls in high availability?

06/26/2023

Description

The “License of HA Pair doesn’t match” or “HA License Sync Error” log message will repeat every 15 minutes if licensing of the Primary and Backup firewalls is not equivalent. This message is intended to alert the firewall administrator that not all services configured on the Primary will be active on the Backup firewall.

For example: The error message may occur if the number of Network Anti-Virus licenses are different on the Primary and Backup appliances, or, if the Primary has Content Filtering Service (CFS) but the Backup does not, there will be no CFS functionality if the Backup becomes the active firewall.

Resolution for SonicOS 7.X

This release includes significant user interface changes and many new features that are different from the SonicOS 6.5 and earlier firmware. The below resolution is for customers using SonicOS 7.X firmware.

Step 1: Synchronize the licenses on both the devices.

Log into the Backup SonicWall’s unique LAN IP address. The management interface should now display Logged Into: Secondary Device in the upper left corner. If all licenses are not already synchronized with the Primary unit, follow these steps:

  • Navigate to the Device | Settings | Licenses page and click Synchronize in the upper right corner.

    Image
  • From the Device | Diagnostics | DNS Name Lookup page, use the “Lookup Name or IP” option to see if the DNS servers listed in the SonicWall WAN Interface are resolving the license manager URL “licensemanager.SonicWall.com” on both units.
     TIP: If the DNS servers are not resolving, try changing the DNS IP addresses on the SonicWall WAN Interface and then try to synchronize the licenses.
  • If the backup unit is not registered, navigate to the Device | Settings | Licenses page and register the SonicWall security appliance on mySonicWall.com. This allows the SonicWall licensing server to synchronize the licenses.

Step 2: Verify the licenses on www.mySonicWall.com

To use the High Availability feature, you must register both the SonicWall appliances on mySonicWall.com as Associated Products.

  • Both appliances must be the same SonicWall model,
  • Must be registered under the same mySonicWall.com user account,
  • And must be separately licensed for SonicOS Enhanced.

 NOTE: The SonicOS Enhanced license is not shareable between the primary and the backup appliances. Both appliances must be licensed separately. 

Verify the HA Secondary device on mySonicWall.com account:

  1. Login to your www.mySonicWall.com account.
  2. Go to My Products | Product Management.
  3. Click on the Primary UTM appliance (e.g. TZ 670) and scroll down to Associated Products section.
  4. Click on High Availability Secondary and ensure that the Serial number of device matches with the Backup SonicWall entry on the Devices | High Availability | Settings page of your Primary SonicWall appliance.

Please Note that the backup appliance of your high availability pair is referred to as the HA Secondary unit on mySonicWall.com. After the appliances are associated as an HA Pair, they can share licenses.

Image

Step 3: Adding secondary UTM appliance under the HA pair on mySonicWall.com

If you have not registered/Associated the HA Secondary device on the mySonicWall.com, follow these steps:

Registering the Secondary/Backup UTM appliance from the SonicWall Management Interface

Important: After registering new SonicWall appliances on mySonicWall.com, you must also register the backup appliance from the SonicOS management interface while logged into its individual management IP address. This allows the backup unit to synchronize with the SonicWall license server (licensemanager.SonicWall.com) and share licenses with the associated primary appliance.

Step 4: Accessing the Secondary UTM appliance and Synchronizing the Licenses

On the Device |High Availability | Monitoring  pageyou can configure unique management IP addresses for both units in the HA Pair which allows you to log in to each unit independently for management purposes. See also Configuring High Availability Monitoring settings

Also you can configure Logical/Probe IP address for SonicWall to monitor a reliable device on one or more of the connected networks. Failure to periodically communicate with the device by the Active unit in the HA Pair will trigger a failover to the Idle unit. If neither unit in the HA Pair can connect to the device, no action will be taken.

 NOTE: The Primary IP Address and Backup IP Address fields must be configured with independent IP addresses on a LAN interface, such as X0, (or a WAN interface, such as X1, for probing on the WAN) to allow logical probing to function correctly.

Image

In the Logical Probe IP Address field, enter the IP address of a downstream device on the LAN network that should be monitored for connectivity. Typically, this should be a downstream router or server. (If probing is desired on the WAN side, an upstream device should be used.) The Primary and Backup appliances will regularly ping this probe IP address. If both can successfully ping the target, no failover occurs. If neither can successfully ping the target, no failover occurs, because it is assumed that the problem is with the target, and not the SonicWall appliances. But, if one appliance can ping the target but the other appliance cannot, failover will occur to the appliance that can ping the target.

Step 5: Try to synchronize the licenses again on both the devices.

Step 6: You may also try to upgrade the firmware to the latest version and try to synchronize the licenses again.

See also How can I upgrade firmware on a High Availability (Hardware Failover) Pair?

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.


Step 1: Synchronize the licenses on both the devices.

Log into the Backup SonicWall’s unique LAN IP address. The management interface should now display Logged Into: Backup SonicWall Status: (green ball) Active in the upper right corner. If all licenses are not already synchronized with the Primary unit, follow these steps:

  • Navigate to the Manage | Licenses page and click Synchronize.

    Image
  • From the Investigate | Tools | System Diagnostics page, use the “DNS Name Lookup” option under Diagnostic Tool drop down menu to see if the DNS servers listed in the SonicWall WAN Interface are resolving the license manager URL “licensemanager.SonicWall.com” on both units.
     TIP: If the DNS servers are not resolving, try changing the DNS IP addresses on the SonicWall WAN Interface and then try to synchronize the licenses.
  • If the backup unit is not registered, navigate to the Manage | Licenses page and register the SonicWall security appliance on mySonicWall.com. This allows the SonicWall licensing server to synchronize the licenses.

Step 2: Verify the licenses on www.mySonicWall.com

To use the High Availability feature, you must register both the SonicWall appliances on mySonicWall.com as Associated Products.

  • Both appliances must be the same SonicWall model,
  • Must be registered under the same mySonicWall.com user account,
  • And must be separately licensed for SonicOS Enhanced.

 NOTE: The SonicOS Enhanced license is not shareable between the primary and the backup appliances. Both appliances must be licensed separately. 

Verify the HA Secondary device on mySonicWall.com account:

  1. Login to your www.mySonicWall.com account.
  2. Go to My Products | Product Management.
  3. Click on the Primary UTM appliance (e.g. TZ 600) and scroll down to Associated Products section.
  4. Click on High Availability Secondary and ensure that the Serial number of device matches with the Backup SonicWall entry on the Manage | High Availability | Base Setup | HA Devices page of your Primary SonicWall appliance.

Please Note that the backup appliance of your high availability pair is referred to as the HA Secondary unit on mySonicWall.com. After the appliances are associated as an HA Pair, they can share licenses. 

Image

Step 3: Adding secondary UTM appliance under the HA pair on mySonicWall.com

If you have not registered/Associated the HA Secondary device on the mySonicWall.com, follow these steps:

Registering the Secondary/Backup UTM appliance from the SonicWall Management Interface

Important: After registering new SonicWall appliances on mySonicWall.com, you must also register the backup appliance from the SonicOS management interface while logged into its individual management IP address. This allows the backup unit to synchronize with the SonicWall license server (licensemanager.SonicWall.com) and share licenses with the associated primary appliance.

Step 4: Accessing the Secondary UTM appliance and Synchronizing the Licenses

On the Manage |High Availability | Monitoring Settings page, you can configure unique management IP addresses for both units in the HA Pair which allows you to log in to each unit independently for management purposes. See also Configuring High Availability Monitoring settings.

Also you can configure Logical/Probe IP address for SonicWall to monitor a reliable device on one or more of the connected networks. Failure to periodically communicate with the device by the Active unit in the HA Pair will trigger a failover to the Idle unit. If neither unit in the HA Pair can connect to the device, no action will be taken.

 NOTE: The Primary IP Address and Backup IP Address fields must be configured with independent IP addresses on a LAN interface, such as X0, (or a WAN interface, such as X1, for probing on the WAN) to allow logical probing to function correctly.

Image

In the Logical Probe IP Address field, enter the IP address of a downstream device on the LAN network that should be monitored for connectivity. Typically, this should be a downstream router or server. (If probing is desired on the WAN side, an upstream device should be used.) The Primary and Backup appliances will regularly ping this probe IP address. If both can successfully ping the target, no failover occurs. If neither can successfully ping the target, no failover occurs, because it is assumed that the problem is with the target, and not the SonicWall appliances. But, if one appliance can ping the target but the other appliance cannot, failover will occur to the appliance that can ping the target.

Step 5: Try to synchronize the licenses again on both the devices.

Step 6: You may also try to upgrade the firmware to the latest version and try to synchronize the licenses again.

See also How to upgrade Firmware on a High Availability (Hardware Failover) Pair

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/how-do-i-troubleshoot-license-error-for-firewalls-in-high-availability/170504903085305/

Sonicwall Configuring High Availability Monitoring settings

Description

On the High Availability | Monitoring page, you can configure both physical and logical interface monitoring. By enabling physical interface monitoring, you enable link detection for the designated HA interfaces. The link is sensed at the physical layer to determine link viability. Logical monitoring involves configuring the SonicWall to monitor a reliable device on one or more of the connected networks. Failure to periodically communicate with the device by the Active unit in the HA Pair will trigger a Failover to the Idle unit. If neither unit in the HA Pair can connect to the device, no action will be taken.

The Primary and Backup IP addresses configured on this page are used for multiple purposes.

  • As independent management addresses for each unit (supported on all physical interfaces).
  • To allow synchronization of licenses between the Idle unit and the SonicWall licensing server .
  • As the source IP addresses for the probe pings sent out during logical monitoring.

When using logical monitoring, the HA Pair will ping the specified Logical Probe IP address target from the Primary as well as from the Backup SonicWall. The IP address set in the Primary IP Address or Backup IP Address field is used as the source IP address for the ping. If both units can successfully ping the target, no Failover occurs. If both cannot successfully ping the target, no Failover occurs, as the SonicWalls will assume that the problem is with the target, and not the SonicWalls. But, if one SonicWall can ping the target but the other SonicWall cannot, the HA Pair will Failover to the SonicWall that can ping the target.

Resolution for SonicOS 7.X

This release includes significant user interface changes and many new features that are different from the SonicOS 6.5 and earlier firmware. The below resolution is for customers using SonicOS 7.X firmware.

The configuration tasks on the High Availability | Monitoring page are performed on the Primary unit and then are automatically synchronized to the Backup.

  1. Login as an administrator to the SonicOS user interface on the Primary SonicWall.
  2. Go to Device In top menu , navigate to High Availability | Monitoring Settings .
  3. Click Configure icon for an interface on the LAN, such as X0.
  4. To enable link detection between the designated HA interfaces on the Primary and Backup units, leave the Enable Physical / Link Monitoring checkbox selected.


    Image
  5. In the Primary IP Address field, enter the unique LAN management IP address of the Primary unit.
  6. In the Backup IP Address field, enter the unique LAN management IP address of the Backup unit.

    Configuring unique management IP addresses for both units in the HA Pair allows you to log in to each unit independently for management purposes. Note that non-management traffic is ignored if it is sent to one of these IP addresses. The Primary and Backup SonicWall security appliances’ unique LAN IP addresses cannot act as an active gateway; all systems connected to the internal LAN will need to use the virtual LAN IP address as their gateway.

    The management IP address of the Backup/Idle unit is used to allow license synchronization with the SonicWall licensing server, which handles licensing on a per-appliance basis (not per-HA Pair). Even if the Backup unit was already registered on MySonicWall before creating the HA association, you must use the link on the Device | Settings Licenses page to connect to the SonicWall server while accessing the Backup appliance through its management IP address.
  7. Select the Allow Management on Primary/Backup IP Address checkbox. When this option is enabled for an interface, a green icon appears in the interface’s management column in the Monitoring Settings table on the High Availability | Monitoring page. Management is only allowed on an interface when this option is enabled.
  8. In the Logical Probe IP Address field, enter the IP address of a downstream device on the LAN network that should be monitored for connectivity.Typically, this should be a downstream router or server. (If probing is desired on the WAN side, an upstream device should be used.) The Primary and Backup appliances will regularly ping this probe IP address. If both can successfully ping the target, no failover occurs. If neither can successfully ping the target, no failover occurs, because it is assumed that the problem is with the target, and not the SonicWall appliances. But, if one appliance can ping the target but the other appliance cannot, failover will occur to the appliance that can ping the target.

     NOTE: The Primary IP Address and Backup IP Address fields must be configured with independent IP addresses on a LAN interface, such as X0, (or a WAN interface, such as X1, for probing on the WAN) to allow logical probing to function correctly.
  9. Optionally, to manually specify the virtual MAC address for the interface, select Override Virtual MAC and enter the MAC address in the field. The format for the MAC address is six pairs of hexadecimal numbers separated by colons, such as A1:B2:C3:d4:e5:f6. Care must be taken when choosing the Virtual MAC address to prevent configuration errors.

    Note:There is a design change on Gen7 in the way MAC Addresses are handled for the HA native vs. monitoring. GEN7 uses the Virtual MAC for all interface IPs, both the Virtual IPs and Primary / Secondary Monitoring IPs, Hence the MAC addresses of the X0 Interface IP(Or any VLAN under X0), will have the same MAC address as of the Primary firewall X0 monitoring IP, the same applies for all the interfaces X1, X2, wherever monitoring IPs will be configured.

    Image
  10. To configure monitoring on any of the other interfaces, repeat the above steps.
  11. When finished with all High Availability configuration, click Accept. All settings will be synchronized to the Idle unit automatically.

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.

The configuration tasks on the High Availability | Monitoring page are performed on the Primary unit and then are automatically synchronized to the Backup.

  1. Login as an administrator to the SonicOS user interface on the Primary SonicWall.
  2. Go to Manage In top menu , navigate to High Availability | Monitoring Settings .
  3. Click Configure icon for an interface on the LAN, such as X0.
  4. To enable link detection between the designated HA interfaces on the Primary and Backup units, leave the Enable Physical / Link Monitoring checkbox selected.
    Image
  5. In the Primary IP Address field, enter the unique LAN management IP address of the Primary unit.
  6. In the Backup IP Address field, enter the unique LAN management IP address of the Backup unit.

    Configuring unique management IP addresses for both units in the HA Pair allows you to log in to each unit independently for management purposes. Note that non-management traffic is ignored if it is sent to one of these IP addresses. The Primary and Backup SonicWall security appliances’ unique LAN IP addresses cannot act as an active gateway; all systems connected to the internal LAN will need to use the virtual LAN IP address as their gateway.

    The management IP address of the Backup/Idle unit is used to allow license synchronization with the SonicWall licensing server, which handles licensing on a per-appliance basis (not per-HA Pair). Even if the Backup unit was already registered on MySonicWall before creating the HA association, you must use the link on the System Licenses page to connect to the SonicWall server while accessing the Backup appliance through its management IP address.
  7. Select the Allow Management on Primary/Backup IP Address checkbox. When this option is enabled for an interface, a green icon appears in the interface’s management column in the Monitoring Settings table on the High Availability | Monitoring page. Management is only allowed on an interface when this option is enabled.
  8. In the Logical Probe IP Address field, enter the IP address of a downstream device on the LAN network that should be monitored for connectivity.Typically, this should be a downstream router or server. (If probing is desired on the WAN side, an upstream device should be used.) The Primary and Backup appliances will regularly ping this probe IP address. If both can successfully ping the target, no failover occurs. If neither can successfully ping the target, no failover occurs, because it is assumed that the problem is with the target, and not the SonicWall appliances. But, if one appliance can ping the target but the other appliance cannot, failover will occur to the appliance that can ping the target.

     NOTE: The Primary IP Address and Backup IP Address fields must be configured with independent IP addresses on a LAN interface, such as X0, (or a WAN interface, such as X1, for probing on the WAN) to allow logical probing to function correctly.
  9. Optionally, to manually specify the virtual MAC address for the interface, select Override Virtual MAC and enter the MAC address in the field. The format for the MAC address is six pairs of hexadecimal numbers separated by colons, such as A1:B2:C3:d4:e5:f6. Care must be taken when choosing the Virtual MAC address to prevent configuration errors.When the Enable Virtual MAC checkbox is selected on the Manage | High Availability| Base Setup page, the SonicOS firmware automatically generates a Virtual MAC address for all interfaces. Allowing the SonicOS firmware to generate the Virtual MAC address eliminates the possibility of configuration errors and ensures the uniqueness of the Virtual MAC address, which prevents possible conflicts.
  10. To configure monitoring on any of the other interfaces, repeat the above steps.
  11. When finished with all High Availability configuration, click Accept. All settings will be synchronized to the Idle unit automatically.

Resolution for SonicOS 6.2 and Below

The below resolution is for customers using SonicOS 6.2 and earlier firmware. For firewalls that are generation 6 and newer we suggest to upgrade to the latest general release of SonicOS 6.5 firmware.

The configuration tasks on the High Availability | Monitoring page are performed on the Primary unit and then are automatically synchronized to the Backup.

  1. Login as an administrator to the SonicOS user interface on the Primary SonicWall.
  2. In the left navigation pane, navigate to High Availability | Monitoring.
  3. Click Configure icon for an interface on the LAN, such as X0.
  4. To enable link detection between the designated HA interfaces on the Primary and Backup units, leave the Enable Physical Interface Monitoring checkbox selected.
    ImageImage
  5. In the Primary IP Address field, enter the unique LAN management IP address of the Primary unit.
  6. In the Backup IP Address field, enter the unique LAN management IP address of the Backup unit.

    Configuring unique management IP addresses for both units in the HA Pair allows you to log in to each unit independently for management purposes. Note that non-management traffic is ignored if it is sent to one of these IP addresses. The Primary and Backup SonicWall security appliances’ unique LAN IP addresses cannot act as an active gateway; all systems connected to the internal LAN will need to use the virtual LAN IP address as their gateway.

    The management IP address of the Backup/Idle unit is used to allow license synchronization with the SonicWall licensing server, which handles licensing on a per-appliance basis (not per-HA Pair). Even if the Backup unit was already registered on MySonicWall before creating the HA association, you must use the link on the System Licenses page to connect to the SonicWall server while accessing the Backup appliance through its management IP address.
  7. Select the Allow Management on Primary/Backup IP Address checkbox. When this option is enabled for an interface, a green icon appears in the interface’s Management column in the Monitoring Settings table on the High Availability | Monitoring page. Management is only allowed on an interface when this option is enabled.
  8. In the Logical Probe IP Address field, enter the IP address of a downstream device on the LAN network that should be monitored for connectivity.Typically, this should be a downstream router or server. (If probing is desired on the WAN side, an upstream device should be used.) The Primary and Backup appliances will regularly ping this probe IP address. If both can successfully ping the target, no failover occurs. If neither can successfully ping the target, no failover occurs, because it is assumed that the problem is with the target, and not the SonicWall appliances. But, if one appliance can ping the target but the other appliance cannot, failover will occur to the appliance that can ping the target.

     NOTE:The Primary IP Address and Backup IP Address fields must be configured with independent IP addresses on a LAN interface, such as X0, (or a WAN interface, such as X1, for probing on the WAN) to allow logical probing to function correctly.
  9. Optionally, to manually specify the virtual MAC address for the interface, select Override Virtual MAC and enter the MAC address in the field. The format for the MAC address is six pairs of hexadecimal numbers separated by colons, such as A1:B2:C3:d4:e5:f6. Care must be taken when choosing the Virtual MAC address to prevent configuration errors.When the Enable Virtual MAC checkbox is selected on the High Availability| Advanced page, the SonicOS firmware automatically generates a Virtual MAC address for all interfaces. Allowing the SonicOS firmware to generate the Virtual MAC address eliminates the possibility of configuration errors and ensures the uniqueness of the Virtual MAC address, which prevents possible conflicts.
  10. Click OK.
  11. To configure monitoring on any of the other interfaces, repeat the above steps.
  12. When finished with all High Availability configuration, click Accept. All settings will be synchronized to the Idle unit automatically.

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/configuring-high-availability-monitoring-settings/170505779399776/

Sonicwall License Manager discontinues support of TLS 1.0 and TLS 1.1 encryption protocols

Last Updated:10/09/2023

Overview

As part of our ongoing commitment to security, we are discontinuing support for the TLS 1.0 and TLS 1.1 encryption protocols in our license manager. This will cause GEN 5 and GEN 6 firewalls running older firmware to not communicate with the license manager leading to licensing issues. The firewall will not be able to validate its license or obtain necessary updates resulting in a licensing failure. The firewall will operate with reduced functionality or disable certain advanced features that require periodic license validation or updates.

Examples of services that will no longer function properly include:

  • Capture Advanced Threat Protection
  • Gateway Anti-Malware
  • Intrusion Prevention
  • Application Control

These licensed features will no longer work as expected. Critical security updates, threat intelligence updates, or other important updates may not be applied, potentially leaving the network vulnerable to emerging threats.

Discontinuing TLS 1.0 and TLS 1.1 is in line with industry best practices and aims to enhance the security of data transmission between your systems and our servers. To ensure uninterrupted service and data security, it’s important to upgrade your firewall to use TLS 1.2 or higher.

Product Impact

All GEN 5 and GEN 6 appliances running an older firmware will be affected when support for TLS 1.0 and TLS 1.1 encryption protocols are disabled.  

Remediation

SonicWall strongly recommends upgrading the firewall’s firmware to the latest version to maintain a secure connection with our license manager, as the latest firmware has the support of encryption protocols TLS 1.2 or later. 

Impacted PlatformsRecommended Firmware VersionMinimum Firmware Version
Gen 5SonicOS 5.9.2.13SonicOS 5.9.2.x
Gen 6SonicOS 6.5.4.12-101nSonicOS 6.2.9.x

Timeline

  • The support for TLS 1.0 and TLS 1.1 will be disabled on October 31, 2023. After this date, connections using these protocols will be rejected by our license manager.
  • Ensure that your systems are upgraded and ready to use TLS 1.2 or higher before the mentioned date to prevent disruption of service.

Product Migration Option

SonicWall has released the GEN 7 hardware which has been designed to take your experience to new heights, offering unparalleled performance, stunning visuals, and cutting-edge features that will revolutionize the way you interact with our products. As SonicWall customers you are eligible for the secure upgrade to the next generation of hardware. For details, please review our Secure upgrade program

Related information

 NOTE: If you do not have an active support contract or need assistance on GEN 7 upgrade options, please contact renewals@sonicwall.com. If you have any questions about the process, please do not hesitate to contact SonicWall support for assistance. Our support team is available to provide guidance and address any concerns you may have. 

Source :
https://www.sonicwall.com/support/product-notification/license-manager-discontinues-support-of-tls-1-0-and-tls-1-1-encryption-protocols/230907124013593/

NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations

Release Date October 05, 2023
Alert CodeAA23-278A

A plea for network defenders and software manufacturers to fix common problems.

EXECUTIVE SUMMARY

The National Security Agency (NSA) and Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint cybersecurity advisory (CSA) to highlight the most common cybersecurity misconfigurations in large organizations, and detail the tactics, techniques, and procedures (TTPs) actors use to exploit these misconfigurations.

Through NSA and CISA Red and Blue team assessments, as well as through the activities of NSA and CISA Hunt and Incident Response teams, the agencies identified the following 10 most common network misconfigurations:

  1. Default configurations of software and applications
  2. Improper separation of user/administrator privilege
  3. Insufficient internal network monitoring
  4. Lack of network segmentation
  5. Poor patch management
  6. Bypass of system access controls
  7. Weak or misconfigured multifactor authentication (MFA) methods
  8. Insufficient access control lists (ACLs) on network shares and services
  9. Poor credential hygiene
  10. Unrestricted code execution

These misconfigurations illustrate (1) a trend of systemic weaknesses in many large organizations, including those with mature cyber postures, and (2) the importance of software manufacturers embracing secure-by-design principles to reduce the burden on network defenders:

  • Properly trained, staffed, and funded network security teams can implement the known mitigations for these weaknesses.
  • Software manufacturers must reduce the prevalence of these misconfigurations—thus strengthening the security posture for customers—by incorporating secure-by-design and -default principles and tactics into their software development practices.[1]

NSA and CISA encourage network defenders to implement the recommendations found within the Mitigations section of this advisory—including the following—to reduce the risk of malicious actors exploiting the identified misconfigurations.

  • Remove default credentials and harden configurations.
  • Disable unused services and implement access controls.
  • Update regularly and automate patching, prioritizing patching of known exploited vulnerabilities.[2]
  • Reduce, restrict, audit, and monitor administrative accounts and privileges.

NSA and CISA urge software manufacturers to take ownership of improving security outcomes of their customers by embracing secure-by-design and-default tactics, including:

  • Embedding security controls into product architecture from the start of development and throughout the entire software development lifecycle (SDLC).
  • Eliminating default passwords.
  • Providing high-quality audit logs to customers at no extra charge.
  • Mandating MFA, ideally phishing-resistant, for privileged users and making MFA a default rather than opt-in feature.[3]

Download the PDF version of this report: PDF, 660 KB

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 13, and the MITRE D3FEND™ cybersecurity countermeasures framework.[4],[5] See the Appendix: MITRE ATT&CK tactics and techniques section for tables summarizing the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques, and the Mitigations section for MITRE D3FEND countermeasures.

For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.[6],[7]

Overview

Over the years, the following NSA and CISA teams have assessed the security posture of many network enclaves across the Department of Defense (DoD); Federal Civilian Executive Branch (FCEB); state, local, tribal, and territorial (SLTT) governments; and the private sector:

  • Depending on the needs of the assessment, NSA Defensive Network Operations (DNO) teams feature capabilities from Red Team (adversary emulation), Blue Team (strategic vulnerability assessment), Hunt (targeted hunt), and/or Tailored Mitigations (defensive countermeasure development).
  • CISA Vulnerability Management (VM) teams have assessed the security posture of over 1,000 network enclaves. CISA VM teams include Risk and Vulnerability Assessment (RVA) and CISA Red Team Assessments (RTA).[8] The RVA team conducts remote and onsite assessment services, including penetration testing and configuration review. RTA emulates cyber threat actors in coordination with an organization to assess the organization’s cyber detection and response capabilities.
  • CISA Hunt and Incident Response teams conduct proactive and reactive engagements, respectively, on organization networks to identify and detect cyber threats to U.S. infrastructure.

During these assessments, NSA and CISA identified the 10 most common network misconfigurations, which are detailed below. These misconfigurations (non-prioritized) are systemic weaknesses across many networks.

Many of the assessments were of Microsoft® Windows® and Active Directory® environments. This advisory provides details about, and mitigations for, specific issues found during these assessments, and so mostly focuses on these products. However, it should be noted that many other environments contain similar misconfigurations. Network owners and operators should examine their networks for similar misconfigurations even when running other software not specifically mentioned below.

1. Default Configurations of Software and Applications

Default configurations of systems, services, and applications can permit unauthorized access or other malicious activity. Common default configurations include:

  • Default credentials
  • Default service permissions and configurations settings
Default Credentials

Many software manufacturers release commercial off-the-shelf (COTS) network devices —which provide user access via applications or web portals—containing predefined default credentials for their built-in administrative accounts.[9] Malicious actors and assessment teams regularly abuse default credentials by:

  • Finding credentials with a simple web search [T1589.001] and using them [T1078.001] to gain authenticated access to a device.
  • Resetting built-in administrative accounts [T1098] via predictable forgotten passwords questions.
  • Leveraging default virtual private network (VPN) credentials for internal network access [T1133].
  • Leveraging publicly available setup information to identify built-in administrative credentials for web applications and gaining access to the application and its underlying database.
  • Leveraging default credentials on software deployment tools [T1072] for code execution and lateral movement.

In addition to devices that provide network access, printers, scanners, security cameras, conference room audiovisual (AV) equipment, voice over internet protocol (VoIP) phones, and internet of things (IoT) devices commonly contain default credentials that can be used for easy unauthorized access to these devices as well. Further compounding this problem, printers and scanners may have privileged domain accounts loaded so that users can easily scan documents and upload them to a shared drive or email them. Malicious actors who gain access to a printer or scanner using default credentials can use the loaded privileged domain accounts to move laterally from the device and compromise the domain [T1078.002].

Default Service Permissions and Configuration Settings

Certain services may have overly permissive access controls or vulnerable configurations by default. Additionally, even if the providers do not enable these services by default, malicious actors can easily abuse these services if users or administrators enable them.

Assessment teams regularly find the following:

  • Insecure Active Directory Certificate Services
  • Insecure legacy protocols/services
  • Insecure Server Message Block (SMB) service
Insecure Active Directory Certificate Services

Active Directory Certificate Services (ADCS) is a feature used to manage Public Key Infrastructure (PKI) certificates, keys, and encryption inside of Active Directory (AD) environments. ADCS templates are used to build certificates for different types of servers and other entities on an organization’s network.

Malicious actors can exploit ADCS and/or ADCS template misconfigurations to manipulate the certificate infrastructure into issuing fraudulent certificates and/or escalate user privileges to domain administrator privileges. These certificates and domain escalation paths may grant actors unauthorized, persistent access to systems and critical data, the ability to impersonate legitimate entities, and the ability to bypass security measures.

Assessment teams have observed organizations with the following misconfigurations:

  • ADCS servers running with web-enrollment enabled. If web-enrollment is enabled, unauthenticated actors can coerce a server to authenticate to an actor-controlled computer, which can relay the authentication to the ADCS web-enrollment service and obtain a certificate [T1649] for the server’s account. These fraudulent, trusted certificates enable actors to use adversary-in-the-middle techniques [T1557] to masquerade as trusted entities on the network. The actors can also use the certificate for AD authentication to obtain a Kerberos Ticket Granting Ticket (TGT) [T1558.001], which they can use to compromise the server and usually the entire domain.
  • ADCS templates where low-privileged users have enrollment rights, and the enrollee supplies a subject alternative name. Misconfiguring various elements of ADCS templates can result in domain escalation by unauthorized users (e.g., granting low-privileged users certificate enrollment rights, allowing requesters to specify a subjectAltName in the certificate signing request [CSR], not requiring authorized signatures for CSRs, granting FullControl or WriteDacl permissions to users). Malicious actors can use a low-privileged user account to request a certificate with a particular Subject Alternative Name (SAN) and gain a certificate where the SAN matches the User Principal Name (UPN) of a privileged account.

Note: For more information on known escalation paths, including PetitPotam NTLM relay techniques, see: Domain Escalation: PetitPotam NTLM Relay to ADCS Endpoints and Certified Pre-Owned, Active Directory Certificate Services.[10],[11],[12]

Insecure legacy protocols/services

Many vulnerable network services are enabled by default, and assessment teams have observed them enabled in production environments. Specifically, assessment teams have observed Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS), which are Microsoft Windows components that serve as alternate methods of host identification. If these services are enabled in a network, actors can use spoofing, poisoning, and relay techniques [T1557.001] to obtain domain hashes, system access, and potential administrative system sessions. Malicious actors frequently exploit these protocols to compromise entire Windows’ environments.

Malicious actors can spoof an authoritative source for name resolution on a target network by responding to passing traffic, effectively poisoning the service so that target computers will communicate with an actor-controlled system instead of the intended one. If the requested system requires identification/authentication, the target computer will send the user’s username and hash to the actor-controlled system. The actors then collect the hash and crack it offline to obtain the plain text password [T1110.002].

Insecure Server Message Block (SMB) service

The Server Message Block service is a Windows component primarily for file sharing. Its default configuration, including in the latest version of Windows, does not require signing network messages to ensure authenticity and integrity. If SMB servers do not enforce SMB signing, malicious actors can use machine-in-the-middle techniques, such as NTLM relay. Further, malicious actors can combine a lack of SMB signing with the name resolution poisoning issue (see above) to gain access to remote systems [T1021.002] without needing to capture and crack any hashes.

2. Improper Separation of User/Administrator Privilege

Administrators often assign multiple roles to one account. These accounts have access to a wide range of devices and services, allowing malicious actors to move through a network quickly with one compromised account without triggering lateral movement and/or privilege escalation detection measures.

Assessment teams have observed the following common account separation misconfigurations:

  • Excessive account privileges
  • Elevated service account permissions
  • Non-essential use of elevated accounts
Excessive Account Privileges

Account privileges are intended to control user access to host or application resources to limit access to sensitive information or enforce a least-privilege security model. When account privileges are overly permissive, users can see and/or do things they should not be able to, which becomes a security issue as it increases risk exposure and attack surface.

Expanding organizations can undergo numerous changes in account management, personnel, and access requirements. These changes commonly lead to privilege creep—the granting of excessive access and unnecessary account privileges. Through the analysis of topical and nested AD groups, a malicious actor can find a user account [T1078] that has been granted account privileges that exceed their need-to-know or least-privilege function. Extraneous access can lead to easy avenues for unauthorized access to data and resources and escalation of privileges in the targeted domain.

Elevated Service Account Permissions

Applications often operate using user accounts to access resources. These user accounts, which are known as service accounts, often require elevated privileges. When a malicious actor compromises an application or service using a service account, they will have the same privileges and access as the service account.

Malicious actors can exploit elevated service permissions within a domain to gain unauthorized access and control over critical systems. Service accounts are enticing targets for malicious actors because such accounts are often granted elevated permissions within the domain due to the nature of the service, and because access to use the service can be requested by any valid domain user. Due to these factors, kerberoasting—a form of credential access achieved by cracking service account credentials—is a common technique used to gain control over service account targets [T1558.003].

Non-Essential Use of Elevated Accounts

IT personnel use domain administrator and other administrator accounts for system and network management due to their inherent elevated privileges. When an administrator account is logged into a compromised host, a malicious actor can steal and use the account’s credentials and an AD-generated authentication token [T1528] to move, using the elevated permissions, throughout the domain [T1550.001]. Using an elevated account for normal day-to-day, non-administrative tasks increases the account’s exposure and, therefore, its risk of compromise and its risk to the network.

Malicious actors prioritize obtaining valid domain credentials upon gaining access to a network. Authentication using valid domain credentials allows the execution of secondary enumeration techniques to gain visibility into the target domain and AD structure, including discovery of elevated accounts and where the elevated accounts are used [T1087].

Targeting elevated accounts (such as domain administrator or system administrators) performing day-to-day activities provides the most direct path to achieve domain escalation. Systems or applications accessed by the targeted elevated accounts significantly increase the attack surface available to adversaries, providing additional paths and escalation options.

After obtaining initial access via an account with administrative permissions, an assessment team compromised a domain in under a business day. The team first gained initial access to the system through phishing [T1566], by which they enticed the end user to download [T1204] and execute malicious payloads. The targeted end-user account had administrative permissions, enabling the team to quickly compromise the entire domain.

3. Insufficient Internal Network Monitoring

Some organizations do not optimally configure host and network sensors for traffic collection and end-host logging. These insufficient configurations could lead to undetected adversarial compromise. Additionally, improper sensor configurations limit the traffic collection capability needed for enhanced baseline development and detract from timely detection of anomalous activity.

Assessment teams have exploited insufficient monitoring to gain access to assessed networks. For example:

  • An assessment team observed an organization with host-based monitoring, but no network monitoring. Host-based monitoring informs defensive teams about adverse activities on singular hosts and network monitoring informs about adverse activities traversing hosts [TA0008]. In this example, the organization could identify infected hosts but could not identify where the infection was coming from, and thus could not stop future lateral movement and infections.
  • An assessment team gained persistent deep access to a large organization with a mature cyber posture. The organization did not detect the assessment team’s lateral movement, persistence, and command and control (C2) activity, including when the team attempted noisy activities to trigger a security response. For more information on this activity, see CSA CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks.[13]

4. Lack of Network Segmentation

Network segmentation separates portions of the network with security boundaries. Lack of network segmentation leaves no security boundaries between the user, production, and critical system networks. Insufficient network segmentation allows an actor who has compromised a resource on the network to move laterally across a variety of systems uncontested. Lack of network segregation additionally leaves organizations significantly more vulnerable to potential ransomware attacks and post-exploitation techniques.

Lack of segmentation between IT and operational technology (OT) environments places OT environments at risk. For example, assessment teams have often gained access to OT networks—despite prior assurance that the networks were fully air gapped, with no possible connection to the IT network—by finding special purpose, forgotten, or even accidental network connections [T1199].

5. Poor Patch Management

Vendors release patches and updates to address security vulnerabilities. Poor patch management and network hygiene practices often enable adversaries to discover open attack vectors and exploit critical vulnerabilities. Poor patch management includes:

  • Lack of regular patching
  • Use of unsupported operating systems (OSs) and outdated firmware
Lack of Regular Patching

Failure to apply the latest patches can leave a system open to compromise from publicly available exploits. Due to their ease of discovery—via vulnerability scanning [T1595.002] and open source research [T1592]—and exploitation, these systems are immediate targets for adversaries. Allowing critical vulnerabilities to remain on production systems without applying their corresponding patches significantly increases the attack surface. Organizations should prioritize patching known exploited vulnerabilities in their environments.[2]

Assessment teams have observed threat actors exploiting many CVEs in public-facing applications [T1190], including:

  • CVE-2019-18935 in an unpatched instance of Telerik® UI for ASP.NET running on a Microsoft IIS server.[14]
  • CVE-2021-44228 (Log4Shell) in an unpatched VMware® Horizon server.[15]
  • CVE-2022-24682, CVE-2022-27924, and CVE-2022-27925 chained with CVE-2022-37042, or CVE-2022-30333 in an unpatched Zimbra® Collaboration Suite.[16]
Use of Unsupported OSs and Outdated Firmware

Using software or hardware that is no longer supported by the vendor poses a significant security risk because new and existing vulnerabilities are no longer patched. Malicious actors can exploit vulnerabilities in these systems to gain unauthorized access, compromise sensitive data, and disrupt operations [T1210].

Assessment teams frequently observe organizations using unsupported Windows operating systems without updates MS17-010 and MS08-67. These updates, released years ago, address critical remote code execution vulnerabilities.[17],[18]

6. Bypass of System Access Controls

A malicious actor can bypass system access controls by compromising alternate authentication methods in an environment. If a malicious actor can collect hashes in a network, they can use the hashes to authenticate using non-standard means, such as pass-the-hash (PtH) [T1550.002]. By mimicking accounts without the clear-text password, an actor can expand and fortify their access without detection. Kerberoasting is also one of the most time-efficient ways to elevate privileges and move laterally throughout an organization’s network.

7. Weak or Misconfigured MFA Methods

Misconfigured Smart Cards or Tokens

Some networks (generally government or DoD networks) require accounts to use smart cards or tokens. Multifactor requirements can be misconfigured so the password hashes for accounts never change. Even though the password itself is no longer used—because the smart card or token is required instead—there is still a password hash for the account that can be used as an alternative credential for authentication. If the password hash never changes, once a malicious actor has an account’s password hash [T1111], the actor can use it indefinitely, via the PtH technique for as long as that account exists.

Lack of Phishing-Resistant MFA

Some forms of MFA are vulnerable to phishing, “push bombing” [T1621], exploitation of Signaling System 7 (SS7) protocol vulnerabilities, and/or “SIM swap” techniques. These attempts, if successful, may allow a threat actor to gain access to MFA authentication credentials or bypass MFA and access the MFA-protected systems. (See CISA’s Fact Sheet Implementing Phishing-Resistant MFA for more information.)[3]

For example, assessment teams have used voice phishing to convince users to provide missing MFA information [T1598]. In one instance, an assessment team knew a user’s main credentials, but their login attempts were blocked by MFA requirements. The team then masqueraded as IT staff and convinced the user to provide the MFA code over the phone, allowing the team to complete their login attempt and gain access to the user’s email and other organizational resources.

8. Insufficient ACLs on Network Shares and Services

Data shares and repositories are primary targets for malicious actors. Network administrators may improperly configure ACLs to allow for unauthorized users to access sensitive or administrative data on shared drives.

Actors can use commands, open source tools, or custom malware to look for shared folders and drives [T1135].

  • In one compromise, a team observed actors use the net share command—which displays information about shared resources on the local computer—and the ntfsinfo command to search network shares on compromised computers. In the same compromise, the actors used a custom tool, CovalentStealer, which is designed to identify file shares on a system, categorize the files [T1083], and upload the files to a remote server [TA0010].[19],[20]
  • Ransomware actors have used the SoftPerfect® Network Scanner, netscan.exe—which can ping computers [T1018], scan ports [T1046], and discover shared folders—and SharpShares to enumerate accessible network shares in a domain.[21],[22]

Malicious actors can then collect and exfiltrate the data from the shared drives and folders. They can then use the data for a variety of purposes, such as extortion of the organization or as intelligence when formulating intrusion plans for further network compromise. Assessment teams routinely find sensitive information on network shares [T1039] that could facilitate follow-on activity or provide opportunities for extortion. Teams regularly find drives containing cleartext credentials [T1552] for service accounts, web applications, and even domain administrators.

Even when further access is not directly obtained from credentials in file shares, there can be a treasure trove of information for improving situational awareness of the target network, including the network’s topology, service tickets, or vulnerability scan data. In addition, teams regularly identify sensitive data and PII on shared drives (e.g., scanned documents, social security numbers, and tax returns) that could be used for extortion or social engineering of the organization or individuals.

9. Poor Credential Hygiene

Poor credential hygiene facilitates threat actors in obtaining credentials for initial access, persistence, lateral movement, and other follow-on activity, especially if phishing-resistant MFA is not enabled. Poor credential hygiene includes:

  • Easily crackable passwords
  • Cleartext password disclosure
Easily Crackable Passwords

Easily crackable passwords are passwords that a malicious actor can guess within a short time using relatively inexpensive computing resources. The presence of easily crackable passwords on a network generally stems from a lack of password length (i.e., shorter than 15 characters) and randomness (i.e., is not unique or can be guessed). This is often due to lax requirements for passwords in organizational policies and user training. A policy that only requires short and simple passwords leaves user passwords susceptible to password cracking. Organizations should provide or allow employee use of password managers to enable the generation and easy use of secure, random passwords for each account.

Often, when a credential is obtained, it is a hash (one-way encryption) of the password and not the password itself. Although some hashes can be used directly with PtH techniques, many hashes need to be cracked to obtain usable credentials. The cracking process takes the captured hash of the user’s plaintext password and leverages dictionary wordlists and rulesets, often using a database of billions of previously compromised passwords, in an attempt to find the matching plaintext password [T1110.002].

One of the primary ways to crack passwords is with the open source tool, Hashcat, combined with password lists obtained from publicly released password breaches. Once a malicious actor has access to a plaintext password, they are usually limited only by the account’s permissions. In some cases, the actor may be restricted or detected by advanced defense-in-depth and zero trust implementations as well, but this has been a rare finding in assessments thus far.

Assessment teams have cracked password hashes for NTLM users, Kerberos service account tickets, NetNTLMv2, and PFX stores [T1555], enabling the team to elevate privileges and move laterally within networks. In 12 hours, one team cracked over 80% of all users’ passwords in an Active Directory, resulting in hundreds of valid credentials.

Cleartext Password Disclosure

Storing passwords in cleartext is a serious security risk. A malicious actor with access to files containing cleartext passwords [T1552.001] could use these credentials to log into the affected applications or systems under the guise of a legitimate user. Accountability is lost in this situation as any system logs would record valid user accounts accessing applications or systems.

Malicious actors search for text files, spreadsheets, documents, and configuration files in hopes of obtaining cleartext passwords. Assessment teams frequently discover cleartext passwords, allowing them to quickly escalate the emulated intrusion from the compromise of a regular domain user account to that of a privileged account, such as a Domain or Enterprise Administrator. A common tool used for locating cleartext passwords is the open source tool, Snaffler.[23]

10. Unrestricted Code Execution

If unverified programs are allowed to execute on hosts, a threat actor can run arbitrary, malicious payloads within a network.

Malicious actors often execute code after gaining initial access to a system. For example, after a user falls for a phishing scam, the actor usually convinces the victim to run code on their workstation to gain remote access to the internal network. This code is usually an unverified program that has no legitimate purpose or business reason for running on the network.

Assessment teams and malicious actors frequently leverage unrestricted code execution in the form of executables, dynamic link libraries (DLLs), HTML applications, and macros (scripts used in office automation documents) [T1059.005] to establish initial access, persistence, and lateral movement. In addition, actors often use scripting languages [T1059] to obscure their actions [T1027.010] and bypass allowlisting—where organizations restrict applications and other forms of code by default and only allow those that are known and trusted. Further, actors may load vulnerable drivers and then exploit the drivers’ known vulnerabilities to execute code in the kernel with the highest level of system privileges to completely compromise the device [T1068].

MITIGATIONS

Network Defenders

NSA and CISA recommend network defenders implement the recommendations that follow to mitigate the issues identified in this advisory. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST) as well as with the MITRE ATT&CK Enterprise Mitigations and MITRE D3FEND frameworks.

The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.[24]

Mitigate Default Configurations of Software and Applications
MisconfigurationRecommendations for Network Defenders
Default configurations of software and applicationsModify the default configuration of applications and appliances before deployment in a production environment [M1013],[D3-ACH]. Refer to hardening guidelines provided by the vendor and related cybersecurity guidance (e.g., DISA’s Security Technical Implementation Guides (STIGs) and configuration guides).[25],[26],[27]
Default configurations of software and applications: Default CredentialsChange or disable vendor-supplied default usernames and passwords of services, software, and equipment when installing or commissioning [CPG 2.A]. When resetting passwords, enforce the use of “strong” passwords (i.e., passwords that are more than 15 characters and random [CPG 2.B]) and follow hardening guidelines provided by the vendor, STIGsNSA, and/or NIST [M1027],[D3-SPP].[25],[26],[28],[29]
Default service permissions and configuration settings: Insecure Active Directory Certificate ServicesEnsure the secure configuration of ADCS implementations. Regularly update and patch the controlling infrastructure (e.g., for CVE-2021-36942), employ monitoring and auditing mechanisms, and implement strong access controls to protect the infrastructure.If not needed, disable web-enrollment in ADCS servers. See Microsoft: Uninstall-AdcsWebEnrollment (ADCSDeployment) for guidance.[30]If web enrollment is needed on ADCS servers:Enable Extended Protection for Authentication (EPA) for Client Authority Web Enrollment. This is done by choosing the “Required” option. For guidance, see Microsoft: KB5021989: Extended Protection for Authentication.[31]Enable “Require SSL” on the ADCS server.Disable NTLM on all ADCS servers. For guidance, see Microsoft: Network security Restrict NTLM in this domain – Windows Security | Microsoft Learn and Network security Restrict NTLM Incoming NTLM traffic – Windows Security.[32],[33]Disable SAN for UPN Mapping. For guidance see, Microsoft: How to disable the SAN for UPN mapping – Windows Server. Instead, smart card authentication can use the altSecurityIdentities attribute for explicit mapping of certificates to accounts more securely.[34]Review all permissions on the ADCS templates on applicable servers. Restrict enrollment rights to only those users or groups that require it. Disable the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag from templates to prevent users from supplying and editing sensitive security settings within these templates. Enforce manager approval for requested certificates. Remove FullControlWriteDacl, and Write property permissions from low-privileged groups, such as domain users, to certificate template objects.
Default service permissions and configuration settings: Insecure legacy protocols/servicesDetermine if LLMNR and NetBIOS are required for essential business operations.If not required, disable LLMNR and NetBIOS in local computer security settings or by group policy.
Default service permissions and configuration settings: Insecure SMB serviceRequire SMB signing for both SMB client and server on all systems.[25] This should prevent certain adversary-in-the-middle and pass-the-hash techniques. For more information on SMB signing, see Microsoft: Overview of Server Message Block Signing. [35] Note: Beginning in Microsoft Windows 11 Insider Preview Build 25381, Windows requires SMB signing for all communications.[36]
Mitigate Improper Separation of User/Administrator Privilege
MisconfigurationRecommendations for Network Defenders
Improper separation of user/administrator privilege:Excessive account privileges,Elevated service account permissions, andNon-essential use of elevated accountsImplement authentication, authorization, and accounting (AAA) systems [M1018] to limit actions users can perform, and review logs of user actions to detect unauthorized use and abuse. Apply least privilege principles to user accounts and groups allowing only the performance of authorized actions.Audit user accounts and remove those that are inactive or unnecessary on a routine basis [CPG 2.D]. Limit the ability for user accounts to create additional accounts.Restrict use of privileged accounts to perform general tasks, such as accessing emails and browsing the Internet [CPG 2.E],[D3-UAP]. See NSA Cybersecurity Information Sheet (CSI) Defend Privileges and Accounts for more information.[37]Limit the number of users within the organization with an identity and access management (IAM) role that has administrator privileges. Strive to reduce all permanent privileged role assignments, and conduct periodic entitlement reviews on IAM users, roles, and policies.Implement time-based access for privileged accounts. For example, the just-in-time access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model) by setting network-wide policy to automatically disable admin accounts at the Active Directory level. As needed, individual users can submit requests through an automated process that enables access to a system for a set timeframe. In cloud environments, just-in-time elevation is also appropriate and may be implemented using per-session federated claims or privileged access management tools.Restrict domain users from being in the local administrator group on multiple systems.Run daemonized applications (services) with non-administrator accounts when possible.Only configure service accounts with the permissions necessary for the services they control to operate.Disable unused services and implement ACLs to protect services.
Mitigate Insufficient Internal Network Monitoring
MisconfigurationRecommendations for Network Defenders
Insufficient internal network monitoringEstablish a baseline of applications and services, and routinely audit their access and use, especially for administrative activity [D3-ANAA]. For instance, administrators should routinely audit the access lists and permissions for of all web applications and services [CPG 2.O],[M1047]. Look for suspicious accounts, investigate them, and remove accounts and credentials, as appropriate, such as accounts of former staff.[39]Establish a baseline that represents an organization’s normal traffic activity, network performance, host application activity, and user behavior; investigate any deviations from that baseline [D3-NTCD],[D3-CSPP],[D3-UBA].[40]Use auditing tools capable of detecting privilege and service abuse opportunities on systems within an enterprise and correct them [M1047].Implement a security information and event management (SIEM) system to provide log aggregation, correlation, querying, visualization, and alerting from network endpoints, logging systems, endpoint and detection response (EDR) systems and intrusion detection systems (IDS) [CPG 2.T],[D3-NTA].
Mitigate Lack of Network Segmentation
MisconfigurationRecommendations for Network Defenders
Lack of network segmentationImplement next-generation firewalls to perform deep packet filtering, stateful inspection, and application-level packet inspection [D3-NTF]. Deny or drop improperly formatted traffic that is incongruent with application-specific traffic permitted on the network. This practice limits an actor’s ability to abuse allowed application protocols. The practice of allowlisting network applications does not rely on generic ports as filtering criteria, enhancing filtering fidelity. For more information on application-aware defenses, see NSA CSI Segment Networks and Deploy Application-Aware Defenses.[41]Engineer network segments to isolate critical systems, functions, and resources [CPG 2.F],[D3-NI]. Establish physical and logical segmentation controls, such as virtual local area network (VLAN) configurations and properly configured access control lists (ACLs) on infrastructure devices [M1030]. These devices should be baselined and audited to prevent access to potentially sensitive systems and information. Leverage properly configured Demilitarized Zones (DMZs) to reduce service exposure to the Internet.[42],[43],[44]Implement separate Virtual Private Cloud (VPC) instances to isolate essential cloud systems. Where possible, implement Virtual Machines (VM) and Network Function Virtualization (NFV) to enable micro-segmentation of networks in virtualized environments and cloud data centers. Employ secure VM firewall configurations in tandem with macro segmentation.
Mitigate Poor Patch Management
MisconfigurationRecommendations for Network Defenders
Poor patch management: Lack of regular patchingEnsure organizations implement and maintain an efficient patch management process that enforces the use of up-to-date, stable versions of OSs, browsers, and software [M1051],[D3-SU].[45]Update software regularly by employing patch management for externally exposed applications, internal enterprise endpoints, and servers. Prioritize patching known exploited vulnerabilities.[2]Automate the update process as much as possible and use vendor-provided updates. Consider using automated patch management tools and software update tools.Where patching is not possible due to limitations, segment networks to limit exposure of the vulnerable system or host.
Poor patch management: Use of unsupported OSs and outdated firmwareEvaluate the use of unsupported hardware and software and discontinue use as soon as possible. If discontinuing is not possible, implement additional network protections to mitigate the risk.[45]Patch the Basic Input/Output System (BIOS) and other firmware to prevent exploitation of known vulnerabilities.
Mitigate Bypass of System Access Controls
MisconfigurationRecommendations for Network Defenders
Bypass of system access controlsLimit credential overlap across systems to prevent credential compromise and reduce a malicious actor’s ability to move laterally between systems [M1026],[D3-CH]. Implement a method for monitoring non-standard logon events through host log monitoring [CPG 2.G].Implement an effective and routine patch management process. Mitigate PtH techniques by applying patch KB2871997 to Windows 7 and newer versions to limit default access of accounts in the local administrator group [M1051],[D3-SU].[46]Enable the PtH mitigations to apply User Account Control (UAC) restrictions to local accounts upon network logon [M1052],[D3-UAP].Deny domain users the ability to be in the local administrator group on multiple systems [M1018],[D3-UAP].Limit workstation-to-workstation communications. All workstation communications should occur through a server to prevent lateral movement [M1018],[D3-UAP].Use privileged accounts only on systems requiring those privileges [M1018],[D3-UAP]. Consider using dedicated Privileged Access Workstations for privileged accounts to better isolate and protect them.[37]
Mitigate Weak or Misconfigured MFA Methods
MisconfigurationRecommendations for Network Defenders
Weak or misconfigured MFA methods: Misconfigured smart cards or tokens In Windows environments:Disable the use of New Technology LAN Manager (NTLM) and other legacy authentication protocols that are susceptible to PtH due to their use of password hashes [M1032],[D3-MFA]. For guidance, see Microsoft: Network security Restrict NTLM in this domain – Windows Security | Microsoft Learn and Network security Restrict NTLM Incoming NTLM traffic – Windows Security.[32],[33]Use built-in functionality via Windows Hello for Business or Group Policy Objects (GPOs) to regularly re-randomize password hashes associated with smartcard-required accounts. Ensure that the hashes are changed at least as often as organizational policy requires passwords to be changed [M1027],[D3-CRO]. Prioritize upgrading any environments that cannot utilize this built-in functionality.As a longer-term effort, implement cloud-primary authentication solution using modern open standards. See CISA’s Secure Cloud Business Applications (SCuBA) Hybrid Identity Solutions Architecture for more information.[47] Note: this document is part of CISA’s Secure Cloud Business Applications (SCuBA) project, which provides guidance for FCEB agencies to secure their cloud business application environments and to protect federal information that is created, accessed, shared, and stored in those environments. Although tailored to FCEB agencies, the project’s guidance is applicable to all organizations.[48]
Weak or misconfigured MFA methods: Lack of phishing-resistant MFAEnforce phishing-resistant MFA universally for access to sensitive data and on as many other resources and services as possible [CPG 2.H].[3],[49]
Mitigate Insufficient ACLs on Network Shares and Services
MisconfigurationRecommendations for Network Defenders
Insufficient ACLs on network shares and servicesImplement secure configurations for all storage devices and network shares that grant access to authorized users only.Apply the principal of least privilege to important information resources to reduce risk of unauthorized data access and manipulation.Apply restrictive permissions to files and directories, and prevent adversaries from modifying ACLs [M1022],[D3-LFP].Set restrictive permissions on files and folders containing sensitive private keys to prevent unintended access [M1022],[D3-LFP].Enable the Windows Group Policy security setting, “Do Not Allow Anonymous Enumeration of Security Account Manager (SAM) Accounts and Shares,” to limit users who can enumerate network shares.
Mitigate Poor Credential Hygiene
MisconfigurationRecommendations for Network Defenders
Poor credential hygiene: easily crackable passwords Follow National Institute of Standards and Technologies (NIST) guidelines when creating password policies to enforce use of “strong” passwords that cannot be cracked [M1027],[D3-SPP].[29] Consider using password managers to generate and store passwords.Do not reuse local administrator account passwords across systems. Ensure that passwords are “strong” and unique [CPG 2.B],[M1027],[D3-SPP].Use “strong” passphrases for private keys to make cracking resource intensive. Do not store credentials within the registry in Windows systems. Establish an organizational policy that prohibits password storage in files.Ensure adequate password length (ideally 25+ characters) and complexity requirements for Windows service accounts and implement passwords with periodic expiration on these accounts [CPG 2.B],[M1027],[D3-SPP]. Use Managed Service Accounts, when possible, to manage service account passwords automatically.
Poor credential hygiene: cleartext password disclosure Implement a review process for files and systems to look for cleartext account credentials. When credentials are found, remove, change, or encrypt them [D3-FE]. Conduct periodic scans of server machines using automated tools to determine whether sensitive data (e.g., personally identifiable information, protected health information) or credentials are stored. Weigh the risk of storing credentials in password stores and web browsers. If system, software, or web browser credential disclosure is of significant concern, technical controls, policy, and user training may prevent storage of credentials in improper locations.Store hashed passwords using Committee on National Security Systems Policy (CNSSP)-15 and Commercial National Security Algorithm Suite (CNSA) approved algorithms.[50],[51]Consider using group Managed Service Accounts (gMSAs) or third-party software to implement secure password-storage applications.
Mitigate Unrestricted Code Execution
MisconfigurationRecommendations for Network Defenders
Unrestricted code executionEnable system settings that prevent the ability to run applications downloaded from untrusted sources.[52]Use application control tools that restrict program execution by default, also known as allowlisting [D3-EAL]. Ensure that the tools examine digital signatures and other key attributes, rather than just relying on filenames, especially since malware often attempts to masquerade as common Operating System (OS) utilities [M1038]. Explicitly allow certain .exe files to run, while blocking all others by default.Block or prevent the execution of known vulnerable drivers that adversaries may exploit to execute code in kernel mode. Validate driver block rules in audit mode to ensure stability prior to production deployment [D3-OSM].Constrain scripting languages to prevent malicious activities, audit script logs, and restrict scripting languages that are not used in the environment [D3-SEA]. See joint Cybersecurity Information Sheet: Keeping PowerShell: Security Measures to Use and Embrace.[53]Use read-only containers and minimal images, when possible, to prevent the running of commands.Regularly analyze border and host-level protections, including spam-filtering capabilities, to ensure their continued effectiveness in blocking the delivery and execution of malware [D3-MA]. Assess whether HTML Application (HTA) files are used for business purposes in your environment; if HTAs are not used, remap the default program for opening them from mshta.exe to notepad.exe.

Software Manufacturers

NSA and CISA recommend software manufacturers implement the recommendations in Table 11 to reduce the prevalence of misconfigurations identified in this advisory. These mitigations align with tactics provided in joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default. NSA and CISA strongly encourage software manufacturers apply these recommendations to ensure their products are secure “out of the box” and do not require customers to spend additional resources making configuration changes, performing monitoring, and conducting routine updates to keep their systems secure.[1]

MisconfigurationRecommendations for Software Manufacturers
Default configurations of software and applicationsEmbed security controls into product architecture from the start of development and throughout the entire SDLC by following best practices in NIST’s Secure Software Development Framework (SSDF), SP 800-218.[54]Provide software with security features enabled “out of the box” and accompanied with “loosening” guides instead of hardening guides. “Loosening” guides should explain the business risk of decisions in plain, understandable language.
Default configurations of software and applications: Default credentialsEliminate default passwords: Do not provide software with default passwords that are universally shared. To eliminate default passwords, require administrators to set a “strong” password [CPG 2.B] during installation and configuration.
Default configurations of software and applications: Default service permissions and configuration settingsConsider the user experience consequences of security settings: Each new setting increases the cognitive burden on end users and should be assessed in conjunction with the business benefit it derives. Ideally, a setting should not exist; instead, the most secure setting should be integrated into the product by default. When configuration is necessary, the default option should be broadly secure against common threats.
Improper separation of user/administrator privilege:Excessive account privileges,Elevated service account permissions, andNon-essential use of elevated accountsDesign products so that the compromise of a single security control does not result in compromise of the entire system. For example, ensuring that user privileges are narrowly provisioned by default and ACLs are employed can reduce the impact of a compromised account. Also, software sandboxing techniques can quarantine a vulnerability to limit compromise of an entire application.Automatically generate reports for:Administrators of inactive accounts. Prompt administrators to set a maximum inactive time and automatically suspend accounts that exceed that threshold.Administrators of accounts with administrator privileges and suggest ways to reduce privilege sprawl.Automatically alert administrators of infrequently used services and provide recommendations for disabling them or implementing ACLs.
Insufficient internal network monitoring Provide high-quality audit logs to customers at no extra charge. Audit logs are crucial for detecting and escalating potential security incidents. They are also crucial during an investigation of a suspected or confirmed security incident. Consider best practices such as providing easy integration with a security information and event management (SIEM) system with application programming interface (API) access that uses coordinated universal time (UTC), standard time zone formatting, and robust documentation techniques.
Lack of network segmentationEnsure products are compatible with and tested in segmented network environments.
Poor patch management: Lack of regular patchingTake steps to eliminate entire classes of vulnerabilities by embedding security controls into product architecture from the start of development and throughout the SDLC by following best practices in NIST’s SSDFSP 800-218.[54] Pay special attention to:Following secure coding practices [SSDF PW 5.1]. Use memory-safe programming languages where possible, parametrized queries, and web template languages.Conducting code reviews [SSDF PW 7.2, RV 1.2] against peer coding standards, checking for backdoors, malicious content, and logic flaws.Testing code to identify vulnerabilities and verify compliance with security requirements [SSDF PW 8.2].Ensure that published CVEs include root cause or common weakness enumeration (CWE) to enable industry-wide analysis of software security design flaws.
Poor patch management: Use of unsupported operating OSs and outdated firmwareCommunicate the business risk of using unsupported OSs and firmware in plain, understandable language.
Bypass of system access controlsProvide sufficient detail in audit records to detect bypass of system controls and queries to monitor audit logs for traces of such suspicious activity (e.g., for when an essential step of an authentication or authorization flow is missing).
Weak or Misconfigured MFA Methods: Misconfigured Smart Cards or Tokens Fully support MFA for all users, making MFA the default rather than an opt-in feature. Utilize threat modeling for authentication assertions and alternate credentials to examine how they could be abused to bypass MFA requirements.
Weak or Misconfigured MFA Methods: Lack of phishing-resistant MFAMandate MFA, ideally phishing-resistant, for privileged users and make MFA a default rather than an opt-in feature.[3]
Insufficient ACL on network shares and servicesEnforce use of ACLs with default ACLs only allowing the minimum access needed, along with easy-to-use tools to regularly audit and adjust ACLs to the minimum access needed.
Poor credential hygiene: easily crackable passwords Allow administrators to configure a password policy consistent with NIST’s guidelines—do not require counterproductive restrictions such as enforcing character types or the periodic rotation of passwords.[29]Allow users to use password managers to effortlessly generate and use secure, random passwords within products.
Poor credential hygiene: cleartext password disclosureSalt and hash passwords using a secure hashing algorithm with high computational cost to make brute force cracking more difficult.
Unrestricted code executionSupport execution controls within operating systems and applications “out of the box” by default at no extra charge for all customers, to limit malicious actors’ ability to abuse functionality or launch unusual applications without administrator or informed user approval.

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, NSA and CISA recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. NSA and CISA recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

  1. Select an ATT&CK technique described in this advisory (see Table 12–Table 21).
  2. Align your security technologies against the technique.
  3. Test your technologies against the technique.
  4. Analyze your detection and prevention technologies’ performance.
  5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
  6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

CISA and NSA recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

LEARN FROM HISTORY

The misconfigurations described above are all too common in assessments and the techniques listed are standard ones leveraged by multiple malicious actors, resulting in numerous real network compromises. Learn from the weaknesses of others and implement the mitigations above properly to protect the network, its sensitive information, and critical missions.

WORKS CITED

[1]   Joint Guide: Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default (2023), https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf
[2]   CISA, Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog
[3]   CISA, Implementing Phishing-Resistant MFA, https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
[4]   MITRE, ATT&CK for Enterprise, https://attack.mitre.org/versions/v13/matrices/enterprise/
[5]   MITRE, D3FEND, https://d3fend.mitre.org/
[6]   CISA, Best Practices for MITRE ATT&CK Mapping, https://www.cisa.gov/news-events/news/best-practices-mitre-attckr-mapping
[7]   CISA, Decider Tool, https://github.com/cisagov/Decider/
[8]   CISA, Cyber Assessment Fact Sheet, https://www.cisa.gov/sites/default/files/publications/VM_Assessments_Fact_Sheet_RVA_508C.pdf
[9]   Joint CSA: Weak Security Controls and Practices Routinely Exploited for Initial Access, https://media.defense.gov/2022/May/17/2002998718/-1/-1/0/CSA_WEAK_SECURITY_CONTROLS_PRACTICES_EXPLOITED_FOR_INITIAL_ACCESS.PDF
[10]  Microsoft KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS), https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429
[11]  Raj Chandel, Domain Escalation: PetitPotam NTLM Relay to ADCS Endpoints, https://www.hackingarticles.in/domain-escalation-petitpotam-ntlm-relay-to-adcs-endpoints/
[12]  SpecterOps – Will Schroeder, Certified Pre-Owned, https://posts.specterops.io/certified-pre-owned-d95910965cd2
[13]  CISA, CSA: CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks, https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-059a
[14]  Joint CSA: Threat Actors Exploit Progress Telerik Vulnerabilities in Multiple U.S. Government IIS Servers, https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-074a
[15]  Joint CSA: Iranian Government-Sponsored APT Actors Compromise Federal Network, Deploy Crypto Miner, Credential Harvester, https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-320a
[16]  Joint CSA: Threat Actors Exploiting Multiple CVEs Against Zimbra Collaboration Suite, https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-228a
[17]  Microsoft, How to verify that MS17-010 is installed, https://support.microsoft.com/en-us/topic/how-to-verify-that-ms17-010-is-installed-f55d3f13-7a9c-688c-260b-477d0ec9f2c8
[18]  Microsoft, Microsoft Security Bulletin MS08-067 – Critical Vulnerability in Server Service Could Allow Remote Code Execution (958644), https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2008/ms08-067
[19]  Joint CSA: Impacket and Exfiltration Tool Used to Steal Sensitive Information from Defense Industrial Base Organization, https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-277a
[20]  CISA, Malware Analysis Report: 10365227.r1.v1, https://www.cisa.gov/sites/default/files/2023-06/mar-10365227.r1.v1.clear_.pdf
[21]  Joint CSA: #StopRansomware: BianLian Ransomware Group, https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-136a
[22]  CISA Analysis Report: FiveHands Ransomware, https://www.cisa.gov/news-events/analysis-reports/ar21-126a
[23]  Snaffler, https://github.com/SnaffCon/Snaffler
[24]  CISA, Cross-Sector Cybersecurity Performance Goals, https://www.cisa.gov/cross-sector-cybersecurity-performance-goals
[25]  Defense Information Systems Agency (DISA), Security Technical Implementation Guides (STIGs), https://public.cyber.mil/stigs/
[26]  NSA, Network Infrastructure Security Guide, https://media.defense.gov/2022/Jun/15/2003018261/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDE_20220615.PDF
[27]  NSA, Actively Manage Systems and Configurations, https://media.defense.gov/2019/Sep/09/2002180326/-1/-1/0/Actively%20Manage%20Systems%20and%20Configurations.docx%20-%20Copy.pdf
[28]  NSA, Cybersecurity Advisories & Guidance, https://www.nsa.gov/cybersecurity-guidance
[29]  National Institute of Standards and Technologies (NIST), NIST SP 800-63B: Digital Identity Guidelines: Authentication and Lifecycle Management, https://csrc.nist.gov/pubs/sp/800/63/b/upd2/final
[30]  Microsoft, Uninstall-AdcsWebEnrollment, https://learn.microsoft.com/en-us/powershell/module/adcsdeployment/uninstall-adcswebenrollment
[31]  Microsoft, KB5021989: Extended Protection for Authentication, https://support.microsoft.com/en-au/topic/kb5021989-extended-protection-for-authentication-1b6ea84d-377b-4677-a0b8-af74efbb243f
[32]  Microsoft, Network security: Restrict NTLM: NTLM authentication in this domain, https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain
[33]  Microsoft, Network security: Restrict NTLM: Incoming NTLM traffic, https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic
[34]  Microsoft, How to disable the Subject Alternative Name for UPN mapping, https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/disable-subject-alternative-name-upn-mapping
[35]  Microsoft, Overview of Server Message Block signing, https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-server-message-block-signing
[36]  Microsoft, SMB signing required by default in Windows Insider, https://aka.ms/SmbSigningRequired
[37]  NSA, Defend Privileges and Accounts, https://media.defense.gov/2019/Sep/09/2002180330/-1/-1/0/Defend%20Privileges%20and%20Accounts%20-%20Copy.pdf
[38]  NSA, Advancing Zero Trust Maturity Throughout the User Pillar, https://media.defense.gov/2023/Mar/14/2003178390/-1/-1/0/CSI_Zero_Trust_User_Pillar_v1.1.PDF
[39]  NSA, Continuously Hunt for Network Intrusions, https://media.defense.gov/2019/Sep/09/2002180360/-1/-1/0/Continuously%20Hunt%20for%20Network%20Intrusions%20-%20Copy.pdf
[40]  Joint CSI: Detect and Prevent Web Shell Malware, https://media.defense.gov/2020/Jun/09/2002313081/-1/-1/0/CSI-DETECT-AND-PREVENT-WEB-SHELL-MALWARE-20200422.PDF
[41]  NSA, Segment Networks and Deploy Application-aware Defenses, https://media.defense.gov/2019/Sep/09/2002180325/-1/-1/0/Segment%20Networks%20and%20Deploy%20Application%20Aware%20Defenses%20-%20Copy.pdf
[42]  Joint CSA: NSA and CISA Recommend Immediate Actions to Reduce Exposure Across all Operational Technologies and Control Systems, https://media.defense.gov/2020/Jul/23/2002462846/-1/-1/0/OT_ADVISORY-DUAL-OFFICIAL-20200722.PDF
[43]  NSA, Stop Malicious Cyber Activity Against Connected Operational Technology, https://media.defense.gov/2021/Apr/29/2002630479/-1/-1/0/CSA_STOP-MCA-AGAINST-OT_UOO13672321.PDF
[44]  NSA, Performing Out-of-Band Network Management, https://media.defense.gov/2020/Sep/17/2002499616/-1/-1/0/PERFORMING_OUT_OF_BAND_NETWORK_MANAGEMENT20200911.PDF
[45]  NSA, Update and Upgrade Software Immediately, https://media.defense.gov/2019/Sep/09/2002180319/-1/-1/0/Update%20and%20Upgrade%20Software%20Immediately.docx%20-%20Copy.pdf
[46]  Microsoft, Microsoft Security Advisory 2871997: Update to Improve Credentials Protection and Management, https://learn.microsoft.com/en-us/security-updates/SecurityAdvisories/2016/2871997
[47]  CISA, Secure Cloud Business Applications Hybrid Identity Solutions Architecture, https://www.cisa.gov/sites/default/files/2023-03/csso-scuba-guidance_document-hybrid_identity_solutions_architecture-2023.03.22-final.pdf
[48]  CISA, Secure Cloud Business Applications (SCuBA) Project, https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project
[49]  NSA, Transition to Multi-factor Authentication, https://media.defense.gov/2019/Sep/09/2002180346/-1/-1/0/Transition%20to%20Multi-factor%20Authentication%20-%20Copy.pdf
[50]  Committee on National Security Systems (CNSS), CNSS Policy 15, https://www.cnss.gov/CNSS/issuances/Policies.cfm
[51]  NSA, NSA Releases Future Quantum-Resistant (QR) Algorithm Requirements for National Security Systems, https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/
[52]  NSA, Enforce Signed Software Execution Policies, https://media.defense.gov/2019/Sep/09/2002180334/-1/-1/0/Enforce%20Signed%20Software%20Execution%20Policies%20-%20Copy.pdf
[53]  Joint CSI: Keeping PowerShell: Security Measures to Use and Embrace, https://media.defense.gov/2022/Jun/22/2003021689/-1/-1/0/CSI_KEEPING_POWERSHELL_SECURITY_MEASURES_TO_USE_AND_EMBRACE_20220622.PDF
[54]  NIST, NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, https://csrc.nist.gov/publications/detail/sp/800-218/final

Disclaimer of Endorsement

The information and opinions contained in this document are provided “as is” and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Trademarks

Active Directory, Microsoft, and Windows are registered trademarks of Microsoft Corporation.
MITRE ATT&CK is registered trademark and MITRE D3FEND is a trademark of The MITRE Corporation.
SoftPerfect is a registered trademark of SoftPerfect Proprietary Limited Company.
Telerik is a registered trademark of Progress Software Corporation.
VMware is a registered trademark of VMWare, Inc.
Zimbra is a registered trademark of Synacor, Inc.

Purpose

This document was developed in furtherance of the authoring cybersecurity organizations’ missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.

Contact

Cybersecurity Report Feedback: CybersecurityReports@nsa.gov
General Cybersecurity Inquiries: Cybersecurity_Requests@nsa.gov 
Defense Industrial Base Inquiries and Cybersecurity Services: DIB_Defense@cyber.nsa.gov
Media Inquiries / Press Desk: 443-634-0721, MediaRelations@nsa.gov 

To report suspicious activity contact CISA’s 24/7 Operations Center at report@cisa.gov or (888) 282-0870. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact.

Appendix: MITRE ATT&CK Tactics and Techniques

See Table 12–Table 21 for all referenced threat actor tactics and techniques in this advisory.

Technique TitleIDUse
Active Scanning: Vulnerability ScanningT1595.002Malicious actors scan victims for vulnerabilities that be exploited for initial access.
Gather Victim Host InformationT1592Malicious actors gather information on victim client configurations and/or vulnerabilities through vulnerabilities scans and searching the web.
Gather Victim Identity Information: CredentialsT1589.001Malicious actors find default credentials through searching the web.
Phishing for InformationT1598Malicious actors masquerade as IT staff and convince a target user to provide their MFA code over the phone to gain access to email and other organizational resources.
Technique TitleIDUse
External Remote ServicesT1133Malicious actors use default credentials for VPN access to internal networks.
Valid Accounts: Default AccountsT1078.001Malicious actors gain authenticated access to devices by finding default credentials through searching the web.Malicious actors use default credentials for VPN access to internal networks, and default administrative credentials to gain access to web applications and databases.
Exploit Public-Facing ApplicationT1190Malicious actors exploit CVEs in Telerik UI, VM Horizon, Zimbra Collaboration Suite, and other applications for initial access to victim organizations.
PhishingT1566Malicious actors gain initial access to systems by phishing to entice end users to download and execute malicious payloads.
Trust RelationshipT1199Malicious actors gain access to OT networks despite prior assurance that the networks were fully air gapped, with no possible connection to the IT network, by finding special purpose, forgotten, or even accidental network connections.
Technique TitleIDUse
Software Deployment ToolsT1072Malicious actors use default or captured credentials on software deployment tools to execute code and move laterally.
User ExecutionT1204Malicious actors gain initial access to systems by phishing to entice end users to download and execute malicious payloads or to run code on their workstations.
Command and Scripting InterpreterT1059Malicious actors use scripting languages to obscure their actions and bypass allowlisting.
Command and Scripting Interpreter: Visual BasicT1059.005Malicious actors use macros for initial access, persistence, and lateral movement.
Technique TitleIDUse
Account ManipulationT1098Malicious actors reset built-in administrative accounts via predictable, forgotten password questions.
Technique TitleIDUse
Valid AccountsT1078Malicious actors analyze topical and nested Active Directory groups to find privileged accounts to target.
Valid Accounts: Domain AccountsT1078.002Malicious actors obtain loaded domain credentials from printers and scanners and use them to move laterally from the network device.
Exploitation for Privilege EscalationT1068Malicious actors load vulnerable drivers and then exploit their known vulnerabilities to execute code in the kernel with the highest level of system privileges to completely compromise the device.
Technique TitleIDUse
Obfuscated Files or Information: Command ObfuscationT1027.010Malicious actors often use scripting languages to obscure their actions.
Technique TitleIDUse
Adversary-in-the-MiddleT1557Malicious actors force a device to communicate through actor-controlled systems, so they can collect information or perform additional actions.
Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB RelayT1557.001Malicious actors execute spoofing, poisoning, and relay techniques if Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service (NBT-NS), and Server Message Block (SMB) services are enabled in a network.
Brute Force: Password CrackingT1110.002Malicious actors capture user hashes and leverage dictionary wordlists and rulesets to extract cleartext passwords.
Credentials from Password StoresT1555Malicious actors gain access to and crack credentials from PFX stores, enabling elevation of privileges and lateral movement within networks.
Multi-Factor Authentication InterceptionT1111Malicious actors can obtain password hashes for accounts enabled for MFA with smart codes or tokens and use the hash via PtH techniques.
Multi-Factor Authentication Request GenerationT1621Malicious actors use “push bombing” against non-phishing resistant MFA to induce “MFA fatigue” in victims, gaining access to MFA authentication credentials or bypassing MFA, and accessing the MFA-protected system.
Steal Application Access TokenT1528Malicious actors can steal administrator account credentials and the authentication token generated by Active Directory when the account is logged into a compromised host.
Steal or Forge Authentication CertificatesT1649Unauthenticated malicious actors coerce an ADCS server to authenticate to an actor-controlled server, and then relay that authentication to the web certificate enrollment application to obtain a trusted illegitimate certificate.
Steal or Forge Kerberos Tickets: Golden TicketT1558.001Malicious actors who have obtained authentication certificates can use the certificate for Active Directory authentication to obtain a Kerberos TGT.
Steal or Forge Kerberos Tickets: KerberoastingT1558.003Malicious actors obtain and abuse valid Kerberos TGTs to elevate privileges and laterally move throughout an organization’s network.
Unsecured Credentials: Credentials in FilesT1552.001Malicious actors find cleartext credentials that organizations or individual users store in spreadsheets, configuration files, and other documents.
Technique TitleIDUse
Account DiscoveryT1087Malicious actors with valid domain credentials enumerate the AD to discover elevated accounts and where they are used.
File and Directory DiscoveryT1083Malicious actors use commands, such as net share, open source tools, such as SoftPerfect Network Scanner, or custom malware, such as CovalentStealer to discover and categorize files.Malicious actors search for text files, spreadsheets, documents, and configuration files in hopes of obtaining desired information, such as cleartext passwords.
Network Share DiscoveryT1135Malicious actors use commands, such as net share, open source tools, such as SoftPerfect Network Scanner, or custom malware, such as CovalentStealer, to look for shared folders and drives.
Technique TitleIDUse
Exploitation of Remote ServicesT1210Malicious actors can exploit OS and firmware vulnerabilities to gain unauthorized network access, compromise sensitive data, and disrupt operations.
Remote Services: SMB/Windows Admin SharesT1021.002If SMB signing is not enforced, malicious actors can use name resolution poisoning to access remote systems.
Use Alternate Authentication Material: Application Access TokenT1550.001Malicious actors with stolen administrator account credentials and AD authentication tokens can use them to operate with elevated permissions throughout the domain.
Use Alternate Authentication Material: Pass the HashT1550.002Malicious actors collect hashes in a network and authenticate as a user without having access to the user’s cleartext password.
Technique TitleIDUse
Data from Network Shared DriveT1039Malicious actors find sensitive information on network shares that could facilitate follow-on activity or provide opportunities for extortion.

Source :
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-278a

Top 5 Security Misconfigurations Causing Data Breaches in 2023

Edward Kost
updated May 15, 2023

Security misconfigurations are a common and significant cybersecurity issue that can leave businesses vulnerable to data breaches. According to the latest data breach investigation report by IBM and the Ponemon Institute, the average cost of a breach has peaked at US$4.35 million. Many data breaches are caused by avoidable errors like security misconfiguration. By following the tips in this article, you could identify and address a security error that could save you millions of dollars in damages.

Learn how UpGuard can help you detect data breach risks >

What is a Security Misconfiguration?

A security misconfiguration occurs when a system, application, or network device’s settings are not correctly configured, leaving it exposed to potential cyber threats. This could be due to default configurations left unchanged, unnecessary features enabled, or permissions set too broadly. Hackers often exploit these misconfigurations to gain unauthorized access to sensitive data, launch malware attacks, or carry out phishing attacks, among other malicious activities.

What Causes Security Misconfigurations?

Security misconfigurations can result from various factors, including human error, lack of awareness, and insufficient security measures. For instance, employees might configure systems without a thorough understanding of security best practices, security teams might overlook crucial security updates due to the growing complexity of cloud services and infrastructures.

Additionally, the rapid shift to remote work during the pandemic has increased the attack surface for cybercriminals, making it more challenging for security teams to manage and monitor potential vulnerabilities.

List of Common Types of Security Configurations Facilitating Data Breaches

Some common types of security misconfigurations include:

1. Default Settings

With the rise of cloud solutions such as Amazon Web Services (AWS) and Microsoft Azure, companies increasingly rely on these platforms to store and manage their data. However, using cloud services also introduces new security risks, such as the potential for misconfigured settings or unauthorized access.

A prominent example of insecure default software settings that could have facilitated a significant breach is the Microsoft Power Apps data leak incident of 2021. By default, Power Apps portal data feeds were set to be accessible to the public.

Unless developers specified for OData feeds to be set to private, virtually anyone could access the backend databases of applications built with Power Apps. UpGuard researchers located the exposure and notified Microsoft, who promptly addressed the leak. UpGuard’s detection helped Microsoft avoid a large-scale breach that could have potentially compromised 38 million records.

Read this whitepaper to learn how to prevent data breaches >

2. Unnecessary Features

Enabling features or services not required for a system’s operation can increase its attack surface, making it more vulnerable to threats. Some examples of unnecessary product features include remote administration tools, file-sharing services, and unused network ports. To mitigate data breach risks, organizations should conduct regular reviews of their systems and applications to identify and disable or remove features that are not necessary for their operations.

Additionally, organizations should practice the principle of least functionality, ensuring that systems are deployed with only the minimal set of features and services required for their specific use case.

3. Insecure Permissions

Overly permissive access controls can allow unauthorized users to access sensitive data or perform malicious actions. To address this issue, organizations should implement the principle of least privilege, granting users the minimum level of access necessary to perform their job functions. This can be achieved through proper role-based access control (RBAC) configurations and regular audits of user privileges. Additionally, organizations should ensure that sensitive data is appropriately encrypted both in transit and at rest, further reducing the risk of unauthorized access.

4. Outdated Software

Failing to apply security patches and updates can expose systems to known vulnerabilities. To protect against data breaches resulting from outdated software, organizations should have a robust patch management program in place. This includes regularly monitoring for available patches and updates, prioritizing their deployment based on the severity of the vulnerabilities being addressed, and verifying the successful installation of these patches.

Additionally, organizations should consider implementing automated patch management solutions and vulnerability scanning tools to streamline the patching process and minimize the risk of human error.

5. Insecure API Configurations

APIs that are not adequately secured can allow threat actors to access sensitive information or manipulate systems. API misconfigurations – like the one that led to T-Mobile’s 2023 data breach, are becoming more common. As more companies move their services to the cloud, securing these APIs and preventing the data leaks they facilitate is becoming a bigger challenge.

To mitigate the risks associated with insecure API configurations, organizations should implement strong authentication and authorization mechanisms, such as OAuth 2.0 or API keys, to ensure only authorized clients can access their APIs. Additionally, organizations should conduct regular security assessments and penetration testing to identify and remediate potential vulnerabilities in their API configurations.

Finally, adopting a secure software development lifecycle (SSDLC) and employing API security best practices, such as rate limiting and input validation, can help prevent data breaches stemming from insecure APIs.

Learn how UpGuard protects against third-party breaches >

How to Avoid Security Misconfigurations Impacting Your Data Breach Resilience

To protect against security misconfigurations, organizations should:

1. Implement a Comprehensive Security Policy

Implement a cybersecurity policy covering all system and application configuration aspects, including guidelines for setting permissions, enabling features, and updating software.

2. Implement a Cyber Threat Awareness Program

An essential security measure that should accompany the remediation of security misconfigurations is employee threat awareness training. Of those who recently suffered cloud security breaches, 55% of respondents identified human error as the primary cause.

With your employees equipped to correctly respond to common cybercrime tactics that preceded data breaches, such as social engineering attacks and social media phishing attacks, your business could avoid a security incident should threat actors find and exploit an overlooked security misconfiguration.

Phishing attacks involve tricking individuals into revealing sensitive information that could be used to compromise an account or facilitate a data breach. During these attacks, threat actors target account login credentials, credit card numbers, and even phone numbers to exploit Multi-Factor authentication.

Learn the common ways MFA can be exploited >

Phishing attacks are becoming increasingly sophisticated, with cybercriminals using automation and other tools to target large numbers of individuals. 

Here’s an example of a phishing campaign where a hacker has built a fake login page to steal a customer’s banking credentials. As you can see, the fake login page looks almost identical to the actual page, and an unsuspecting eye will not notice anything suspicious.

Real Commonwealth Bank Login Page
Real Commonwealth Bank Login Page.
Fake Commonwealth Bank Login Page
Fake Commonwealth Bank Login Page

Because this poor cybersecurity habit is common amongst the general population, phishing campaigns could involve fake login pages for social media websites, such as LinkedIn, popular websites like Amazon, and even SaaS products. Hackers implementing such tactics hope the same credentials are used for logging into banking websites.

Cyber threat awareness training is the best defense against phishing, the most common attack vector leading to data breaches and ransomware attacks.

Because small businesses often lack the resources and expertise of larger companies, they usually don’t have the budget for additional security programs like awareness training. This is why, according to a recent report, 61% of small and medium-sized businesses experienced at least one cyber attack in the past year, and 40% experienced eight or more attacks.

Luckily, with the help of ChatGPT, small businesses can implement an internal threat awareness program at a fraction of the cost. Industries at a heightened risk of suffering a data breach, such as healthcare, should especially prioritize awareness of the cyber threat landscape.

Learn how to implement an internal cyber threat awareness campaign >

3. Use Multi-Factor Authentication

MFA and strong access management control to limit unauthorized access to sensitive systems and data.

Previously compromised passwords are often used to hack into accounts. MFA adds additional authentication protocols to the login process, making it difficult to compromise an account, even if hackers get their hands on a stolen password

4. Use Strong Access Management Controls

Identity and Access Management (IAM) systems ensure users only have access to the data and applications they need to do their jobs and that permissions are revoked when an employee leaves the company or changes roles.

The 2023 Thales Dara Threat Report found that 28% of respondents found IAM to be the most effective data security control preventing personal data compromise.

5. Keep All Software Patched and Updated

Keep all environments up-to-date by promptly applying patches and updates. Consider patching a “golden image” and deploying it across your environment. Perform regular scans and audits to identify potential security misconfigurations and missing patches.

An attack surface monitoring solution, such as UpGuard, can detect vulnerable software versions that have been impacted by zero-days and other known security flaws.

6. Deploy Security Tools

Security tools, such as intrusion detection and prevention systems (IDPS) and security information and event management (SIEM) solutions, to monitor and respond to potential threats.

It’s essential also to implement tools to defend against tactics often used to complement data breach attempts, for example. DDoS attacks – a type of attack where a server is flooded with fake traffic to force it offline, allowing hackers to exploit security misconfigurations during the chaos of excessive downtime.

Another important security tool is a data leak detection solution for discovering compromised account credentials published on the dark web. These credentials, if exploited, allow hackers to compress the data breach lifecycle, making these events harder to detect and intercept.

Dara leaks compressing the data breach lifecycle.

Learn how to detect and prevent data leaks >

7. Implement a Zero-Trust Architecture

One of the main ways that companies can protect themselves from cloud-related security threats is by implementing a Zero Trust security architecture. This approach assumes all requests for access to resources are potentially malicious and, therefore, require additional verification before granting access.

Learn how to implement a Zero-Trust Architecture >

A Zero-Trust approach to security assumes that all users, devices, and networks are untrustworthy until proven otherwise.

8. Develop a Repeatable Hardening Process

Establish a process that can be easily replicated to ensure consistent, secure configurations across production, development, and QA environments. Use different passwords for each environment and automate the process for efficient deployment. Be sure to address IoT devices in the hardening process. 

These devices tend to be secured with their default factory passwords, making them highly vulnerable to DDoS attacks.

9. Implement a Secure Application Architecture

Design your application architecture to obfuscate general access to sensitive resources using the principle of network segmentation.

Learn more about network segmentation >

Cloud infrastructure has become a significant cybersecurity issue in the last decade. Barely a month goes by without a major security breach at a cloud service provider or a large corporation using cloud services.

10. Maintain a Structured Development Cycle

Facilitate security testing during development by adhering to a well-organized development process. Following cybersecurity best practices this early in the development process sets the foundation for a resilient security posture that will protect your data even as your company scales.

Implement a secure software development lifecycle (SSDLC) that incorporates security checkpoints at each stage of development, including requirements gathering, design, implementation, testing, and deployment. Additionally, train your development team in secure coding practices and encourage a culture of security awareness to help identify and remediate potential vulnerabilities before they make their way into production environments.

11. Review Custom Code

If using custom code, employ a static code security scanner before integrating it into the production environment. These scanners can automatically analyze code for potential vulnerabilities and compliance issues, reducing the risk of security misconfigurations.

Additionally, have security professionals conduct manual reviews and dynamic testing to identify issues that may not be detected by automated tools. This combination of automated and manual testing ensures that custom code is thoroughly vetted for security risks before deployment.

12. Utilize a Minimal Platform

Remove unused features, insecure frameworks, and unnecessary documentation, samples, or components from your platform. Adopt a “lean” approach to your software stack by only including components that are essential for your application’s functionality.

This reduces the attack surface and minimizes the chances of security misconfigurations. Furthermore, keep an inventory of all components and their associated security risks to better manage and mitigate potential vulnerabilities.

13. Review Cloud Storage Permissions

Regularly examine permissions for cloud storage, such as S3 buckets, and incorporate security configuration updates and reviews into your patch management process. This process should be a standard inclusion across all cloud security measures. Ensure that access controls are properly configured to follow the principle of least privilege, and encrypt sensitive data both in transit and at rest.

Implement monitoring and alerting mechanisms to detect unauthorized access or changes to your cloud storage configurations. By regularly reviewing and updating your cloud storage permissions, you can proactively identify and address potential security misconfigurations, thereby enhancing your organization’s data breach resilience.

How UpGuard Can Help

UpGuard’s IP monitoring feature monitors all IP addresses associated with your attack surface for security issues, misconfigurations, and vulnerabilities. UpGuard’s attack surface monitoring solution can also identify common misconfigurations and security issues shared across your organization and its subsidiaries, including the exposure of WordPress user names, vulnerable server versions, and a range of attack vectors facilitating first and third data breaches.

UpGuard's Risk Profile feature displays security vulnerabilities associated with end-of-life software.
UpGuard’s Risk Profile feature displays security vulnerabilities associated with end-of-life software.

To further expand its mitigation of data breach threat categories, UpGuard offersa data leak detection solution that scans ransomware blogs on the dark web for compromised credentials, and any leaked data could help hackers breach your network and sensitive resources.

UpGuard's ransomware blog detection feature.
UpGuard’s ransomware blog detection feature.

Source :
https://www.upguard.com/blog/security-misconfigurations-causing-data-breaches

Initial and Advanced Firewall Setup for high security environments

Description

This article covers how to setup firewall initial and advanced configuration when configuring in environments that requires top security compliance, military environments and closed environments.

Resolution

Resolution for SonicOS 7.X

This release includes significant user interface changes and many new features that are different from the SonicOS 6.5 and earlier firmware. The below resolution is for customers using SonicOS 7.X firmware.

Interfaces Configuration:

After collecting all necessary infrastructure-related information such as the relevant service IP networks,addresses, and so on, you can begin the basic configuration. To complete the basic configuration, complete the following steps:

  1. Log in to the default LAN interface X0, using the default IP:192.168.168.168.
  2. Go to Network |System | Interfaces.

         

  3. Under the Interface Settings section, click the Configure icon and assign relevant IP addresses to the interfaces in the trusted and untrusted zones.

                           Image
  4. Based on the information previously collected, assign the IP address to the interfaces in the correct subnet, you can use the default network as well.
  5. Enable HTTPS management and user management on the interfaces.
  6. Enable the desired protocols on the LAN and WAN interfaces.
  7. Configure the management interface with the appropriate IP addresses, net masks, and gateways, This is used only for controlling traffic management to the firewall.
  8. Disable DHCP server: Uncheck ‘Enable DHCP Server’ under Network | System | DHCP Server > DHCPv4 Server Settings.

          

  9. Set Firewall Host and Domain Names, Navigate to Device | Settings | Administration with Firewall Administration
    i.  Enter the firewall Name in the ‘Firewall Name’ box
    ii. Enter the firewall Domain Name (i.e. mydomain.net) in the ‘Firewall’s Domain Name’ box and click Accept.

    Image

Admintrator Settings:

  1. Set Administrator Account Properties:
    a. Under Firewall Administrator| Administrator Name & Password: Verify Administrator Name and set the password.
    b. Under Device | Settings | Administration with Login/Multiple Administrators

    i. Check ‘Password Must be Changed Every (days)
    ii. Check ‘Bar repeated passwords for this many changes’ – set to ‘10’
    iii. Select ‘New password must contain 8 characters different from the old password’
    iv. Set ‘Enforce a minimum password length of:’ to ‘16’
    v. Set ‘Enforce password complexity’ to ‘Require alphabetic, numeric, and symbolic characters’ (from the drop-down box choices)
    vi. Set ‘Complexity Requirement’ to ‘2’ in each box
    vii. Check all ‘Apply the above password constraints for:’ boxes
    viii. Set the ‘Log out the administrator after inactivity of (minutes)’ timer to ‘10’
    ix. Check the ‘Enable the administrator/user lockout’ checkbox

    1. Set ‘Failed login attempts per minute before lockout’ to ‘3’
    2. Set ‘Lockout Period (minutes)’ to ‘30’
    x. Set ‘Max login attempts through CLI’ to ‘3’
    1. Click ‘Accept’ (may require a reboot).

               Image

    xi. Under ‘Multiple Administrators’ – Select ‘Enable Multiple Administrative Roles’

          Image

    xii. Under Audit/Sonic OS API, ‘Enhanced Audit Logging Support’ – Select ‘Enable Enhanced Audit Logging’, click Accept.

             Image


User Configuration:

Force a new login session after a password change and display user login information since last login:
Navigate to Device | Users | Settings and Select ‘Force Relogin After Password Change’, Select ‘Display User Login Info Since Last Login’ and Click ‘Accept’.

      Image

Advanced Configuration:

For Advanced configurations in the firewall, complete the following additional steps:

  1. If a closed system is necessary, go to the Backend Server Communication section 12 and disable the Prevent communication with Backend servers option after the licensing protocol synchronizes, See the SonicOS Administration Guide for more information on manually updating these signatures.
  2. Under Diag page settings,In internal settings:
    1. Go to the Security Services Settings section, click Apply IPS Signatures Bidirectionally.
    2. Go to the ICMP Settings section, disable both ICMP packet settings.
    3. Under the VPN Settings section, enable the Trust Built-in CA certificates for IKE authentication and Local certificate import option.
    4. Click Close.
  3. Navigate to Device>Diagnostics and deselect “Periodic Secure Diagnostic Reporting for Support Purposes” and “Automatic Secure Crash Analysis Reporting”, the click “Accept”.
  4. Restart the firewall.
  5. Disable Advanced Networking:
    a. In Network| System | Dynamic Routing and disable Advanced Routing.

           Image
  6. Change IKEv2 Dynamic Client Proposal in IPSec VPN Advanced Settings to require at least DH Group 14,AES-256 encryption, and SHA-256 authentication:
    a. In IPSec VPN / Advanced, navigate to ‘IKEv2 Settings’ and click the ‘IKEv2 Dynamic Client Proposal’ button
    b. Change ‘DH Group’ to ‘14’ as appropriate
    c. Change ‘Encryption’ to ‘AES-256’
    d. Change ‘Authentication’ to ‘SHA-256’
    e. Click ‘Accept’ and then ‘Accept’ again

                   Image

Setting configuration:

  1. Turn off SSH and SNMP Management (not allowed 1 in FIPS mode):
    a. Navigate to Network | System | Interfaces and select the configuration icon for X0 (this assumes it’ the only interface that SSH or SNMP management might be  enabled on; turn off for any others configured for SSH and/or SNMP management)
    b. Deselect SSH or SNMP as appropriate.
    c. Click  ‘Ok’.

           Image
  2. Set session quota for each management IP (NOTE: This applies to both IPv4 and IPv6):
    a. Using the browser, navigate to the diag.html page https://<IP address> /sonicui/7/m/Mgmt/settings to https://<IP address>/sonicui/7/m/Mgmt/settings/diag.
    b. Check the box labeled ‘Set Connection Limitation of Management Policies’ and accept and exit internal settings.

    i. NOTE: This will require an automatic reboot

           Image
  3. Enable “Drop and log network packets whose source or destination address is 3 reserved by RFC”
    a. In Network | Firewall | Advanced> IPV6 settings,  navigate to the ‘IPv6 Advanced Configuration’ section
    b. Check the option ‘Drop and log network packets whose source or destination address is reserved by RFC’ and accept it.

            Image

172220  Log alert when the log buffer is 75% full
Log -> Settings -> Log category -> General -> Logs at 75% of maximum:  set the priority to Alert

       Image

172218 Minimum number of characters changed for password should be eight (8)
Device>Settings> Administration > Login/Multiple Administrators:

Image

172221 Login history during a user defined time period
Diag settings, new checkbox to set the time interval for login history. Note: The system -> Status the login history is displayed. The text in the display still shows as “since system restart” but it is actually since the organizationally defined time period in the below setting.

         Image

Sample output:
• Last successful login timestamp 04/11/2016 17:30:32.000.
• Number of all user successful login attempts since system reset is 1.

Note: Login history for CAC user with LDAP

Login History for a CAC user with credentials imported from LDAP will be recorded only when the user accounts are imported from LDAP locally onto the firewall. In order for the firewall to track history of the account the user account information should be available locally on the firewall.
If using CAC with LDAP , import the LDAP user accounts locally by clicking the “Import Users” and clicking “save”.

172219 Minimum password lifetime
Device>Settings> Administration > Login/Multiple Administrators:

Image

172223 Password complexity requirements should be applicable to OTP
Device> User -> Settings -> checkbox to apply password constraints to OTP

        Image

171473 Indefinite lockout of a user for wrong password(Device>Settings> Administration > Login/Multiple Administrators:)
172217 Enforce a limit of number of invalid consecutive logons within a time period

Image

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.

Interfaces Configuration:

After collecting all necessary infrastructure-related information such as the relevant service IP networks,addresses, and so on, you can begin the basic configuration. To complete the basic configuration, complete the following steps:

  1. Log in to the default LAN interface X0, using the default IP:192.168.168.168.
  2. Go to Manage |Network| Interfaces.

        
  3. Under the Interface Settings section, click the Configure icon and assign relevant IP addresses to the interfaces in the trusted and untrusted zones.

             Image
  4. Based on the information previously collected, assign the IP address to the interfaces in the correct subnet, you can use the default network as well.
  5. Enable HTTPS management and user management on the interfaces.
  6. Enable the desired protocols on the LAN and WAN interfaces.
  7. Configure the management interface with the appropriate IP addresses, net masks, and gateways, This is used only for controlling traffic management to the firewall.
  8. Disable DHCP server: Uncheck ‘Enable DHCP Server’ under Manage | Network| DHCP Server > DHCPv4 Server Leases Scopes.


  9. Set Firewall Host and Domain Names, Navigate to Manage| Appliance | Base Settings  with Firewall Administration
    i.  Enter the firewall Name in the ‘Firewall Name’ box
    ii. Enter the firewall Domain Name (i.e. mydomain.net) in the ‘Firewall’s Domain Name’ box and click Accept.

    Image

Admintrator Settings:

  1. Set Administrator Account Properties:
    a. Under Administrator Name & Password: Verify Administrator Name and set the password.
    b. Under Administration / Login Security with Login/Multiple Administrators

    i. Check ‘Password Must be Changed Every (days)
    ii. Check ‘Bar repeated passwords for this many changes’ – set to ‘10’
    iii. Select ‘New password must contain 8 characters different from the old password’
    iv. Set ‘Enforce a minimum password length of:’ to ‘16’
    v. Set ‘Enforce password complexity’ to ‘Require alphabetic, numeric, and symbolic characters’ (from the drop-down box choices)
    vi. Set ‘Complexity Requirement’ to ‘2’ in each box
    vii. Check all ‘Apply the above password constraints for:’ boxes
    viii. Set the ‘Log out the administrator after inactivity of (minutes)’ timer to ‘10’
    ix. Check the ‘Enable the administrator/user lockout’ checkbox

    1. Set ‘Failed login attempts per minute before lockout’ to ‘3’
    2. Set ‘Lockout Period (minutes)’ to ‘30’
    x. Set ‘Max login attempts through CLI’ to ‘3’
    1. Click ‘Accept’ (may require a reboot).

            Image

    xi. Under ‘Multiple Administrators’ – Select ‘Enable Multiple Administrative Roles’.

           Image

    xii. Under ‘Enhanced Audit Logging Support’ – Select ‘Enable Enhanced Audit Logging’, click Accept.

                       Image

User Configuration:

Force a new login session after a password change and display user login information since last login:
Navigate to Manage | Users | Settings and Select ‘Force Relogin After Password Change’, Select ‘Display User Login Info Since Last Login’ and Click ‘Accept’.

            Image

Advanced Configuration:

For Advanced configurations in the firewall, complete the following additional steps:

  1. If a closed system is necessary, go to the Backend Server Communication section 12 and disable the Prevent communication with Backend servers option after the licensing protocol synchronizes, See the SonicOS Administration Guide for more information on manually updating these signatures.
  2. Under Diag page settings, In internal settings:
    1. Go to the Security Services Settings section, click Apply IPS Signatures Bidirectionally.
    2. Go to the ICMP Settings section, disable both ICMP packet settings.
    3. Under the VPN Settings section, enable the Trust Built-in CA certificates for IKE authentication and Local certificate import option.
    4. Click Accept and exit the internal settings.
  3. Navigate to Device>Diagnostics and deselect “Periodic Secure Diagnostic Reporting for Support Purposes” and “Automatic Secure Crash Analysis Reporting”, the click “Accept”.
  4. Restart the firewall.
  5. Disable Advanced Networking:
    a.In Network / Routing, change ‘Advanced Routing’ to ‘Simple RIP Advertisement’

     Image
  6. Change IKEv2 Dynamic Client Proposal in IPSec VPN Advanced Settings to require at least DH Group 14,AES-256 encryption, and SHA-256 authentication:
    a. In IPSec VPN / Advanced, navigate to ‘IKEv2 Settings’ and click the ‘IKEv2 Dynamic Client Proposal’ button
    b. Change ‘DH Group’ to ‘14’ as appropriate
    c. Change ‘Encryption’ to ‘AES-256’
    d. Change ‘Authentication’ to ‘SHA-256’
    e. Click ‘Ok’ and then ‘Accept’ again.

          Image

Setting configuration:

  1. Turn off SSH and SNMP Management (not allowed 1 in FIPS mode):
    a. Navigate to Network | System | Interfaces and select the configuration icon for X0 (this assumes it’ the only interface that SSH or SNMP management might be  enabled on; turn off for any others configured for SSH and/or SNMP management)
    b. Deselect SSH or SNMP as appropriate.
    c. Click  ‘Ok’.

                 Image
  2. Set session quota for each management IP (NOTE: This applies to both IPv4 and IPv6):
    a. Using the browser, navigate to the diag.html page (<IP address of host>/diag.html)
    b. Check the box labeled ‘Set Connection Limitation of Management Policies’

    i. NOTE: This will require an automatic reboot

    Image
  3. Enable “Drop and log network packets whose source or destination address is 3 reserved by RFC”
    a. In Firewall Settings >Advanced Settings,  navigate to the ‘IPv6 Advanced Configuration’ section
    b. Check the option ‘Drop and log network packets whose source or destination address is reserved by RFC’ and accept it.

             Image

172220  Log alert when the log buffer is 75% full
Log -> Base setup -> Log category -> General -> Logs at 75% of maximum:  set the priority to Alert

               Image

172218 Minimum number of characters changed for password should be eight (8)
Manage>Appliance> Base settings > Login security:

Image

172221 Login history during a user defined time period
Diag settings, new checkbox to set the time interval for login history. Note: The system -> Status the login history is displayed. The text in the display still shows as “since system restart” but it is actually since the organizationally defined time period in the below setting.

Image

Sample output:
• Last successful login timestamp 04/11/2016 17:30:32.000.
• Number of all user successful login attempts since system reset is 1.

Note: Login history for CAC user with LDAP

Login History for a CAC user with credentials imported from LDAP will be recorded only when the user accounts are imported from LDAP locally onto the firewall. In order for the firewall to track history of the account the user account information should be available locally on the firewall.
If using CAC with LDAP , import the LDAP user accounts locally by clicking the “Import Users” and clicking “save”.

172219 Minimum password lifetime
Manage>Appliance> Base settings > Login security:

Image

172223 Password complexity requirements should be applicable to OTP
Manage> Users -> Settings -> checkbox to apply password constraints to OTP

Image

171473 Indefinite lockout of a user for wrong password(Manage>Appliance> Base settings > Login security:)
172217 Enforce a limit of number of invalid consecutive logons within a time period

Image

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/initial-and-advanced-firewall-setup-for-high-security-environments/210714000203227/

Can Settings be Exported/Imported from one SonicWall to Another? (Support Matrix)

Description

While settings can be exported from one SonicWall to another, not every model of SonicWall is compatible with all others. Similarly, some firmware versions are not compatible with subsequent versions as new features were added or changes were made to existing features. This article details which settings files are supported to and from each SonicWall UTM device to help administrators avoid possible settings corruption from unsupported settings Imports.

Resolution

Support Matrix for Gen 7 Products

SonicOS 7 is only compatible with Gen 7 hardware such as the TZ570 and 670. SonicOS 6.5.1.3 is the minimum version supported for settings import to a TZ running SonicOS 7. Existing settings for Global Bandwidth Management, Virtual Assist and Content Filter Client Enforcement cannot be imported into SonicOS 7. Global Bandwidth Management is replaced by Advanced Bandwidth Management, and the other features are deprecated in SonicOS 7.

NOTE: Settings import from Gen6/6.5 is only supported with migration tool. For help with creating Gen7 settings file using migration tool, please follow: How to Create Gen 7 Settings File by Using the Online Migration Tool?. Once you have a Gen7 compatible configuration from Migration tool, settings can be imported into relevant Gen7 models as per the product matrix.

Image

Configuration Settings Import Support by Version

 CAUTION: Settings from a higher firmware version cannot be imported into a lower version of firmware. For example it is not supported to import 6.5.3.x settings into 6.5.1.x firmware.

How To Understand And Resolve Settings Corruption

The following matrix illustrates the supported source and destination versions of SonicOS when importing configuration settings from one appliance to another. SonicOS 6.5 and 7.0 are included.

Image

Configuration settings import to a TZ running SonicOS 7 from any SonicOS 6.x version prior to SonicOS 6.5.x is supported as a two-step process:

  1. Upgrade the TZ from SonicOS 6.x to SonicOS 6.5.1.3 or higher.
  2. Export settings from the upgraded TZ and then use the migration tool to  import them to the TZ running SonicOS 7.

Configuration Settings Import Support by Platform

The matrix in this section shows the SonicWall firewalls running SonicOS 6.5 or 7.0 whose configuration settings can be imported to SonicWall platforms running SonicOS 7.0.

In the matrix, the source firewalls are in the left column, and the destination firewalls are listed across the top.

Image
Image

The legend for the above table is:

Image

 NOTE: Settings import is supported form SOHO running SonicOS 5.9 to SonicWall platforms running SonicOS 7.0. This is a special case, as SOHO cannot run SonicOS6.5.


Support Matrix for Importing Preferences from Gen 5 to Gen 6 Products

 NOTE: Upgrading from SonicOS 5.9.0.x to SonicOS 6.1.x.x is NOT supported at this time.

 NOTE: SonicOS running on NSv does NOT support settings import from a physical to virtual NSv

Failing to follow the guidelines as provided in this article may result in a failed upgrade and/or corruption of the configuration file, which would then require a manual configuration of the firewall settings.

 TIP: When importing settings to a TZ Series Firewall, make sure to disable Portshield on the destination Firewall beforehand to ensure the interface configuration will be updated.

 CAUTION: Settings from a higher firmware version cannot be imported into a lower version of firmware. For example importing 6.5.4.5 settings into 6.5.4.4 firmware is unsupported.

Image

Image

TZ Series / SOHO Series Configuration Import Support

Image

NSA / SuperMassive Configuration Import Support

Image

NSa Configuration Import Support

Image

Image

 NOTE:  SonicOS running on NSv Gen 6/6.5 does not support settings import to NSv Gen 7 devices at this time.


See also:

How to Understand and Resolve Settings Corruption

How do I safely perform a firmware downgrade?

SonicOS 6.5 administrative and upgrade guides – Reference Links

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/can-settings-be-exported-imported-from-one-sonicwall-to-another-support-matrix/170505258332789/