Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: new script tcp-connect.nse
From: Hani Benhabiles <kroosec () gmail com>
Date: Wed, 20 Jun 2012 21:30:25 +0100

On 06/20/2012 08:56 PM, Toni Ruottu wrote:
Fair enough. Feedback is good. It might look too much like an error
message at the moment. I do not know how to improve it though.

On Wed, Jun 20, 2012 at 5:31 PM, David Fifield <david () bamsoftware com> wrote:
On Tue, Jun 19, 2012 at 08:52:38PM +0300, Toni Ruottu wrote:
On Tue, Jun 19, 2012 at 8:25 PM, David Fifield <david () bamsoftware com> wrote:
On Sun, Jun 10, 2012 at 03:12:32PM +0300, Toni Ruottu wrote:
I wrote a new script last week. It connects to a tcp service to make
sure the port is really reachable. There are a few use cases for this
- The user runs a TCP SYN scan, and wants to separate oaks from
apples. Which open ports are really open, and which ones are merely
open in the firewall?
- The user runs a TCP connect scan against a firewall that sometimes
randomly fakes open ports. The second connect done by the script will
- The user scans a service which crashes after the scan reports it to
be open, and all other scripts fail to connect information from that
- The user scans a load balancer where the initial scan accidentally
hits a server that has an open port that its siblings are lacking.

First I thought this script would be too heavy for the default
category as it runs against most services. However, it would typically
never produce output when other scripts do. If both this one and some
other script produces output, that is something the user might want to
know. Also, if the user is running a script scan, it must at least be
ok to do full connections to the ports, so I think it should be ok to
run this script if the user asks for both -sS and -sC. Finally, open
ports not being open sounds generally like a useful thing to know.
This is an interesting idea. I don't think that it should be default. If
I were going to do this, I think I would just use -sV --version-light.
The services that can't be connected to will be "tcpwrapped".
Ok. Feel free to remove default from categories.
I don't plan to add this script unless someone else speaks up.

David Fifield
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/
Hi Toni,

This is not really specific to this script but seeing it gives me some not clear yet ideas like adding the possibility of sending a user defined payload and looking for user defined patterns in the response (size, regex/hard matching etc...) notifying the user when there is a match.

(Basic example for the sake of demonstration of what tcp-payload may look like)

Say that I have some HTTP exploit and a target that is vulnerable would return a 500 response. A user could put the HTTP request in a file and choose something like "500 Internal Server Error" and specify them in script args. When a match occurs, a simple output is provided for that port.

Although you can write such scenarios with few efforts in NSE, this may prove to be a swiss army knife for users that don't have strong Nmap scripting knowledge or just want to rapidly prototype some PoC / detection mechanisms while benefiting from Nmap's awesome network discovery and scanning abilities especially when scanning large networks. With enough parameters that the user could change, such a script could be very popular.

Of course supporting binary payloads / response matching would be a must to make such a script useful.

These are just unstructured ideas at the moment. I would happily work on this if someone finds this interesting and could add any remarks. :)


Hani Benhabiles

Twitter: https://twitter.com/#!/kroosec
Blog: http://kroosec.blogspot.com

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]