The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.

NAME

    Net::Nessus::Message - An implementation of Nessus Messages.

SYNOPSIS

    # Read a message from a socket
    my $msg = Net::Nessus::Message->new('socket' => $sock,
                                        'sender' => 'SERVER');

DESCRIPTION

The Nessus client and server are communicating with each other by sending and receiving messages. The message format is described in the files ntp_white_paper.txt (Protocol version 1.0) and ntp_white_paper_11.txt (Protocol version 1.1) of the Nessus distribution. In short messages consist of field lists, the fields being separated by the string ' <|> ' (including the spaces, not including the quotes). The first and the last lines are the words SERVER or CLIENT, depending on who's sending a message.

However, there are not only single line messages: Some messages, in particular the plugin and rule lists or the nessus preference lists do contain of multiple lines.

The Net::Nessus::Message class is abstract: Constructors never return instances of this class, but instances of subclasses. For example, if the server is sending a list of plugins, then an instance of Net::Nessus::Message::PLUGIN_LIST is returned.

METHOD INTERFACE

Reading a message from a socket

  my $msg = Net::Nessus::Message->new(%attr);

(Class Method) This method is reading a message from a socket, given by the socket attribute of the hash array %attr. The message is expected to be introduced and terminated by either SERVER or CLIENT, a specific sender is forced by setting the attribute sender, both are accepted otherwise. Likewise you may force a specific message type by setting the attribute type.

Example:

  my $msg = Net::Nessus::Message->new('socket' => $sock,
                                      'sender' => 'SERVER',
                                      'type' => 'PLUGIN_LIST');

Creating a message by supplying attributes

While the socket constructor is good for reading messages, you need another constructor for writing messages. The main difference is that you call the appropriate classes constructor this time and not a generic constroctur, unlike above.

Example:

  my $msg = Net::Nessus::Message::PREFERENCES->new(\%attr);

Available messages are:

PLUGIN_LIST
  $msg = Net::Nessus::Message::PLUGIN_LIST(\@plugins);
  $msg->print($sender, $socket);

Plugin lists are sent by the server as soon as the client connects The client may present the list to the user and let him select the plugins being called. The message has a single method

  $msg->Plugins();

that returns an array ref of hash refs, each of them having the attributes id, name, category, copyright, description summary and family.

PREFERENCES
PREFERENCES_ERRORS
  my $msg = Net::Nessus::Message::PREFERENCES->new(\%attr);
  my $msg = Net::Nessus::Message::PREFERENCES_ERRORS->new(\%attr);

Similar to the PLUGIN_LIST, the PREFERENCES are sent to the client if he has connected. The client may reply with another list of own preferences. Its method

  $msg->Prefs();

returns the preferences hash ref. The PREFERENCES message is available beginning with protocol version 1.1 and obsoletes the old NEW_ATTACK message in favour of the shorter version.

If the client has sent a PREFERENCES message, the server will respond a PREFERENCES_ERROR message. This is almost the same, except that only those values appear that had illegal values in the PREFERENCES message. The values in the reply will be the servers default values.

RULES
  $msg = Net::Nessus::Message::RULES(\@rules);

This is the third message sent to the client upon connect. Its only method is

  $msg->Rules();

returning an array ref of rules, each rule consisting of a single string.

HOLE
INFO
  $msg = Net::Nessus::Message::HOLE->new
      ([$host, $port, $description, $service, $proto]);

The HOLE and INFO messages are used by the server for reporting security problems. INFO messages are considered warnings, HOLE messages are expected to be more serious. You may use the following methods for retrieving more info:

  $msg->Host();
  $msg->Port();
  $msg->Description();
  $msg->Service();
  $msg->Proto();
  $msg->ScanID();

The methods Service and Description are valid as of NTP 1.1 only, they return undef in NTP 1.0. The Proto and Port methods may return undef even with NTP 1.1, in which case the Service method returns "general". Thus the Service method is used best to distinguish between NTP 1.0 and 1.1. The method ScanID, available with our proposed NTP 1.2 enhancements returns the scans ID, as presented in the plugin list.

PORT
  $msg = Net::Nessus::Message::PORT->new([$host, $port]);

The PORT message is sent, if the server finds an open port without known security problems. Thus the methods are similar to the HOLE and INFO messages, except that a Description method is missing.

  $msg->Host();
  $msg->Port();
ERROR

The ERROR message is used by the Nessus server to report problems. Its attributes are:

  $msg->ErrMsg
NEW_ATTACK
  # NTP 1.0
  $msg = Net::Nessus::Message::NEW_ATTACI->new
      ([$host, $pluginlist, $maxhosts, $recursive, $portrange]);
  # NTP 1.1
  $msg = Net::Nessus::Message::NEW_ATTACI->new([$host]);

NEW_ATTACK messages are sent by the client for launching new scans. Its attributes are:

  $msg->Host();
  $msg->PluginList();
  $msg->MaxHosts();
  $msg->Recursive();
  $msg->PortRange();

Except for the Host method, these are valid with NTP 1.0 only. They return the value undef in later versions.

STAT
  $msg = Net::Nessus::Message::STAT->new([$host, $port]);

The STAT message is sent by the server as an indicator for the port scanning status. Its attributes are:

  $msg->Host();
  $msg->Port();

As of NTP 1.1, this message is obsoleted by the STATUS message.

STOP_ATTACK
  $msg = Net::Nessus::Message::STOP_ATTACK->new([$host]);

The STOP_ATTACK message is sent by the client. It forces the server to stop attacking the given host:

  $msg->Host();
PLUGINS_ORDER
  $msg = Net::Nessus::Message::PLUGINS_ORDER->new([$plugins]);

This message is sent by the server before he starts scanning. It will contain the same list of plugins that the client requested with the NEW_ATTACK message (NTP 1.0) or the PREFERENCES message (NTP 1.1), but in the order they will be executed. The message has a method

  $msg->Plugins();

which returns an array of plugin ID's.

STATUS
  $msg = Net::Nessus::Message::STATUS->new([$host, $action, $status]);

This message is sent from an NTP 1.1 server as a progress indicator. It's attributes are:

  $msg->Host();
  $msg->Action();
  $msg->Status();

where the Host method returns a host being scanned, the Action method returns either portscan or attack and the Status method returns a string in the form "23/80" to indicate that 23 of

80 actions have been executed.

STOP_WHOLE_TEST
  $msg = Net::Nessus::Message::STOP_WHOLE_TEST->new([]);

This message, available with NTP 1.1 only, can be used to stop the whole test, unlike the STOP_ATTACK message which is stopping a single host only.

The message has no attributes, thus no methods for fetching attributes are available.

BYE
  $msg = Net::Nessus::Message::BYE->new([]);

This message is sent by the server to indicate that a scan is done.

AUTHOR AND COPYRIGHT

The Net::Nessus package is

  Copyright (C) 1998    Jochen Wiedmann
                        Am Eisteich 9
                        72555 Metzingen
                        Germany

                        Phone: +49 7123 14887
                        Email: joe@ispsoft.de
  All rights reserved.

You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file.

SEE ALSO

Net::Nessus::Client(3)