nasl_guide.tex

大国补丁后的nessus2.2.8的源代码

%
%
%                      THE NASL REFERENCE GUIDE
%
%
% This document has been written in LaTeX. To compile it,
% type 'latex nasl_guide.tex', and you will get a .dvi
% file.
%
%
% Written by Renaud Deraison <[e-mail]>
% $Id: nasl_guide.tex,v 1.19 2003/01/07 01:39:22 renaud Exp $


\documentclass{article}

% Do I need this ?

\usepackage{graphicx}
\usepackage{fancyhdr}
\pagestyle{fancy}
\fancyhead{}
\fancyhead[LE,RO]{NASL Reference Guide}
\fancyfoot[LE,RO]{}

\title{The Nessus Attack Scripting Language Reference Guide}
\author{Renaud Deraison $<$[e-mail]$>$}
\date{Version 1.4.0}


\begin{document}
\maketitle
\tableofcontents
\newpage
\section{Introduction}

\subsection{What is NASL ?}

NASL is a scripting language designed for the Nessus security scanner. Its aim 
is to allow anyone to write a test for a given security hole in a few minutes,
to allow people to share their tests without having to worry about their 
operating system, and to garantee everyone that a NASL script can not do
anything nasty except performing a given security test against a given
target.\\
Thus, NASL allows you to easily forge IP packets, or to send regular packets.
It provides you some convenient functions that will make the test of web and
ftp server easier to write. NASL garantees you that a NASL script :
\begin{itemize}
\item will not send any packet to a host other than the target host
\item will not execute any commands on your local system
\end{itemize}



\subsection{What NASL is not ?}

NASL is not a powerful scripting language. Its purpose is to make scripts that 
are security tests. So, do not expect to write a third generation web server
in this language, nor a file conversion utility. 
Use perl, python or whatever scripting language to do this  - they are 100 times faster\\

NASL was designed rather quickly, so you may spot some inconstencies in its
syntax.
Please, let me know if you find some.



\subsection{Why not using Perl/Python/tcl/\textit{whatever you like} for Nessus ?}


I know that there is a lot of very good scripting languages around
here, and that NASL is really weak compared to them. But none of
these languages is secure, in the sense that you can easily write
a test that will be a trojan and will indeed open a connection to
a third party host - letting it know that you are a Nessus user, 
and even eventually send the name of your targets to this evil
third party host. Or worse, it could send your passwd file, or
whatever.\\

Another problem with many of these scripting language : a lot of
them are memory hungry. It can also be an headache if you want to
configure them for Nessus. Just think about Perl. Perl is good.
Perl is beautiful (according to some). But how much time will you
have to spend to install all the modules that may be necessary for
writing efficient Nessus tests ? \verb+Net::RawIP+ is only one of them.\\

NASL, on the other hand, does not take a huge amount of memory. This
way, you can launch 20 threads of nessusd at the same time, without
the need of having 256Mb of RAM. NASL is also self-sufficient. That
is, you will not have to install a dozen of packages for each new
security test. 

\subsection{Why should you write your tests in NASL ?}

You may already wonder whether it is worth or not to learn yet 
another scripting language to write your tests, rather than
coding them in C or Perl, or whatever. What you must know
is that :
\begin{itemize}
\item NASL is optimized for Nessus. Writing a Nessus test in this
language is fast
\item NASL has a lot of things in common with C, so you should not
be afraid of it
\item NASL produces secure and easily sharable security tests
\item NASL produces portable and easily modifiable security tests. When
the Windows NT version of Nessus is released, you will use the same
functions to do the same things (such as sending raw IP packets)
\end{itemize}



\subsection{What this guide will teach you}

This guide teaches you how to write your own Nessus tests in NASL.
This is my first attempt to write a comprehensive document, so
I may have written complicated things. 

\subsection{NASL limitations : what to not expect}

As I stated before, NASL is not a powerful language. The biggest limitations as
of now are :
\begin{itemize}

\item \textit{Structures}. Structures are not supported. They may be in a
not-so-far-away future, but today they are not

\item \textit{A correct debugger}. NASL has no correct debugger. However, there is a standalone interpretor 'nasl'


\end{itemize}



\subsection{History of the NASL interpretor}

The first NASL interpretor was a modification of a personal
project called \verb+pkt_forge+, written by Renaud Deraison in 1998, which
was an interactive shell to manipulate packets. The parser was written
quickly and it was ugly, memory management was awful, and the execution
of the scripts was slow.\\
In 2002, Michel Arboi re-wrote most of the NASL engine, and the project
was dubbed 'NASL2'. Michel used bison to handle most of the grammar, and
the new version is way faster, while leaving room for even more improvement
in the future.

\subsection{Thanks}

I would like to thank the following persons for their advices regarding the design
of NASL.
Without them, NASL would be more akward than it is already :
\begin{itemize}
\item Denis \textsc{Ducamp} ([e-mail])
\item \textsc{Fyodor} ([e-mail])
\item Noam \textsc{Rathaus} ([e-mail])
\item Michel \textsc{Arboi} ([e-mail])
\end{itemize}

I always appreciate suggestions and complaints about the language. Do not
hesitate to share your opinion (be it good or bad) with me.

\newpage
\section{The basics : NASL syntax}


NASL syntax is very similar to C, except that a lot of boring stuff has
been removed. You do not have to care about the type of your objects,
nor do you have to allow memory for them or free it. You do not need to
declare your variables before you use them. You just have to focus on
the security test you want to perform.\\

If you do not know C, then you will have a hard time reading this manual
has it is currently intended for C programmers. Just complain and this guide
will be made more readable in the future.


\subsection{Comments}

  The comment char is '\verb+#+'. It only comments out the current line.\\

\noindent Examples : 
 
Valid comments are :
\begin{verbatim}    
    
 	a = 1;  # let a = 1 
	
	# Set b to 2 :
	b = 2;
\end{verbatim}	
	
	
Invalid comments would be :
\begin{verbatim}   
   	#
	  Set a to 1 :
	  		#
			
	 a = 1;
	
	 a = # set a to 1 # 1;
	 
	  		
\end{verbatim}

\subsection{Variables, variables types, memory allocation, includes}

  You do not need to declare variables before you use them, but you
  may want to explicitely mark them as 'local' in a function, to avoid
  modifying extern variables (see the relevant section about that).
 
 
You do not have to care about the variable types. The
NASL interpretor will yell at you if you try to do bogus
things, such as adding an IP packet to a number.
And you do not have to care about memory allocation nor
do you have to care about the includes. There is no
include. Memory is allocated when needed.

\subsection{Numbers and strings}

Numbers can be entered in three bases : decimal, hexadecimal, or binary.

All these lines are correct :
\begin{verbatim}

 a = 1204;
 b = 0x0A;
 c = 0b001010110110;
 d = 123 + 0xFF;
 
\end{verbatim}

The strings must be quoted. Note that, unlike C, the characters are not interpolated
unless you explicitly ask to interpolate them using the \verb+string()+ function.

\begin{verbatim}

 a = "Hello\nI'm Renaud";           # a equals to "Hello\nI'm Renaud"
 b =  string("Hello\nI'm Renaud");  # b equals to "Hello
                                    #              I'm renaud"  	

 c = string(a);                     # c equals to b

\end{verbatim}

The \verb+string()+ function will be dealt with in the ``String Manipulation'' section.

\subsection{Anonymous / Non Anonymous arguments}


\subsubsection{Non Anonymous functions}

One thing which is different with C is the way NASL handles the 
arguments of a function. In C, you must know by heart which argument
must be at which place. And this quickly becomes an headache 
when a function you call has more than 10 arguments.
For instance, imagine a C function which will forge an IP packet for
you. This function requires a dozen of arguments. If you want to use
it, then you will have to remember their exact order or read the
the documentation of this function. This is a waste of time, and
this is what NASL attempts to avoid.\\

So, when the order of the arguments of a function is important,
and when the different arguments of the function have different
types, then the function is a non anonymous function. That is,
you have to give the name of the elements. If you forget
some elements, then you will be prompted for them at 
runtime.

\begin{itemize}


\item Example :

The function \verb+forge_ip_packet()+ has a lot of elements. These
two calls are valid and perform the exact same thing :
\begin{verbatim}
	forge_ip_packet(ip_hl : 5, ip_v : 4, 
			ip_p : IPPROTO_TCP);
			
	forge_ip_packet(ip_p : IPPROTO_TCP,
			ip_v : 4, ip_hl : 5);
\end{verbatim}
			
The user will be prompted at runtime for the missing
arguments (\verb+ip_len+, and so on...). Of course, a 
security test must not directly interact with the user, but
this is handy for debugging and quick coding.
\end{itemize}

\subsubsection{Anonymous functions}

 The anonymous functions are functions that take only one argument,
or arguments of the same type.

Examples :
\begin{verbatim}
	send_packet(my_packet);
	send_packet(packet1, packet2, packet3);
\end{verbatim}	
These functions may have options. For instance, the \verb+send_packet()+
function waits for an answer. If you feel there is no need to
read the host's answer, then you can deactivate the pcap, and
speed up the test :
\begin{verbatim}
	send_packet(packet, use_pcap:FALSE);
\end{verbatim}	
	


\subsection{For and while}
	
The for and while work like in C :


For :
\begin{verbatim}
	for(instruction_start;condition;end_loop_instruction)
	{
	 #
	 # Some instructions here 
	 #
	}
\end{verbatim}	
or 
\begin{verbatim}
	for(instruction_start;condition;end_loop_instruction)function();
\end{verbatim}	
	

While :
\begin{verbatim}
	while(condition)
	{
	 #
	 # Some instructions here
	 #	
	}
\end{verbatim}	
or
\begin{verbatim}	
	while(condition)function();
\end{verbatim}	
	
\noindent Examples :

\begin{verbatim}
	# Count from 1 to 10
	for(i=1;i<=10;i=i+1)display("i : ", i, "\n");
	

	# Count from 1 to 9, and say the type
	# of each number (even or odd)
	for(j=1;j<10;j=j+1){
		if(j & 1)display(j, " is odd\n");
		else display(j, " is even\n");		
		}


	# Do something completely useless :
	
	i = 0;
	while(i < 10)
	{
	 i = i+1;
	}

\end{verbatim}


\subsection{User-defined functions}

NASL now supports user-defined functions. A user-defined function is defined
like this :

\begin{verbatim}

function my_function(argument1, argument2, ....)
{
 #
 # Body of the function
 #
 return(some_value); # this is optional
}

\end{verbatim}

User-defined functions \textbf{must} use non-anonymous arguments. Recursion is handled.


Example :
\begin{verbatim}
function fact(n)
{
  if((n == 0)||(n == 1))
    return(n);
  else
    return(n*fact(n:n-1));
}

display("5! is ", fact(n:5), "\n");

\end{verbatim}


User-defined function may \textbf{not} contain other user-defined functions (actually, they can but the NASL interpretor will yell at you if you call the function that defines its subfunction more than once)

  Note that if you want your function to return a value (that's the purpose of a function after all), then you have to use the function \verb+return()+. Since \verb+return()+ is a function, you \textbf{must} use parenthesis, that is, the following is incorrect :
  \begin{verbatim}

function func()
{
   return 1; # parenthesis are missing here !
}
  
\end{verbatim}
      

\subsection{Operators}

The standard C operators work in NASL. That is, \verb;+;,\verb+-+,
\verb+*+, \verb+/+ and \verb+%+ work. At this time, the operators priority
is not taken in account, but this will change. In addition to this
operators, the binary operators \verb+|+ and \verb+&+ are implemented.

In addition to this, there are two operators that do not exist in C :

\subsubsection{The 'x' operator}
	
for and while are great and handy. But because the condition
has to be evaluated at each iteration, then there is a loss
of performance, which can be of some trouble if you want
to send a SYN storm or whatever. The '\verb+x+' operator
will repeat the same function N times, and will go
really fast (at native C speed actually).

\noindent Example :
\begin{verbatim}
	send_packet(udp) x 10;
\end{verbatim}	

Will send the same udp packet ten times.	 


\subsubsection{The '$><$' operator}

The \verb+><+ operator is a boolean operator which returns
true if a string of chars A is contained in a string B.

\noindent Example :