Re: [NSE] TN3270 version script

[Daniel Miller <bonsaiviking () gmail com>]

Phil,

Ok, this is making good sense to me now. We'll distinguish tn3270 as a
separate service name. I'll change the one current match to tn3270 from
telnet; do you have any feedback on the product name, which is currently
"IBM OS/390 or SNA telnetd" ? I'd guess this could be corrected to
something either more accurate or more general.

After the initial terminal type negotiation, is there some text like a
banner that the server sends? It would be nice to be able to retrieve more
than just the service name in that case.

For SSL (probably telnets on port 992), the best way to handle this is to
let version detection spot the SSL tunnel, then just use comm.tryssl to do
your connection. It leverages the version detection results (if -sV says
it's SSL, use that) and port number (992 is probably SSL, 23 is probably
plaintext) to determine when to try SSL with a fallback to plaintext if
that fails. In other words, don't worry about detecting and reporting SSL
tunnel in this script.

The portrule should definitely be: shortport.version_port_or_service({23,
992}, {"telnet", "telnets", "tn3270"}). Don't worry about supporting older
service databases; that's one of the easiest things to manually update, far
easier than getting a new script to work in older Nmap versions.

Let us know if there's anything else we can do to help.

Dan

On Fri, Aug 28, 2015 at 3:57 PM, Phil <mainframed767 () gmail com> wrote:

> Hi Daniel,
>
> let me try and answer your questions:
>
> 1)  in this case we label it telnet, since it's using the Telnet option
> negotiation mechanism
> Yes, this is correct, TN3270 is built on top of telnet but isn’t like
> telnet
>
> 2) Do these scripts make sense running against tn3270?
>
> No they don’t. Those scripts won’t work at all (I’ve tested) because
> TN3270 has further handshake negotiations and is a different protocol.
>
> 3) should TN3270 be really treated like a different service altogether?
> It really should be treated as a different service, it’s only related to
> telnet in the very beginning of protocol handshake.
>
> 4) Is this always the case, or should the script attempt to negotiate
> TN3270 with any telnetd that asks for Terminal Type, even among other
> options?
> Pretty much in all my testing of test mainframes and some internet
> available one this is the case. But basically, if it says ‘send ttype’ and
> you send 'IBM-3279-4-E’ the next reply will be another ‘IAC DO’ for further
> option negotiation, other wise it will ask for other terminal types (IAC
> SB).
>
> 5 ) Once we answer these questions, we can move into more
> implementation-related issues like what portrule would be best (my guess
> would be some invocation of shortport.version_port_or_service [1]), using
> comm.tryssl [2] instead of tn_open, and how to best report the script's
> findings.
>
> Great, I certainly struggled with making a portrule robust enough to
> detect tn3270 appropriately. The reason I used ‘unknown’ was in previous
> version of NMAP the version detection would list things like ‘IIS’ and
> ‘unknown’ and ‘Gnu Telnetd’ as the services detected so I was casting a
> wide net. And the SSL components were based on older scripts, I had never
> seen tryssl.
>
>
> On Aug 28, 2015, at 1:04 PM, Daniel Miller <bonsaiviking () gmail com> wrote:
>
> Phil,
>
> I'm excited to see better mainframe support in NSE! I think we should
> carefully consider how this script and others may interact so that we build
> a good picture of the target and allow scripts to properly inform each
> other.
>
> A quick check through nmap-service-probes shows that we have at least one
> probe match for the same TN3270 service:
>
> Probe TCP NULL q||
> match telnet m|^\xff\xfd\($| p|IBM OS/390 or SNA telnetd|
>
> So in this case we label it telnet, since it's using the Telnet option
> negotiation mechanism. This is used as a signal to other scripts like
> telnet-brute and telnet-encryption that the port in question should be
> probed further. Do these scripts make sense running against tn3270? Or
> should TN3270 be really treated like a different service altogether?
>
> Your script also looks for a response of "\xff\xfd\x18", the Terminal Type
> option. This option is obviously used by more telnet daemons than just
> TN3270-capable ones, but yours specifically will only match those that send
> no other options. Is this always the case, or should the script attempt to
> negotiate TN3270 with any telnetd that asks for Terminal Type, even among
> other options?
>
> Once we answer these questions, we can move into more
> implementation-related issues like what portrule would be best (my guess
> would be some invocation of shortport.version_port_or_service [1]), using
> comm.tryssl [2] instead of tn_open, and how to best report the script's
> findings.
>
> Thanks again for sharing your work with us!
>
> Dan
>
> [1] https://nmap.org/nsedoc/lib/shortport.html#version_port_or_service
> [2] https://nmap.org/nsedoc/lib/comm.html#tryssl
>
> On Wed, Aug 26, 2015 at 1:30 PM, Phil <mainframed767 () gmail com> wrote:
>
> > Hi,
> >
> > This script enhances the version detection for mainframes (or others, but
> > mostly mainframes) running TN3270 and appropriately identifies ports which
> > support TN3270 (either through IAC DO TN3270E or through the more common
> > IAC SEND TTYPE).
> >
> >
> > Output:
> > PORT    STATE SERVICE    VERSION
> > 23/tcp  open  tn3270     Telnet TN3270
> > 992/tcp open  ssl/tn3270 Telnet TN3270 w/SSL
> >
> > This is my first NSE script submission so let me know if there’s anything
> > I’ve missed or need to change.
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Sent through the dev mailing list
> > https://nmap.org/mailman/listinfo/dev
> > Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/