[Openvas-commits] r1478 - in trunk/openvas-server: . doc
scm-commit@wald.intevation.org
scm-commit at wald.intevation.org
Wed Oct 1 16:07:21 CEST 2008
Author: mwiegand
Date: 2008-10-01 16:07:21 +0200 (Wed, 01 Oct 2008)
New Revision: 1478
Removed:
trunk/openvas-server/doc/otp_specification_10.txt
Modified:
trunk/openvas-server/ChangeLog
trunk/openvas-server/MANIFEST
Log:
* doc/otp_specification_10.txt: Removed; the specification for OTP has
been updated and moved to the OpenVAS compendium.
* MANIFEST: Updated.
Modified: trunk/openvas-server/ChangeLog
===================================================================
--- trunk/openvas-server/ChangeLog 2008-10-01 09:47:52 UTC (rev 1477)
+++ trunk/openvas-server/ChangeLog 2008-10-01 14:07:21 UTC (rev 1478)
@@ -1,3 +1,10 @@
+2008-10-01 Michael Wiegand <michael.wiegand at intevation.de>
+
+ * doc/otp_specification_10.txt: Removed; the specification for OTP has
+ been updated and moved to the OpenVAS compendium.
+
+ * MANIFEST: Updated.
+
2008-09-25 Michael Wiegand <michael.wiegand at intevation.de>
Post release version bump.
Modified: trunk/openvas-server/MANIFEST
===================================================================
--- trunk/openvas-server/MANIFEST 2008-10-01 09:47:52 UTC (rev 1477)
+++ trunk/openvas-server/MANIFEST 2008-10-01 14:07:21 UTC (rev 1478)
@@ -17,7 +17,6 @@
doc/openvas-mkcert-client.1
doc/openvas-mkrand.1
doc/openvas-rmuser.8
-doc/otp_specification_10.txt
doc/session_saving.txt
doc/TODO.txt
include/config.h
Deleted: trunk/openvas-server/doc/otp_specification_10.txt
===================================================================
--- trunk/openvas-server/doc/otp_specification_10.txt 2008-10-01 09:47:52 UTC (rev 1477)
+++ trunk/openvas-server/doc/otp_specification_10.txt 2008-10-01 14:07:21 UTC (rev 1478)
@@ -1,674 +0,0 @@
- OpenVAS Transport Protocol Specification 1.0
-
- Authors:
- Michael Wiegand <michael.wiegand at intevation.de>
- Jan-Oliver Wagner <jan-oliver.wagner at intevation.de>
-
-ABOUT THIS DOCUMENT
- This document describes OTP, the protocol used for communication between the
- server and client modules of the Open Vulnerability Assessment System
- (OpenVAS).
-
-STATUS
- This document is currently a draft; it does not describe the complete protocol
- yet but is still close to the Nessus Transport Protocol, version 1.2.
-
- Apart from this the documentation itself is not complete yet.
-
-INTRODUCTION
- The OpenVAS project is a fork of the Nessus project. Because of this, the
- initial protocol used for client-server communication was the Nessus
- Transport Protocol (NTP). In order to address the shortcomings of NTP and to
- facilitate further improvements in the OpenVAS modules it became necessary to
- make changes to the protocol. Since NTP was specified by the Nessus project
- and changes to NTP by the Nessus project are to be expected, a decision was
- made to switch to a new protocol to avoid collisions with future protocol
- specifications by the Nessus project and to avoid confusion with other
- well-established protocols.
-
-GENERAL CONSIDERATIONS
- The initial specification of the OpenVAS Transport Protocol (OTP) is very
- close to the NTP implementation in the last versions available under the GNU
- General Public License (GPL).
-
-CHANGES
- This section describes the changes between NTP 1.2 and OTP 1.0.
-
- Plug-in upload:
- Section 10 of the NTP Extensions describes the ATTACHED_PLUGIN message type.
- Using this message type, it was possible for a client to upload a plug-in to a
- server. Due to security considerations described in the OpenVAS change request
- #4 [1], this message type has been removed from the protocol.
-
- Version information:
- The undocumented NESSUS_VERSION message type has been replaced with the
- OPENVAS_VERSION message type. When an OPENVAS_VERSION message is issued by the
- client, the server is expected to respond with a message containing the
- current server version.
-
- New message types:
- In addition to the existing message types HOLE, INFO and NOTE two new message
- types have been added to the protocol: DEBUG and LOG. Their purpose is to give
- clients more control about the verbosity of the messages they receive from the
- server.
-
- Detached scans:
- This functionality has been dropped due to design decisions.
- This means the following commands have been removed
- from the protocol: DETACHED_SESSIONS_LIST and DETACHED_STOP.
- The following preferences have been removed from the protocol as
- well: detached_scan, continuous_scan, delay_between_scan_loops,
- detached_scan_email_address.
-
- Plugin order information:
- The server command PLUGINS_ORDER was defined for NTP 1.2 but not
- implemented in the server. This command has been removed from the protocol.
-
- Starting a scan:
- NTP offered two ways of starting a scan, NEW_ATTACK and LONG_ATTACK.
- The latter allowed arbitray long list of targets while the first
- was limited to 4000 bytes. The OpenVAS-Client (and so did NessusClient)
- used only LONG_ATTACK anyway.
-
- Protocol extensions:
- These protocol extensions have been made standard of the OTP
- protocol: "timestamps", "dependencies", "plugins_version",
- "plugins_cve_id", "plugins_bugtraq_id" and "plugins_xrefs".
-
-GENERAL ASPECTS OF PROTOCOL
-
- The OTP protocol is text-based, human readable and line-oriented.
-
- Each line is made of fields separated by "<|>. The first fields indicates
- whether it is a command send by client or by server ("CLIENT" vs. "SERVER").
-
-PROTOCOL INITIALIZER AND PROTOCOL FEATURES
-
- Description:
-
- The client start the protocol with a initializer of
- the protocol version followed by parameters switching
- on various features. Available protocol features are:
-
- md5_caching (server will use the MD5 caching feature)
-
- Syntax:
-
- < OTP/1.0 >< protocol_feature1 protocol_feature2 ... >
- User : user_name
- Password : user_password
-
-PROTOCOL COMMANDS
-
- ATTACHED_FILE
-
- Description:
-
- This command corresponds to the plugin preferences
- type "file". It follows the command PREFERENCES
- to upload the specified files from client to server.
-
- Syntax:
-
- CLIENT <|> ATTACHED_FILE
- name: file_name
- content: octet/stream
- bytes: file_length
- file_content
-
- where
- file_name: the path and name of the file.
- It is a identifier to reference the file
- in the plugin preferences.
- file_length: the number of bytes that will follow after the newline
- file_content: the actual file as byte stream.
-
- COMPLETE_LIST
-
- Description:
-
- This command can be used by the client in case the protocol
- feature "md5_caching" was selected by the client.
-
- It usually follows the PLUGINS_MD5 commands of the server
- in case the server side md5sum is not equal to the md5sum
- of the client side cached NVTs. Alternatively, the client
- can use the command SEND_PLUGINS_MD5.
-
- The server will answer with command PLUGIN_LIST.
-
- Syntax:
-
- CLIENT <|> COMPLETE_LIST <|> CLIENT
-
- ERROR
-
- Description:
-
- In case of problems the server sends an error message with this
- command. In case of unrecoverable problems, the server will then
- close connection with BYE command.
-
- Syntax:
-
- SERVER <|> ERROR <|> error description <|> SERVER
-
- FINISHED
-
- Description:
-
- The server will send this information each time when a scan
- of a single host is finished.
- This will only be done if requested by the client via setting
- the prefences option "ntp_opt_show_end".
-
- Syntax:
-
- SERVER <|> FINISHED <|> host <|> SERVER
-
- GO ON
-
- Description:
-
- This command can be used by the client in case the protocol
- feature "md5_caching" was selected by the client.
-
- It usually follows the PLUGINS_MD5 commands of the server
- in case the server side md5sum is equal to the md5sum
- of the client side cached NVTs.
-
- The server will answer with command PREFERENCES and
- communication will continue as it would have been without
- md5_caching feature.
-
- Syntax:
-
- CLIENT <|> GO ON <|> CLIENT
-
- HOLE
-
- Description:
-
- With this command the server reports a identified
- problem of class "security hole".
- The "general" version is applied if no port relates to the hole.
-
- Syntax:
-
- SERVER <|> HOLE <|> host <|> service_name (port_number/protocol_type) <|> description <|> oid <|> SERVER
-
- SERVER <|> HOLE <|> host <|> general <|> description <|> oid <|> SERVER
-
- where
- host: the target system
- service_name: the name of the service (like in /etc/services)
- port_number: the port number the problem relates to.
- protocol_type: "tcp" or "udp".
- description: the problem description where newlines have been
- replaced by semicolons.
- oid: the OID of the NVT that identified the problem.
-
- INFO
-
- Description:
-
- With this command the server reports a identified
- problem of class "security info".
- The "general" version is applied if no port relates to the info.
-
- Syntax:
-
- SERVER <|> INFO <|> host <|> service_name (port_number/protocol_type) <|> description <|> oid <|> SERVER
-
- SERVER <|> INFO <|> host <|> general <|> description <|> oid <|> SERVER
-
- where
- host: the target system
- service_name: the name of the service (like in /etc/services)
- port_number: the port number the problem relates to.
- protocol_type: "tcp" or "udp".
- description: the problem description where newlines have been
- replaced by semicolons.
- oid: the OID of the NVT that identified the problem.
-
- LONG_ATTACK
-
- Description:
-
- With this command the client requests the server to attack target
- system(s) "hosts". "hosts" is one or many (comma-separated) IP or FQDN.
-
- "length" is the number of bytes of "hosts". In case this does not match,
- the server will close connection.
-
- Before the client sends LONG_ATTACK, the commands PREFERENCES and
- RULES should be applied.
-
- Syntax:
-
- CLIENT <|> LONG_ATTACK
- length
- hosts
-
- NOTE
-
- Description:
-
- With this command the server reports a identified
- problem of class "security note".
- The "general" version is applied if no port relates to the note.
-
- Syntax:
-
- SERVER <|> NOTE <|> host <|> service_name (port_number/protocol_type) <|> description <|> oid <|> SERVER
-
- SERVER <|> NOTE <|> host <|> general <|> description <|> oid <|> SERVER
-
- where
- host: the target system
- service_name: the name of the service (like in /etc/services)
- port_number: the port number the problem relates to
- protocol_type: "tcp" or "udp".
- description: the problem description where newlines have been
- replaced by semicolons.
- oid: the OID of the NVT that identified the problem.
-
- OPENVAS_VERSION
-
- Description:
-
- With this command the client asks the server to send
- its version.
-
- The server will answer as shown in the syntax.
-
- Syntax:
-
- CLIENT <|> OPENVAS_VERSION <|> CLIENT
-
- SERVER <|> OPENVAS_VERSION <|> version <|> SERVER
-
- PLUGINS_DEPENDENCIES
-
- Description:
-
- The PLUGINS_DEPENDENCIES messages are send after the RULES messages.
-
- Syntax:
-
- SERVER <|> PLUGINS_DEPENDENCIES
- plugin_1_name <|> dependency1 <|> dependency2 <|> ... <|>
- plugin_2_name <|> dependency1 <|> dependency2 <|> ... <|>
- ...
- <|> SERVER
-
- PLUGINS_MD5
-
- Description:
-
- Attention: This command occurs in two ways.
-
- 1. This command replaces PLUGIN_LIST command in case the protocol
- feature "md5_caching" was selected by the client.
-
- "md5sum" is the MD5 sum over all NVTs.
-
- 2. This command follows the SEND_PLUGINS_MD5 command of the client
- and delivers the md5sums for each NVT.
-
- Syntax:
-
- 1.
- SERVER <|> PLUGINS_MD5 <|> md5sum <|> SERVER
-
- 2.
- SERVER <|> PLUGINS_MD5
- nvt_name1 <|> md5sum1
- nvt_name2 <|> md5sum2
- ...
- <|> SERVER
-
- PLUGIN_INFO
-
- Description:
-
- This command is issued by the client to request
- information of the NVT specified by its oid.
-
- Syntax:
-
- CLIENT <|> PLUGIN_INFO <|> oid <|> CLIENT
-
- The server answers with this line (analogous to PLUGIN_LIST command):
-
- oid <|> name <|> category <|> copyright <|> description <|> summary <|> family <|> plugin_version <|> cve_id <|> bugtraq_id <|> xrefs
-
- In case no plugin with OID=oid is found, the server will not answer at all.
-
- PLUGIN_LIST
-
- Description:
-
- With this command the server sends detailed information about
- the available NVTs.
-
- The server will send PREFERENCES and RULES right after this command.
-
- The client might request individual NVT information via PLUGIN_INFO
- command.
-
- Syntax:
-
- SERVER <|> PLUGIN_LIST <|>
- oid <|> name <|> category <|> copyright <|> description <|> summary <|> family <|> plugin_version <|> cve_id <|> bugtraq_id <|> xrefs
- oid <|> name <|> category <|> copyright <|> description <|> summary <|> family <|> plugin_version <|> cve_id <|> bugtraq_id <|> xrefs
- ...
- <|> SERVER
-
- PORT
-
- Description:
-
- With this command the server reports on open port
- "port_number" on target system "host".
-
- Syntax:
-
- SERVER <|> PORT <|> host <|> port_number <|> SERVER
-
- PREFERENCES
-
- Description:
-
- With this command the values for the preferences are
- communicated. The server uses the commands to inform
- about defaults, the client uses the command to send
- the user selections. The server answers with PREFERENCES_ERROR.
-
- Note that besides some general preferences, the syntax definition
- describes also per-NVT preferences and its special way of applying these.
-
- Available preferences:
- ntp_save_sessions:
- If set to "yes", the server will support server-side saving of
- scan sessions and these commands will be available: SESSIONS_LIST,
- SESSION_DELETE and SESSION_RESTORE.
- save_session:
- If set to yes, the server will save the scan as a session.
- save_empty_sessions:
- Only considered if save_session is set to "yes".
- If set to "yes" even emtpy scans will be saved a session.
- max_threads:
- test_file:
- ping_hosts:
- reverse_lookup:
- outside_firewall:
- host_expansion:
- port_range:
- max_hosts:
- save_knowledge_base:
- Activates KB saving when set to "yes"
- only_test_hosts_whose_kb_we_have:
- Only scans host for which the KB is filled when set to "yes"
- only_test_hosts_whose_kb_we_dont_have:
- Only scans host for which the KB is empty when set to "yes"
- kb_restore:
- Restore the KB contents for tested hosts when when set to "yes".
- kb_dont_replay_scanners:
- Don't run scanners in case in case kb_restore is set to "yes"
- and there is contents in the KB when set to "yes".
- kb_dont_replay_info_gathering:
- Don't run gatherers in case in case kb_restore is set to "yes"
- and there is contents in the KB when set to "yes".
- kb_dont_replay_attacks:
- Don't run attack scripts in case in case kb_restore is set to "yes"
- and there is contents in the KB when set to "yes".
- kb_dont_replay_denials:
- Don't run DoS attack scripts in case in case kb_restore is set to "yes"
- and there is contents in the KB when set to "yes".
- kb_max_age:
- This sets the maximum age (in seconds) of a KB until
- it gets disregarded.
- timeout.<nvt_id> = <timeout>
- Set the timeout <timeout> for NVT <nvt_id>. Timeout of "-1"
- means no specific timeout.
-
- Only sent by CLIENT:
- plugin_set: empty means all NVTs
- ntp_opt_show_end: Tell server to send FINISHED messages
- ntp_keep_communication_alive: Tell server to keep the connection even
- after a scan was finished.
- ntp_short_status: Tell server send shorter STATUS message in
- order to save band width.
-
- Syntax:
-
- SERVER <|> PREFERENCES <|>
- pref_name <|> value
- pref_name <|> value
- pref_name <|> value
- ...
- <|> SERVER
-
- CLIENT <|> PREFERENCES <|>
- pref_name <|> value
- pref_name <|> value
- pref_name <|> value
- ...
- <|> CLIENT
-
- For preference of individual NVTs these lines can occur inside the list:
-
- nvt_name[pref_type]:pref_name <|> value
-
- where
- nvt_name: This references the NVT for which the preferences are set
- pref_type: Defines the variable type of the preference which ultimately
- determines the widget type in the client GUI.
- pref_name: This references the Preference and at the same time is used as
- the visible string for the user in the GUI.
- value: The default value for this preference when sent by SERVER,
- the user selected value if send by CLIENT
-
- and pref_type is one of these:
- checkbox: value is "yes" or "no"
- entry: value is a text string
- password: value is a text string but should not be shown in GUI or
- in cleartext in local files
- radio: value is a list of semicolon-separated options when sent by SERVER
- and only the user-selected option name when sent by CLIENT
- file: value is "<none>" when sent by SERVER and a file path when sent
- by CLIENT. The client has to submit the file under the very same
- path name using the command ATTACHED_FILE.
-
-
- PREFERENCES_ERRORS
-
- Description:
-
- With this command the server reports problems with the
- parameters set by the client. It follows immediately
- the PREFERENCES command of the client.
-
- Each "pref_name" occuring in this list was not accepted
- by the server. The server will apply "default_value" instead.
-
- In case no "pref_name" is reported with this command,
- all preferences where accepted.
-
- Syntax:
-
- SERVER <|> PREFERENCES_ERRORS
- pref_name <|> default_value
- pref_name <|> default_value
- pref_name <|> default_value
- ...
- <|> SERVER
-
- RULES
-
- Description:
-
- Rules define restrictions for target systems.
- Client-side rules self-restrict target host patterns,
- server-side rules are just for information to the client.
- These rule sets are independent of each other.
-
- Syntax:
-
- SERVER <|> RULES <|>
- rule_1;
- rule_2;
- rule_3;
- ...
- <|> SERVER
-
- CLIENT <|> RULES <|>
- rule_1;
- rule_2;
- rule_3;
- ...
- <|> CLIENT
-
- SEND_PLUGINS_MD5
-
- Description:
-
- This command can be used by the client in case the protocol
- feature "md5_caching" was selected by the client.
-
- It usually follows the PLUGINS_MD5 commands of the server
- in case the server side md5sum is not equal to the md5sum
- of the client side cached NVTs. Alternatively, the client
- can use the command COMPLETE_LIST.
-
- The server will answer with command PLUGINS_MD5.
-
- Syntax:
-
- CLIENT <|> SEND_PLUGINS_MD5 <|> CLIENT
-
- SESSIONS_LIST
-
- Description:
-
- The CLIENT request with this command the list of sessions
- stored on the server side for the logged in user.
-
- The SERVER will answer with the same command and provide
- the list of sessions. The session names are derived from
- time stamps. The hosts are the targets applied for the
- respective session. The hosts are just there to help identify
- the sessions. It is cut after 4000 bytes of length.
-
- Syntax:
-
- CLIENT <|> SESSIONS_LIST <|> CLIENT
-
- SERVER <|> SESSIONS_LIST
- session_name1 hosts1
- session_name2 hosts2
- ...
- <|> SERVER
-
- SESSION_DELETE
-
- Description:
-
- With this command the client deletes the session identified
- with "session_name" from the server-side storage.
- The server will not answer in case of success, else
- it will answer with an ERROR command.
-
- Syntax:
-
- CLIENT <|> SESSION_DELETE <|> session_name <|> CLIENT
-
-
- SESSION_RESTORE
-
- Description:
-
- With this command the client tells the server to pick up
- again the session identified with "session_name".
- The server will act as if a LONG_ATTACK command has issued
- and will send all results that were collected so far for this
- session immediately (and naturally rapidley) and then
- continue the scan where it stopped.
-
- Syntax:
-
- CLIENT <|> SESSION_RESTORE <|> session_name <|> CLIENT
-
-
- STATUS
-
- Description:
-
- With this command, the server informs the client about
- the progress of the scan for target system "host".
- "attack_state" is either "portscan" or "attack" (or just
- "p" and "a" in case the client has set preferences
- option "ntp_short_status").
- "current" is the currently processed port and "max"
- the last port number to be tested.
-
- Syntax:
-
- SERVER <|> STATUS <|> host <|> attack_state <|> current/max <|> SERVER
-
- In case the client has set "ntp_short_status":
-
- SERVER <|> STATUS <|> attack_state:host:current:max <|> SERVER
-
-
- STOP_ATTACK
-
- Description:
-
- With this command, the client tells the server to stop
- scanning target "host".
-
- Syntax:
-
- CLIENT <|> STOP_ATTACK <|> host <|> CLIENT
-
- STOP_WHOLE_TEST
-
- Description:
-
- With this command the client tells to stop
- the currently running test.
-
- Syntax:
-
- CLIENT <|> STOP_WHOLE_TEST <|> CLIENT
-
- TIME
-
- Description:
-
- The TIME messages are sent by the server to inform
- about the duration of scanning a host and of the whole scan.
-
- Syntax:
-
- After completion of scanning a target host the server sends:
-
- SERVER <|> TIME <|> HOST_START <|> host <|> time_string <|> SERVER
- SERVER <|> TIME <|> HOST_END <|> host <|> time_string <|> SERVER
-
- or, in case STOP_ATTACK was issued by the client:
-
- SERVER <|> TIME <|> HOST_START <|> host <|> time_string <|> SERVER
- SERVER <|> TIME <|> HOST_INTERRUPTED <|> host <|> time_string <|> SERVER
-
- After completion of the whole scan the server sends:
-
- SERVER <|> TIME <|> SCAN_START <|> time_string <|> SERVER
- SERVER <|> TIME <|> SCAN_END <|> time_string <|> SERVER
-
- where time_string is of the form "Wed Jun 30 21:49:08 1993".
-
-REFERENCES
- [1] http://www.openvas.org/openvas-cr-4.html
More information about the Openvas-commits
mailing list