0

I am having some issues when trying to use a teleport node as a sort of proxy to scan resources inside networks behind that said proxy node.

My setup looks like this: I have a node inside my Teleport cluster that i would like to use to proxy nmap scans to resources behind this node (the resources are disconnected from the internet, the teleport node acts as the only link to the outside, to access the resources you need to first ssh into "proxy node" and then you gain access to the resources inside the said network).

I want to be able to do this remotely from another teleport agent so I basically start a dynamic port forward: tsh ssh -D 1080 <teleport_node>

Then I use this new socks5 proxy in conjuction with proxychains to scan a resource in the network i mentioned before: proxychains4 nmap -sT -Pn -sV -n <resource_ip>

The result is that somehow... all ports are open and tcpwrapped. The same command but using scanme.nmap.org as the resource never actually ends (or i never waited enough for it to end, but i don't think it actually ever ends).

Removing the -sV flag from nmap does make it "work" but renders the output absolutely useless because all ports are seen as open.

Doing the same exact thing as above but instead using standard ssh (OpenSSH) to dynamically port forward traffic results in the expected outcome: ssh -D 127.0.0.1:1080 <teleport_node>

Does anybody have any idea if tsh somehow changes the way that a normal dynamic port forward works as opposed to using ssh?

1
  • nmap doesn't use normal TCP/IP sockets; rather they use raw sockets which essentially bypasses a lot of the networking stack in the OS. Commented Apr 11, 2024 at 10:25

1 Answer 1

1

Nmap can not operate through a proxy by design. If there was such a possibility, it would be written into a Nmap code itself long time ago (it's a very mature software) and you weren't need to use proxychains or whatever redirector.

It is supposed to connect to target systems directly. It needs to observe every bit of the connection behaviour. Even the time delay of some reply packets can make a difference (for example, for the OS fingerprinting code).

Obviously, it all would be hidden by the proxy when it is behind a proxy. In this case proxychains replaces a library syscall function with its own wrapper, and that wrapper first connects to a SSH dynamic forward proxy and that connection succeeds, and that success and other connection information is being reported to the original caller, e.g. Nmap, which it then shows to you. So congratulations, you are only scanning a proxy and therefore obtaining information about the proxy itself, e.g. about your SSH client machine!

You can't make this work with any flags you can put there. Instead, install Nmap within the perimeter, e.g. on the virtual machine inside that network, and then you can use it in the SSH session, it will perfectly work that way.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.