Taking the next step to learn more about Forward Enterprise

Intermediate

In Forward Networks' path search feature, the two queries “from IP with Destination IP” and “from IP To IP” may look similar, but perform very different kinds of searches with possibly different results. Here's a breakdown of their differences:1. From IP A with Destination IP BPurpose: shows path results that start from location of A, and the packet’s destination IP is set to B, at source (i.e. at location of A). Shows both dropped (e.g. by firewall) and delivered traffic. Behavior: The path search begins from the source and considers the destination IP as part of the packet header. It does not explicitly locate the destination as a physical or logical endpoint; instead, it treats the destination IP as an attribute of the packet. Use Case: Ideal when you want to trace how a packet with a specific source and destination IP address moves through the network, even if the destination location is unknown or incomplete in the model. Also useful when troubleshooting an issue from the point of view of the sender: a sender tries to send traffic to an address, but you are not sure if traffic reaches the destination, or whether at destination a DNAT changes the destination address. Limitations: May show packets delivered to incorrect location for B (due to routing issues, or missing devices in snapshot) Gotchas: this may include dropped paths, or paths that do not make it all the way to the actual location of B. If you create an “exist check” based on this kind of query, any delivered traffic (even to the wrong location) will cause the check to pass because there is no filter for delivery of packet to the location of B.2. From IP A To IP BPurpose: Show traffic originating from location of A, with source IP=A at the location of A, delivered to location of B, with dest IP=B at the location of B. Behavior: The path search resolves the To IP to a specific network location (e.g., a device interface, host, or edge point) and traces the path from the source to that resolved location. It considers the destination IP B, as both an endpoint and an attribute of the traffic at the exit point. Use Case: Ideal for ensuring traffic reaches a specific device, interface, or host whose address is B. Useful for creating “exist checks” to ensure traffic reaches a particular destination. . Limitations: If the destination IP cannot be resolved to a specific location in the model, the search will fail to return results. Gotchas: if traffic is dropped before reaching location of B, the path search returns no results. If the drop is due to a firewall drop, use the “permit-all” keyword in path search to see the path.If there is DNAT or load balancing in the network, IP address B should be the post-NAT address for the destination. Key Difference:While Destination IP focuses on filtering based on the IP address in the packet, To ensures the traffic reaches a specific, resolved endpoint in the network with that address as destination at the exit point. How to know which format of the query to use? If you are not sure if the address B is pre or post-NAT, start with “From IP A To IP B” but also add permit-all to work around firewall blocking traffic. If that doesn’t work, try “From IP A with Destination IP B” . If you are troubleshooting connectivity between A and B and you have got information about source and destination from the sender, use “From IP A with Destination IP B” query.Have questions? Ask below!

Intermediate

OverviewSecurity Technical Implementation Guides (STIGs) are critical for ensuring that organizational devices accessing the Department of Defense Information Networks (DODIN) meet stringent security requirements. The NQE STIG compliance check makes it easier to validate that device configurations are compliant with STIG standards and verify those configurations remain compliant with each snapshot. STIG compliance involves a comprehensive list of requirements ensuring proper configuration of authentication, logging, network time protocol (NTP), and management plane. These requirements can vary significantly depending on the device type and vendor, with different configurations needed for everything from backbone routers and campus layer switches, to VPN concentrators. Given the complexity and variety of these requirements, maintaining compliance can be a daunting task. This NQE solution provides comprehensive auditing capabilities for STIG compliance as well as extensibility to validate organizational directives.ResultsThe STIG compliance NQE and dashboard provides one place where users can quickly see compliance statuses and identify issues, making it easier to confirm compliance. It simplifies checks by confirming the presence of exact configuration lines in devices and offers guidance on more complex functional STIG requirements, helping not only ensure STIG compliance but offer additional flexibility for custom compliance requirements. Customers find immense value in this solution because it significantly reduces the manpower and resources needed for manual auditing and script creation. Moreover, it ensures that organizations stay up-to-date with the ever-evolving STIG standards by providing regular updates and compliance checks.SolutionTo address this challenge, we developed a comprehensive solution that aggregates high and medium severity STIG checks into an easily accessible platform. This NQE solution identifies compliance violations as defined by STIG standards, helping organizations establish controls and governance to secure their networks. Customization options allow users to input domain-specific information for functional checks, and a dashboard provides a clear overview of key performance indicators (KPIs) related to compliance. This includes both STIG guidelines and organizational directives. By offering precise, updated, and comprehensive STIG compliance checks, our solution helps organizations maintain high security standards with minimal effort. These NQEs support a broad list of vendors and models for STIGs analysis.Example dashboard view Where to find the STIG Compliance NQEs? You will find the STIG compliance check NQEs in the FWD.app NQE Library: Forward Library > Security > STIGs > Sample STIG NQE:/** * @intent The Cisco ASA must be configured to filter outbound traffic, allowing onlyauthorized ports and services. Severity: high * @description Information flow control regulates where information is allowed to travel withina network and between interconnected networks. Blocking or restricting detectedharmful or suspicious communications between interconnected networks enforcesapproved authorizations for controlling the flow of traffic.The firewall thatfilters traffic outbound to interconnected networks with different securitypolicies must be configured to permit or block traffic based onorganization-defined traffic authorizations. * * Severity: high * Operating System: cisco_asa * Device Type: NA * Version/Revision: V1R4 * Group_Title: SRG-NET-000019-FW-000003 * Vulnerability ID: V-239852 * Rule ID: SV-239852r665842_rule * Rule Version: CASA-FW-000010 * Legacy Vulnerabilities: ["CCI-001414"] */import "Security/STIGs/Cisco/Utils";// AUTO-GENERATED ABOVE HEREpatternIface = ```interface nameif {ifaceName:string} security-level ip address```;patternAccessGroup = ```access-group {accessGroupName:string} in interface {ifaceName:string}```;patternAcl = ```access-list {accessGroupName:string} {(!("eq" | "range")string)* } {"eq" | "range"} {string*}```;getIfaceNames(matches) = foreach match in matches select distinct match.data.ifaceName;haveInvalidAcl(config) =length((foreach match in blockMatches(config, patternAccessGroup) select distinct match.data.accessGroupName) - (foreach match in blockMatches(config, patternAcl) select distinct match.data.accessGroupName)) > 0;isVulnerable(params, config) = length(getIfaceNames(blockMatches(config, patternIface)) - getIfaceNames(blockMatches(config, patternAccessGroup))) > 0 || haveInvalidAcl(config);// AUTO-GENERATED BELOW HEREcheckContent = """Review the ASA configuration to determine if it only permits outbound trafficusing authorized ports and services.Step 1: Verify that an ingress ACL hasbeen applied to all internal interfaces as shown in the example below.interface GigabitEthernet0/0 nameif INSIDE security-level 100 ip address10.1.11.1 255.255.255.0………access-group INSIDE _IN in interface INSIDE Step2: Verify that the ingress ACL only allows outbound traffic using authorizedports and services as shown in the example below.access-list INSIDE _INextended permit tcp any any eq www access-list INSIDE _IN extended permit tcpany any eq https access-list INSIDE _IN extended permit tcp any any eq…access-list INSIDE _IN extended deny ip any any logIf the ASA is notconfigured to only allow outbound traffic using authorized ports and services,this is a finding.""";fixText = """Step 1: Configure the ingress ACL similar to the example below.ASA(config)#access-list INSIDE_INextended permit tcp any any eq httpsASA(config)#access-list INSIDE_INextended permit tcp any any eq httpASA(config)#access-list INSIDE_INextended permit tcp any any eq …ASA(config)# access-listINSIDE_INextended deny ip any any log Step 2: Apply the ACL inbound onall internal interfaces as shown in the example below.ASA(config)#access-group INSIDE_IN in interface INSIDEASA(config)# end""";intent = """The Cisco ASA must be configured to filter outbound traffic, allowing onlyauthorized ports and services.""";description = """Information flow control regulates where information is allowed to travel withina network and between interconnected networks. Blocking or restricting detectedharmful or suspicious communications between interconnected networks enforcesapproved authorizations for controlling the flow of traffic.The firewall thatfilters traffic outbound to interconnected networks with different securitypolicies must be configured to permit or block traffic based onorganization-defined traffic authorizations.""";ruleData = { severity: "1 - high", intent, description, checkContent, fixText, ruleVersion: "CASA-FW-000010", vulnerabilityId: "V-239852", skipped: false, };export ruleDataV239852 = ruleData;export isVulnerableV239852(config: List<ConfigLine>) = isVulnerable({}, config);f(params) = foreach device in network.devices where isPresent(device.files.config) where device.platform.os == OS.ASA select { violation: isVulnerable(params, device.files.config), Device: device.name, OS_Version: device.platform.osVersion, Model: device.platform.model, Mgmt_IPs: device.platform.managementIps, };// AUTO GENERATED ABOVE HEREg() = f({});g()

Intermediate

It is possible to use the Forward Enterprise API to automate integration with your change control process. For example, suppose you manage Change Control work using a system like ServiceNow to document the owner of a change, the devices involved, the state of the change, and the change results. You may want to trigger the creation of a workspace network and collection via the API. Forward Networks integrates with ServiceNow for ticket creation and CMDB management, but there is not a specific integration for Change Control. However, if your ticketing/workflow system supports running API calls, you can trigger Forward API calls to automate your workflow. Suppose your Change Control Process is the following:Create a ServiceNow ticket to track the change. Add a work plan, including the devices that are part of the change, to the ticket. Create a Workspace Network in Forward Enterprise with the devices in the change. Define NQE queries to validate the state of the network before and after the change (for example, what is the state of all the BGP peers on the devices in the change?) Run a pre-change collection on the Workspace Network. Apply the changes in the maintenance window. Run a post-change collection on the Workspace Network. Compare the state of the network between snapshots using the Diffs feature Save relevant files from the change to ServiceNow. (optional) This article demonstrates the API calls you’ll make to verify your Change Control process.Create an API key using a service account. Create a Workspace network Trigger a collection of all devices in the Workspace Network Gets a list of all snapshots in a network Verify that your Workspace network snapshot has completed and is processed After applying your Change Window modifications, trigger the API to create another snapshot of your Workspace network Get the snapshotId of your post-change snapshot Send other users a link to the Workspace Network Send other users directly to the Diff in Forward Use API to extract before and after files / NQE check results Example: NQE query to list state of BGP neighbors before and after a change. Call your BGP NQE from the API See the following article on how to run some of these Change Control verifications manually https://community.forwardnetworks.com/change-management-96/using-intent-checks-to-verify-a-change-control-536Steps 3, 5, 7, and 9 above can be automated using the API, and you can insert a link into your ServiceNow ticket that will take the user directly to the Diff output for the change. Below is a detailed description of the APIs that would be required to accomplish this task. It is assumed here that the developer is managing the API workflow from within the ticketing/workflow system and is able to parse JSON output between API calls using something like javascript. API Calls Required for Change Control integration Create an API key using a service account. The API key will have access to Forward Networks that match the user permissions of the service account. Note: All of the API calls mentioned below can used can be viewed and tested from https://docs.fwd.app/latest/api-doc/ Since a workspace network is created from a parent network, you need the networkId of the parent network. You can find it in the URL when you have your main network selected. In the screenshot below, the networkId is 153030. Create a Workspace network Use a POST API call to generate the Workspace Network https://fwd.app/api/networks/{networkId}/workspaces If you are running Forward Enterprise on your own servers, replace fwd.app above with your own server URL. The networkId is the id of the main network. The body of the API call is needed here to give the workspace network a name and specify what devices are in the network. Note also that we give the workspace network a retention period of 30 days. Consult https://docs.fwd.app/latest/api-doc/ for additional fields for this or any other API call. The screenshot below is showing an API call plug-in for VSCode. The API key and password have already been entered on the Auth page (not shown) The response code should be 200 OK and look something like this: { "creator": "forward-api-test@test.com", "secondsToExpiry": 604796, "name": "CHANGE: 101", "id": "300015", <----- This is the networkId of the workspace network that was just created. "parentId": "153030", "createdAt": 1744445805385, "note": "For change window 2025-4-30", "retentionDays": 7, "orgId": "1234", "creatorId": "12345"} The networkId for the Workspace Network just created (300015) will be needed from the JSON output for the next step. Trigger a collection of all devices in the Workspace Network When the user reaches the step in the workflow to perform pre-change checks, you can trigger a collection of all the devices in the Workspace Network as follows: POST - https://fwd.app/api/networks/300015/startcollection Every time a collection is run, Forward Enterprise connects to all devices and cloud instances in the workspace via SSH or API and collects configuration and state data. The time required for this step depends on the number of devices, size of the files, network latency, etc. For all of the remaining steps below, you need to know the snapshotId of each snapshot you want to perform an action on. You also need to verify that the workspace network collection and processing is complete. Many of the API calls that follow will fail if the snapshot is not finished processing. Gets a list of all snapshots in a network First, we get a list of all the snapshots in the network. GET - https://fwd.app/api/networks/300015/snapshots{ "creator": "forward-api-test@test.com", "secondsToExpiry": 604787, "name": "CHANGE: 101", "id": "300015", "parentId": "153030", "createdAt": 1744896805385, "note": "For change window 2025-4-30", "retentionDays": 30, "orgId": "1234", "creatorId": "12345" "snapshots": [ { "id": "655104", <-------------------- The most recent snapshot that we just triggered. "processingTrigger": "COLLECTION", "totalDevices": 2, "creationDateMillis": 1744897351132, "processedAtMillis": 1744897360153, "oldestCollectionMillis": 1744897302652, "latestCollectionMillis": 1744897350708, "isDraft": false, "state": "PROCESSED" }, { "id": "655100", "note": "Initial subset of parent snapshot 153030", "processingTrigger": "IMPORT", "totalDevices": 2, "creationDateMillis": 1744859660200, "processedAtMillis": 1744896810791, "isDraft": false, "state": "PROCESSED" } ]} From the above the JSON output, you can obtain the snapshotId. The most recent snapshot collected is listed first. If the state does not show “processed”, you need to wait before performing other actions. Verify that your Workspace network snapshot has completed and is processed To check that a single snapshot has completed and is processed, use the following API call. (You could re-run the call every 5 minutes until processing is complete). GET - https://fwd.app/api/snapshots/655104/metrics { "snapshotId": "655104", "needsReprocessing": false, ......}The false response here tells us that the snapshot has been processed. It does NOT need reprocessing. Once the pre-change snapshot is confirmed, the user can proceed with their maintenance work. After applying your Change Window modifications, trigger the API to create another snapshot of your Workspace network POST - https://fwd.app/api/networks/300015/startcollection Get the snapshotId of your post-change snapshotRun the list snapshots API again to get the latest snapshotId and verify that processing is complete once again.GET - https://fwd.app/api/networks/300015/snapshots Now you will have two snapshotIds to compare, say 655104 and 655105. It is HIGHLY recommended at this point to provide the user a link to the workspace network in the ticket/workflow system, so that the user can view the changes in the Forward Platform Send other users a link to the Workspace Network The format of the link will be: https://fwd.app/?/search?networkId=300015 This will take the user straight to the workspace network 300015.Send other users directly to the Diff in Forward You could also direct the user straight to the diff between the two snapshotshttps://fwd.app/?/diffs?networkId=300015&snapshotId=655104&baseSnapshotId=655105 You can construct the above URL from the network and snapshot IDs obtained from the previous API calls. The Diff feature page is the easiest way for the user to compare pre and post change config and state files, as well as the results of NQE queries in the inventory. Use API to extract before and after files / NQE check results You can also using API calls to extract the before and after files or the results of an NQE check before and after the change. Remember that this output will be less readable than in the platform, but can be saved indefinitely in ticketing/workflow system. Example: NQE query to list state of BGP neighbors before and after a change. Suppose you have an NQE query that lists the state of BGP neighbors on all the devices in the network. The user can view these change from Diffs page. You can also export the table of differences in BGP state using an API call to the NQE query. For example, this NQE query lists the BGP neighbors and their state./* * @intent Verifies that enabled BGP peerings are established */foreach device in network.devicesforeach networkInstance in device.networkInstancesforeach protocol in networkInstance.protocolswhere isPresent(protocol.bgp)let bgp = protocol.bgpforeach neighbor in bgp.neighborswhere isPresent(neighbor.sessionState)where neighbor.enabledselect { violation: neighbor.sessionState != BgpSessionState.ESTABLISHED, deviceName: device.name, protocolIdentifier: protocol.identifier, neighborNeighborAddress: neighbor.neighborAddress, sessionState: neighbor.sessionState, neighborDevice: neighbor.peerDeviceName} Obtain the NQE query by find the Qid from the (i) next to the query name in the NQE Library. Call your BGP NQE from the API Then use the following API call to run the NQE query and see the diffs between two snapshots: POST - https://fwd.app/api/nqe-diffs/655104/655105BODY:{ "queryId": "Q_e59d897e165e45e7249f91c35ac9d74f6cd534e6"} The JSON output from this query will provide a table which includes BGP neighbors that were added, changed, or modified during the change. { "totalNumRows": 3, "rows": [ { "type": "ADDED", "after": { "violation": false, "deviceName": "router-1", "protocolIdentifier": "BGP", "neighborNeighborAddress": "10.1.1.2", "sessionState": "ESTABLISHED", "neighborDevice": null } { "type": "MODIFIED", "before": { "violation": false, "deviceName": "router-1", "protocolIdentifier": "BGP", "neighborNeighborAddress": "169.254.2.2", "sessionState": "ESTABLISHED", "neighborDevice": null }, "after": { "violation": true, "deviceName": "router-1", "protocolIdentifier": "BGP", "neighborNeighborAddress": "169.254.2.2", "sessionState": "IDLE", "neighborDevice": null } } ]}Some final thoughts. We did not show how to list the files for each device and download them. This can be done and will require multiple API calls depending on which files you want to pull, but all the API calls needed are listed in this section of the documentation. https://docs.fwd.app/latest/api-doc/#network-snapshots Briefly, you would need to run an API to list the files collected for each device, then an API call to download each file to the ticket/workflow system.

Intermediate

Integrating Forward Networks with LDAP or LDAPS streamlines user authentication, enhances security, and simplifies access control management. By leveraging an existing LDAP directory, organizations can enforce role-based access, reduce administrative overhead, and ensure users have appropriate permissions based on predefined security groups. This integration enables seamless user provisioning, centralizes authentication policies, and strengthens compliance with enterprise security standards. In this guide, I’ll walk you through the step-by-step process of configuring LDAP and LDAPS authentication for Forward Networks, including prerequisites, setup instructions, and troubleshooting best practices. Questions? Ask in the comments below. Connect Forward to LDAP/SConnecting the forward app to an authentication source allows for granular connectivity to allow users to have the appropriate access to in the forward applicationPrerequisites:An LDAP Source CA / Sub CA infrastructure (certificate Authority for the LDAPS source)Understanding your Domain DN structure. Active Directory organizes all of its users, computers, groups, and objects within a specific structure. This structure can be observed using Active Directory Users and Computers (ADUC) tool . From within the tool, it is possible to display the DN for any object. To enable this ability,Go to View → Advanced FeaturesThe ADUC tool will now display some additional information. To get the DN from any object while in advanced mode, Right-Click the object and select Properties Select the Attribute Editor tab and Scroll down until you see the distinguishedName property. Here is the full distinguished name for that object Configuring Forward for LDAPLogin to the forward web interface as local administrator and navigate to Settings → Accounts → External Authentication These settings will be to configure LDAP (not secure). It may be worth getting this connection setup prior to configuring a LDAPS connection to limit the number of items that may need to be troubleshot.Hostname or IP = This can be the hostname or IP address of the Domain controller - it does not matter which one is used Port = 389 is the standard LDAP port for LDAP communication. When setting up just a LDAP connection, specify this port. Domain = Enter the domain name, this is typically in the format of xxx.yyy or xxx.yyy.zzz Base DN = This will be the Base DN for where the security groups are configured to allow controlled access to the Forward Platform (see Access Control Groups below) Test Connection, when all of these items are configured, the connection can be tested. If the settings are correct, a Success message will appear next to the button.Note that the Use LDAPS toggle is off for a LDAP connection Configuring Forward for LDAPSHere are the sample configurations for setting up LDAPS Hostname or IP = This should be the Fully Qualified Domain Name (FQDN) of the domain controller. This should not be the IP address UNLESS, the Domain controller certificate has a Subject Alternative Name (SAN) entry with the IP address of the DC on the certificate. Port = The LDAPS port is 636. Domain = Enter the domain name, this is typically in the format of xxx.yyy or xxx.yyy.zzz TLS Certificate = Cut and paste in the TLS certificate for authenticating to Active Directory. This ideally would be the certificate chain for the Windows network (subordinate + root certificate or just root if the CA is self-signed). This can also be the actual certificate from the domain controller. The risk of trusting the actual certificate from the domain controller is when it is renewed, the LDAPS authentication will stop working until the new certificate is added to the connection. Base DN = This will be the Base DN for where the security groups are configured to allow controlled access to the Forward Platform (see Access Control Groups below) Test Connection, when all of these items are configured, the connection can be tested. If the settings are correct, a Success message will appear next to the button.Note that the Use LDAPS toggle must be ON for a LDAPS connection. Setting up Access Control Groups To set up tiered access to the Forward platform, access control groups are tied to Active Directory Security groups to allow users to be assigned to different access levels. There are four roles within the Forward Platform:Net Admin = Administrator level access Net Operator = Operations level access Read-only = User level access Limited Read-only = Limited User level accessTo set these groups up within ADUC: Select a location to create your security groups. In this example the groups are already created, but this details the process of creating a security group. If you already have a security groups OU structure, you can skip this step.Right-click in the right pane of ADUC. Select New → Group Ensure that the Security radial button and Global radial button are selected. Give your security group a name. Once completed, it will look similar to the picture above. NOTE that the OU that these security groups belong to is ad.lab.local. This needs to be represented in Base DN for the LDAP connection. These security groups from Active directory are mapped to groups within the forward platform. Testing LDAP Authentication:The testing of LDAP authentication cannot be tested until the following items are complete:The fields for LDAP or LDAPS are configured The Access control groups are created and assigned within the Forward Platform Users are assigned within ADUC to the Security groups that are mapped to the Forward platform. Navigate to the External Authentication page.Click the Test user query. This brings a credential login prompt. Enter the username. The username the forward platform is looking for is the userPrinicalName and NOT the sAMAccountName. In more complex AD deployments, the userPrincipalName is often different than the sAMAcountName. In cases where the userPrincipalName and the sAMAccountName are the same (as above), logging in the the sAMAccountName will work ( I verified this ), but the platform is expecting the userPrincipalName. If something changes in your environment and these two names become different at some point, the platform will only accept userPrincipalName. Enter your password. You can click on the eye symbol if you want to see the password in cleartext to ensure it was typed in correctly. Click Test. Clicking the Test user query button above should show a Succeeded message at the bottom of the page. Troubleshooting DNS! DNS! DNS!Not being able to resolve hostname to IP addresses is the number one reason something is not working.To ensure that DNS is working properly on the Forward platform, login and run the following command: 1. [forward@test-fwd-fips-1 ~]$ nslookup labdc01.ad.lab.local2. Server: 192.168.15.13. Address: 192.168.15.1#534. 5. Name: labdc01.ad.lab.local6. Address: 172.16.14.11 In the command above , we are looking up the hostname of the domain controller to validate that the server knows the IP address. This lookup was successful. 1. [forward@test-fwd-fips-1 ~]$ nslookup labdc02.ad.lab.local2. ;; Got SERVFAIL reply from 192.168.15.1, trying next server3. Server: 172.16.14.14. Address: 172.16.14.1#535. 6. ** server can't find labdc02.ad.lab.local: SERVFAIL If the response looked like the above, there is a DNS issue. The first place to look is:1. [forward@test-fwd-fips-1 ~]$ cat /etc/resolv.conf2. # Generated by NetworkManager3. search localdomain4. nameserver 192.168.15.15. nameserver 172.16.14.1 Confirm if there are any other DNS servers that should be referenced. If there are, they can be added using nmtui and adding the additional nameserver: Edit the connection: Edit the adapter Add the DNS server.Editing the resolv.conf will work, but the entry may go away with a reboot. 1. [forward@test-fwd-fips-1 ~]$ cat /etc/resolv.conf2. # Generated by NetworkManager3. search localdomain4. nameserver 192.168.15.15. nameserver 172.16.14.16. nameserver 172.16.12.1 If there are no other DNS servers and it is unclear why DNS is not working, as a LAST RESORT, the hosts file can be updated:1. [forward@test-fwd-fips-1 ~]$ cat /etc/hosts2. 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain43. ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 For the host that is not able to be resolved, the entry can be added to this file.1. [forward@test-fwd-fips-1 ~]$ cat /etc/hosts2. 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain43. ::1 localhost localhost.localdomain localhost6 localhost6.localdomain64. 172.16.11.25 labdc02.ad.lab.local While this solution will work, It can create problems long term. At some point the DNS issue will get resolved and eventually over time , the host entry in the hosts file and DNS will conflict or drift and additional troubleshooting will need to take place. Use the hosts file as a LAST RESORT. TLS Certificate issueIf while testing the TLS connection to the LDAPS source in the Forward platform, you get an error testing the certificate: The certificate needs to be validated. We can connect to the LDAPS source using openssl to see what certificates are being presented.Run the following command from the Forward platform:1. openssl s_client -connect {ipaddress of server: port for SSL} --showcerts Example: 1. [forward@test-fwd-fips-1 ~]$ openssl s_client -connect 172.16.14.11:636 --showcerts 2. CONNECTED(00000003) 3. Can't use SSL_get_servername 4. depth=1 DC = local, DC = lab, DC = ad, CN = WinCA 5. verify error:num=20:unable to get local issuer certificate 6. verify return:1 7. depth=0 CN = labdc01.ad.lab.local 8. verify return:1 9. ---10. Certificate chain11. 0 s:CN = labdc01.ad.lab.local12. i:DC = local, DC = lab, DC = ad, CN = WinCA13. -----BEGIN CERTIFICATE-----14. MIIHYDCCBUigAwIBAgITWQAAAAedrm27u7xcBgAAAAAABzANBgkqhkiG9w0BAQsF15. ADBQMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxEzARBgoJkiaJk/IsZAEZFgNsYWIx16. EjAQBgoJkiaJk/IsZAEZFgJhZDEOMAwGA1UEAxMFV2luQ0EwHhcNMjUwMTExMTM017. MzMxWhcNMjYwMTExMTM0MzMxWjAfMR0wGwYDVQQDExRsYWJkYzAxLmFkLmxhYi5s18. b2NhbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOym2whIlqys43hA19. +VRVj4zpB5gkIKVjfgh2kUKLPB3tt8d0vgofFjWvS/9MF87jDfRuPkrf3TQKuylh20. ymfWwDZcaCLojIzTyprp5vlz82qY/lwyWwfENegr6QSwMew0RpvtwAoiK6RfXJHX21. a5C2HB0CAwEAAaOCA2IwggNeMC8GCSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4A22. QwBvAG4AdAByAG8AbABsAGUAcjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH23. AwEwDgYDVR0PAQH/BAQDAgWgMHgGCSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwIC24. AgCAMA4GCCqGSIb3DQMEAgIAgDALBglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsG25. CWCGSAFlAwQBAjALBglghkgBZQMEAQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYD26. VR0OBBYEFIQiImYPLEe+bhaU8c0HqbcTHjdXMB8GA1UdIwQYMBaAFLLxj8f8unA+27. mw5v8NqMAgpWBM3/MIH1BgNVHR8Ege0wgeowgeeggeSggeGGga5sZGFwOi8vL0NO28. PVdpbkNBLENOPVdpbkNBLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl29. cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWFkLERDPWxhYixEQz1s30. b2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M931. Y1JMRGlzdHJpYnV0aW9uUG9pbnSGLmh0dHA6Ly93aW5jYS5hZC5sYWIubG9jYWwv32. Q2VydEVucm9sbC9XaW5DQS5jcmwwggEGBggrBgEFBQcBAQSB+TCB9jCBqAYIKwYB33. BQUHMAKGgZtsZGFwOi8vL0NOPVdpbkNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl34. BgNVHREEOTA3oB8GCSsGAQQBgjcZAaASBBABiihyOiVjRosAtGuPTQDighRsYWJk35. YzAxLmFkLmxhYi5sb2NhbDANBgkqhkiG9w0BAQsFAAOCAgEADaBOdNrCYzO7yjTW36. XOEXmhU1Ls+9KE2/jKUn45SkaA72U+WKDweMGEU57+ooE/EPWFgKQdLAi8MS9MKR37. RxxeurgVvegH7juR+TzetGo4VgRQ6jcsRp81bf8+DbrjfGRDGT/hCT44g57uqYfU38. AA0SAAu72qN52CeLdhxG7x4nA9d4yYcCpx7TZ39iUvPJn3Ob8HRQONi/0xZZ0CeJ39. 5RReCe2Ws1G6qIx0ZuWmXOIgDZTutYoVW91iQgL5ryDolQmGD+b5a9+eUQz50aEQ40. ktbFgQ3VD3OY5U4OUAoMQXBHz/65sj04P9ZH19t6HCiIZGrdDXLBGW1mc1En5CVc41. KKIA6fGy1FLa/wAcA2bdJYaJdz6kzzjHhwRWlaq/dpLgP57kDb8tRByx1Ca/jF9+42. AEWVkMHSsi2hurCzFGFd8/pBNiQXA11DAogRlg9QwpE2hCcIkmA0+LksQPdYsnR743. kN9mk253Qde9wAs1/sievPADwIDlzVKfHwsx3rz1NUEO9CcUSFbYx87TupmH0Z9t44. I+4j41iI3QxzlpoFFEE6Piv+E29MMCA1UbVCtL1TAm60EGkGtNoiKZkyDMR72oo645. FQVHcmTls1/qE3qIQBCbCwGzrmOdSv/aVuw/vtMuxcrkNblmSsvPW/m0j7MPHWAb46. b4pFYM/+sBc14EFNapXzjyMDY1E=47. -----END CERTIFICATE-----48. 1 s:DC = local, DC = lab, DC = ad, CN = WinCA49. 50. -----BEGIN CERTIFICATE-----51. MIIF7zCCA9egAwIBAgICEAIwDQYJKoZIhvcNAQELBQAwgY0xIzAhBgkqhkiG9w0B52. CQEWFHlvdXJlbWFpbEBtcGx4LmxvY2FsMQswCQYDVQQGEwJVUzELMAkGA1UECAwC53. VkExEjAQBgNVBAcMCUNoYW50aWxseTENMAsGA1UECgwERGFhczEaMBgGA1UECwwR54. RGFhUy1UZXN0IFJvb3QgQ0ExDTALBgNVBAMMBHJvb3QwHhcNMjQxMTE3MTczMDE455. WhcNMzQxMTE1MTczMDE4WjBQMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxEzARBgoJ56. kiaJk/IsZAEZFgNsYWIxEjAQBgoJkiaJk/IsZAEZFgJhZDEOMAwGA1UEAxMFV2lu57. Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDDa2axEJvB3DzQGb8C58. UdVuV0VozRjZ/04jQ7Zgb/kzdCRgs8FGyFkPe9yNamSH+8Q9dy1ixzViZPyUJLL159. kNdJ3Odnq+FnJeLkO8hcFugbcUAIVQwnDOAU0LSB+M6F+Uksh+0/KtwwkfAF2Uhn60. rYUj5f9POi0R+KThsBrAUqJ3bc79tRhD9/i2Ybuo9PJeLySp4PVy/O2kabhsR7++61. B0kM3USD310P68slrx63hwoRZlUfYNLlDSAdwSP16j/dVk4Nd+zyX3c3Ah4IbuEt62. sOZyRi8CzprxXgQuUvoCiUt02Fh5XhB29PDh0cOuFvM27MQKkfitWORcy5HLBch763. m+Wu5wyIz5A8/i9mwTCWgIWkpSoljYgJJFRB3TokcWfcYKZJf5HBFleV6pl4+6Ds64. Il1GDY2PsTh6cKNvwpdPKtCm3A7+La5uVjyJKnfEavuLdlR65LBIH6st8IQIl2+P65. NVGNHXznVXC+P8WIsIW8/XcR/QIDAQABo4GUMIGRMB0GA1UdDgQWBBSy8Y/H/Lpw66. PpsOb/DajAIKVgTN/zAfBgNVHSMEGDAWgBTlfZC2UAr+loOAkXgwrE0+kITx3DAS67. BgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjArBgNVHR8EJDAiMCCg68. HqAchhpodHRwOi8vMTcyLjE2LjE1LjkvY3JsLnBlbTANBgkqhkiG9w0BAQsFAAOC69. AgEAs/q5sbGjXBzm6wseJGv1tlkMnmBCgN+7Xyd23p78i7KBZyLQc5tCfW5StcEU70. ZGl0dzF+bHcO7FD1Bd8u3Zj9R/nQG+xJEc1CEeaIjoLeidRcHwBJ42LCQCZ3nBaQ71. gF9BeU7oVRqIkwvHlcOJ8jMLIwUAciUbaO7dFnZxxO+sa5cCOdNi7p9cSxvpv2jQ72. NvQTmwfMMTXX2IEu8DwsJqLs8PYvZtuDX5OCPRaX9j6f/Gtth9EdOHfzRTqbGD9a73. o7WB6EgcNW9NtXQ278bHuJA4YMmqPGtfNcxWPiINLxi/D3lDmscZhDYRNkxqCuXf74. LhT/L2SkPHJg9zeuaqXS1gcQKRDxqzhNMaf99hA5wccxMVKC00O6by+Ti16KyQvI75. 0F1KrOcPcIVoA25JLd/WUQsd++tAv3y9vQ8lyanzdc/0KVzF5D3MFuBfcOuU3DaP76. OqC64JDLMINoBhBhb5SZM3TTjsv9fLa0X8FOuFJr3qlLigUKnDq8ndSJ0A8vu5b677. PgCWaoyrFLjiPooiD7IGsKG8Xe45C3ukF/nZ6GWipHXhjVoQIOLxb4Xo/A0kjn3I78. 3wO+k3ugDB83NDd05o33+E7rywqwo+oubIssVYLmQ6eZgY/vsezUNQP96jn0aSCT79. ot/p6Jx8srvKSjks/97LFVxq27z/goOVwN7kO1B/mT/7PUg=80. -----END CERTIFICATE-----81. ---82. Server certificate83. subject=CN = labdc01.ad.lab.local84. 85. issuer=DC = local, DC = lab, DC = ad, CN = WinCA86. 87. ---88. No client certificate CA names sent89. Client Certificate Types: RSA sign, DSA sign, ECDSA sign90. Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA51291. Shared Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA51292. Peer signing digest: SHA25693. Peer signature type: RSA-PSS94. Server Temp Key: ECDH, P-384, 384 bits95. --- In the example above, the connection to the LDAPS source presented two certificates. The first one is the certificate from the actual server. The second one is the certificate of the windows certificate authority. These can both be tested. To check the validity of the certificate in windows, cut and paste each certificate from this output into their own notepad document.Copy each certificate starting and ending at:1. -----BEGIN CERTIFICATE-----2. -----END CERTIFICATE----- Save the file and rename the file extension from .txt to .cer Open the certificate (double-click or right-click → open) to look at the properties Here we can see the certificate in not expired.Here is the second certificate in the openssl output: This is the certificate for the Certificate Authority and also has not expired.If the certificates check out and the test LDAP connection is still not working, it is possible that the certificate chain is required. In this case copy and paste both certificates back to back into the certificate field in the forward platform. Note that a certificate chain typically is at least 3 certificates. The root ca, the sub-ca, and the cert of the connecting server (LDAP). By integrating Forward Networks with LDAP or LDAPS, organizations can streamline authentication, enforce consistent security policies, and provide users with the right level of access to critical network data. This setup not only enhances operational efficiency but also strengthens compliance and security by leveraging existing directory services. Once configured, administrators can easily manage user permissions through Active Directory, ensuring a seamless and scalable access control model. With a properly integrated authentication system, your team can focus on optimizing network operations with confidence. Have questions? Ask below!

Intermediate

Is often necessary to audit the same setting across multiple vendors.For example, the NTP server setting differs across vendors.You can write an exportable function that returns the NTP servers for ANY device type.The following NQE query creates a reusable function called getNtpServers with the export command. The function takes a single argument device and returns a list of NTP servers based on the device type. A different function is called using the when statement based on the OS. Note that the NTP server configuration in Cisco devices is in the device.files.config file (the running configuration), but for Fortinet and F5 devices you need the result of a Custom Command to see the NTP configuration.Note also that the same nested function getCiscoNtpServers is used for multiple Cisco OS types.If you find an OS type or pattern that isn’t identified, you can add in new patterns and functions, or alter or expand the patterns already included./** * @intent Helper function getNtpServers(device: Device) returns a list of NTP servers for a given device. * @description Helper function getNtpServers(device: Device) returns a list of NTP servers for a given device. * * NOTE - A custom command must be added for the function to work for the following device types: * * Fortinet - show system ntp * F5 - list sys ntp */patternFortinet = ```config system ntp config ntpserver edit {number} set server {ntpServer:string}```;patternPaloAlto = ```config devices localhost.localdomain deviceconfig system ntp-servers primary-ntp-server ntp-server-address {primaryNtpServer:string} secondary-ntp-server ntp-server-address {secondaryNtpServer:string}```;patternCisco = ```ntp server```;patternIosXr = ```ntp server vrf {vrf:string} {ntpServer:string} {string*}```;patternArista = ```ntp server```;patternF5 = ```sys ntp servers {ntpServer:(string*)}```;patternJunos = ```system ntp server {ntpServer:string}```;patternDell = ```sntp server {ntpServer:string}```;patternDell2 = ```ntp server {ntpServer:string}```;patternVersa = ```ntp server {ntpServer:string}```;getFortinetNtpServers(device) = foreach command in device.outputs.commands where command.commandText == "show system ntp" let commandString = command.response let editedCommandString = replace(commandString, "\"", "") let parsedCommand = parseConfigBlocks(OS.FORTINET, editedCommandString) foreach match in blockMatches(parsedCommand, patternFortinet) select { serverId: match.data.ntpServer };getPaloAltoNtpServers(device) = foreach match in blockMatches(device.files.config, patternPaloAlto) let serverList = [match.data.primaryNtpServer, match.data.secondaryNtpServer] foreach server in serverList select { serverId: server };getCiscoNtpServers(device) = foreach x in [0] let lines = (foreach match in blockMatches(device.files.config, patternCisco) select match.blocks) foreach line in lines let lineString = toString(line) let validRegex = re`^ntp server(?: vrf \S+)? (\d{1,3}(?:\.\d{1,3}){3}|[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}|[a-zA-Z0-9.\-]+)` foreach serverMatch in regexMatches(lineString, validRegex) select { serverId: serverMatch.data["1"] };getIosXrNtpServers(device) = foreach match in blockMatches(device.files.config, patternIosXr) select { serverId: match.data.ntpServer };getAristaNtpServers(device) = foreach x in [0] let lines = (foreach match in blockMatches(device.files.config, patternArista) select match.blocks) foreach line in lines let lineString = toString(line) let validRegex = re`^ntp server(?: vrf \S+)? (\d{1,3}(?:\.\d{1,3}){3}|[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}|[a-zA-Z0-9.\-]+)` foreach serverMatch in regexMatches(lineString, validRegex) select { serverId: serverMatch.data["1"] };getF5NtpServers(device) = foreach command in device.outputs.commands where command.commandText == "list sys ntp" let commandString = command.response let editedCommandString = replace(commandString, "{", "") let editedCommandString = replace(editedCommandString, "}", "") let parsedCommand = parseConfigBlocks(OS.F5, editedCommandString) foreach match in blockMatches(parsedCommand, patternF5) foreach entry in match.data.ntpServer select { serverId: entry };getJunosNtpServers(device) = foreach match in blockMatches(device.files.config, patternJunos) select { serverId: match.data.ntpServer };getDellNtpServers(device) = foreach x in [0] let serverList1 = (foreach match in blockMatches(device.files.config, patternDell) select match.data.ntpServer) let serverList2 = (foreach match in blockMatches(device.files.config, patternDell2) select match.data.ntpServer) let serverList = if length(serverList1) > length(serverList2) then serverList1 else serverList2 foreach server in serverList select { serverId: server };getVersaNtpServers(device) = foreach match in blockMatches(device.files.config, patternVersa) select { serverId: match.data.ntpServer };export getNtpServers(device: Device) = foreach x in [0] let ntpServers = when device.platform.os is FORTINET -> getFortinetNtpServers(device); PAN_OS -> getPaloAltoNtpServers(device); IOS -> getCiscoNtpServers(device); NXOS -> getCiscoNtpServers(device); IOS_XR -> getIosXrNtpServers(device); IOS_XE -> getCiscoNtpServers(device); ASA -> getCiscoNtpServers(device); ARISTA_EOS -> getAristaNtpServers(device); F5 -> getF5NtpServers(device); JUNOS -> getJunosNtpServers(device); DELL_OS6 -> getDellNtpServers(device); DELL_OS9 -> getDellNtpServers(device); DELL_OS10 -> getDellNtpServers(device); DELL_SONIC -> getDellNtpServers(device); VERSA -> getVersaNtpServers(device); otherwise -> [{ serverId: null : String }] foreach server in ntpServers select server.serverId;Create a folder called Helper Functions in the root of your Org Repository, and save the above NQE query as Get NTP Servers.Then create another query that imports and uses the function as follows:import "Helper Functions/Get NTP Servers";foreach device in network.deviceswhere device.platform.vendor != Vendor.FORWARD_CUSTOMlet ntpServers = getNtpServers(device)select { violation: !isPresent(max(ntpServers)), device: device.name, vendor: device.platform.vendor, OS: device.platform.os, "NTP Servers": ntpServers}This query will show a violation if the list ntpServers is empty. Also note that Forward Networks synthetic devices are ignored, since they have no NTP configuration.Notice the reusable simplicity of the line: let ntpServers = getNtpServers(device)The function can be used within any other NQE query to find the NTP Servers for a given device.You can create Helper Functions for settings like DNS, login banner, SNMP config, and more and add them to the Helper Functions folder.A similar approach to that above for getting DNS servers can be seen here:

This NQE uses the L3 interface info and ARP tables to find the subnets in use on your network. It lists the associated vlan, used addresses, devices, and usage statistics.An optional parameter allows you to search for an IP address, and whether the IP is in use or not, it will display the subnet it belongs to.import "@fwd/L3/Interface Utilities";numHostsInSubnetV4(maskLength) = if 2 ^ (32 - maskLength) >= 4 then 2 ^ (32 - maskLength) - 2 else 2 ^ (32 - maskLength);numHostsInSubnetV6(maskLength) = 2 ^ (128 - maskLength);@queryquery(IP_Addresses: List<IpAddress>) = foreach device in network.devices foreach interface in getL3Interfaces(device) let addresses = (foreach address in interface.ipv4.addresses select { ip: address.ip, mask: address.prefixLength }) + (foreach address in interface.ipv6.addresses select { ip: address.ip, mask: address.prefixLength }) let neighbors = (foreach address in interface.ipv4.neighbors select address.ip) + (foreach address in interface.ipv6.neighbors select address.ip) foreach address in addresses let subnet = ipSubnet(networkAddress(ipSubnet(address.ip, address.mask)), address.mask) let ips = (foreach address in addresses select address.ip) + neighbors foreach ip in ips group { ip, vlan: interface.vlan, device: device.name } as address by subnet as subnets where if length(IP_Addresses) > 0 then max(foreach ip in IP_Addresses select ip in subnets) else true let vlan = distinct(foreach item in address where isPresent(item.vlan) select toString(item.vlan)) let ips = distinct(foreach item in address where item.ip in subnets select item.ip) let devices = distinct(foreach item in address select item.device) let total = if isIPv4(subnets) then numHostsInSubnetV4(length(subnets)) else numHostsInSubnetV6(length(subnets)) let used = length(ips) let unused = total - used let percent = 100 * used / total select { subnet: subnets, vlan, "Used IPs": ips, Devices: devices, "Number Used": used, "Number Available": unused, "% Used": percent };

Intermediate

Intent checks can be used to verify that the network is working as intended following a network change.Suppose we are performing a Change Control to route traffic from the Internet to a web application running behind a load balancer.We are going to use an intent check to validate that the server is reachable from an Internet router. Also check out my article on using Forward for Change Control: We begin by performing a path search from the Internet router to the intended web app IP. Note that traffic is currently dropped on the atl-edge-fw01 firewall.We want to quickly validate that this traffic is delivered after the change, so we save the path search as an intent check. Here we want to verify that at least one possible path exists between the source and destination. Furthermore, we want to verify that the traffic is delivered, so we add status:delivered to the path search criteria, and click Next. Give the intent check a name and intent description and click Create Intent. Now that the intent check has been created, we see it listed under Verify > Intent.The path search verification shows failed because we have not yet made a change, and the traffic is dropped on the firewall. During the maintenance window, we make several routing and firewall changes. We run a new collection, and see that the Intent Check is now passed.Click on passed. The History column on the left shows on which snapshots the intent check passes and on which snapshots it fails. As seen in the path card, the packet is delivered in the latest snapshot. We can click on a previous snapshot in the history and look at files that changed during the maintenance. Note the change in the app3-web-vip object. The firewall change was required for the NATed traffic on atl-edge-fw-1, which you can see by expanding the path details in the path card for that device. By creating an intent check before the maintenance window, we reduce the time required to verify whether or not the change is successful, and automatically document the results!

Intermediate

When working with STIG compliance checks, a common challenge is that many checks only verify the existence of a control—not whether the configured values align with site-specific requirements. This can be a problem when compliance policies vary across different data centers and locations.With a little work, it is easy to customize the queries. Benefits are apparent. You get: more precision to verify your specific ACL and group names Verifying differing configuration policies across multiple data centers or locations Improved compliance and governance across a variety of configurations and regionsThere are two approaches you can use to customize queries.Copy the query and modify the block match to include the value of your parameter Parametrize the query and use your location-specific string value as a query parameter. Parameterized queries are slightly more complex but make existing STIG checks - and other NQEs - more flexible.Let’s use an example of a library STIG query /Forward Library/Security/STIGs/Cisco/Cisco IOS Router NDM/CISC-ND-000140 V-215667 to illustrate. The intent of the query as described by the DISA is: * @intent The Cisco router must be configured to enforce approved authorizations for controlling the flow of management information within the device based on control policies. The library query offers the following logic:patternAcccessList = ```line vtyaccess-class {string} in```;isVulnerable(params, config)= !hasBlockMatch(config, patternAcccessList); The code looks for the control plane configuration (“line vty”) within the Cisco device configuration and marks it as a violation if the vty line is not configured to restrict access to an access-class. For a more precise policy verification, you would want to check that the vty line access is restricted to not just any access-class, but a specific access class specified by your corporate policy. Let’s try that with the assumption that the access class in your location A carries the name of VTY_IN_A. Taking approach 1 you can copy the query to your own org repository and modify the check as follows:patternAcccessList = ```line vtyaccess-class VTY_IN_A in```;isVulnerable(params, config)= !hasBlockMatch(config, patternAcccessList); Note: when copying the query you need to modify the import statement from the relative to an absolute path to read:import "@fwd/Security/STIGs/Cisco/Utils"; This simple approach works well if your policy calls for the same access list in all locations. However, if you still want more precision but your policy is location-specific, you may take approach number 2 and make the query parameterized. Parametrizing the query is an approach that allows you to run an NQE query with arguments using @query statement. More details about this approach are in this NQE documentation chapter. In this case the check code would look like this:patternAcccessList = ```line vtyaccess-class {accessClass:string} in```;//VTY_ACCESS_IN in vrf-alsogetMatches(params, config) =foreach match in blockMatches(config, patternAcccessList)select { "List_name": match.data.accessClass, "ByPolicy": match.data.accessClass == toString(params)} ;isVulnerable(params, config) =!any(foreach match in getMatches(params, config) select match.ByPolicy);This query retrieves the string that restricts the access-class, if that string exists. Then it outputs all matches with the determination if the string matches the policy string. Finally, it declares a violation if no access-class restrictions are found or any of the found strings do not match the string specified as a query parameter.To call the query you would use a @query NQE command. When executing the query, specify your string in the Parameters section. The query below is a full parameterized version of the query we described above. Let us know if you have questions or need help adapting it for your setup! * @intent The Cisco router must be configured to enforce approved authorizations forcontrolling the flow of management information within the device based oncontrol policies. Severity: medium * @description A mechanism to detect and prevent unauthorized communication flow must beconfigured or provided as part of the system design. If management informationflow is not enforced based on approved authorizations, the network device maybecome compromised. Information flow control regulates where managementinformation is allowed to travel within a network device. The flow of allmanagement information must be monitored and controlled so it does not introduceany unacceptable risk to the network device or data. Application-specificexamples of enforcement occur in systems that employ rule sets or establishconfiguration settings that restrict information system services ormessage-filtering capability based on message content (e.g., implementing keyword searches or using document characteristics).Applications providinginformation flow control must be able to enforce approved authorizations forcontrolling the flow of management information within the system in accordancewith applicable policy. * * Severity: medium * Operating System: cisco_ios * Device Type: Router * Version/Revision: V3R1 * Group_Title: SRG-APP-000038-NDM-000213 * Vulnerability ID: V-215667 * Rule ID: SV-215667r991819_rule * Rule Version: CISC-ND-000140 * Legacy Vulnerabilities: ["CCI-001368", "CCI-004192", "SV-105161", "V-96023"] */import "@fwd/Security/STIGs/Cisco/Utils";// AUTO-GENERATED ABOVE HEREpatternAcccessList = ```line vty access-class {accessClass:string} in```;//VTY_ACCESS_IN in vrf-alsogetMatches(params, config) = foreach match in blockMatches(config, patternAcccessList)select { "List_name": match.data.accessClass, "ByPolicy": match.data.accessClass == toString(params) } ;isVulnerable(params, config) = !any(foreach match in getMatches(params, config) select match.ByPolicy);// isVulnerable(params, config)= !hasBlockMatch(config, patternAcccessList);// AUTO-GENERATED BELOW HEREcheckContent = """Review the Cisco router configuration to verify that it is compliant with thisrequirement. Step 1: Verify that the line vty has an ACL inbound applied asshown in the example below.line vty 0 1 access-class MANAGEMENT_NET intransport input sshStep 2: Verify that the ACL permits only hosts from themanagement network to access the router.ip access-list extended MANAGEMENT_NETpermit ip x.x.x.0 0.0.0.255 anydeny ip any any log-inputIf the Ciscorouter is not configured to enforce approved authorizations for controlling theflow of management information within the device based on control policies, thisis a finding.""";fixText = """Configure the Cisco router to restrict management access to specific IPaddresses via SSH as shown in the example below.SW2(config)#ip access-liststandard MANAGEMENT_NET SW2(config-std-nacl)#permit x.x.x.0 0.0.0.255SW2(config-std-nacl)#exit SW2(config)#line vty 0 1 SW2(config-line)#transportinput ssh SW2(config-line)#access-class MANAGEMENT_NET in SW2(config-line)#end""";intent = """The Cisco router must be configured to enforce approved authorizations forcontrolling the flow of management information within the device based oncontrol policies.""";description = """A mechanism to detect and prevent unauthorized communication flow must beconfigured or provided as part of the system design. If management informationflow is not enforced based on approved authorizations, the network device maybecome compromised. Information flow control regulates where managementinformation is allowed to travel within a network device. The flow of allmanagement information must be monitored and controlled so it does not introduceany unacceptable risk to the network device or data. Application-specificexamples of enforcement occur in systems that employ rule sets or establishconfiguration settings that restrict information system services ormessage-filtering capability based on message content (e.g., implementing keyword searches or using document characteristics).Applications providinginformation flow control must be able to enforce approved authorizations forcontrolling the flow of management information within the system in accordancewith applicable policy.""";ruleData = { severity: "2 - medium", intent, description, checkContent, fixText, ruleId: "SV-215667r991819_rule", ruleVersion: "CISC-ND-000140", vulnerabilityId: "V-215667", stig: "Cisco IOS Router NDM", stigVersion: "V3R1", skipped: false, };export ruleDataV215667 = ruleData;export isVulnerableV215667(config: List<ConfigLine>) = isVulnerable({}, config);f(params) = foreach device in network.devices where isPresent(device.files.config) where isIosRouter(device.platform) select { violation: isVulnerable(params, device.files.config), ListMatches: getMatches(params, device.files.config), Device: device.name, OS_Version: device.platform.osVersion, Model: device.platform.model, Mgmt_IPs: device.platform.managementIps, };// AUTO GENERATED ABOVE HERE@queryquery(params: String) = f(params);

Intermediate

For Forward Enterprise on-prem customers running air-gapped instances, maintaining up-to-date security data can offer challenges. This Python script addresses those challenges by automating the daily update of the CVE (Common Vulnerabilities and Exposures) database, ensuring your instance reflects the latest threat intelligence—even when it’s offline. You can perform these updates in the Forward Enterprise UI, but this script offers an automated solution to ensure you’re running the most up-to-date definitions. In addition to CVEs, you can modify this script to include custom definitions to identify threats and compliance requirements specific to your industry or sector. Jump to the script Designed for Security and Compliance Teams This script is particularly valuable for:Security Operations Center (SOC) teams monitoring for zero-day vulnerabilities Audit and compliance professionals needing accurate, up-to-date security data Any on-prem customer managing Forward Enterprise in a secure or regulated environment By removing the need for daily manual updates, it saves time and reduces the risk of human error in high-stakes environments. Automate Download to Upload Here’s how the script works:Connect to Forward’s web platform using your credentials (or ideally, an API key). Downloads the latest CVE database as a compressed file. Uploads the file to your on-prem instance, using its local credentials and endpoint information. Runs on a schedule (via cron or task scheduler), so the update process is hands-off after setup. Typically, this script runs on a bastion host—any machine that can access both the internet and the internal network. It could be your laptop or a dedicated server bridging the two environments Expand Beyond CVEs with Minimal EffortWhile the script’s primary use case is daily CVE updates, it’s flexible enough to support other workflows:Upload custom or third-party compliance files Sync internal datasets not available via API Extend the logic to support multiple destination hosts With only minor tweaks to the source URL and upload target, the same foundation can support a broader set of update tasks. Running the script requires:A modern Python environment The requests library (a common dependency) A Forward user account with download access to the CVE database On-prem instance credentials (or support for insecure uploads if no certificate is installed)Python Script #!/usr/bin/env python3import argparseimport loggingimport osimport reimport sysimport requestsfrom requests.auth import HTTPBasicAuthfrom requests.adapters import HTTPAdapterfrom urllib3.util.retry import Retrydef setup_logging(verbose): level = logging.DEBUG if verbose else logging.INFO logging.basicConfig( level=level, format='%(asctime)s - %(levelname)s - %(message)s' )def create_session(): session = requests.Session() retries = Retry( total=3, backoff_factor=1, status_forcelist=[502, 503, 504], allowed_methods=["GET", "PUT"] ) session.mount('https://', HTTPAdapter(max_retries=retries)) return sessiondef download_file(session, url, auth): logging.info(f"Downloading from {url}...") response = session.get(url, auth=auth) if response.status_code != 200: logging.error(f"Failed to download file. Status code: {response.status_code}") sys.exit(1) # Extract filename from Content-Disposition content_disposition = response.headers.get('Content-Disposition', '') filename = "cve-index.bin.gz" # default if 'filename=' in content_disposition: filename = content_disposition.split('filename=')[-1].strip('";') logging.info(f"Download successful. Filename: {filename}") return response.content, filenamedef safe_filename(name): return re.sub(r'[^\w.-]', '_', name)def save_file_locally(data, filename='cve-index.bin.gz'): safe_name = safe_filename(filename) path = os.path.join('/tmp', safe_name) logging.debug(f"Saving file to {path} for debugging purposes.") with open(path, 'wb') as f: f.write(data) logging.info(f"File saved as {path}.")def upload_file(session, data, upload_url, auth, verify=True): headers = {'Content-Type': 'application/x-gzip'} logging.info(f"Uploading to {upload_url}...") response = session.put(upload_url, headers=headers, auth=auth, data=data, verify=verify) if response.status_code not in (200, 201, 204): logging.error(f"Failed to upload file. Status code: {response.status_code}") logging.debug(response.text) sys.exit(1) logging.info("Upload successful.")def main(): parser = argparse.ArgumentParser(description='Download and forward CVE index file.') parser.add_argument('--fwd-user', required=True, help='Username for fwd.app') parser.add_argument('--fwd-pass', required=True, help='Password for fwd.app') parser.add_argument('--target-host', required=True, help='Target host (e.g., portal.forwardnetworks.your.instance.url)') parser.add_argument('--target-user', required=True, help='Username for target host') parser.add_argument('--target-pass', required=True, help='Password for target host') parser.add_argument('--insecure-upload', action='store_true', help='Disable SSL verification on upload') parser.add_argument('--verbose', action='store_true', help='Enable verbose logging') args = parser.parse_args() setup_logging(args.verbose) source_url = 'https://fwd.app/api/cve-index' target_url = f'https://{args.target_host}/api/cve-index' session = create_session() file_data, filename = download_file(session, source_url, HTTPBasicAuth(args.fwd_user, args.fwd_pass)) save_file_locally(file_data, filename) upload_file( session, file_data, target_url, HTTPBasicAuth(args.target_user, args.target_pass), verify=not args.insecure_upload )if __name__ == "__main__": main()

Intermediate

I have been getting questions about interpreting the new CVE detection status in the Forward Networks Vulnerabilities application. This post explains the thought process behind the change and sheds light on how to interpret the new statuses. As you may know, most vulnerability scanners (especially the black box kind) rely on the OS version a network device is running to flag it as vulnerable to a CVE (or not). The information on whether a certain OS is vulnerable is typically publicized both in the CIS NVD database and vendor advisories. While relying on the OS version casts a wide net and typically does identify all the potentially vulnerable devices, it often identifies hundreds of vulnerabilities - many more than those that need to be prioritized for patching. The reason this approach identifies too many devices (false positives) is that it is unable to understand the configuration of the devices. For example, some of the devices may not enable the vulnerable module. A common example is a web management console which is subject to many Apache web server vulnerabilities. However, if a web management is not enabled on a device, such device would not be vulnerable. Historically, Forward Networks has been able to identify truly vulnerable devices and help the teams focus on addressing / patching those devices and their vulnerabilities. While the vast improvement over the generic vulnerability scanners, the older implementation of Forward Networks vulnerability detection had certain ambiguities. Specifically, the devices identified as having OS Match vulnerabilities could be vulnerable because the vulnerabilities in their OSes were always present, regardless of the configuration or possibly vulnerable, because Forward Networks has not yet implemented configuration analysis for those operating system or the configuration analysis did not complete. Further, Forward Networks treated equally the patched devices with OSes that did not have any known CVEs and the devices with vulnerable OSes but not vulnerable configurations by omitting both from the CVE list. Differentiating between these two cases would have helped with upgrade planning and results comparison between Forward networks and other vulnerability scanners. In the Forward App versions up to 25.3, the CVE detection decision tree is as follows: Release 25.4 addresses all of the above issues by making the CVE detection status more precise. Rather than two statuses, OS Match and Config Match, the new release publishes five detection statuses: Conig Confirmed Vulnerable (Vulnerable), Config-Independent Vulnerability (Vulnerable) , Config detection not supported (Possibly vulnerable), Config cannot be confirmed (Possibly vulnerable), and Config not vulnerable (Not vulnerable in the current configuration). CVEs that affect no operating systems found in customer environments are not listed. This decision was made for two reasons: It would introduce a lot of irrelevant information into the product. For example, CVEs that only affect IOS would never affect any network devices. There is no reason to mention them. It would bloat both the Forward CVE database and the UI with hundreds of pages non-actionable CVEs.On the contrary, including the CVEs that affect devices with the same OS, but not affect certain devices in their existing configuration is helpful because:It help reconcile the results from black-both vulnerability scanners like Qualys or Tenable that produce results only on the basis of the OS version It helps identify devices that could become vulnerable after a relatively minor configuration change. Here is a decision diagram for the new detection:Questions on CVE detection in Forward? Ask me in the comments below.

Intermediate

Extracting a Windows PFX certificate and key using OpenSSL is done for several reasons:Migration – Moving a certificate from Windows IIS to another server (e.g., Apache, Nginx, cloud platforms). Format Conversion – Extracting the certificate and key separately for systems that require PEM (.crt & .key), JKS, or DER formats. Client Authentication – Using the certificate for mutual TLS authentication in APIs, OpenVPN, or other security setups. Troubleshooting & Backup – Keeping separate key/cert files for SSL/TLS debugging or recovery. CLI & Automation – Using certificates in OpenSSL or other command-line tools that don’t support .pfx bundles.The first step to extracting a windows PFX certificate is to make sure that the certificate extracted includes the private key. This may require a custom certificate request that has the export private key request enabled. A windows PFX certificate that includes the private key will require a password to export the key and certificate(s).To extract the pfx certificate using openssl, run the following command:1. openssl pkcs12 -in win10_cert.pfx -nodes -out win10_cert.pemEnter Import Password:Enter the password for the private key when the certificate was exported from windows. I’ve broken apart the different segments of the extracted certificate below:1. Bag Attributes2. Microsoft Local Key set: &lt;No Values&gt;3. localKeyID: 01 00 00 004. Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider5. friendlyName: te-Machine-d49b9a0d-7106-4e6b-8a67-c95cec7601556. Key Attributes7. X509v3 Key Usage: 10 The first block in the output is the private key. Copy just the key starting and ending at:-----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- Copy this entire block to a file called hostname.key8. -----BEGIN PRIVATE KEY-----9. MIIJQwIBADANBgkqhkiG9w0BAQEFAASCCS0wggkpAgEAAoICAQDH7P2fR6X5xXWN10. rln5cwKne7WqWZ04TS43gamKKEsgvqoCmVT+UD18AjhI/R3wUHMBrTLxIjk4Qidf11. vJY30UuYflXtKHyFZlKEorp5xJYSThSXRIRIPOhgZesVTwtUVIQc1gw494eAKPNR12. h3FA5Z2ISQwYpL/i/LzK17DXB3g8z8zUoYPbMAghyWEqzbi4drGEIcGbMx7IZqw+13. wgpUOIjOiMnbul0UzqrP2j0Brjkaov4T13/HYAYKLWlczDvuuYvjR5mMTaxsQ6xK14. n9rt4kv+HK0wq6pbUL3yd7aRuHJk5QPxm2feZh+tu0IXpko2gz5Tn/xUJ8M77Zcc15. hA3V83uh3Sui/WTiiDs8oIt41fPK78rwoT8lx5ybYvSVOl1KTZIvX8MlTIdj3BRo16. RiqNRAxpc5SfEcK30ULlAoL9yOy/h0bpsW8keq2Q0FEXcGARIYHk1bCv+Cjf6Mfe17. AOyIy8OsEotatIWBn49ir33WM1PuvjnEyZPY9c4o2U/hdxQm21A8int9kZuxQkHv18. 4NZeMwQA+zhdNy9auEDlO7CjCFaRW8pUilxMITjXNsRT89KdQpibOW1gom+yP6HT19. t3tO0RlIpB68o8zpnbgUPgVe0N/mjEVyjNRJ/5bvbInjOTPaKhy19u5F08lnrjcb20. PoA5T7L3PC8dE4cCF2IZeYQGovUIFQIDAQABAoICAQCeaRGsm0DP3719PaDdHlwE21. hTIsgEYwrnB5sRqVsk5c5LkdT6tXdqZSehj6BnmWdj55H8pyeTkdr6Fcn70AsEY222. WtJ/tgWNxTQ8Ys6uN8+sUioFznVGqvR+29lKk+BJwUQpTqLIq5juaxtI5PlxhTN323. bxusV2teRJbKJ1USBLrFp6/SDNq0qE02tk4+z4Sn7b7KMIDy2JMv7B0DzK/3XwZ724. 9E+E2jAfEDl93tC1ssYpmzOPReMo/KByo0iGQ6Ac3X+FByh/4E9tKSIRIaliWhFi25. FzZyTVs42elbtkYFOqt9sWvRrxhnHaT/N8cMyYMjfn4T8OtCpHxQyhVUDvROTJId26. 7XNH9gFlqIq+TG/RDVSAdPcVWyV5ewHO4AxOVFa1zRBbtLewmfd4v/iHb8cXa/KT27. Bg2JHMDnaU/jJ0+q7pBFPZO8KXiQRLrr70de33ZxOWTinJ0M7B0HGdUbj/zVx43I28. LgS6NofJwW4ib5h4FLv+IQKCAQEA4ZWMUMRW02Uw2b1FtCQAmJE1EMJ0lpFnYiaW29. N7IOrvN02Pl499HiIGpMAMtg6DPEeTxk2YX2Hp0IgZY5eOmwuZUoJcznr8xCN0Jh30. 9Pj4pU6HyXJjYUDpjgnXYHH4mKWnT0wE34mv1fAYqvtdy/E9yicvCF71UX41Sw3h31. P4XrnvggzZzbEOVtUsGpDzRKdW7jEe2DIyAhkQFdvDMuF+0AhONeSQs+QYsMHfCQ32. 9BwtM7vEowqFmSzFlraAUYUlFLH+AjWhMMRhtDaxfrGAUcunD4H66Tb23sqAqWL833. vd1VnIJf+hmSk/kVh6HR9/PKfIcUq5Gg/kUPw+JgWc4PHqwV4wKCAQEA4uHLfOg334. 29sjzeiJ2Z1Byj4kLHIdb/rDCCfGJmxUfnGmYGXgG2ncIZcuFtCesrO28stsdPL/35. xgKDcsXvt8wEvWFn+ModtydGnN4SnfWgZ41kCPtqPmhtp8VZtPmJrNkE1rAz71dd36. 48yJooi5UUGtxihrQ6lIf2B97KT4hgo+OZ14Tnu0IiRQchf4E7tAvIP85x4FsRmJ37. zAX0KDhpPV7PTdBP9+gBNh0KyDy3rThrOlVwiHyfZVoFvvWfUTlK46zT9O1pA9ge38. UokYA5U/kKc4H3IOY7049C1U4RwGMllkufs341rTTsBpOnCUxs2O3goCDuAYrh0639. La1f7GztUNYLpwKCAQB0MA2MUAQUb4sgqv7q0JxJ+IhncHCSWKPyBsPaPeiYLabi40. VmP66Gxam8U3p4jrMDai5vtemkPw8pq9+/zwDRVMEMoT5hzzC/aS9ar0fQO8SN1h41. YXxUTBW/Zcw7zZfoL3IkQphD9mvNehOKhVuDPma/5zyvSBF8fs++L5DzoeuA/nYO42. 0Rp38mNDe6GyxhEPuSRVSIsBnXwMbrKzy3yTMCvTRjR61MKlCZQdG5ndUWHqwmx+43. OV4kTc4bWTZwRm6Z4S9ePfce4hcctgrnoU7hUk5ii2ULl5bBm3V3SRe6RvTgXrpG44. W8OGWYXATRWTa0rApuZ7k89jB3keQEu2FY7uEl5XAoIBAEQCRRoLDft0Y/YsF25I45. 6liyaet8xYA0ndPLAGWyIV3JuYK55wSwpdDX3XPvUzLkFhoPilJAKRV02WxFEwd446. O499LEpyY5fsSQlqtA/vegawZmUe4AkXCo+445wRFQjgAMhOBzNecAGB5Vv4Ofy247. gF2e7hBZJScxiG2wQeMEHQTuRAran/OACTE6KB3aCpy3v86TvEcLDbg/rKGFz14b48. Fm8P23jHbd2HtRyyvqhI+jOBOvtex/T8mC5WuEwDrYQz4VFQ/SKu3OAGwlEIowY849. aeFbMh8JsJHZKNFVsjHThBMPz//x0NeRa7md16sEIShDvbwxxpQipLbeepuHR1fs50. 4Y8CggEBANAQPNFNP7HthQGuGsEQ4heWsA50naHFSvQ5JYCy76Ou6cbxmCIMlpZ651. kQxRnkK+tMZWkw3ridipWSoXmJXEddCRs7zeUFOAmERALAekcjP/fNn692KiID3w52. /clh78pUGMNsWgIY/fP9r/PAYADJ5U2kzNU8WRAZmngFiS98SMmLmmFgcf/wPio653. 5PixdFmDJUhr6wCABeyK0YoZM7a3YfL5A/ayshTzEE8AsaEOHFBMGbKtg0dK0DIQ54. Rp0fS06d9ordwTpba8PAgO3gVDfNc1eogmO3jJ8aZqZXky08pFS/1TuXGovkArKd55. JO8n3mVVMfNIUrT/Z45Xp+dN6AZMFds=56. -----END PRIVATE KEY-----57. Bag Attributes58. localKeyID: 01 00 00 0059. subject=CN=WinCA.ad.lab.local60. issuer=DC=local, DC=lab, DC=ad, CN=WinCA The second block is the host certificate. Copy just this certificate starting and ending at:-----BEGIN CERTIFICATE----- -----END CERTIFICATE-----Copy this entire block to a file called hostname.pem61. -----BEGIN CERTIFICATE-----62. MIIHrzCCBZegAwIBAgITWQAAAAV6eQwRvhFPjQAAAAAABTANBgkqhkiG9w0BAQsF63. ADBQMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxEzARBgoJkiaJk/IsZAEZFgNsYWIx64. EjAQBgoJkiaJk/IsZAEZFgJhZDEOMAwGA1UEAxMFV2luQ0EwHhcNMjUwMTAyMDA165. ODQwWhcNMjYwMTAyMDA1ODQwWjAdMRswGQYDVQQDExJXaW5DQS5hZC5sYWIubG9j66. YWwwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDH7P2fR6X5xXWNrln567. cwKne7WqWZ04TS43gamKKEsgvqoCmVT+UD18AjhI/R3wUHMBrTLxIjk4QidfvJY368. 0UuYflXtKHyFZlKEorp5xJYSThSXRIRIPOhgZesVTwtUVIQc1gw494eAKPNRh3FA69. 5Z2ISQwYpL/i/LzK17DXB3g8z8zUoYPbMAghyWEqzbi4drGEIcGbMx7IZqw+wgpU70. OIjOiMnbul0UzqrP2j0Brjkaov4T13/HYAYKLWlczDvuuYvjR5mMTaxsQ6xKn9rt71. y8OsEotatIWBn49ir33WM1PuvjnEyZPY9c4o2U/hdxQm21A8int9kZuxQkHv4NZe72. MwQA+zhdNy9auEDlO7CjCFaRW8pUilxMITjXNsRT89KdQpibOW1gom+yP6HTt3tO73. 0RlIpB68o8zpnbgUPgVe0N/mjEVyjNRJ/5bvbInjOTPaKhy19u5F08lnrjcbPoA574. T7L3PC8dE4cCF2IZeYQGovUIFQIDAQABo4ICszCCAq8wHQYJKwYBBAGCNxQCBBAe75. DgBNAGEAYwBoAGkAbgBlMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAO76. BgNVHQ8BAf8EBAMCBaAwHQYDVR0OBBYEFKlYYgC4rUe7J8YIdcJ9X7gYWNy4MB8G77. A1UdIwQYMBaAFLLxj8f8unA+mw5v8NqMAgpWBM3/MIH1BgNVHR8Ege0wgeowgeeg78. geSggeGGga5sZGFwOi8vL0NOPVdpbkNBLENOPVdpbkNBLENOPUNEUCxDTj1QdWJs79. aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u80. LERDPWFkLERDPWxhYixEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN081. P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGLmh0dHA6Ly9382. aW5jYS5hZC5sYWIubG9jYWwvQ2VydEVucm9sbC9XaW5DQS5jcmwwggEGBggrBgEF83. BQcBAQSB+TCB9jCBqAYIKwYBBQUHMAKGgZtsZGFwOi8vL0NOPVdpbkNBLENOPUFJ84. QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m85. aWd1cmF0aW9uLERDPWFkLERDPWxhYixEQz1sb2NhbD9jQUNlcnRpZmljYXRlP2Jh86. c2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBJBggrBgEFBQcw87. AoY9aHR0cDovL3dpbmNhLmFkLmxhYi5sb2NhbC9DZXJ0RW5yb2xsL1dpbkNBLmFk88. LmxhYi5sb2NhbF9XaW5DQTAdBgNVHREEFjAUghJXaW5DQS5hZC5sYWIubG9jYWww89. DQYJKoZIhvcNAQELBQADggIBALiJcwW+zCvZphslg+11YlZ/ENwJ1EkWwjA0/9/T90. eavu/EWVRca87GhD45vy9MwsOyfV+Nq60PtxybZpBtgxs3A2aXYvLbI9e7cWP6mN91. sAPKQh/FOWMgaNLZNEk24goOG5H0RF3TbAaV7b8uVcM2QmVg1MUYl7+bB2sCMhoR92. Cg1BXKFODR+LOJpwT7a9+rzzeMhUgemW/sZJIZcBTAVP9bDYnBHTe1l/QArU2ph793. nFIuCiPgUXkTlbc9NnE5gzDZ/AcfKKljCTvni2baiT9IXZLxq66wny84/TPPUL8t94. gQg/j76CIIkuCVpaWxn5TNQPrIlBhgb9437jzRQwHCrp+Az20sg+QA+LFQGZ2cM495. cDRy02iEl3XrX+Eyb79fUYWC7lgFvgK6OFh+piOeHxjtnDqgVFysrQT/IZOZEY0X96. 1YloIu6NlIlDBe6nt13MwUq76sa0qdg15GIixfc1ySOPYfXcU9etf5eb2Td3DWiu97. 2JPZW5rF/srmqaXDw1NglIvKWOPGbm6AQ4TgAEAcBLFR+6gtGIc35KOdc0rmv7KK98. T6piNL/S4WzWiBGNy0BdG1bxjD63WC5k0If7/FTDn7lRFqS0jvDdySxMfpIilz2999. nD7oe0SX4KtUIL1ldTXvbhcDbMC+ef62o+iv/xO606Mnl3ZAEeycNe+pi2iEX1fD100. hM87101. -----END CERTIFICATE-----102. Bag Attributes: &lt;Empty Attributes&gt;103. subject=emailAddress=youremail@mplx.local, C=US, ST=VA, L=Chantilly, O=LAB, OU=LAB-Test RootCA, CN=root104. issuer=emailAddress=youremail@mplx.local, C=US, ST=VA, L=Chantilly, O=LAB, OU=LAB-Test Root CA,CN=rootThe next two blocks are the sub-ordinateCA and root CA certificates. If you need the certificate chain, all three of these should be in the hostname.pem file (stacked).105. -----BEGIN CERTIFICATE-----106. MIIGDTCCA/WgAwIBAgIUM9oXbxz9n9ABgAdPRzalJ0K9EqQwDQYJKoZIhvcNAQEL107. BQAwgY0xIzAhBgkqhkiG9w0BCQEWFHlvdXJlbWFpbEBtcGx4LmxvY2FsMQswCQYD108. VQQGEwJVUzELMAkGA1UECAwCVkExEjAQBgNVBAcMCUNoYW50aWxseTENMAsGA1UE109. DAJWQTESMBAGA1UEBwwJQ2hhbnRpbGx5MQ0wCwYDVQQKDAREYWFzMRowGAYDVQQL110. DBFEYWFTLVRlc3QgUm9vdCBDQTENMAsGA1UEAwwEcm9vdDCCAiIwDQYJKoZIhvcN111. AQEBBQADggIPADCCAgoCggIBAL/jA+w+km/Zn13mg4XJrmCsQCiClVLFHzH6/dTe112. ngwn2qwOpc3oG+HnULAlq0ZeJdUrHFDfD356NBOQNKRzdpNEBBmGeCnGmTPL/7nw113. 1cu2b6X9Bdka/ZLTl48LZ8vhZLm8s1N9lPXm34HBl5Zvfi6rjUCOIkINe2+MCD6F114. 5h86gZdK+lvnl1gywJwRE8aI4IyZ37maE1nQ923iblQVqe+rgfhW4LGGHeVAR40m115. C5IRmCdveVlYIKWAbl15rc8/06ANF21jdLVr/MarxPxAEt6qUNMooV6Nq6VbHsAj116. IWYpHKLPnUB6PLB+aWeAWY655ljCourzwoH8CxK73LH1FZosOlIAgmvre+prZVb6117. aid98M8SECWtPH1hrv5TSNkpxAj+yCd1vVX0WBaCJzK4z0fcEw8/MtR8doHme1kg118. bjA5BDJvTaR8cAS2M7QGDxfDtbs05mYKi7IwKrr8ViQcj0bcL7Muxr19XEFEMq9U119. jsTP8O0k2wNoSPtrZ0aOjfFh8MxMvUwZvqzw3S24OzXJPOMsbJFj6Clshm9K3Nca120. 0L2z9ZCDaDwvdnY7MT0yaMYc1hCsyc6+N8m8WVwDYRG3W39W5ODNUV46EfVzaoi5121. 0xM+dRwPCxPlahccyUxECPO3b7RCPwd63eWpIYyWwE60SRwWA1ZYhdbgUXKOvJ+p122. QqQVAgMBAAGjYzBhMB0GA1UdDgQWBBTlfZC2UAr+loOAkXgwrE0+kITx3DAfBgNV123. HSMEGDAWgBTlfZC2UAr+loOAkXgwrE0+kITx3DAPBgNVHRMBAf8EBTADAQH/MA4G124. v1IdIKJXhxd9FjclVJ5oWeL+x9MBwj19T+1AVkK25DLC/AxwAB7dJdUlxjUMOTDu125. NHlstqavAfzNRr37czdarvvgN7ghpA4LD5QHvXbtQG7EqYczL7GY4TzKXZ3Amzgj126. WjgZ795hzx0bKH56Tp5MR24p955iRyeyaDwVJ0lS8pakB6Bqam71YaK/YUSHOG2S127. 0r0UF6UJMvLF6N2Z1iHdJEYzwgt1aD4xn5CrrmzorTR8IrLDuBi2r3RbG9PNxJhY128. pBxYs1WFBhxFkPpMSWZarKP4VAoMvH0yVrvMsxv1Eaimdwf5GiOYgahFebSh3+LX129. vJdco0sgzb1Qn3rrHTdirXkR8trpNj8IX6JaEJ5S5oy7clw/eRosF2dqC7nhfFRL130. 1A5XasLhvUPnJFBqZlNteg24HwjILrSxV4h0eg1LOK2BtO9NuWSVhIhDFUrZozro131. IbpWCyQAv+q1UOcylEO3jhYzE9E6BukuMGMP3XYBqjXnBqxHHxHVYeNoiRmhns9O132. 2HusZD/yty2LPRv4m8NUf6A=133. -----END CERTIFICATE-----134. Bag Attributes: &lt;Empty Attributes&gt;135. subject=DC=local, DC=lab, DC=ad, CN=WinCA136. issuer=emailAddress=youremail@mplx.local, C=US, ST=VA, L=Chantilly, O=LAB, OU=LAB-Test Root CA,CN=root137. -----BEGIN CERTIFICATE-----138. MIIF7zCCA9egAwIBAgICEAIwDQYJKoZIhvcNAQELBQAwgY0xIzAhBgkqhkiG9w0B139. CQEWFHlvdXJlbWFpbEBtcGx4LmxvY2FsMQswCQYDVQQGEwJVUzELMAkGA1UECAwC140. VkExEjAQBgNVBAcMCUNoYW50aWxseTENMAsGA1UECgwERGFhczEaMBgGA1UECwwR141. RGFhUy1UZXN0IFJvb3QgQ0ExDTALBgNVBAMMBHJvb3QwHhcNMjQxMTE3MTczMDE4142. WhcNMzQxMTE1MTczMDE4WjBQMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxEzARBgoJ143. kiaJk/IsZAEZFgNsYWIxEjAQBgoJkiaJk/IsZAEZFgJhZDEOMAwGA1UEAxMFV2lu144. Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDDa2axEJvB3DzQGb8C145. UdVuV0VozRjZ/04jQ7Zgb/kzdCRgs8FGyFkPe9yNamSH+8Q9dy1ixzViZPyUJLL1146. kNdJ3Odnq+FnJeLkO8hcFugbcUAIVQwnDOAU0LSB+M6F+Uksh+0/KtwwkfAF2Uhn147. rYUj5f9POi0R+KThsBrAUqJ3bc79tRhD9/i2Ybuo9PJeLySp4PVy/O2kabhsR7++148. VcvN8ZknPOKy5BLrFJmev88mYXvlHoWGuzHjr8pmJTUcIUd0fVAhD0wD+LBpDQKt149. MROyGojv037lRWSCBaSbSLdXcuaNnwqMV7upIaAw64xW45ob50ohNCB+HPH3pIDV150. m+Wu5wyIz5A8/i9mwTCWgIWkpSoljYgJJFRB3TokcWfcYKZJf5HBFleV6pl4+6Ds151. Il1GDY2PsTh6cKNvwpdPKtCm3A7+La5uVjyJKnfEavuLdlR65LBIH6st8IQIl2+P152. NVGNHXznVXC+P8WIsIW8/XcR/QIDAQABo4GUMIGRMB0GA1UdDgQWBBSy8Y/H/Lpw153. PpsOb/DajAIKVgTN/zAfBgNVHSMEGDAWgBTlfZC2UAr+loOAkXgwrE0+kITx3DAS154. BgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjArBgNVHR8EJDAiMCCg155. HqAchhpodHRwOi8vMTcyLjE2LjE1LjkvY3JsLnBlbTANBgkqhkiG9w0BAQsFAAOC156. AgEAs/q5sbGjXBzm6wseJGv1tlkMnmBCgN+7Xyd23p78i7KBZyLQc5tCfW5StcEU157. ZGl0dzF+bHcO7FD1Bd8u3Zj9R/nQG+xJEc1CEeaIjoLeidRcHwBJ42LCQCZ3nBaQ158. gF9BeU7oVRqIkwvHlcOJ8jMLIwUAciUbaO7dFnZxxO+sa5cCOdNi7p9cSxvpv2jQ159. NvQTmwfMMTXX2IEu8DwsJqLs8PYvZtuDX5OCPRaX9j6f/Gtth9EdOHfzRTqbGD9a160. o7WB6EgcNW9NtXQ278bHuJA4YMmqPGtfNcxWPiINLxi/D3lDmscZhDYRNkxqCuXf161. LhT/L2SkPHJg9zeuaqXS1gcQKRDxqzhNMaf99hA5wccxMVKC00O6by+Ti16KyQvI162. 0F1KrOcPcIVoA25JLd/WUQsd++tAv3y9vQ8lyanzdc/0KVzF5D3MFuBfcOuU3DaP163. OqC64JDLMINoBhBhb5SZM3TTjsv9fLa0X8FOuFJr3qlLigUKnDq8ndSJ0A8vu5b6164. PgCWaoyrFLjiPooiD7IGsKG8Xe45C3ukF/nZ6GWipHXhjVoQIOLxb4Xo/A0kjn3I165. 3wO+k3ugDB83NDd05o33+E7rywqwo+oubIssVYLmQ6eZgY/vsezUNQP96jn0aSCT166. ot/p6Jx8srvKSjks/97LFVxq27z/goOVwN7kO1B/mT/7PUg=167. -----END CERTIFICATE----- When managing certificates across different systems, having the flexibility to extract and convert a PFX certificate and key can be invaluable. Whether you’re migrating to a new server, securing client authentication, or simply troubleshooting an SSL/TLS issue, OpenSSL provides a straightforward way to handle these tasks efficiently. By understanding when and why to extract these components, you can ensure a seamless and secure integration across various platforms and applications.

Using Forward Enterprise - Intermediate

Forward Enterprise - Intermediate Topics 🟦

Path Search - Understanding the Difference Between Destination IP and To

STIG Compliance Checks

Change Control Workflow Automation with the API

SSO - How to connect Forward to LDAP/S

Create an exportable function to validate a device setting for any device type

NQE to Identify IP Subnet Utilization

Using Intent Checks to Verify a Change Control

Enhancing STIG Compliance Checks with Parameterized Queries

Keep CVE Data Current in Air-Gapped Forward Enterprise Instances

How to read the new CVE Detection statuses in 25.4+

Extract Windows PFX certificate and key with openssl

Check for Unused Firewall Rules (and Catch New Ones Too)

Other Levels

Intermediate Resources 🟦

Using Forward Enterprise - Intermediate

Forward Enterprise - Intermediate Topics 🟦

Path Search - Understanding the Difference Between Destination IP and To

STIG Compliance Checks

Change Control Workflow Automation with the API

SSO - How to connect Forward to LDAP/S

Create an exportable function to validate a device setting for any device type

NQE to Identify IP Subnet Utilization

Using Intent Checks to Verify a Change Control

Enhancing STIG Compliance Checks with Parameterized Queries

Keep CVE Data Current in Air-Gapped Forward Enterprise Instances

How to read the new CVE Detection statuses in 25.4+

Extract Windows PFX certificate and key with openssl

Check for Unused Firewall Rules (and Catch New Ones Too)

Other Levels

Intermediate Resources 🟦

Sign up

Select a login option:

Welcome to the Forward Networks Community

Select a login option:

Scanning file for viruses.

This file cannot be downloaded