Skip to main content

Port

Checks if a TCP port is open or closed on a given IP address or hostname. This node is crucial for network security audits, service availability monitoring, firewall configuration validation, and ensuring critical services are accessible.

Common Properties​

  • Name - The custom name of the node.
  • Color - The custom color of the node.
  • Delay Before (sec) - Waits in seconds before executing the node.
  • Delay After (sec) - Waits in seconds after executing node.
  • Continue On Error - Automation will continue regardless of any error. The default value is false.
info

If the ContinueOnError property is true, no error is caught when the project is executed, even if a Catch node is used.

Inputs​

  • IP - IP address or hostname to check. Can be a domain name, IP address (IPv4), or localhost.
  • Port - Port number to check (1-65535). Common ports include 80 (HTTP), 443 (HTTPS), 22 (SSH), 3306 (MySQL), etc.

Options​

  • Check Port - Determines the expected port state:
    • Port is open - Returns true if the port accepts connections
    • Port is closed - Returns true if the port refuses connections
  • Timeout - Timeout in seconds for the connection attempt (default: 60 seconds)

Output​

  • Result - Boolean value indicating if the port matches the expected state:
    • true - Port state matches the check condition
    • false - Port state does not match the check condition

How It Works​

The Port node attempts a TCP connection to verify port accessibility. When executed, the node:

  1. Validates the IP address/hostname and port number inputs
  2. Creates a TCP connection attempt to the specified host and port
  3. Waits for the specified timeout period for connection
  4. Determines if the port is open (connection successful) or closed (connection failed)
  5. Compares the actual state with the expected state (Check Port option)
  6. Returns true if actual state matches expected state, false otherwise

Example Use Cases​

Verify Web Server is Running​

Check if HTTP/HTTPS ports are open and accepting connections:

// Input
IP: "www.example.com"
Port: "443"
Check Port: "Port is open"
Timeout: 10

// Output
true  // HTTPS server is running and accessible

Database Availability Check​

Monitor if database server port is accessible:

// Input
IP: "db.example.com"
Port: "3306"
Check Port: "Port is open"

// Output
true  // MySQL database is accepting connections

Security Audit - Verify Ports are Closed​

Ensure non-essential ports are properly closed:

// Input
IP: "production-server.com"
Port: "23"  // Telnet port (should be closed)
Check Port: "Port is closed"

// Output
true  // Port 23 is properly closed (secure)

Service Deployment Verification​

Confirm service is listening on correct port after deployment:

// After deploying new API
IP: "api.example.com"
Port: "8080"
Check Port: "Port is open"

// Output
true  // API is successfully deployed and listening

Load Balancer Health Check​

Verify backend servers are accepting connections:

// Check each backend server
IP: "backend-01.internal"
Port: "80"
Check Port: "Port is open"

// Repeat for backend-02, backend-03, etc.
// Only route traffic to servers returning true

Multi-Port Service Monitoring​

Check if all required ports for a service are open:

// Web application requiring multiple ports
// Port 80: HTTP
// Port 443: HTTPS
// Port 3000: Admin Panel
// Port 5432: PostgreSQL

// Check each port
// Alert if any required port is closed

Common Port Numbers Reference​

Web Services​

  • 80 - HTTP
  • 443 - HTTPS
  • 8080 - HTTP Alternative
  • 8443 - HTTPS Alternative

Database Services​

  • 3306 - MySQL/MariaDB
  • 5432 - PostgreSQL
  • 1433 - Microsoft SQL Server
  • 27017 - MongoDB
  • 6379 - Redis

Remote Access​

  • 22 - SSH
  • 3389 - RDP (Remote Desktop)
  • 23 - Telnet (insecure, should be closed)

Email Services​

  • 25 - SMTP
  • 110 - POP3
  • 143 - IMAP
  • 587 - SMTP (Submission)
  • 993 - IMAPS
  • 995 - POP3S

Other Services​

  • 21 - FTP
  • 53 - DNS
  • 389 - LDAP
  • 636 - LDAPS
  • 9200 - Elasticsearch

Tips for Effective Use​

  • Use Specific Timeouts - Short timeouts (5-10s) for local networks, longer (30-60s) for remote servers
  • Port Range Scanning - Use a loop to check multiple ports sequentially
  • Hostname vs IP - Hostnames require DNS resolution (slightly slower); IPs are faster
  • Security Consideration - Regular port scanning can trigger security alerts; coordinate with security teams
  • Firewall Impact - Some firewalls drop packets silently, causing timeouts instead of immediate rejections
  • Service vs Port - An open port doesn't guarantee the service is working correctly; use Website or other nodes for full verification
  • Internal vs External - Check both internal and external accessibility for public services
  • Regular Monitoring - Schedule port checks to detect unauthorized changes or service failures

Common Errors and Solutions​

Error: "IP cannot be empty"​

Cause: The IP input is missing or contains an empty string.

Solution: Ensure the IP input variable contains a valid hostname or IP address.

Error: "Port cannot be empty"​

Cause: The Port input is missing or contains an empty string.

Solution: Provide a valid port number (1-65535).

Error: "Status check cannot be empty"​

Cause: The "Check Port" option is not properly selected.

Solution: Select either "Port is open" or "Port is closed" in the options.

Error: "Invalid port number"​

Cause: Port number is outside the valid range (1-65535) or not a number.

Solution:

  • Ensure port is between 1 and 65535
  • Verify the port variable contains a numeric value
  • Check for extra spaces or non-numeric characters

Connection Timeout​

Cause: Connection attempt exceeded the specified timeout.

Solution:

  • Increase the Timeout value
  • Verify the hostname/IP is correct and reachable
  • Check network connectivity
  • Confirm no firewall is blocking the connection
  • Verify the host is online (use Ping node first)

Expected Port Open but Result is False​

Cause: Port is actually closed or filtered by firewall.

Solution:

  • Verify the service is running on the target host
  • Check firewall rules on the target host
  • Confirm network firewalls allow traffic to that port
  • Use netstat or similar tools on target to verify port is listening
  • Check if the service is bound to the correct interface (0.0.0.0 vs 127.0.0.1)

Expected Port Closed but Result is False​

Cause: Port is actually open (potential security issue).

Solution:

  • Investigate what service is running on the port
  • Review server configuration
  • Close unnecessary services
  • Update firewall rules
  • Conduct security audit

Integration Examples​

Complete Server Health Check​

// 1. Ping server to verify network reachability
// 2. Check critical ports:
//    - Port 22 (SSH) - should be open for admin
//    - Port 80 (HTTP) - should be open for web
//    - Port 443 (HTTPS) - should be open for web
//    - Port 23 (Telnet) - should be closed for security
// 3. Use Website node to verify web service
// 4. Generate health report

Security Compliance Audit​

// Check all servers in infrastructure
// Verify insecure ports are closed:
const insecurePorts = [21, 23, 69, 135, 139, 445];

// For each server:
//   For each insecure port:
//     Check Port: "Port is closed"
//     If result is false: Flag security violation
// Generate compliance report

Service Deployment Validation​

// Deployment checklist automation
// 1. Check if old service port is closed (e.g., 8080)
// 2. Check if new service port is open (e.g., 9000)
// 3. Verify firewall updated (external check)
// 4. Test service functionality (Website/API nodes)
// 5. Mark deployment as successful only if all checks pass

Load Balancer Backend Monitoring​

// Monitor all backend servers
const backends = [
  {ip: "10.0.1.10", port: "80"},
  {ip: "10.0.1.11", port: "80"},
  {ip: "10.0.1.12", port: "80"}
];

// For each backend:
//   Check if port 80 is open
//   If closed:
//     - Remove from load balancer pool
//     - Alert operations team
//     - Log incident

Database Failover Automation​

// Check primary database
IP: "db-primary.internal"
Port: "5432"
Check Port: "Port is open"

// If result is false (primary down):
//   1. Verify secondary database is available
//   2. Update application config to use secondary
//   3. Send alert
//   4. Monitor primary for recovery

Network Segmentation Validation​

// Verify network segmentation is working
// From DMZ server, check:
//   - Can access port 443 on web server (should be open)
//   - Cannot access port 3306 on database (should be closed/filtered)
// Ensures proper firewall rules

Port Scan Detection System​

// Monitor for suspicious port scanning
// Track port check attempts
// If >10 different ports checked from same IP in 1 minute:
//   - Log potential port scan
//   - Alert security team
//   - Consider IP blocking

Microservices Health Monitoring​

// Check all microservice ports
const services = [
  {name: "Auth Service", ip: "auth.internal", port: "8080"},
  {name: "User Service", ip: "user.internal", port: "8081"},
  {name: "Payment Service", ip: "payment.internal", port: "8082"},
  {name: "Notification Service", ip: "notify.internal", port: "8083"}
];

// For each service:
//   Check port is open
//   Record response time
//   Update service registry
// Generate microservices health dashboard