users-manual.lyx

linux平台下的多系统漏洞扫描工具客户端

The default filtering selection has the sequence 
\begin_inset Quotes eld
\end_inset 

Subnet
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

Host
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

Port
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

Severity
\begin_inset Quotes erd
\end_inset 

.
 By changing this sequence and the selections in the corresponding list
 you may creat arbitrary filters in order to create helpful views for exploring
 and understanding the scan results.
\layout Subsubsection

Report Formats
\layout Standard

The scan results can be exported into a number of formats.
 Basically it can be distinguished between 3 types of formats: Interchange-Forma
ts, Editable Documents and Read-only Documents.
 The last type currently is the PDF Report file.
 With a capable view it allows to browse back and forth through the document
 using the various inserted hyperlinks.
\layout Standard

For further information see the section about the menu command 
\begin_inset Quotes eld
\end_inset 

Report->Export
\begin_inset Quotes erd
\end_inset 

.
\layout Section

Special Features
\layout Subsection

NessusClient Preferences
\layout Standard

NessusClient allows to specify some individual preferences that determine
 some ways how the client GUI works.
\layout Standard
\align center 

\begin_inset Graphics
	filename images/preferences-dlg-en.png
	scale 90
	keepAspectRatio

\end_inset 


\layout Standard

The following selection are available:
\layout Subsubsection

User Interface
\layout Paragraph

Auto expand tree elements
\layout Standard

In the left-hand treeview clicking on a task or a scope automatically expands
 the corresponding tree if checked.
\layout Standard

If not checked, the user has to manually click on the expand icon each time.
\layout Subsubsection

Connection to Nessus Server
\layout Paragraph

Automatically connect
\layout Standard

If this setting is enabled, the NessusClient will try to connect to the
 server when a scope is executed.
 For user certificates without a password, this will work immediately.
 For password protected user certificates or simple password based authenticatio
n, the password will be stored in memory after a successful login until
 NessusClient is closed.
\layout Subsubsection

External Links in HTML/PDF
\layout Standard

These settings determine the URLs for linking more information on Nessus
 Plugin, CVE/CAN and BugTraq ID in Reports of format HTML or PDF.
 The defaults as shown in the screenshots are recommended since there up-to-date
 information are to be found.
 The defaults are reactivated when field is left empty.
\layout Standard

In case you want to package a Nessus report with e.g.
 CVE/CAN details for offline-reading, you may enter an apropriate definition
 like ``mitre/%s/%s/%s.html'' in case you have a directory structure relative
 to the report file with mitre/CVE/yyyy/nnnn.html and mitre/CAN/yyyy/nnnn.html
 where yyyy is the year and nnnn is the number of the record.
 Then you could package all files together.
\layout Standard

Note, that the strings defined here are filled into the html link parameter
 ``href'' as it is.
 The tool ``htmldoc'' is issued to produce a pdf out of this html report.
 Depending on the version and features the created links in the PDF file
 may be created differently.
\layout Subsection

User-defined Access Rules
\layout Subsubsection

General
\layout Standard

Nessus Server keeps a list of access rules similar to usual firewall rules.
 In no way can these be overridden by the Nessus Client.
\layout Standard

Furthermore, the Nessus Server Administrator can add specific rules for
 each user while applying the tool 
\family typewriter 
nessus-adduser
\family default 
.
\layout Standard

And finally, the User may add another set of rules in NessusClient.
\layout Subsubsection

Syntax
\layout Standard

A rule might either be a default definition: 
\begin_inset Quotes eld
\end_inset 

default deny
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

default reject
\begin_inset Quotes erd
\end_inset 

 or 
\begin_inset Quotes eld
\end_inset 

default accept
\begin_inset Quotes erd
\end_inset 

.
\layout Standard

Or it is a target specific definition that consists of the action (
\begin_inset Quotes eld
\end_inset 

deny
\begin_inset Quotes erd
\end_inset 

, 
\begin_inset Quotes eld
\end_inset 

reject
\begin_inset Quotes erd
\end_inset 

 or 
\begin_inset Quotes eld
\end_inset 

accept
\begin_inset Quotes erd
\end_inset 

) and a target specified with its IP (eg.
 192.168.10.10).
\layout Standard

Note that it must be an IP.
 The use of hostnames is not allowed due to security reasons.
\layout Subsubsection

Manage rules in NessusClient
\layout Standard

A rule consists of a action and (in case no default action is dfined) a
 target.
 There are in total 6 actions available where the user can select one in
 the selection box.
 The target is to be specified manually in a text entry field.
\layout Standard

Once clicking the button 
\begin_inset Quotes eld
\end_inset 

Add rule
\begin_inset Quotes erd
\end_inset 

, the specified action/target is added to the group 
\begin_inset Quotes eld
\end_inset 

Clientside userrules
\begin_inset Quotes erd
\end_inset 

.
\layout Standard

If a rule in this section is selected, the button 
\begin_inset Quotes eld
\end_inset 

Remove rule
\begin_inset Quotes erd
\end_inset 

 will delete it from the list.
 No serverside rule can be removed of course.
\layout Subsubsection

Example for User-defined Access Rule
\layout Standard

You are the security team of BigBank Corp.
 The management authorized you to scan the network, BUT you're not allowed
 to scan 172.20.142.2 under any circumstance, because it's a SWIFT server and
 if it goes down, so does the bank (and your company and legal responsability).
 So you add :
\layout Standard
\added_space_top smallskip \added_space_bottom smallskip 

\family typewriter 
deny 172.20.142.2
\layout Standard
\noindent 
as a user rule in the GUI, and you are now SURE that you'll never scan this
 IP - even if you later on ask nessusd to scan it.
 
\layout Subsubsection

Example for a Adminstrator-defined Access Rule
\layout Standard
\added_space_bottom smallskip 
By editing nessusd.rules (only the administrator for Nessus Server can do
 that), you make sure that nessusd will not be used to scan any system it
 should not scan.
 If your internal network is 10.0.0.0/8, you basically want to make sure that
 nobody will scan anything else (either by fat-fingering an IP or just by
 malice), so you edit 
\family typewriter 
nessusd.rules
\family default 
 and you add :
\layout Standard


\family typewriter 
allow 10.0.0.0/8
\layout Standard


\family typewriter 
allow 127.0.0.1
\layout Standard


\family typewriter 
default deny
\layout Subsection

Local Security Checks: Theory
\layout Subsubsection

What are "local" security checks?
\layout Standard

Starting with Nessus 2.1.0, it is possible to give Nessus SSH credentials
 to log into the remote Unix systems and determine which patchs need to
 be applied.
 What this really means is that if you give Nessus the proper SSH key, it
 will litterally log into the remote host, extract the list of installed
 software, and tell you which packages have an update ready for them.
\layout Standard

The real goal of this feature is to easily keep track of all the missing
 patches of a given system, without the potential hazards and false positives
 of remote security checks.
 It is really important to understand that enabling local security checks
 do not discover flaws such as unauthorized suid binaries, they simply determine
 which patches are missing from the remote operating system.
\layout Subsubsection

Which operating systems are supported at this time?
\layout Standard

At this time, Nessus is able to determine the missing patches of the following
 operating systems :
\layout Itemize

AIX 5.x
\layout Itemize

Debian
\layout Itemize

Fedora Core 1 and 2
\layout Itemize

FreeBSD 4.x, 5.x (including the port collection)
\layout Itemize

Gentoo Linux (all advisories from 2004)
\layout Itemize

Mac OS X (and Mac OS X Server)
\layout Itemize

Mandrake Linux (8.0 to 10.0)
\layout Itemize

RedHat Enterprise Linux (2.1 and 3.0)
\layout Itemize

Solaris (2.5.1, 2.6, 7, 8 and 9)
\layout Itemize

SuSE Linux (7.0 to 9.1)
\layout Itemize

Microsoft Windows NT, 2000, XP, 2003 
\layout Standard

We hope to support more systems in the future (HP-UX, Tru64, etc...).
 
\layout Subsubsection

Which Solaris patches are checked for?
\layout Standard

We have implemented checks for Solaris 2.5.1, 7, 8 and 9 (both on sparc and
 i386 architectures).
 We check for every patch listed by Sun in the "Patch containing security
 fixes" of their patch page.
\layout Subsubsection

Is it intended to support more systems?
\layout Standard

We do not intend to support every operating system which has ever surfaced
 on the face of earth.
 However, we intend to create 
\begin_inset Quotes eld
\end_inset 

working groups
\begin_inset Quotes erd
\end_inset 

 of people working on a given operating system.
 Basically, we are looking for people who would be responsible for producing
 the security checks relevant to the operating system they use (and love).
 If you are interested in taking part in such a group (or to even lead a
 given OS group), please contact the Nessus Development Team.
\layout Subsubsection

What are "local" security checks NOT?
\layout Standard

At this time, Nessus does not check the local security policy of the remote
 system, like Tiger does (ie: directories writeable by any users, wrong
 permissions on a sensitive configuration file, and so on...).
 Read about SLAD (Security Local Auditing Daemon) for extensive on-site
 testing of remote targets that porentially are compromised.
 SLAD can be accessed via respective NASL scripts.
\layout Subsubsection

Why do we need to perform local security checks, is not Nessus good enough
 to determine security issues?
\layout Standard

Nessus 2.0 is, at its heart, a network based scanner.
 This means that it will connect to the remote host and attempt to determine
 the flaws affecting every service on it.
 However, testing everything from the point of view of the network has its
 own shortcomings.
 In particular, a 100% network-based security scanner can not do the following
 :
\layout Itemize

Determine client-side flaws: There are more and more client-side vulnerabilities
 published every day, ranging from flaws in mail clients to XML libraries.
 It simply is not possible to check for those from the point of view of
 an active scanner.
 The only way to detect such flaws is to deploy a passive scanner (ie: NeVO)
 or to locally check that every host has been patched.
\layout Itemize

Determine local flaws: Obviously, the security level of local utilities
 can not be determined from the point of view of the network.
 By running local security checks, Nessus will tell you if a user logged
 into the remote host can use an overflow in a suid binary to gain root
 privileges.
\layout Itemize

Determine flaws in disabled services: If a host has a vulnerable service
 installed, but it's not running at the time of the scan, a vulnerability
 will be missed.
 Having an unpatched disabled service is a potential security hazard - if
 the service is ever enabled in the future, it might be exploited.
\layout Standard

So traditional network-based scanners have their inherent limitations, which
 can now be overcomed thanks to this new feature.
\layout Subsubsection

Will Nessus recognize individually compiled and installed packages?
\layout Standard

If you e.g.
 compiled your DNS server by hand instead of using the system's one: Will
 Nessus see it ? No!
\layout Standard

Nessus sticks to the patches provided by your OS vendor.
 However, note that it usually is a good administrative practice to stick
 to your vendor packages, as it makes the upgrade of your system much easier.
\layout Standard

In the future, Nessus might be able to detect if a running server is not
 of the same version as the one installed by RPM (or any other packaging
 system) and may improve its output this way.
\layout Subsubsection

Why care about local security if there is no local user?
\layout Standard

E.g.
 why should one care if the web server has local overflows in suid binaries
 but there's no local user on it, apart from oneself?
\layout Standard

At the time this feature starts to be discussed, many people would object
 that they don't really care about local security because their server simply
 is a web server with no local users, therefore nobody can exploit a local
 vulnerability.
 The answer is a simple security practice: 
\series bold 
containment
\series default 
.
 If your web server is vulnerable to a given flaw (be it a misconfiguration,
 a badly written PHP script, or an 0day in Apache), an attacker will be
 able to obtain a shell on your system.
 The question really is: do you want to make it easy for the attacker to
 gain super-user privileges and gain the full control of your system, or
 do you want to contain him to the privileges your web server is running
 with? (These privileges will prevent the attacker to modify your kernel,
 load a rogue kernel module, and generally will make it harder for him to
 cover his tracks).
 So 
\series bold 
local security really matters
\series default 
, since it's your last line of defense.
\layout Subsubsection

How can enabling local security checks improve my scanning experience?