Re: Scanning trough proxy, including Tor: Ethical consideration

[Jacek Wielemborek <d33tah () gmail com>]

W dniu 14.07.2015 o 13:44, Fabio Pietrosanti (naif) - lists pisze:
> Regarding the high-performance scanning trough proxy, including and
> especially Tor, did you considered the ethical aspects of such
> implementation?
>
> Up to now there are no point'n'click high-performance ports canning tool
> to work well behind Tor, this means that the Tor network abuse for ports
> canning exists, but it's not yet a major problem for Tor Exit Node
> operators.
>
> Whenever nmap will support scanning trough Tor with high-performance and
> high-accuracy, we will see a strong increase in amount of abuses of the
> Tor network.
>
> This will lead to problems to Tor Exit Node operators that on a
> volunteer basis support the Tor anonymity network.
>
> I'd suggest to keep the patch for scanning trough Tor, off nmap official
> software releases.
>
> I know it's a controversial topic, but consider the possible impact it
> will have on a public, free, volunteer run Tor network.

Hello Fabio,

Thank you for raising this topic. I have to tell you that I find it
really tricky - I am no expert on neither ethics nor tor and I think
that it would be trivial to come up with points to either defend or
attack the thesis that implementing features that specifically target
Tor is ethical. Here is my take on this topic:

First of all, I would like to try to rephrase what you said to make sure
I understand it properly - you worry that the implementation of scanning
features that easily work behind tor will invite script kiddies to
perform malicious activities using this network.

One of my main reasons why I believe that this should not be a real
worry is that Nmap is not the best tool for script kiddies. While it's
not as uncomfortable to use as Metasploit, it also has a different goal.
Nmap in my opinion is indeed a tool that can be used for security
testing purposes. An experienced hacker *CAN* use it, combined with
other tools, to gain access to systems. Philosophically though, I don't
find it trivial.

It's not like NSE scripts usually tell you "okay, so there's the default
password being used for this router, now just visit this URL and click
NUKE". I recently had a discussion with other Nmap developers regarding
adding post-exploitation capabilities to this tool. The general opinion
was that this is not "the Nmap way" to run exploits and automatically
take control of systems. I'm not sure if script kiddies would find as
much use of Nmap as you imagine.

You also mentioned the worry that this feature would become of "high
performance and high accuracy". It's impossible to achieve higher
performance and accuracy that Internet allows and what I would expect
the code I write to achieve is a very tiny fraction of this. The port
scanning features are quite slow (right now it's only possible to make
one connection per second) and far from efficient.

Even if I manage to fix the bugs I am currently struggling with, the
"problem" is that to the best of my knowledge, some (or maybe even many)
TCP ports are inaccessible behind Tor specifically because they put exit
node administrators at danger. I heard that SMTP is such an example,
because of spam bots.

The other thing - still, I have no exit node operator experience - is
that whenever I read about running such a node, it is advised to take
extra care. I heard pieces of advice such ranging from "use a separate
IP" to "live far away from box running a node server because it IS going
to be raided" and even official tutorials seem to suggest careful
configuration, including an exit node policy that would let through
connections to only 70 TCP ports [1]. Given that, I think that this is a
job for someone who knows what he's doing and is prepared to handle
various potentially anonymous people trying to perform malicious actions
using one's node. My Nmap branch won't probably be any of the biggest
worries then.

Now that I addressed the reasons why I believe that making a combination
of Nmap and Tor would not cause as many problems as you expect, I offer
you to take a look at the flip side of the coin. If you take a look at
port scanning research, you can see that it is gaining in popularity.
Take a look at Fyodor's work, Internet Census 2012, Zmap, Shodan and
Rapid7 research to see that internet-wide research is now something
basically being constantly performed. Leave an HTTP port open on the
Internet and you're guaranteed to see bots scanning it for exploits.
Some of this research is legitimate, some is malicious (agressive
"commercial" botnets), but I don't think that this can be avoided
anymore. And it definitely pushed the state of computer security
forward, slowly changing the mentality from "nobody will find a needle
in the haystack" to "it will be found sooner or later, so I'd better
patch it".

Given that, I would prefer things to speed up even further. If this
research is going to be performed, perhaps it's better to carry it out
with good tools so that at least exit node operators' bandwidth isn't
going to be wasted with repeated trials?

You might have a different opinion on this and I have to admit that I
hadn't given it a lot of consideration - keep in mind that I'm replying
to you within an hour of your original post. I hope though that at least
some of the points I'm making seem reasonable to you and you will note
that this is not a black-and-white issue.

Cheers,
d33tah

[1] https://blog.torproject.org/running-exit-node

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/