Mailing List Archive

Restore Sessions vs. Manage Reports on Server
Hi,

I am currently refactoring the "Restore/Delete Session" feature.

My idea was that actually this will be a "Manage Reports on Server"
feature where you have the options to import one to your local client
software or to delete one on the server side.

In the code I see that there is a lot handling of options and plugin
configuration just for restoring a session.
Shouldn't it be as simple as just retrieving the attack results
alone?
My preference would be to just load the results an not have even
the monitoring dialog running.

Would it be correct to follow this idea of just getting the result
data?

Best

Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/
Re: Restore Sessions vs. Manage Reports on Server [ In reply to ]
On Mon, Nov 01, 2004 at 04:13:57PM +0100, Jan-Oliver Wagner wrote:
> I am currently refactoring the "Restore/Delete Session" feature.
>
> My idea was that actually this will be a "Manage Reports on Server"
> feature where you have the options to import one to your local client
> software or to delete one on the server side.
>
> In the code I see that there is a lot handling of options and plugin
> configuration just for restoring a session.
> Shouldn't it be as simple as just retrieving the attack results
> alone?
> My preference would be to just load the results an not have even
> the monitoring dialog running.
>
> Would it be correct to follow this idea of just getting the result
> data?

my first approach to this would be ignore nessus/attack.c:
restore_attack() and instead call comm_restore_session()
directly from nessus/monitor_dialog.c:monitor_dialog_setup().
Coarse test show that this seems to work.

However, the questions remains: what was the stuff in restore_attack()
good for?

Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/
Re: Restore Sessions vs. Manage Reports on Server [ In reply to ]
On Mon, Nov 01, 2004 at 04:41:12PM +0100, Jan-Oliver Wagner wrote:
> On Mon, Nov 01, 2004 at 04:13:57PM +0100, Jan-Oliver Wagner wrote:
> > I am currently refactoring the "Restore/Delete Session" feature.
> >
> > My idea was that actually this will be a "Manage Reports on Server"
> > feature where you have the options to import one to your local client
> > software or to delete one on the server side.
> >
> > In the code I see that there is a lot handling of options and plugin
> > configuration just for restoring a session.
> > Shouldn't it be as simple as just retrieving the attack results
> > alone?
> > My preference would be to just load the results an not have even
> > the monitoring dialog running.
> >
> > Would it be correct to follow this idea of just getting the result
> > data?
>
> my first approach to this would be ignore nessus/attack.c:
> restore_attack() and instead call comm_restore_session()
> directly from nessus/monitor_dialog.c:monitor_dialog_setup().
> Coarse test show that this seems to work.
>
> However, the questions remains: what was the stuff in restore_attack()
> good for?

I further tried to understand the current concept of saving sessions.

The Nessus book says that it is in principle a feature to pick up
a scan that was interrrupted due to a (server) crash and continue where
it was stopped.

But as far as I read the code of the client, all the current paramters
are send to the server for this "restoring".
Unfortunately there is no guarantee that these are the same parameters
used to initially start the scan.
So, I get the feeling that the design of this feature is somehow broken.

I really need some discussion about this feature to improve the client!

Best

Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/
Re: Restore Sessions vs. Manage Reports on Server [ In reply to ]
On Thu, Nov 04, 2004 at 10:07:48AM +0100, Jan-Oliver Wagner wrote:
> But as far as I read the code of the client, all the current paramters
> are send to the server for this "restoring".
> Unfortunately there is no guarantee that these are the same parameters
> used to initially start the scan.
> So, I get the feeling that the design of this feature is somehow broken.
>
> I really need some discussion about this feature to improve the client!

Session saving was some kind of attempt to protect the user against a
connection loss and to change parameters "on the fly". Ie: you start to
scan 10.0.0.0/16, and after 50mn of scanning you realize that things
would be faster if you had not enabled three port scanners but one.
Instead of stopping the scan, disabling two port scanners, and
restarting from scratch, you can restore the session with the new
parameters.

So in that regard, the design is not really broken, but it does not
prevent you from shooting yourself in the foot.


That being said, I'm considering getting rid of session saving
altogether. Not many people use them, it's an under-tested feature,
session restoration is quite slow, and I'd like to simplify the source
code of nessusd as much as possible.

So I'd advise you to leave that part alone for the moment. At worse,
I'll re-implement it "correctly" in the future, but at this time it
just gets in the way.



-- Renaud
Re: Restore Sessions vs. Manage Reports on Server [ In reply to ]
On Thu, Nov 04, 2004 at 03:38:40PM +0100, Renaud Deraison wrote:
> That being said, I'm considering getting rid of session saving
> altogether. Not many people use them, it's an under-tested feature,
> session restoration is quite slow, and I'd like to simplify the source
> code of nessusd as much as possible.
>
> So I'd advise you to leave that part alone for the moment. At worse,
> I'll re-implement it "correctly" in the future, but at this time it
> just gets in the way.

OK, so I could make it just a "Manage Reports on Server" feature in the GTK
GUI. That means

1. to have a special dialog to do this management
(2 actions: Import or Delete a Report).
This is essentially the corresponding list widget and buttons of the
current target page.
2. Move the configure option "store session on server" of the target
page to the page "general" as "store reports on server".
3. The option "store empty session" of the target page could be disable
for the GUI as it makes no real sense in this context.

This proposal is actually another view on the session-saving feature for
the user. This view is a more narrow one than what the session-saving
is actually able to do and it basically says: you can store your reports
on the server and retrieve them from different clients.

Eventually, once you decided how to proceed with the session saving
feature it is possible to change the view again and reactivate some
GUI code.

Is this a reasonable approach?
(quick response would be appreciated, we are trying to have Nessus
GTK Client feature-complete by the end of this week).

All the best

Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/
Re: Restore Sessions vs. Manage Reports on Server [ In reply to ]
Hi,

in a discussion with Renaud it turned out that these features
of session saving should be removed from the GTK client for now.
So I did and removed some of the code (still archived in CVS).
However, I did not remove all unneeded code because I fear
to break the KB feature.

Best

Jan

On Fri, Nov 12, 2004 at 11:49:00AM +0100, Jan-Oliver Wagner wrote:
> On Thu, Nov 04, 2004 at 03:38:40PM +0100, Renaud Deraison wrote:
> > That being said, I'm considering getting rid of session saving
> > altogether. Not many people use them, it's an under-tested feature,
> > session restoration is quite slow, and I'd like to simplify the source
> > code of nessusd as much as possible.
> >
> > So I'd advise you to leave that part alone for the moment. At worse,
> > I'll re-implement it "correctly" in the future, but at this time it
> > just gets in the way.
>
> OK, so I could make it just a "Manage Reports on Server" feature in the GTK
> GUI. That means
>
> 1. to have a special dialog to do this management
> (2 actions: Import or Delete a Report).
> This is essentially the corresponding list widget and buttons of the
> current target page.
> 2. Move the configure option "store session on server" of the target
> page to the page "general" as "store reports on server".
> 3. The option "store empty session" of the target page could be disable
> for the GUI as it makes no real sense in this context.
>
> This proposal is actually another view on the session-saving feature for
> the user. This view is a more narrow one than what the session-saving
> is actually able to do and it basically says: you can store your reports
> on the server and retrieve them from different clients.
>
> Eventually, once you decided how to proceed with the session saving
> feature it is possible to change the view again and reactivate some
> GUI code.
>
> Is this a reasonable approach?
> (quick response would be appreciated, we are trying to have Nessus
> GTK Client feature-complete by the end of this week).

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/