🔄 Topic

Understanding why a service may fail even when a system is reachable.

🎯 Goal

Identify the difference between a reachable host and a working service.

🛠 What I Did

Investigated SSH connection failures by checking:

if the service was running
if the port was open
if the system was reachable

Used tools like:

ss -tulpn

to verify listening services.

This helped separate three different questions that are easy to mix together:

can I reach the host?
is the service actually listening?
is something in the path blocking the connection?

🔗 Key Cybersecurity Connections

Attackers and defenders both rely on:

service enumeration
identifying open ports
validating reachable services

🔍 Investigation Questions

Is the service running?
Is the port listening?
Is the firewall blocking access?

🚨 Detection Opportunities

unusual service exposure
unexpected open ports
abnormal listening processes

🧭 MITRE ATT&CK Techniques

T1046 — Network Service Discovery

⚠ Challenges

Confusing:

network reachability
service availability

📚 What I Learned

a host can respond but still refuse connections
services must be explicitly running
verification requires multiple checks
troubleshooting improves when each layer is tested separately
“connection refused” and “host unreachable” point to different problems

➡ Next Steps

explore firewall configurations
simulate blocked vs open services

🧠 Reflection

This reinforced a critical mindset:

Never assume — always verify.

🧩 Lessons Learned

What worked

Layered troubleshooting.

What broke

Assuming connectivity equals functionality.

Why it broke

Different layers behave independently.

Fix / takeaway

Validate network, then service.

This is the kind of small distinction that matters in alert triage. A reachable host with a closed port is a different story from a missing host, a firewall block, or a broken route.

📈 Skill Progression Context

This strengthens troubleshooting and investigative thinking.

😄 TL;DR

The server wasn’t broken…
it just wasn’t listening.