my 0,02: this is not just for NESSUS but in general:
Use your head, not a check-list - every network is a bit different.
make sure all scans are notified properly but only to the absolute
minimumnumber of people who need to know about them and will not
"hide" faulty
systems or overreact if unexpected things happen
make sure someone is available to handle any queries when and after scanning
is running
let the control room know when scans are running (e.g. person or process
running the scan emails or calls to tell them when the scan starts and
stops)
Planning:
get knowledge if possible of which IP address ranges are workstations, which
network, which server, which printer, which dial-in etc...
before scanning large-scale, experiment and explore - e.g. icmp ping/tcp syn
port scan for only the most common services - just to find out roughly how
many live IPs you have and in which ranges they are, checking %network load
, % cpu load on your scan server and "network-near" switches routers,
firewalls, etc... during experimental scans
- (SNMP is in my experience unreliable as often restricted to LAN or
VLAN)
- ping a few machines to find out network speeds, run a fast multi-dns
query (batch file) to see if the dns machine starts timing out requests
when loaded...
- Sometimes the worst response times are in the datacentre area where
support personnel is using large numbers of network-intensive tools so you
may need to place your scanner "network-near" the core WAN routers!
Then get a network expert and discuss the details of scanning strategy
you should anyway plan to scan network devices and server farms differently
from office networks; you may have time/load data to help you plan
- if you have a dial-in ip pool, you will need to scan that in the
evening when the salesmen and road warriors log in
- best time to scan office networks in my experience is between 10:00
and 15:00 hrs as otherwise a lot of machines are offline
- best time to scan central and critical machines in my experience is
lunchtime: you have all your experts around in case anything happens but the
interactive load is low (watch for large time-critical batch processing jobs
planned at the same time)
- web is a special case, especially if your web users are spread over
many time zones. Notabene: if you have multiple identical "load-balanced"
systems (really identical - hw, fw and sw) you may wish to take one out of
the pool and scan only that for a start
I would not exclude any "false positives" - have the gurus check them out if
you are not allowed to do it yourself to make sure they are false - what
used to be a false positive can become a real positive after a patch or
other configuration changes, and new attacks appear all the time
most modern network devices can take scan loads - very many little packets
(except for snmp and rpc calls to windows which can be HEAVY) without
flinching.
handling large numbers of small requests/packets can cause old routers,
small dns servers etc. to falter... If you have network-load/capacity
problems, you may wish to cut down on notoriously heavy tests
Therefore try to use a POWERFUL router as gateway for the scan server
machine(s) and position it in a master segment of the network near
authentication DNS WINS etc. servers if possible
If segments of the WAN are weak or there are active filtering devices
between you and the target networks, place several little locked-down
scanner boxes locally in the LANs or VLANs you want to scan and trigger
scans on them remotely (using encrypted communication) - in my experience
even an "open" route through many network devices which can handle packets
differently or filter them can modify packets and falsify scan results
Frequency of scanning of workstation and printer networks :-- how big is
your target - if you have 146 live IPs, you can do them e.g. every two
months if your password lifetime is 90 days.
If you have e.g.50'000, plan to go around all of them in portions once a
year or so as you should on this scale have a uniform set-up with slight
variations - an initial sample scan e.g. 1000 will tell you what the rest
will probably look like and you can plan to mass-remedy them, taking 20%
fallout in your stride:- so the FIX will need to be planned in small
portions to give local support teams the time to catch up with the fallout
the most common problem with distributed simultaneous scans is user
lockout:- if you are running multiple scans, make sure you do not run
password guessing tests simultaneously or in quick succession against two or
more authentication (e.g. LDAP, AD) servers as this will result in mass
lockout (ditto other forms of shared user authentication services)
WATCH YOUR SCANS (e.g. using local login or encrypted communication and
using both the remote control interface and a "console" terminal on the scan
server - e.g. ssh/ssl through vpn)
- core dumps, screens of death etc. on your scan server can happen!
- routing loops or obsolete routes to IP addresses in the target range
can result in scans hanging or running at snail's pace
- some scans will pick up a password file and start cracking - which
can take for ever if you let it run - slowing down the scan considerably:
the knowledge that you can get a password to crack is usually sufficient
indication of poor security
know which machines are low on CPU, network capability etc. beforehand,
especially if they are critical machines (e.g. a telephone switch[PABX]
which you need to call the fire brigade): "weak-kneed" machines can become
unresponsive as they try to handle and log all the queries the scan throws
at them, others reboot, security devices which log or filter traffic can
succumb (indicating you are vulnerable to a trivial DOS);
you usually only find this out (sadly) after your first carpet-bombing!
Some scan types can be single-threaded so the only way to speed such scans
up is to run multiple servers against different ranges in your target
network (e.g. port scans).
Know your scanner and how it works - run single threaded tasks on multiple
machines, multithreaded ones on servers with POWERFUL CPUs and good NETWORK
CONNECTIVITY - (your scan server may otherwise not be able to handle the
load it generates)
If your network has poor core servers (AUTH, DNS, WINS, etc...) or
nearly-capacity-loaded routers, you need LONG tcpip timeouts and perform
single slow scans of limited ranges - ditto if you are scanning in a network
area protected by firewalls, which will slow down responses to tcp
handshakes etc... - hence the exploratory work to discover how the network
reacts as above. (scanning DMZ VLANs is usually a pain - very slow and
little information gleaned if the systems are hardened correctly - internal
tools which list out configuration details are often better value for
effort)
re automation of scanning:
Whatever you use as "security manager" (e.g. security centre):-
I recommend going for automation only after several "carpet-bombings"
run by hand - i.e. when you know roughly how it will work and affect the
network
Even if automated, WATCH YOUR SCANS - i.e. have a process or person
monitor the automated scanning and possibly a sanity checker to check that
the monitor is really monitoring and have an always-available person who
receives a report when the job started and ended and how it went
Albert
2007/10/31, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
>
> I'd be interested in hearing from anyone who has enterprise level
> deployments of Nessus, and how you handle a few items, for those that are
> able to share:
>
> 1) With regulations such as PCI requiring production network scanning --
> when do you scan? Downtimes? Daytime, etc?
>
> 2) What has your experience been with outages, overload, etc based on the
> above? How have you mitigated the risk of overloading network devices with
> sessions, device failure, etc?
>
> 3) What settings as far as throttling/sessions/# hosts, have you found to
> be most efficient (and over what sort of network, fast ethernet\gb, etc)
>
> 4) What settings for safe checks, port range, paranoia, thorough -- have
> been most effective as a balance between accuracy / false positives / speed?
>
> 5) Have you implemented workstation scanning? Do you scan all? A pool?
> Rotate quarterly?
>
> 6) For those using a distributed scanner architecture -- what's been
> effective? what did you "do wrong"? What do you wish you'd done?
> Tips/thoughts?
>
> 7) Thoughts on Security Center as a management tool for distributed
> scanning?
>
> Thanks in advance,
> Mike
>
>
>
>
>
>
> _______________________________________________
> Nessus mailing list
> [email protected]
> http://mail.nessus.org/mailman/listinfo/nessus
>
<<image/gif>>
_______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
