Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Testing if a port can be reached, using built-in tools other than ol' telnet

carehart.org

Post reply on HN
Print view View original

41–50 of 87 posts

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#41

Post by Snawoot »

Eduard wrote: post #32
Snawoot wrote: post #2

Not sure if I'd like to send anything into tested port just to tell if it is open. I'd rather stick with telnet or whatever is available. Also worth mentioning that bash also has network capabilities, you can check port like this: :

> Not sure if I'd like to send anything into tested port just to tell if it is open. can you elaborate? From a stealth perspective, probing for a port will always reveal to the other side that they are being probed

It's not about stealth, it's about a bad habit of sending some bytes without thinking how it will be interpreted.

Examples:

- Syslog-ng server will interpret it as valid log messages

- HP JetDirect on port 9100 will print HTTP request: https://twitter.com/AviKivity/status/1405147699557638145

- What if service is protected by fail2ban and accounting protocol errors?

After all, sending anything was not my intention, so I won't send.

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#42

Post by cassianoleal »

zee2345 wrote: post #5

Windows can install full Linux distro via WSL. You can have a nmap in two minutes! I like it much better than MacBook with its incompatible ARM cpu, and outdated commands from some ancient BSD!

GNU tools are generally one command away on macOS. So is nmap, and it takes a lot less than 2 minutes to have it running directly on the host. What's ARM incompatiblw with? Certainly not Linux distros, certainly not GNU tools, and certainly not networking. Not to mention that for most things that don't run native, Rosetta2 makes them work at near native performance.

You can also run Linux on a VM if you want. With the native macOS virtualisation stack in UTM it takes about 2 seconds to have a full Linux VM up and running.

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#43

Post by renewiltord »

zee2345 wrote: post #5

Windows can install full Linux distro via WSL. You can have a nmap in two minutes! I like it much better than MacBook with its incompatible ARM cpu, and outdated commands from some ancient BSD!

Big fan of using Orbstack for this. Full Linux VM with transparent access to Mac disk. I love it.

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#44

Post by goalieca »

amelius wrote: post #16

I sometimes wonder why we still use port numbers. Wouldn't it make much more sense to use strings to name ports?

I don’t see much value. Each packet has a source port as well as a destination port. The source port is usually random and is the port the server responds to. Proxies, nats, firewalls all handle port numbers very efficiently and the tcp and udp headers themselves only use 16-bits + 16-bits on the wire. These are aligned to a 32-bit boundary which helps efficient hardware and software parsing. There’s no variable length to worry about and waste more bytes on. There’s no string encodings like Utf-8.

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#45

Post by Dylan16807 »

> Another beneficial difference of this over the old telnet approach is that with that, a successful connection would show a blank screen if the connection, awaiting commands. You'd have to know telnet keystrokes and commands to break out of that

Not when it says "Escape Character is 'CTRL+]'" every time you run it.

Or does that depend on how you run it with the windows version?

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#46

Post by Dylan16807 »

HL33tibCe7 wrote: post #25
amelius wrote: post #20

Earlier quoted context omitted.

Yeah, but it's still port numbers under the hood. The big downside of this is that you can get clashes. For example, VNC uses 5901 and up on my system. What if I have some other service that uses ports in the same range? A more sane approach would be to call those ports e.g. vnc/work, vnc/meeting, etc. so there would be no conflicts and you would know what each port is used for. And it would work even if you don't ha…

The reason this hasn't been done is that it would require changes to the headers of TCP and UDP, which would be a massive undertaking (for similar reasons to why IPv4 -> IPv6 is such a pain). Would both the source and destination ports both be strings? Normally, for a client->server packet, the source port is meaningless, so what string would you use? Or would your new protocol support both string ports and integer p…

> for similar reasons to why IPv4 -> IPv6 is such a pain

Much less painful though because only the endpoints would need to know.

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#48

Post by keepamovin »

Kind of unrelated but here's a little bit of bash I use for checking this locally:

  # Check if the port is available
  is_port_free() {
    if [[ "$1" =~ ^[0-9]+$ ]] && [ "$1" -ge 1024 ] && [ "$1" -le 65535 ]; then
      echo "Valid port number." >&2
    else
      echo "Invalid port number." >&2
      return 1
    fi

    if netstat -lnt | awk '$6 == "LISTEN" && $4 ~ ":'$1'$" {exit 1}'; then
      # Return a truthy value if the port is available
      return 0
    else
      # Return a falsey value if the port is in use
      return 1
    fi
  }

Re: Testing if a port can be reached, using built-in tools other than ol' telnet

#49

Post by AceyMan »

mkirchner wrote: post #13

Ha! This was probably the first serious problem I ever tackled with an open source contribution! The year was 2002, the 2.4 Linux kernel had just been released and I was making money on the side building monitoring software for a few thousand (mostly Solaris) hosts owned by a large German car manufacturer. Everything was built in parallel ksh code, “deployed” to Solaris 8 on Sun E10Ks, and mostly kicked off by cron.…

The syntax is different and I don't remember who compiles the binaries, but as a primarily Windows sysadmin, tcping is literally the first thing I put in my %PATH% on a new jumpbox; even ahead of dig, believe it or not.

(After that it's Russinovich's sysinternala suite.)

Post reply on HN