Spam detection software, running on the system "paris.fr.nth-dimension.org.uk",
has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
[email protected] for details.
Content preview: On Monday 19 July 2010 02:52:00 Christian Kuersteiner wrote:
> It has to be in a quite minimal setup that we can somehow limit the >
possible
effects as you described. As with almost all scans in a > automated tool
I think it can just provide some hints and starters for > further testing
which should be done manually and more controllable. [...]
Content analysis details: (5.8 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.8 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[212.183.132.78 listed in dnsbl.sorbs.net]
0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
[212.183.132.78 listed in zen.spamhaus.org]
1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT
[212.183.132.78 listed in bb.barracudacentral.org]
2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL
[212.183.132.78 listed in psbl.surriel.com]
-0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5%
[score: 0.0258]
1.0 RDNS_DYNAMIC Delivered to internal network by host with
dynamic-looking rDNS
The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam. If you wish to view
it, it may be safer to save it to a file and open it with an editor.
--- Begin Message ---
On Monday 19 July 2010 02:52:00 Christian Kuersteiner wrote:
> It has to be in a quite minimal setup that we can somehow limit the
> possible effects as you described. As with almost all scans in a
> automated tool I think it can just provide some hints and starters for
> further testing which should be done manually and more controllable.
This is always true, OpenVAS and such tools are very much the start of my
testing process rather than the end, but then I'm a penetration tester and not
a vulnerability analyst. Having said that, for the latter case, any tools we
integrate into OpenVAS need to be configured to a sane default, because the
operators may not have the skills / experience to do so themselves.
> The problem I face right now is mainly how I should invoke a java
> program (or better: where should I put the jar file so I can find and
> launch it within NASL).
I have a Debian package for Dirbuster that installs the jar as
/usr/share/dirbuster-0.9.10/DirBuster.jar. However, that is by no means
universal (one of the the problems with Java apps unfortunately).
> An other possibility would be to use another tool (and circumvent the
> whole java problem). One tool which I used quite a bit before is dirb
> (dirb.sourceforge.net). Although I think the functionality is not as
> good as in DirBuster and not as fast it might be quite okay for our
> needs. Do you guys have some other tools you use for brute forcing web
> directories which might serve well in an OpenVAS environment?
Dirb would be a great choice IMO, it has some fastastic lists /and/ it is
designed for command line scanning. I was going to suggest it, but I didn't
want to out you off if you were still keen to do a Dirbuster NASL.
Tim
--
Tim Brown
<mailto:[email protected]>
<http://www.openvas.org/>
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
_______________________________________________
Openvas-plugins mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins