Hi Christian,
Thanks for your quick answer.
I checked every parameters you mentioned and I confirm those are not set
(empty string) in my current scan config:
* Nmap (NASL wrapper)
Do not randomize the order in which ports are scanned = "no"
Do not scan targets not in the file = "no"
Fragment IP packets (bypasses firewalls) = "no"
Log nmap output = "no"
RPC port scan = "no"
Run dangerous port scans even if safe checks are set = "no"
Service scan = "no"
Data length = ""
Host Timeout (ms) = ""
Initial RTT timeout (ms) = ""
Max RTT Timeout (ms) = ""
Max Retries = ""
Maximum wait between probes (ms) = ""
Min RTT Timeout (ms) = ""
Minimum wait between probes (ms) = ""
Ports scanned in parallel (max) = ""
Ports scanned in parallel (min) = ""
Source port = ""
File containing grepable results = ""
TCP scanning technique = connect()
Timing policy = Polite
And the same goes for:
* Launch Nmap for Network Scanning
Aggressive OS detection = "no"
Disable DNS resolution = "no"
Fragment IP packets (bypasses firewalls) = "no"
Identify the remote OS = "no"
RPC port scan = "no"
Service scan = "no"
Trace hop path to each host = "no"
Treat all hosts as online = "no"
Exclude hosts = ""
Host Timeout (ms) = ""
Hosts scanned in parallel (max) = ""
Hosts scanned in parallel (min) = ""
Initial RTT timeout (ms) = ""
Max RTT Timeout (ms) = ""
Min RTT Timeout (ms) = ""
Minimum wait between probes (ms) = ""
Ports scanned in parallel (max) = ""
Ports scanned in parallel (min) = ""
Source port = ""
File containing XML results = ""
TCP scanning technique = connect()
Timing policy = Polite
Am I supposed to see an additionnal argument in the NMAP command lines like
I expect?
Any other idea why the "timing policy" is not taken into account?
Regards,
On Thu, Jun 7, 2018 at 12:20 PM, Christian Fischer <
christian.fisc...@greenbone.net> wrote:
> Hi,
>
> could you make sure that you havn't changed any of the following
> settings of the "nmap.nasl" preferences from the default / empty string:
>
> Max Retries :
> Host Timeout (ms) :
> Min RTT Timeout (ms) :
> Max RTT Timeout (ms) :
> Initial RTT Timeout (ms) :
> Ports scanned in parallel (min)
> Ports scanned in parallel (max)
> Minimum wait between probes (ms)
> Maximum wait between probes (ms)
>
> As soon as one or more of the above preferences has any data set the
> "Timing policy :" doesn't apply anymore.
>
> Regards,
>
> On 07.06.2018 08:53, Alexandre Brasseur wrote:
> > Hi everyone,
> >
> > I am mostly performing scans on networks were bandwidth consumption is
> > critical and should therefore be as low as possible.
> > From my first observations, the most bandwidth-intensive part of the scan
> > is the beginning, were lots of NMAP processes are being triggered, like
> so:
> > ---openvassd: testing AAA.BBB.CCC.DDD (/var/lib/openvas/plugins/
> nmap.nasl)
> > ---nmap -n -Pn -oG /tmp/nmap-AAA.BBB.CCC.DDD -sT -sU -p T:1-65535,U: ...
> >
> > As a consequence, I am looking for a way to lower the "aggressiveness" of
> > those NMAP processes (see "timing template" of NMAP MANPAGE)
> > After looking in "/var/lib/openvas/plugins/nmap.nasl" and
> > "/var/cache/openvas/nmap.nasl.nvti", such a configuration seems
> possible by
> > modifying the "Scans Configs" using the "Greenbone" web interface.
> > But even after switching from "Normal" to "Polite", the command line
> > arguments remained the same, while I was expecting the option "-T<0-5>"
> to
> > appear in those.
> >
> > Here is my current working config under Debian Stretch 9.3 (Kernel
> > 4.9.0-5-amd64):
> > ii greenbone-security-assistant 6.0.11+dfsg.1-2
> > amd64 remote network security auditor - web interface
> > ii greenbone-security-assistant-common 6.0.11+dfsg.1-2
> all
> > architecture independent files for greenbone-security-assistant
> > ii libopenvas8 8.0.8-2
> > amd64 remote network security auditor - shared libraries
> > ii openvas 6.0.9-2
> > amd64 remote network security auditor - metapackage
> > ii openvas-cli 1.4.5-1
> > amd64 Command Line Tools for OpenVAS
> > ii openvas-manager 6.0.9-2
> > amd64 Manager Module of OpenVAS
> > ii openvas-manager-common 6.0.9-2
> all
> > architecture independent files for openvas-manager
> > ii openvas-scanner 5.0.7-3
> > amd64 remote network security auditor - scanner
> >
> > Thanks in advance for your help,
> >
> > Regards.
> >
> >
> >
> > _______________________________________________
> > Openvas-discuss mailing list
> > Openvas-discuss@wald.intevation.org
> > https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/
> openvas-discuss
> >
>
> --
>
> Christian Fischer | PGP Key: 0x54F3CE5B76C597AD
> Greenbone Networks GmbH | https://www.greenbone.net
> Neumarkt 12, 49074 Osnabrück, Germany | AG Osnabrück, HR B 202460
> Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
>
>
--
Alexandre Brasseur
Quality Assurance Engineer
Escaux
Escaux, Communication as easy as the web
Chaussée de Bruxelles 408, 1300 Wavre, Belgium
Direct: +3227887554
Main: +3226860900
www.escaux.com
Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website
<https://www.escaux.com/docs/ContractInfo.html>.
Ce message est soumis aux conditions disponibles sur notre site web
<https://www.escaux.com/docs/ContractInfo.html>.
This message is subject to the terms and conditions available on our website
<https://www.escaux.com/docs/ContractInfo.html>.
_______________________________________________
Openvas-discuss mailing list
Openvas-discuss@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
