Discussion:
[RFC][NSE] Modify shortport.ssl and shortport.http to avoid tcpwrapped services
Daniel Miller
2012-09-14 21:28:55 UTC
Permalink
List,

Recently, I did a scan that resulted in lots of tcpwrapped services (I
think it was a firewall/router/tarpit), resulting in several SSL-related
scripts running for a long time before timing out. Checking into the
shortport.ssl function, I thought that it could be extended to check for
tcpwrapped services (while still matching ssl-tunnelled services that
get detected as tcpwrapped).

I also added the functionality to shortport.http, and made it match if
Version detection labels a service http. Here's the patch:

diff --git a/nselib/shortport.lua b/nselib/shortport.lua
index 9d18bdc..e41e881 100644
--- a/nselib/shortport.lua
+++ b/nselib/shortport.lua
@@ -176,7 +176,11 @@ LIKELY_HTTP_SERVICES = {
-- @usage
-- portrule = shortport.http

-http = port_or_service(LIKELY_HTTP_PORTS, LIKELY_HTTP_SERVICES)
+http = function (host, port)
+ return port.version.name == "http" or
+ ( port.version.name ~= "tcpwrapped" and
+ port_or_service(LIKELY_HTTP_PORTS, LIKELY_HTTP_SERVICES)(host, port))
+end

local LIKELY_SSL_PORTS = {
443, 465, 587, 636, 989, 990, 992, 993, 994, 995, 5061, 6679,
6697, 8443,
@@ -198,7 +202,8 @@ local LIKELY_SSL_SERVICES = {
-- portrule = shortport.ssl
function ssl(host, port)
return port.version.service_tunnel == "ssl" or
- port_or_service(LIKELY_SSL_PORTS, LIKELY_SSL_SERVICES, {"tcp",
"sctp"})(host, port)
+ ( port.version.name ~= "tcpwrapped" and
+ port_or_service(LIKELY_SSL_PORTS, LIKELY_SSL_SERVICES, {"tcp",
"sctp"})(host, port))
end

return _ENV;

Please let me know if anyone sees any issue with this. Since it affects
lots of things, I won't commit until I get some feedback.

Dan
David Fifield
2012-09-14 21:40:12 UTC
Permalink
Checking into the shortport.ssl function, I thought that it could be
extended to check for tcpwrapped services (while still matching
ssl-tunnelled services that get detected as tcpwrapped).
It looks fine to me. Here,
I also added the functionality to shortport.http, and made it match
+http = function (host, port)
+ return port.version.name == "http" or
+ ( port.version.name ~= "tcpwrapped" and
+ port_or_service(LIKELY_HTTP_PORTS, LIKELY_HTTP_SERVICES)(host, port))
+end
"if Version detection labels a service http": it already does that.
"http" is in LIKELY_HTTP_SERVICES. I think the check
return port.version.name == "http"
is redundant.

David Fifield
Daniel Miller
2012-09-15 02:15:51 UTC
Permalink
Post by David Fifield
"if Version detection labels a service http": it already does that.
"http" is in LIKELY_HTTP_SERVICES. I think the check
return port.version.name == "http"
is redundant.
Of course, I should have caught that. Thanks for pointing it out. I
think the new function would then be:

http = function(host, port)
return (port.version.name ~= "tcpwrapped" and
port_or_service(LIKELY_HTTP_PORTS, LIKELY_HTTP_SERVICES)(host, port))
end

Dan
Daniel Miller
2012-09-17 20:32:08 UTC
Permalink
Post by David Fifield
Checking into the shortport.ssl function, I thought that it could be
extended to check for tcpwrapped services (while still matching
ssl-tunnelled services that get detected as tcpwrapped).
It looks fine to me. Here,
I also added the functionality to shortport.http, and made it match
+http = function (host, port)
+ return port.version.name == "http" or
+ ( port.version.name ~= "tcpwrapped" and
+ port_or_service(LIKELY_HTTP_PORTS, LIKELY_HTTP_SERVICES)(host, port))
+end
"if Version detection labels a service http": it already does that.
"http" is in LIKELY_HTTP_SERVICES. I think the check
return port.version.name == "http"
is redundant.
David Fifield
I'm abandoning this change, since in some of my testing, services that
were detected as "tcpwrapped" actually succeeded later in responding to
SSL probes from NSE. I'm guessing this is due to the timing options of
my scan (especially --max-retries=1) leading to dropped packets and/or
rate limiting by the targets.

I'm open to suggestions from the list on how to modify scripts to
gracefully handle timeouts (which would be the case if the service were
truly tcpwrapped).

Dan

Loading...