Hifn 7955 doesn't work with Freebsd 7.0-release - FreeBSD

This is a discussion on Hifn 7955 doesn't work with Freebsd 7.0-release - FreeBSD ; Hi, I am trying to setup two Soekris 4521 with a minipci vpn1411 (Hi/fn 7955) in a vpn. I understood that the crypto card should automatically work with only three kernel configuration file modification. So I added these three lines ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Hifn 7955 doesn't work with Freebsd 7.0-release

  1. Hifn 7955 doesn't work with Freebsd 7.0-release

    Hi,

    I am trying to setup two Soekris 4521 with a minipci vpn1411 (Hi/fn 7955) in
    a vpn.

    I understood that the crypto card should automatically work with only three
    kernel configuration file modification.

    So I added these three lines

    device crypto
    device cryptodev
    device hifn

    I tested with openvpn (the one release with pkg_add). I used the default
    cipher (I think this is BF-CBC - Blowfish 128 bit). The VPN works but I
    didn't notice any difference in performance (with or without the crypto
    card).
    I also tested the crypto card with AES128 but the performance only got worse
    (didn't have a baseline for that one)

    Relevant output:
    dmesg | grep hifn
    hifn0 mem 0xa0000000-0xa0000fff,0xa0002000-0xa0003fff,0xa0008000-0xa000ffff
    irq 10 at device 16.0 on pci0
    hifn0: [ITHREAD]
    hifn0: Hifn 7955, rev 0, 32KB dram, pll=0x801

    dmesg | grep crypto
    cryptosoft0: on motherboard

    uname -a
    FreeBSD Soekris 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat May 17 10:53:38 UTC
    2008 root@One:/usr/obj/usr/src/sys/C5 i386

    Any help would be appreciated

    Richard

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  2. Re: Hifn 7955 doesn't work with Freebsd 7.0-release

    >
    >I tested with openvpn (the one release with pkg_add). I used the default
    >cipher (I think this is BF-CBC - Blowfish 128 bit). The VPN works but I


    Hi,
    See the man page for supported ciphers.

    >didn't notice any difference in performance (with or without the crypto
    >card).
    >I also tested the crypto card with AES128 but the performance only got worse
    >(didn't have a baseline for that one)


    For single crypto streams, you are not going to see any improvement
    really. Where it works, is when you have multiple connections. e.g.
    on our old backup server, we would have several dumps coming in over
    ssh (3des) and the card made a significant reduction in CPU usage. It
    doesnt really improve single crypto streams performance wise.

    You can also confirm its working by using hifnstats in
    /usr/src/tools/tools/

    ---Mike
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  3. Re: Hifn 7955 doesn't work with Freebsd 7.0-release

    Richard van Mansom wrote:
    > Hi,
    >
    > I am trying to setup two Soekris 4521 with a minipci vpn1411 (Hi/fn 7955) in
    > a vpn.
    >
    > I understood that the crypto card should automatically work with only three
    > kernel configuration file modification.
    >
    > So I added these three lines
    >
    > device crypto
    > device cryptodev
    > device hifn
    >
    > I tested with openvpn (the one release with pkg_add). I used the default
    > cipher (I think this is BF-CBC - Blowfish 128 bit). The VPN works but I
    > didn't notice any difference in performance (with or without the crypto
    > card).
    > I also tested the crypto card with AES128 but the performance only got worse
    > (didn't have a baseline for that one)
    >
    > Relevant output:
    > dmesg | grep hifn
    > hifn0 mem 0xa0000000-0xa0000fff,0xa0002000-0xa0003fff,0xa0008000-0xa000ffff
    > irq 10 at device 16.0 on pci0
    > hifn0: [ITHREAD]
    > hifn0: Hifn 7955, rev 0, 32KB dram, pll=0x801
    >
    > dmesg | grep crypto
    > cryptosoft0: on motherboard
    >
    > uname -a
    > FreeBSD Soekris 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat May 17 10:53:38 UTC
    > 2008 root@One:/usr/obj/usr/src/sys/C5 i386
    >
    > Any help would be appreciated
    >
    >

    Unfortunately openssl doesn't use the accelerator by default. This
    means all apps that use openssl likewise are not automatically
    accelerated. I suggested a patch but it was not accepted. I can't
    recall how you force openssl and/or consumers to use the device.

    If you want to check whether the kernel support is working correctly
    look in src/tools/tools/crypto for cryptotest and hifnstats.

    Sam

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  4. nessus gtk yields empty scan


    [kayve@kv_bsd ~]$ uname -a
    FreeBSD kv_bsd 6.3-STABLE FreeBSD 6.3-STABLE #0: Wed May 7 19:40:55 PDT
    2008 root@kv_bsd:/usr/obj/usr/src/sys/GENERIC i386
    [kayve@kv_bsd ~]$ pkg_info | grep essus
    pkg_info: show_file: can't open '+COMMENT' for reading
    nessus-gtk2-2.2.9_1 A security scanner: looks for vulnerabilities in a
    given ne
    nessus-libnasl-2.2.9_1 Nessus Attack Scripting Language
    nessus-libraries-2.2.9_1 Libraries for Nessus, the security scanner
    [kayve@kv_bsd ~]$


    when i boot there seems like there are a lot of rpm errors during
    the nessus loads. i think something is wrong but i don't know
    what. i don't know what to say i don't know what is wrong
    i can type faster without caps it is NOT that hard to read.
    the gtk GUI has a lot of plugins i think they are all selected
    there is a host called minkay.sfsu.edu i am supposed to scan i
    have a log in i put in host 10.1.1.1 like this webpage says



    ttp://www.securityfocus.com/infocus/1741

    oops. i pasted it twice below sorry.

    1.0 Introduction
    Nessus is a great tool designed to automate the testing and discovery of
    known security problems. Typically someone, a hacker group, a security
    company, or a researcher discovers a specific way to violate the security
    of a software product. The discovery may be accidental or through directed
    research; the vulnerability, in various levels of detail, is then released
    to the security community. Nessus is designed to help identify and solve
    these known problems, before a hacker takes advantage of them. Nessus is a
    great tool with lots of capabilities. However it is fairly complex and few
    articles exist to direct the new user through the intricacies of how to
    install and use it. Thus, this article shall endeavor to cover the basics
    of Nessus setup and configuration. The features of the current versions of
    Nessus (Nessus 2.0.8a and NessusWX 1.4.4) will be discussed. Future
    articles will cover Nessus in more depth.

    Nessus is a free program released under the GPL. Historically, many in the
    corporate world have ridiculed such public domain software as being a
    waste of time, instead choosing "supported" products developed by
    established companies. Typically these packages cost hundreds or thousands
    of dollars, and are often purchased using the logic that you get what you
    pay for. Some people are starting to realize that public domain software,
    such as Nessus, isn't always inferior and sometimes it is actually
    superior. Paid technical support for Nessus is even available from
    www.tenablesecurity.com. Nessus also has a great community of developers
    anchored by the primary author, Renaud Deraison. When allowed to fairly
    compete in reviews against other vulnerability scanners, Nessus has
    equaled or outshined products costing thousands of dollars. [ref:
    Information Security, Network Computing]

    One of the very powerful features of Nessus is its client server
    technology. Servers can be placed at various strategic points on a network
    allowing tests to be conducted from various points of view. A central
    client or multiple distributed clients can control all the servers. The
    server portion will run on most any flavor of Unix. It even runs on MAC OS
    X and IBM/AIX, but Linux tends to make the installation simpler. These
    features provide a great deal of flexibility for the penetration tester.
    Clients are available for both Windows and Unix. The Nessus server
    performs the actual testing while the client provides configuration and
    reporting functionality.
    2.0 Installation
    Nessus server installation is fairly simple even for a Windows jockey like
    me. First an installed version of Unix is required. Secondly, prior
    installation of several external programs is recommended: NMAP is the
    industry standard for port scanners, Hydra is a weak password tester and
    Nikto is a cgi/.script checker. While not required, these external
    programs greatly enhance Nessus' scanning ability. They are included
    because they are the best applications in their class. If installed in the
    PATH$ before Nessus installation, they will automatically be available.

    The simplest installation method is using the Lynx automatic install. Lynx
    is included on many of the linux versions. The Lynx command is (logged in
    as a user, and not root) :

    lynx -source http://install.nessus.org | sh

    This should install the server on most platforms with no other steps
    necessary. Note that the latest install script can also be downloaded and
    run locally. Whether you install directly off the Website or using the
    same install script offline, either way the script will setup a temporary
    suid and ask for your root password when required -- if you don't like
    this feature you can download, compile and install the four required
    tarballs individually. The above command should also be used periodically
    to upgrade Nessus as new versions are regularly released. You will be
    questioned about proxy servers, a download method (www or CVS), and the
    branch of the development tree to use; most of the time the defaults are
    the best choice. This is the simplest method of installation however; you
    are effectively giving the install.nessus.org server temporary root
    privileges. Thus there is a security risk with this method albeit a low
    one. So if you are paranoid, and paranoid is not always a bad thing in the
    security field, installation can be done the old-fashioned way by
    downloading and compiling the source. For information on performing an
    install from scratch see: www.nessus.org/nessus_2_0.html.
    3.0 Setup
    Once the server is installed, some basic setup steps are required. The
    first task to complete in the new install is to add a user. A new user can
    be added by the "nessus-adduser" command. The script will question you for
    the authentication method. Authentication can be performed by several
    means, however a password is the simplest and is recommended. The next
    question queries about rules to restrict the user account. When used
    across an enterprise, a user can be restricted and only allowed to scan
    specified IP addresses. However, for most uses this will be left blank,
    allowing the user to scan anything. A certificate also needs to be
    generated as well to be used to encrypt the traffic between the client and
    server. The nessus-mkcert command accomplishes this.
    3.1 Update plug-ins
    Before a scan is done, the plug-ins should be updated. Nessus plug-ins are
    very much like virus signatures in a common virus scanner application.
    Each plug-in is written to test for a specific vulnerability. These can be
    written to actually exploit the vulnerability or just test for known
    vulnerable software versions. Plug-ins can be written in most any language
    but usually are written in the Nessus Attack Scripting Language (NASL).
    NASL is Nessus' own language, specifically designed for vulnerability test
    writing. Each plug-in is written to test for a specific known
    vulnerability and/or industry best practices. NASL plug-ins typically test
    by sending very specific code to the target and comparing the results
    against stored vulnerable values. There are a few built-in plug-ins that
    do not use NASL. These are C and Perl scripts to perform special purposes
    that can not easily be done in NASL. Among these is the Services plug-in
    which identifies port-to-program mappings.

    Plug-in updates should be done frequently. New vulnerabilities are being
    discovered and disseminated all the time. Typically after a new
    vulnerability is released to the public, someone in the Nessus community
    writes a NASL plug-in, releases it to the public and submits it to
    www.nessus.org. It is then reviewed by the developers and added to the
    approved plug-in list. For high risk, high profile vulnerabilities a
    plug-in is often released the same day the vulnerability information is
    publicly released. Updating plug-ins from the maintained list is fairly
    simple involving a simple command: nessus-update-plugins. This command
    must be done as root. By no means however, are you limited to the list of
    plug-ins from www.nessus.org. New and special purpose plug-ins can be
    written relatively easily using NASL, so you can write your own custom
    plug-ins as well.
    3.2 Launch the daemon
    Nessus is now installed, updated and ready to go. The simplest way to get
    the server running is (as root) issue the nessusd -D command. In order to
    use it, one must use a client. There are three primary Nessus clients. The
    native Unix GUI version is installed at server install time.
    Alternatively, Nessus can be controlled from the command line. A third
    option, a Windows version also exists called NessusWX. The binaries for
    NessusWX can be found here . The NessusWX install is a straightforward
    Windows install. All three clients work well. Personally I prefer
    NessusWX. It is better organized, allows for easier reporting, and has a
    better facility for managing different sessions (groups of hosts to scan)
    then its Unix counterparts. To run the native Unix GUI client, run the
    nessus command or for NessusWX click the eye icon after installation.
    3.3 Client connection
    Since Nessus is a client server technology, once running the client a
    connection must be made to the server. In the native client, enter the
    server IP, username and password (created with the nessus-adduser command)
    and hit login. The process in NessusWX is similar but uses the
    communications | connect menus. The client is connected to the server thru
    an SSL connection and a list of the currently installed plug-ins is
    downloaded. On the first run the SSL certificate is also downloaded and
    verification is requested. This verification ensures that in the future
    you are actually communicating with the server intended. Figures 1 and 2
    shows the connection using the Unix and Windows GUI tools, respectively.
    Figure 3 shows user authentication using the NessusWX client.

    Figure 1: Starting the Nessus server and connecting with the Unix GUI
    Figure 1: Starting the Nessus server and connecting with the Unix GUI

    Figure 2: Connecting to the Nessus server with NessusWX (Windows Client)
    Figure 2: Connecting to the Nessus server with NessusWX (Windows Client)

    Figure 3: Enter in the server IP and the login and password setup with
    nessus_adduser
    Figure 3: Enter in the server IP and the login and password setup with
    nessus_adduser

    4.0 Using Nessus
    Now that we have installed and connected to Nessus lets explore some of
    the options available. The most obvious and powerful aspect of Nessus is
    its plug-in feature. The choice of plug-ins is critical to the success of
    a scan. Most plug-ins are written very well and rarely trigger false
    positives or negatives; however, a few are not. One example of a poorly
    written plug-in is the test for the classic Windows IIS hack RFP's MSDAC
    /RDS vulnerability. Rain Forest Puppy (RFP) publicized this vulnerability
    in 1999. The vulnerability makes use of the %system%/msadc/msadcs.dll file
    and leads to total system compromise on un-patched IIS 4.0 servers. The
    problem is that the Nessus plug-in only tests for the existence of the
    /msadc/msadcs.dll file. It does not take into account patches, windows
    versions etc. Thus with this plug-in enabled, a false positive will show
    up on many IIS servers and must be sorted out manually.

    Before anyone yells out, "see the problems of public domain software," one
    should note that the same types of problems exist with the high priced
    "supported" vulnerability scanners as well. This problem is a result of
    the current state of the technology. The difference is that typically in
    purchased products you cannot easily examine the exact "proprietary"
    testing methodology as can be done with Nessus, thus making resolution of
    the false positive difficult.
    4.1 Choosing dangerous/non-dangerous plug-ins
    Plug-ins are categorized in several different and sometimes confusing
    ways. One method of plug-in grouping is by category. Most importantly,
    some plug-ins are categorized as Dangerous/Denial of Service (DOS). These
    plug-ins will actually perform a DOS attack and crash systems that have
    these particular problems. Needless to say these should not be blindly run
    on production systems. They won't cause long term damage, but at least a
    reboot will be required. In both clients, there are buttons to "Enable all
    plug-ins" or just "Enable all but dangerous plug-ins" (called "Enable
    Non-DOS" in NessusWX). Note that the author of the plug-in decides if it
    is dangerous or not. Most of the time, this has been very well chosen.
    However there are instances (Exmple: the rpc_endpoint mapper plug-in),
    where the plug-in causes a DOS but it is not listed as dangerous. The
    native client denotes dangerous plug-ins with a caution triangle. NessusWX
    has no special way to notate a dangerous plug-in other then using the
    enable "Enable Non-DOS" button. One other thing to be aware of is that
    sometimes even a "non-dangerous" plug-in can crash software. Since the
    plug-ins are sending non-standard data, there is always the risk, albeit
    rare, that a new undiscovered DOS will be stumbled upon. Therefore anytime
    systems are being scanned one should be aware that system crashes,
    although unlikely, are possible even with "non-dangerous" plug-ins. Figure
    4, below, shows plug-in selection using the Unix GUI. Similarly, Figures 5
    and 6 show plug-in selection using NessusWX for Windows:

    Figure 4: Enabling all but dangerous plugins with the Unix Nessus GUI
    Figure 4: Enabling all but dangerous plugins with the Unix Nessus GUI

    Figure 5: Selecting plug-ins with the Windows NessusWX Client
    Figure 5: Selecting plug-ins with the Windows NessusWX Client

    Figure 6: Enabling non-dangerous plug-ins with the Windows NessusWX Client
    Figure 6: Enabling non-dangerous plug-ins with the Windows NessusWX Client

    4.2 Safe-checks
    This is a good place to mention the related concept of safe-checks.
    Safe-checks disables the dangerous parts of safe-check compatible plug-ins
    and causes them to check just through passive methods such as version
    numbers in banners. Since a patch or workaround may be installed,
    safe-checks are not as reliable as actually exploiting the vulnerability.
    They might cause false positives or false negatives. The valuable trade
    off is that they should not crash a machine. The safe-check option is on
    the scan options tab (the options tab in NessusWX). Figure 7 shows the
    safe-check option in the NessusWX interface:

    Figure 7: Choosing Safe Checks
    Figure 7: Choosing Safe Checks

    The second method of plug-in organization is in families such as Windows,
    FTP SNMP, SMB, Cisco, etc. I find this to be a rather unhelpful grouping
    due to the arbitrary categorizing process. Should an FTP vulnerability
    that only exists on a Windows box go in the Windows family or the FTP
    family? Since this decision is left up to the plug-in writer with little
    guidance, there are examples of both. The filtering/search mechanism is
    very helpful to isolate certain vulnerabilities. A filter can be initiated
    on name, plug-in number, etc. Clicking on the family and then the plug-in
    will give details of what the plug-in tests for. If intricate details are
    needed, the actual NASL code at cgi.nessus.org/plugins/ can be referenced.
    Note the DOS family is not the same as the dangerous/DOS category of
    plug-ins. A dangerous/DOS category plug-in actually exploits the
    vulnerability while a plug-in in the DOS family may just check for the
    vulnerability by checking software versions, for example. To perform a
    simple noisy scan on a non-production system, enabling all plug-ins is the
    best choice. If stealth or a production system is involved, choices can
    get complicated. We will talk in-depth about plug-ins selection in a
    future article.
    4.3 Port scanning
    The other critical part of the scanning process is port scanning. Port
    scanning is the process by which the active ports for an IP address are
    identified. Each port is tied to a specific application. Nessus is a smart
    scanner and only runs a test if the specific program for that test is
    available. For example, only Web server plug-ins are run if a Web server
    is found. Since often ports are changed from their default to hide them,
    Nessus has a plug-in called services. The services plug-in attempts to
    identify the program running on each port. Once the program is identified,
    only the user-selected and pertinent plug-ins are run against it.

    Nessus has several options to scan for ports. There is the built-in
    wrapper for NMAP, widely acknowledged as the best port scanner around.
    There is also an internal scanner and a custom ping scan. As with plug-in
    selection, port scanning is very dependent on the situation. For a simple
    scan, the internal "sync" scan using default parameters with pings
    enabled, found on the "Perf" tab of the Unix GUI and the Port scan tab of
    NessusWX, is sufficient. Figures 8 and 9, below, show the internal SYN
    scan option using NessusWX and the Unix GUI client, respectively:

    Figure 8: Configuring the internal SYN scan for a simple port scan on
    NessusWX
    Figure 8: Configuring the internal SYN scan for a simple port scan on
    NessusWX

    Figure 9: Configuring the internal SYN scan for a simple port scan on the
    Unix Client
    Figure 9: Configuring the internal SYN scan for a simple port scan on the
    Unix Client

    4.3 Identify targets
    The final task is to identify your targets. This is done on the targets
    tab. Targets can be specified as a single IP Address, as a subnet or as a
    range of IP addresses. I normally try to break them down into logical
    groups. It is typically easier to deal with smaller groups at one time.
    Figures 10 and 11 show how to select targets in both client environments:

    Figure 10: Specifying Targets in the Unix GUI
    Figure 10: Specifying Targets in the Unix GUI

    Figure 11: Target Selection in NessusWX
    Figure 11: Target Selection in NessusWX

    4.4 Start a scan
    With your Nessus client and server in hand you are ready to scan systems.
    To start a scan in the Unix GUI just click "Start Scan" at the bottom of
    the window. In NessusWX, right click the desired session and select
    Execute. Properly used, Nessus can and will pinpoint problems and provide
    solutions. However, misused it can and will crash systems, cause the loss
    of data, and possibly cost you your job. As with anything powerful, there
    comes risk and responsibilities. Scanned systems sometimes will crash.
    Don't scan any system without permission. I suggest your first scan be
    against your own isolated test system. Future articles will lead you
    thorough a scan, sort out false positives and talk about stealth and
    firewall scanning. Figures 12, 13 and 14 show a scan using NessusWX.

    Figure 12: Starting a scan in NessusWX
    Figure 12: Starting a scan in NessusWX

    Figure 13: Starting a scan in NessusWX
    Figure 13: Starting a scan in NessusWX

    Figure 14: NessusWX scan in Progress
    Figure 14: NessusWX scan in Progress
    5.0 Conclusion
    Nessus is an excellent tool that will greatly aid your ability to test and
    discover known security problems. As has been mentioned several times in
    this article, the power that Nessus gives you should be used wisely as it
    can render production systems unavailable with some of the more dangerous
    plus-ins. For more information on Nessus, visit the official Nessus site
    at www.nessus.org. Happy Scanning!

    1.0 Introduction
    Nessus is a great tool designed to automate the testing and discovery of
    known security problems. Typically someone, a hacker group, a security
    company, or a researcher discovers a specific way to violate the security
    of a software product. The discovery may be accidental or through directed
    research; the vulnerability, in various levels of detail, is then released
    to the security community. Nessus is designed to help identify and solve
    these known problems, before a hacker takes advantage of them. Nessus is a
    great tool with lots of capabilities. However it is fairly complex and few
    articles exist to direct the new user through the intricacies of how to
    install and use it. Thus, this article shall endeavor to cover the basics
    of Nessus setup and configuration. The features of the current versions of
    Nessus (Nessus 2.0.8a and NessusWX 1.4.4) will be discussed. Future
    articles will cover Nessus in more depth.

    Nessus is a free program released under the GPL. Historically, many in the
    corporate world have ridiculed such public domain software as being a
    waste of time, instead choosing "supported" products developed by
    established companies. Typically these packages cost hundreds or thousands
    of dollars, and are often purchased using the logic that you get what you
    pay for. Some people are starting to realize that public domain software,
    such as Nessus, isn't always inferior and sometimes it is actually
    superior. Paid technical support for Nessus is even available from
    www.tenablesecurity.com. Nessus also has a great community of developers
    anchored by the primary author, Renaud Deraison. When allowed to fairly
    compete in reviews against other vulnerability scanners, Nessus has
    equaled or outshined products costing thousands of dollars. [ref:
    Information Security, Network Computing]

    One of the very powerful features of Nessus is its client server
    technology. Servers can be placed at various strategic points on a network
    allowing tests to be conducted from various points of view. A central
    client or multiple distributed clients can control all the servers. The
    server portion will run on most any flavor of Unix. It even runs on MAC OS
    X and IBM/AIX, but Linux tends to make the installation simpler. These
    features provide a great deal of flexibility for the penetration tester.
    Clients are available for both Windows and Unix. The Nessus server
    performs the actual testing while the client provides configuration and
    reporting functionality.
    2.0 Installation
    Nessus server installation is fairly simple even for a Windows jockey like
    me. First an installed version of Unix is required. Secondly, prior
    installation of several external programs is recommended: NMAP is the
    industry standard for port scanners, Hydra is a weak password tester and
    Nikto is a cgi/.script checker. While not required, these external
    programs greatly enhance Nessus' scanning ability. They are included
    because they are the best applications in their class. If installed in the
    PATH$ before Nessus installation, they will automatically be available.

    The simplest installation method is using the Lynx automatic install. Lynx
    is included on many of the linux versions. The Lynx command is (logged in
    as a user, and not root) :

    lynx -source http://install.nessus.org | sh

    This should install the server on most platforms with no other steps
    necessary. Note that the latest install script can also be downloaded and
    run locally. Whether you install directly off the Website or using the
    same install script offline, either way the script will setup a temporary
    suid and ask for your root password when required -- if you don't like
    this feature you can download, compile and install the four required
    tarballs individually. The above command should also be used periodically
    to upgrade Nessus as new versions are regularly released. You will be
    questioned about proxy servers, a download method (www or CVS), and the
    branch of the development tree to use; most of the time the defaults are
    the best choice. This is the simplest method of installation however; you
    are effectively giving the install.nessus.org server temporary root
    privileges. Thus there is a security risk with this method albeit a low
    one. So if you are paranoid, and paranoid is not always a bad thing in the
    security field, installation can be done the old-fashioned way by
    downloading and compiling the source. For information on performing an
    install from scratch see: www.nessus.org/nessus_2_0.html.
    3.0 Setup
    Once the server is installed, some basic setup steps are required. The
    first task to complete in the new install is to add a user. A new user can
    be added by the "nessus-adduser" command. The script will question you for
    the authentication method. Authentication can be performed by several
    means, however a password is the simplest and is recommended. The next
    question queries about rules to restrict the user account. When used
    across an enterprise, a user can be restricted and only allowed to scan
    specified IP addresses. However, for most uses this will be left blank,
    allowing the user to scan anything. A certificate also needs to be
    generated as well to be used to encrypt the traffic between the client and
    server. The nessus-mkcert command accomplishes this.
    3.1 Update plug-ins
    Before a scan is done, the plug-ins should be updated. Nessus plug-ins are
    very much like virus signatures in a common virus scanner application.
    Each plug-in is written to test for a specific vulnerability. These can be
    written to actually exploit the vulnerability or just test for known
    vulnerable software versions. Plug-ins can be written in most any language
    but usually are written in the Nessus Attack Scripting Language (NASL).
    NASL is Nessus' own language, specifically designed for vulnerability test
    writing. Each plug-in is written to test for a specific known
    vulnerability and/or industry best practices. NASL plug-ins typically test
    by sending very specific code to the target and comparing the results
    against stored vulnerable values. There are a few built-in plug-ins that
    do not use NASL. These are C and Perl scripts to perform special purposes
    that can not easily be done in NASL. Among these is the Services plug-in
    which identifies port-to-program mappings.

    Plug-in updates should be done frequently. New vulnerabilities are being
    discovered and disseminated all the time. Typically after a new
    vulnerability is released to the public, someone in the Nessus community
    writes a NASL plug-in, releases it to the public and submits it to
    www.nessus.org. It is then reviewed by the developers and added to the
    approved plug-in list. For high risk, high profile vulnerabilities a
    plug-in is often released the same day the vulnerability information is
    publicly released. Updating plug-ins from the maintained list is fairly
    simple involving a simple command: nessus-update-plugins. This command
    must be done as root. By no means however, are you limited to the list of
    plug-ins from www.nessus.org. New and special purpose plug-ins can be
    written relatively easily using NASL, so you can write your own custom
    plug-ins as well.
    3.2 Launch the daemon
    Nessus is now installed, updated and ready to go. The simplest way to get
    the server running is (as root) issue the nessusd -D command. In order to
    use it, one must use a client. There are three primary Nessus clients. The
    native Unix GUI version is installed at server install time.
    Alternatively, Nessus can be controlled from the command line. A third
    option, a Windows version also exists called NessusWX. The binaries for
    NessusWX can be found here . The NessusWX install is a straightforward
    Windows install. All three clients work well. Personally I prefer
    NessusWX. It is better organized, allows for easier reporting, and has a
    better facility for managing different sessions (groups of hosts to scan)
    then its Unix counterparts. To run the native Unix GUI client, run the
    nessus command or for NessusWX click the eye icon after installation.
    3.3 Client connection
    Since Nessus is a client server technology, once running the client a
    connection must be made to the server. In the native client, enter the
    server IP, username and password (created with the nessus-adduser command)
    and hit login. The process in NessusWX is similar but uses the
    communications | connect menus. The client is connected to the server thru
    an SSL connection and a list of the currently installed plug-ins is
    downloaded. On the first run the SSL certificate is also downloaded and
    verification is requested. This verification ensures that in the future
    you are actually communicating with the server intended. Figures 1 and 2
    shows the connection using the Unix and Windows GUI tools, respectively.
    Figure 3 shows user authentication using the NessusWX client.

    Figure 1: Starting the Nessus server and connecting with the Unix GUI
    Figure 1: Starting the Nessus server and connecting with the Unix GUI

    Figure 2: Connecting to the Nessus server with NessusWX (Windows Client)
    Figure 2: Connecting to the Nessus server with NessusWX (Windows Client)

    Figure 3: Enter in the server IP and the login and password setup with
    nessus_adduser
    Figure 3: Enter in the server IP and the login and password setup with
    nessus_adduser

    4.0 Using Nessus
    Now that we have installed and connected to Nessus lets explore some of
    the options available. The most obvious and powerful aspect of Nessus is
    its plug-in feature. The choice of plug-ins is critical to the success of
    a scan. Most plug-ins are written very well and rarely trigger false
    positives or negatives; however, a few are not. One example of a poorly
    written plug-in is the test for the classic Windows IIS hack RFP's MSDAC
    /RDS vulnerability. Rain Forest Puppy (RFP) publicized this vulnerability
    in 1999. The vulnerability makes use of the %system%/msadc/msadcs.dll file
    and leads to total system compromise on un-patched IIS 4.0 servers. The
    problem is that the Nessus plug-in only tests for the existence of the
    /msadc/msadcs.dll file. It does not take into account patches, windows
    versions etc. Thus with this plug-in enabled, a false positive will show
    up on many IIS servers and must be sorted out manually.

    Before anyone yells out, "see the problems of public domain software," one
    should note that the same types of problems exist with the high priced
    "supported" vulnerability scanners as well. This problem is a result of
    the current state of the technology. The difference is that typically in
    purchased products you cannot easily examine the exact "proprietary"
    testing methodology as can be done with Nessus, thus making resolution of
    the false positive difficult.
    4.1 Choosing dangerous/non-dangerous plug-ins
    Plug-ins are categorized in several different and sometimes confusing
    ways. One method of plug-in grouping is by category. Most importantly,
    some plug-ins are categorized as Dangerous/Denial of Service (DOS). These
    plug-ins will actually perform a DOS attack and crash systems that have
    these particular problems. Needless to say these should not be blindly run
    on production systems. They won't cause long term damage, but at least a
    reboot will be required. In both clients, there are buttons to "Enable all
    plug-ins" or just "Enable all but dangerous plug-ins" (called "Enable
    Non-DOS" in NessusWX). Note that the author of the plug-in decides if it
    is dangerous or not. Most of the time, this has been very well chosen.
    However there are instances (Exmple: the rpc_endpoint mapper plug-in),
    where the plug-in causes a DOS but it is not listed as dangerous. The
    native client denotes dangerous plug-ins with a caution triangle. NessusWX
    has no special way to notate a dangerous plug-in other then using the
    enable "Enable Non-DOS" button. One other thing to be aware of is that
    sometimes even a "non-dangerous" plug-in can crash software. Since the
    plug-ins are sending non-standard data, there is always the risk, albeit
    rare, that a new undiscovered DOS will be stumbled upon. Therefore anytime
    systems are being scanned one should be aware that system crashes,
    although unlikely, are possible even with "non-dangerous" plug-ins. Figure
    4, below, shows plug-in selection using the Unix GUI. Similarly, Figures 5
    and 6 show plug-in selection using NessusWX for Windows:

    Figure 4: Enabling all but dangerous plugins with the Unix Nessus GUI
    Figure 4: Enabling all but dangerous plugins with the Unix Nessus GUI

    Figure 5: Selecting plug-ins with the Windows NessusWX Client
    Figure 5: Selecting plug-ins with the Windows NessusWX Client

    Figure 6: Enabling non-dangerous plug-ins with the Windows NessusWX Client
    Figure 6: Enabling non-dangerous plug-ins with the Windows NessusWX Client

    4.2 Safe-checks
    This is a good place to mention the related concept of safe-checks.
    Safe-checks disables the dangerous parts of safe-check compatible plug-ins
    and causes them to check just through passive methods such as version
    numbers in banners. Since a patch or workaround may be installed,
    safe-checks are not as reliable as actually exploiting the vulnerability.
    They might cause false positives or false negatives. The valuable trade
    off is that they should not crash a machine. The safe-check option is on
    the scan options tab (the options tab in NessusWX). Figure 7 shows the
    safe-check option in the NessusWX interface:

    Figure 7: Choosing Safe Checks
    Figure 7: Choosing Safe Checks

    The second method of plug-in organization is in families such as Windows,
    FTP SNMP, SMB, Cisco, etc. I find this to be a rather unhelpful grouping
    due to the arbitrary categorizing process. Should an FTP vulnerability
    that only exists on a Windows box go in the Windows family or the FTP
    family? Since this decision is left up to the plug-in writer with little
    guidance, there are examples of both. The filtering/search mechanism is
    very helpful to isolate certain vulnerabilities. A filter can be initiated
    on name, plug-in number, etc. Clicking on the family and then the plug-in
    will give details of what the plug-in tests for. If intricate details are
    needed, the actual NASL code at cgi.nessus.org/plugins/ can be referenced.
    Note the DOS family is not the same as the dangerous/DOS category of
    plug-ins. A dangerous/DOS category plug-in actually exploits the
    vulnerability while a plug-in in the DOS family may just check for the
    vulnerability by checking software versions, for example. To perform a
    simple noisy scan on a non-production system, enabling all plug-ins is the
    best choice. If stealth or a production system is involved, choices can
    get complicated. We will talk in-depth about plug-ins selection in a
    future article.
    4.3 Port scanning
    The other critical part of the scanning process is port scanning. Port
    scanning is the process by which the active ports for an IP address are
    identified. Each port is tied to a specific application. Nessus is a smart
    scanner and only runs a test if the specific program for that test is
    available. For example, only Web server plug-ins are run if a Web server
    is found. Since often ports are changed from their default to hide them,
    Nessus has a plug-in called services. The services plug-in attempts to
    identify the program running on each port. Once the program is identified,
    only the user-selected and pertinent plug-ins are run against it.

    Nessus has several options to scan for ports. There is the built-in
    wrapper for NMAP, widely acknowledged as the best port scanner around.
    There is also an internal scanner and a custom ping scan. As with plug-in
    selection, port scanning is very dependent on the situation. For a simple
    scan, the internal "sync" scan using default parameters with pings
    enabled, found on the "Perf" tab of the Unix GUI and the Port scan tab of
    NessusWX, is sufficient. Figures 8 and 9, below, show the internal SYN
    scan option using NessusWX and the Unix GUI client, respectively:

    Figure 8: Configuring the internal SYN scan for a simple port scan on
    NessusWX
    Figure 8: Configuring the internal SYN scan for a simple port scan on
    NessusWX

    Figure 9: Configuring the internal SYN scan for a simple port scan on the
    Unix Client
    Figure 9: Configuring the internal SYN scan for a simple port scan on the
    Unix Client

    4.3 Identify targets
    The final task is to identify your targets. This is done on the targets
    tab. Targets can be specified as a single IP Address, as a subnet or as a
    range of IP addresses. I normally try to break them down into logical
    groups. It is typically easier to deal with smaller groups at one time.
    Figures 10 and 11 show how to select targets in both client environments:

    Figure 10: Specifying Targets in the Unix GUI
    Figure 10: Specifying Targets in the Unix GUI

    Figure 11: Target Selection in NessusWX
    Figure 11: Target Selection in NessusWX

    4.4 Start a scan
    With your Nessus client and server in hand you are ready to scan systems.
    To start a scan in the Unix GUI just click "Start Scan" at the bottom of
    the window. In NessusWX, right click the desired session and select
    Execute. Properly used, Nessus can and will pinpoint problems and provide
    solutions. However, misused it can and will crash systems, cause the loss
    of data, and possibly cost you your job. As with anything powerful, there
    comes risk and responsibilities. Scanned systems sometimes will crash.
    Don't scan any system without permission. I suggest your first scan be
    against your own isolated test system. Future articles will lead you
    thorough a scan, sort out false positives and talk about stealth and
    firewall scanning. Figures 12, 13 and 14 show a scan using NessusWX.

    Figure 12: Starting a scan in NessusWX
    Figure 12: Starting a scan in NessusWX

    Figure 13: Starting a scan in NessusWX
    Figure 13: Starting a scan in NessusWX

    Figure 14: NessusWX scan in Progress
    Figure 14: NessusWX scan in Progress
    5.0 Conclusion
    Nessus is an excellent tool that will greatly aid your ability to test and
    discover known security problems. As has been mentioned several times in
    this article, the power that Nessus gives you should be used wisely as it
    can render production systems unavailable with some of the more dangerous
    plus-ins. For more information on Nessus, visit the official Nessus site
    at www.nessus.org. Happy Scanning!

    *----------------------------------------------------------*
    Kayven Riese, BSCS, MS (Physiology and Biophysics)
    (415) 902 5513 cellular
    http://kayve.net
    Webmaster http://ChessYoga.org
    *----------------------------------------------------------*
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  5. Re: Hifn 7955 doesn't work with Freebsd 7.0-release

    0n Wed, May 21, 2008 at 08:19:26PM -0700, Sam Leffler wrote:

    >Unfortunately openssl doesn't use the accelerator by default. This means
    >all apps that use openssl likewise are not automatically accelerated. I
    >suggested a patch but it was not accepted. I can't recall how you force
    >openssl and/or consumers to use the device.


    How annoying is that. Why wasn't the patch accepted ?

    -aW


    IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email.


    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  6. libz.so no found


    kv_bsd#cd /usr/ports/distfiles
    kv_bsd#mv /usr/home/kayve/Nessus-3.2.0-fbsd7.tbz .
    kv_bsd#pkg_add Nessus-3.2.0-fbsd7.tbz
    pkg_add: package VisualOS-1.0.5_3 has no origin recorded
    /libexec/ld-elf.so.1: Shared object "libz.so.4" not found, required by
    "nessusd"

    - Please run /usr/local/nessus/sbin/nessus-adduser to add an admin user
    - Register your Nessus scanner at http://www.nessus.org/register/ to
    obtain
    all the newest plugins
    - You can start nessusd by typing /usr/local/etc/rc.d/nessusd.sh start
    kv_bsd#/usr/local/etc/rc.d/nessusd.sh start
    Nessus/libexec/ld-elf.so.1: Shared object "libz.so.4" not found, required
    by "nessusd"
    kv_bsd#


    *----------------------------------------------------------*
    Kayven Riese, BSCS, MS (Physiology and Biophysics)
    (415) 902 5513 cellular
    http://kayve.net
    Webmaster http://ChessYoga.org
    *----------------------------------------------------------*
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  7. Many Nessus startup errors


    I am not generating reports

    http://www.monkeyview.net/id/965/fsc...s/nessus.vhtml

    During startup, 20K plugins try to load. A lot of them fail
    or something:

    http://www.monkeyview.net/id/965/fsc...p5210017.vhtml
    http://www.monkeyview.net/id/965/fsc...p5210018.vhtml

    *----------------------------------------------------------*
    Kayven Riese, BSCS, MS (Physiology and Biophysics)
    (415) 902 5513 cellular
    http://kayve.net
    Webmaster http://ChessYoga.org
    *----------------------------------------------------------*
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  8. Re: libz.so no found

    On Wed, 21 May 2008, Jeremy Chadwick wrote:

    > On Wed, May 21, 2008 at 10:13:43PM -0700, KAYVEN RIESE wrote:
    >> kv_bsd#cd /usr/ports/distfiles
    >> kv_bsd#mv /usr/home/kayve/Nessus-3.2.0-fbsd7.tbz .
    >> kv_bsd#pkg_add Nessus-3.2.0-fbsd7.tbz
    >> pkg_add: package VisualOS-1.0.5_3 has no origin recorded
    >> /libexec/ld-elf.so.1: Shared object "libz.so.4" not found, required by
    >> "nessusd"

    >
    > First and foremost, you hijacked an existing thread by replying to it
    > with regards to a completely different issue. Please don't do this, it
    > confuses mail clients which follow thread references. Please don't hit
    > reply on unrelated messages and start a new/unrelated discussion.


    i don't know wtf you are talking about these are all my threads.

    >
    > Secondly, the missing library error shown above would happen on machines
    > running FreeBSD 6.x or earlier. /lib/libz.so.4 exists on RELENG_7.
    >


    i am still on freeBSD 6.3 is this a serious problem?

    > Another possibility is that something completely destroyed ld.so's
    > shared library cache path. Of course, you'd be seeing all sorts of
    > programs reporting missing libraries, and not just nexxus.
    >


    so running freeBSD 6.3 is a fatal problem, or just extraneously
    irrelevant?

    > If the startup script for nessus calls ldconfig or uses
    > $LD_LIBRARY_PATH, that could explain the missing library.
    >
    > --
    > | Jeremy Chadwick jdc at parodius.com |
    > | Parodius Networking http://www.parodius.com/ |
    > | UNIX Systems Administrator Mountain View, CA, USA |
    > | Making life hard for others since 1977. PGP: 4BD6C0CB |
    >
    >


    *----------------------------------------------------------*
    Kayven Riese, BSCS, MS (Physiology and Biophysics)
    (415) 902 5513 cellular
    http://kayve.net
    Webmaster http://ChessYoga.org
    *----------------------------------------------------------*
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  9. Re: libz.so no found

    On Fri, 23 May 2008, KAYVEN RIESE wrote:
    > okay, so I don't have a shortcut key for freeBSD-hacker.. I went into
    > my freeBSD saved box, grabbed the first email, replied to all,
    > deleted everything including the subject, and despite having revised
    > the subject, your sooperphreekiness found out I was muddling around
    > in the deally bobber? Is that what you are talking about then? So
    > in the future, I should know that editing the subject line will not
    > suffice to make a new thread?
    >
    > If so, sorry. I get it now.


    Your mail client sets the In-Reply-To header to the message ID of the
    email you pulled out of your saved folder.

    Mail clients use this header to track what thread a message is in (even
    if someone changed the subject).

    --
    Daniel O'Connor software and network engineer
    for Genesis Software - http://www.gsoft.com.au
    "The nice thing about standards is that there
    are so many of them to choose from."
    -- Andrew Tanenbaum
    GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.8 (FreeBSD)

    iD8DBQBINoV85ZPcIHs/zowRAuKTAJ9V75EnWcuCKkca3tDZYmqBUg4IvgCbBAjG
    10kjGAtyj97vUpPY6KZQaFE=
    =Aelj
    -----END PGP SIGNATURE-----


  10. Re: libz.so no found

    On Fri, 23 May 2008, Daniel O'Connor wrote:

    > On Fri, 23 May 2008, KAYVEN RIESE wrote:
    >> okay, so I don't have a shortcut key for freeBSD-hacker.. I went into
    >> my freeBSD saved box, grabbed the first email, replied to all,
    >> deleted everything including the subject, and despite having revised
    >> the subject, your sooperphreekiness found out I was muddling around
    >> in the deally bobber? Is that what you are talking about then? So
    >> in the future, I should know that editing the subject line will not
    >> suffice to make a new thread?
    >>
    >> If so, sorry. I get it now.

    >
    > Your mail client sets the In-Reply-To header to the message ID of the
    > email you pulled out of your saved folder.
    >
    > Mail clients use this header to track what thread a message is in (even
    > if someone changed the subject).


    Thanks. This makes things clear. I'm sorry that I felt "scolded"
    by the confusing barrage (I guess at least a couple of you thought
    this should have been obvious to me).

    >
    > --
    > Daniel O'Connor software and network engineer
    > for Genesis Software - http://www.gsoft.com.au
    > "The nice thing about standards is that there
    > are so many of them to choose from."
    > -- Andrew Tanenbaum
    > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
    >


    *----------------------------------------------------------*
    Kayven Riese, BSCS, MS (Physiology and Biophysics)
    (415) 902 5513 cellular
    http://kayve.net
    Webmaster http://ChessYoga.org
    *----------------------------------------------------------*
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


+ Reply to Thread