Frequently Asked Questions

General FAQs

Firebind Recon was launched in 2020 and focuses on finding weaknesses in network security controls.  Firebind Recon uses software agents deployed in different network segments to transmit custom payloads of PII and/or threat data (malware, etc.) to continuously test firewall rules, IPS/IDS rules, DLP rules and router and switch ACLs.  Firebind Cloud was launched in 2016 and uses software agents to continuously test last-mile network performance to the Internet.  See the Firebind Cloud page for its FAQ.

Firebind Recon - Trial and Pricing

After filling out the trial request form, you will be contacted within a few hours (M-F).  A corporate email is requested but if you submit the trial request with a non-corporate email we will still consider your request.  No credit card is required.  The standard trial period is 14 days but can be extended as needed.  After the trial period ends the user can subscribe to a paid plan or simply retain access to the features of the free plan.

Firebind Recon has a free tier that provides a single agent license and on-demand testing.  Paid plans provide various additional capabilities including any number of customer agents, scheduled testing, automated alarming, and more.

Firebind Recon - Operation

Firebind Recon agents are available for:

  • Windows 10 or Windows Server 2012 or later – 64-bit
  • macOS 10.11 or later – 64-bit
  • Linux (x86_64) – 64 bit
  • Raspberry Pi 3 of 4 – full agent installer available if running Ubuntu Server 18.04 64-bit or later
  • Raspberry Pi 1, 2, 3, or 4 – customer supplies 32-bit Java installation and deploys with Firebind agent jar file using Firebind provided script
System Requirements
  • Single core or better
  • 300MB RAM
  • 200MB disk space (Windows and macOS), 350MB disk space (Linux)

Upon creation of an agent, links to each of the above installers will be provided. To install, simply run the installer and paste in the Agent ID that was generated during agent creation.

After installation it may be necessary to reboot the machine, however, after that, the agent will automatically start up upon start or reboot of the machine.

Firebind Recon agents poll the web console every 30 seconds. The polling mechanism allows for:

  • Providing a “heartbeat” to the console to let the console know the agent is still operational
  • Retrieving protocol script information
  • Retrieving scan configuration information including target, protocol script, schedule, and suite
  • Retrieving other instructions including “scan now”

Results will show a port was open or closed. Open means the payload sequence completed successfully between customer agent and Firebind Recon target without being modified. Closed means that the payload sequence failed in some way for the given port.

Port Closed Messages

1. Handshake Connection Refused

For TCP port testing, this indicates that while the client was trying to establish a 3-way handshake with the server, upon sending the initial SYN packet, the client received back a TCP RESET (TCP RST) from an intervening network device, forcing the client to close the connection. This is one of the 2 common methods of firewall blocking of TCP ports. For UDP port testing, this is not applicable.

2. Payload Receive Refused

For TCP port testing, this indicates the client was able to complete the 3-way handshake (establish a socket), however, after sending the test payload, the client received a TCP RESET (TCP RST) message, forcing the client to close the connection. The most likely case is that some intervening device (such as a firewall or proxy server) intercepted the connection and established the socket with the client (as opposed to the client establishing a socket directly with the Firebind Recon server.) Then the firewall or proxy decided to forcibly close the connection since the payload didn’t meet the firewall or proxy criteria for passage. For UDP port testing, this could indicate the client receiving back an ICMP Host Unreachable message.

3. Payload Receive Time Out

For TCP port testing, this indicates that the client was able to complete the 3-way handshake (establish a socket), however, after sending the test payload, the client timed out waiting for a reply. The most likely case is that some intervening device (such as a firewall or proxy server) intercepted the connection and established the socket with the client (as opposed to the client establishing a socket directly with the Firebind Recon target.) Then the firewall or proxy dropped the payload since the payload didn’t meet the firewall or proxy criteria for passage. For UDP port testing, since there is no 3-way handshake (socket connection), this generally indicates a firewall blocking UDP traffic for the given port.

4. Handshake Connection Timed Out

For TCP port testing, this indicates that while the client was trying to establish a 3-way handshake with the server, upon sending the initial SYN packet, the client received no response from the server, indicating that an intervening firewall silently discarded (dropped) the SYN packet. This is one of the 2 common methods of firewall blocking of TCP ports. For UDP port testing, this is not applicable.

5. Payload Receive Error

For TCP or UDP port testing, this indicates some unknown error in the payload receive process. This could occur because the remote system closed the connection during an attempt to receive data. This error is possible but uncommon, and would be considered an edge case.

6. Handshake Connection Initiation Failure

For TCP port testing, this indicates there was a client problem initiating the 3-way handshake with the server in order to establish a TCP socket (the client was unable to send the SYN packet to start the handshake process.) This error is possible but uncommon, and would be considered an edge case. For UDP port testing, this is not applicable.

7. Payload Receive Mismatch

For TCP port testing, this indicates the client was able to complete the 3-way handshake (establish a socket), however, after sending the test payload, the client received back a payload that did not match what it sent. The most likely case is that some intervening device (such as a firewall or proxy server) intercepted the connection and established the socket with the client (as opposed to the client establishing a socket directly with the Firebind Recon server.) Then the firewall or proxy determined that the payload didn’t match the criteria for passage. This is a common failure result for TCP port 25 which many ISPs will only allow SMTP traffic to pass through. In that example, the client tries to connect to the Firebind Recon target on TCP port 25, but the ISP’s firewall intercepts, trying to validate that the traffic is formatted as SMTP packets. It then sends a message back to the client warning it that only SMTP traffic is supported (which Firebind interprets as this error message of “Payload Receive Mismatch.” For UDP port testing this indicates a similar scenario to TCP port testing except UDP doesn’t have the handshake phase.

8. Payload Send Failure

For TCP or UDP port testing, this indicates the client had a problem sending the payload to the server. This error is possible but uncommon, and would be considered an edge case.

Yes.  Firebind maintains a repository of Firebind Recon and third-party created payloads on our public Github account.

No. Firebind Recon exclusively sends traffic from the user deployed agent out to a Firebind Recon target agent that is operated by either Firebind or the user. Firebind Recon solely sends traffic to this other target in order to enumerate the security controls being enforced by the network security devices that are in the path between the 2 agents.