[RFC] Partial results for timed-out hosts
Daniel Miller <[email protected]> Sun, 12 Jan 2020 23:57:52 -0600
| Newsgroups | gmane.comp.security.nmap.devel |
|---|---|
| Message-ID | <CABmvJnMZPnhRqVNN0CjpzQho=aY=ofta81F4nMDvaoHtMMckDA@mail.gmail.com> |
--000000000000a001bf059bff288b Content-Type: multipart/alternative; boundary="000000000000a001bd059bff2889" --000000000000a001bd059bff2889 Content-Type: text/plain; charset="UTF-8" Hi, friends! For a long time, Nmap users have been asking for a way to get partial results for targets that have timed out during scanning as a result of the -T5 or --host-timeout options (#64). Now, I think we have a good way to deliver that feature, and I want to get feedback before committing it. First, I need to point out another new feature that just got added, because my proposal follows on from it: the "hosthint" XML output tag (#1858). This new tag is emitted during host discovery as soon as a target is found to be up, and contains the same identifying elements as the "host" tag. The intent is to give some useful information before all the scan phases are complete for the entire hostgroup. This feature was proposed and implemented by Paul Miseiko at Rapid7. The proposed partial output needs to be distinguished clearly from ordinary output so that it is not interpreted as complete. The "hosthint" element is already intended to contain a subset of the information in the final output, so it naturally makes sense to use for this case, too. In the XML data stream, a timed out host will be output within a "hosthint" element, with all the same sub-tags and attributes as a completed host, as far as they are available. Our existing output functions handle missing data very well, so it was a simple change (patch attached). In the Normal output stream (such as to STDOUT), the output resembles ordinary output for a target, but features an extra output line at the beginning: "Partial results for 192.0.2.1 due to host timeout:" The Grepable output stream has the same "Host: 192.0.2.1 () Status: Timeout" line, but then has a "Host: 192.0.2.1 () Status: Up" line and a "Ports:" line as usual. As much as possible, I want to hear feedback on the particulars of this approach. I already know lots of folks are excited to get partial results back from timed-out targets, so of course I'm excited, too. I just want to know if this way of doing it will work for most users. Dan #1858 - hosthint feature: http://issues.nmap.org/1858 #64 - Nmap should log results when host timeout reached: http://issues.nmap.org/64 Attachment: timeout-hosthint.patch, modifications to nmap.cc to print host output when timeout is reached. --000000000000a001bd059bff2889 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"ltr">Hi, fr= iends!</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">For a long time, Nm= ap users have been asking for a way to get partial results for targets that= have timed out during scanning as a result of the -T5 or --host-timeout op= tions (#64). Now, I think we have a good way to deliver that feature, and I= want to get feedback before committing it.</div><div dir=3D"ltr"><br></div= ><div dir=3D"ltr">First, I need to point out another new feature that just = got added, because my proposal follows on from it: the "hosthint"= XML output tag (#1858). This new tag is emitted during host discovery as s= oon as a target is found to be up, and contains the same identifying elemen= ts as the "host" tag. The intent is to give some useful informati= on before all the scan phases are complete for the entire hostgroup. This f= eature was proposed and implemented by Paul Miseiko at Rapid7.</div><div di= r=3D"ltr"><br></div><div>The proposed partial output needs to be distinguis= hed clearly from ordinary output so that it is not interpreted as complete.= The "hosthint" element is already intended to contain a subset o= f the information in the final output, so it naturally makes sense to use f= or this case, too. In the XML data stream, a timed out host will be output = within a "hosthint" element, with all the same sub-tags and attri= butes as a completed host, as far as they are available. Our existing outpu= t functions handle missing data very well, so it was a simple change (patch= attached).</div><div><br></div><div>In the Normal output stream (such as t= o STDOUT), the output resembles ordinary output for a target, but features = an extra output line at the beginning: "Partial results for 192.0.2.1 = due to host timeout:"</div><div><br></div><div>The Grepable output str= eam has the same "Host: 192.0.2.1 () Status: Timeout" line, but t= hen has a "Host: 192.0.2.1 () Status: Up" line and a "Ports:= " line as usual.</div><div><br></div><div>As much as possible, I want = to hear feedback on the particulars of this approach. I already know lots o= f folks are excited to get partial results back from timed-out targets, so = of course I'm excited, too. I just want to know if this way of doing it= will work for most users.</div><div><br></div><div>Dan</div><div><br></div= ><div>#1858 - hosthint feature: <a href=3D"http://issues.nmap.org/1858">htt= p://issues.nmap.org/1858</a></div><div>#64 - Nmap should log results when h= ost timeout reached: <a href=3D"http://issues.nmap.org/64">http://issues.nm= ap.org/64</a></div><div><br></div><div>Attachment: timeout-hosthint.patch, = modifications to nmap.cc to print host output when timeout is reached.<br><= /div><div><br></div></div> </div></div> --000000000000a001bd059bff2889-- --000000000000a001bf059bff288b Content-Type: text/x-patch; charset="US-ASCII"; name="timeout-hosthint.patch" Content-Disposition: attachment; filename="timeout-hosthint.patch" Content-Transfer-Encoding: base64 Content-ID: <f_k5c0pw3v0> X-Attachment-Id: f_k5c0pw3v0 ZGlmZiAtLWdpdCBhL25tYXAuY2MgYi9ubWFwLmNjCmluZGV4IDVhZDA1NzMuLjJiNThjMWYgMTAw NjQ0Ci0tLSBhL25tYXAuY2MKKysrIGIvbm1hcC5jYwpAQCAtMjI1NSwyMyArMjI1NSwxOCBAQCBp bnQgbm1hcF9tYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pIHsKICAgICAgIGN1cnJlbnRocyA9 IFRhcmdldHNbdGFyZ2V0bm9dOwogICAgICAgLyogTm93IEkgY2FuIGRvIHRoZSBvdXRwdXQgYW5k IHN1Y2ggZm9yIGVhY2ggaG9zdCAqLwogICAgICAgaWYgKGN1cnJlbnRocy0+dGltZWRPdXQoTlVM TCkpIHsKLSAgICAgICAgeG1sX29wZW5fc3RhcnRfdGFnKCJob3N0Iik7Ci0gICAgICAgIHhtbF9h dHRyaWJ1dGUoInN0YXJ0dGltZSIsICIlbHUiLCAodW5zaWduZWQgbG9uZykgY3VycmVudGhzLT5T dGFydFRpbWUoKSk7Ci0gICAgICAgIHhtbF9hdHRyaWJ1dGUoImVuZHRpbWUiLCAiJWx1IiwgKHVu c2lnbmVkIGxvbmcpIGN1cnJlbnRocy0+RW5kVGltZSgpKTsKLSAgICAgICAgeG1sX2Nsb3NlX3N0 YXJ0X3RhZygpOwotICAgICAgICB3cml0ZV9ob3N0X2hlYWRlcihjdXJyZW50aHMpOwotICAgICAg ICB4bWxfZW5kX3RhZygpOyAvKiBob3N0ICovCi0gICAgICAgIHhtbF9uZXdsaW5lKCk7Ci0gICAg ICAgIGxvZ193cml0ZShMT0dfUExBSU4sICJTa2lwcGluZyBob3N0ICVzIGR1ZSB0byBob3N0IHRp bWVvdXRcbiIsCisgICAgICAgIGxvZ193cml0ZShMT0dfUExBSU4sICJQYXJ0aWFsIHJlc3VsdHMg Zm9yICVzIGR1ZSB0byBob3N0IHRpbWVvdXQ6XG4iLAogICAgICAgICAgICAgICAgICAgY3VycmVu dGhzLT5OYW1lSVAoaG9zdG5hbWUsIHNpemVvZihob3N0bmFtZSkpKTsKICAgICAgICAgbG9nX3dy aXRlKExPR19NQUNISU5FLCAiSG9zdDogJXMgKCVzKVx0U3RhdHVzOiBUaW1lb3V0XG4iLAogICAg ICAgICAgICAgICAgICAgY3VycmVudGhzLT50YXJnZXRpcHN0cigpLCBjdXJyZW50aHMtPkhvc3RO YW1lKCkpOworICAgICAgICB4bWxfb3Blbl9zdGFydF90YWcoImhvc3RoaW50Iik7CiAgICAgICB9 IGVsc2UgewogICAgICAgICAvKiAtLW9wZW4gbWVhbnMgZG9uJ3Qgc2hvdyBhbnkgaG9zdHMgd2l0 aG91dCBvcGVuIHBvcnRzLiAqLwogICAgICAgICBpZiAoby5vcGVuT25seSgpICYmICFjdXJyZW50 aHMtPnBvcnRzLmhhc09wZW5Qb3J0cygpKQogICAgICAgICAgIGNvbnRpbnVlOwotCiAgICAgICAg IHhtbF9vcGVuX3N0YXJ0X3RhZygiaG9zdCIpOworICAgICAgfQorCiAgICAgICAgIHhtbF9hdHRy aWJ1dGUoInN0YXJ0dGltZSIsICIlbHUiLCAodW5zaWduZWQgbG9uZykgY3VycmVudGhzLT5TdGFy dFRpbWUoKSk7CiAgICAgICAgIHhtbF9hdHRyaWJ1dGUoImVuZHRpbWUiLCAiJWx1IiwgKHVuc2ln bmVkIGxvbmcpIGN1cnJlbnRocy0+RW5kVGltZSgpKTsKICAgICAgICAgeG1sX2Nsb3NlX3N0YXJ0 X3RhZygpOwpAQCAtMjI4OSw3ICsyMjg0LDYgQEAgaW50IG5tYXBfbWFpbihpbnQgYXJnYywgY2hh ciAqYXJndltdKSB7CiAgICAgICAgIGxvZ193cml0ZShMT0dfUExBSU4gfCBMT0dfTUFDSElORSwg IlxuIik7CiAgICAgICAgIHhtbF9lbmRfdGFnKCk7IC8qIGhvc3QgKi8KICAgICAgICAgeG1sX25l d2xpbmUoKTsKLSAgICAgIH0KICAgICB9CiAgICAgbG9nX2ZsdXNoX2FsbCgpOwogCgo= --000000000000a001bf059bff288b Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/ --000000000000a001bf059bff288b--