Also worth mentioning that bash also has network capabilities, you can check port like this:
: < /dev/tcp/google.com/80 && echo OK || echo ERRORThis even works on my Mac.
But one issue I encountered was timeout. I just tried:
: < /dev/tcp/google.com/8080 && echo OK || echo ERROR
timeout 5 bash -c ': < /dev/tcp/google.com/8080' && echo OK || echo ERRORYeah, I didn't know that. I definitely had a suspicion it was how you say, and "basically" was my fudge word, because I didn't know. I hadn't thought much about it, but I did not know for sure. Thanks for tellin me.
I've thought about this idea: mapping the internet to the Unix filesystem, a la proc. I know TabFS, but I think the mapping could be better.
I think it's an interesting problem to consider what a good mapping would be. But it's all tradeoffs I guess. I haven't thought that much about it. But it did seem interesting.
Maybe not interesting enough to really commit to, because it seemed kinda like a big project. But definitely interesting to consider. What do you think? What kind of mapping would you do?
As it happens (if memory serves) telnet can send some bytes on connection also, in attempting to negotiate terminal settings with the remote “telnet server”. That said the /dev/tcp trick is indeed great for bash though!
can you elaborate? From a stealth perspective, probing for a port will always reveal to the other side that they are being probed
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.