Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Nessus-Users
[Top] [All Lists]

Re: Nessus in the Enterprise

Subject: Re: Nessus in the Enterprise
Date: Fri, 10 Nov 2006 12:52:22 -0500
a free web interface for nessus is inprotect www.inprotect.com

and it works pretty good for scanning and reporting.  It is a little slower
then command line nessus scans but it can act as a central start for scans
and reports.

On 11/10/06, John Scherff <JScherff@24hourfit.com> wrote:

*Zate*,



We automate the whole process with perl and shell scripts, use an Oracle
back-end to store the results, and display the results and month-over-month
trends with a PHP front-end.  We also have an email-based self-service
scanning system wherein users can submit scan requests directly to the
scanning server with the server name(s) in the subject block and scanning
options in the message body.  The HTML results are sent back to them and to
anyone they put in the CC block.



*A word of caution*: you must use strong access control for anything like
this, for obvious reasons.  If you post your scan results on Apache as many
people do, you can easily restrict access using Active Directory groups
using something like the following in your httpd.conf file:



LDAPSharedCacheSize 2000000

LDAPCacheEntries 2048

LDAPCacheTTL 600

LDAPOpCacheEntries 2048

LDAPOpCacheTTL 600



<Directory /*full-path-to-scan-report-directory*>

  SSLRequireSSL

  AuthType Basic

  AuthName "Windows User Credentials"

  Order deny,allow

  Allow from *a.b.c.d/24*

  Deny from all

  AuthLDAPAuthoritative on

  AuthLDAPBindDN "cn=*ldap-proxy-account*,ou=*blah*,dc=*example*,dc=*com*"

  AuthLDAPBindPassword "*ldap-proxy-password*"

  AuthLDAPEnabled on

  AuthLDAPGroupAttributeIsDN on

  AuthLDAPURL "ldap://*example.com*/ou=*blah*,dc=*example*,dc=*com*
?sAMAccountName?sub?(objectclass=user)"

  require group cn=Nessus Report Viewers,ou=*blah*,dc=*example*,dc=*com*

</Directory>



*Notes*:

·         The key here is the "require group" directive. This is an AD
global security or distribution group. Do NOT enclose this in quotes or it
will not work (even though other directives *require* quotes around the
DN).

·         With recent versions of mod_ldap / mod_auth_ldap, you can't
specify *just* the domain for the base DN.  You must go at least one level
deeper (e.g., OU).

·         In the AuthLDAPURL directive, specifying just the domain name
(versus the FQDN of the domain controller) works for us *because* all our
DCs are also DNSs (AD-integrated) and a DNS query for the domain name
returns the NS records of the DNSs.  This gives us fault-tolerance.

·         The setup above does not encrypt the password between the Apache
server and the domain controller.  We can get away with that because both
network segments are in a tightly controlled data center.  If that
connection will traverse an untrusted network in your case, you will want to
use LDAP over SSL/TLS.



You can also authenticate via Kerberos with something like the following
(however, I've not yet found a way to use group-based access control):



<Directory /*full-path-to-scan-report-directory*>

  AuthType Kerberos

  AuthName "Kerberos Login"

  KrbMethodNegotiate Off

  KrbMethodK5Passwd On

  KrbAuthoritative On

  KrbAuthRealms EXAMPLE.COM

  KrbVerifyKDC Off

  require valid-user

  SSLRequireSSL

</Directory>



*Notes*:

·         The above configuration specifically turns off KDC verification
(does not use keytab, KrbMethodNegitiate = off, KrbVerifyKDC = off).  Again,
our stuff is in a trusted environment.  If yours is not, don't do it this
way.

·         You will have to properly configure your /etc/krb5.conf for this
to work.  On Red Hat / Fedora, this is trivially easy to do with the
authconfig command.



If you want to discuss more, send me your phone number off-list by email.
I'll try to call you when I'm not mired in PCI-DSS compliance hurdles.



*John Scherff*

*Sr. IT Security Analyst*

*24 Hour Fitness*
 ------------------------------

*From:* nessus-bounces@list.nessus.org [mailto:
nessus-bounces@list.nessus.org] *On Behalf Of *Zate Berg
*Sent:* Thursday, November 09, 2006 6:14 AM
*To:* nessus@list.nessus.org
*Subject:* Nessus in the Enterprise



Good Morning All,

I was wondering if anyone could contact me off the list to discuss how
they have Nessus setup and deployed in a large network.  I am not finding
much information on things like reporting and a centralized web interface.

Mainly looking for info such as

* what you run it on,
* how many scanners you use,
* how you manage user access to the scanners,
* do you use a central Web console of some kind? (does a full featured one
exist?)
* How do you store your reports?

Thanks :)

--
Zate

_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus


_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
<Prev in Thread] Current Thread [Next in Thread>