Oh wait, nevermind :-)

Put that aside, prejudice is bad when it comes to commercial adoption. Even if you’re good and you want to use it, there are cases when you don’t want it simply because you can’t sell it. Take financial market as example: if you can’t integrate it with Excel, you probably won’t sell it. Stupid as it looks, but that’s the way it works (things get a little easier when you talk about algotrading). Now, the point on this colocation: there’s an obvious concern about network security – example taken – in the financial market, but everyone uses Nessus results as benchmarks and “oh, we’re safe now”. I’ve seen security firms selling their we-check-your-network-and-make-it-safe services using “we run our software on Windows” as a kind of faster-results assurance, and what they do is topology check + nessus run + report – 8 weeks guaranteed results, US$25k.

Now, this is what I see happening to most of programmers – not the ideal, not honorable, but real life, so keep that in mind: average citizen, average world. Say you’re a great programmer, and you want to be a employee in one of these firms – you tell then about Ruby, they reply “ru-what?”, puf, bye-bye job. But you tell then you have great experience using Nessus, oh, you’re a great security professional, yes you are.

It’s as chocking as it looks, but we live a non-US reality here (Latin America). I used the financial market as an example because that’s where I am right now, and I see that most of the people in charge of IT (specially IT security) only “heard about it” – and it sells only if they heard about it. This scenery is changing, yes, but in the meantime you’ll still have lots of people away from great projects just because they can’t use it in real life. It’s really great doing things by the pleasure of doing it, but sometimes you have someone else to take care of, and money *is* motivation. Not so noble, but – again – it’s real life.

The reason NASL is inferior to other languages such as Perl, Python, Ruby, etc, is because NASL does not have a good community behind it and as such code has to be reinvented all the time. This doesn’t mean that you cannot keep the core tests (the ones that come by default with the framework) dependency free. Perhaps they can be built upon your own libraries which you are sure that are safe.

I have no right to point fingers to any of this projects but I am only giving advice based on my experience. I believe that if someone writes a framework based on JavaScript, Java then the community will pick it up very quickly because everybody understands these two languages very very well. Well, Metasploit is the winning framework here because it is based on Ruby and there are a lot of Ruby fans. NASL is not hard to learn but it puts off a lot of people before they even start.

I am deeply impressed my the Metasploit guys and what they have done. The tool is fantastic. The framework is extremely stable and extensible. But Metasploit is not Nessus and Nessus is not Metasploit. Nessus has a good reporting framework with tones of tests. Metasploit has a good penetration testing toolkit, but no good report framework. I haven’t dig deep enough into Metasploit, so if I am wrong, don’t eat me. Nmap is also coming along with their NSE scripting language which is based on Lua. I like the idea!

All of these projects started for very different purposes and all of them are heading the same way – universalism. All of them are now developed to become the one and only framework you need for security but I hardly doubt that this will ever happen. Only time will tell. I often say that we’ve got already a universal framework. It is called OS. I believe that all of these tools should try to do more of what they already do and not what someone have already done.

hawaii67, don’t wait until you are ready. Give them the code and I am sure that they will find a way to integrate it.

I think it is just a matter of time till metasploit will have a vulnerability scanner included. I’m writing my own vuln scanner in ruby at the moment – standalone by now but since it’s written in ruby it should be easy to integrate it in metasploit.

The whole topic of what language plugins should be written in has come up more times than I care to remember and it essentially boils down to. The moment you discount NASL, you have fans of every major language out there (and that includes me – Perl ;)) pushing their pet language. Over time we’ve learnt to accept the limitations of the language and focus on the code. As a counter point, because OpenVAS is Free Software, we’re not limited to what 3rd party tools we can call out to which means we can use the best tool for the job.

Yes, we *know* the project is raw, and yes we’d love to have more resources behind it (although did you know development is now split across 3 continents and includes half a dozen different commercial outfits) but honestly, the biggest hindrance has been a problem of tainted code licenses, something we’ve finally got to grips with I believe.

With respect to stability, if you’d care to file examples, I’m sure the team would be happy to resolve any particular issues you could report, certainly the code base has been cleaned up significantly since we started work on it.

With the greatest respect to you, whilst some tests can be replaced with “regular expressions” (and I’ll think you’ll find such tests already are), there are many that can not. I’m sure simple “version disclosure vulnerabilities” can be checked this way, but not all bugs are so shallow.

Come and talk to us on IRC some time. You might still disagree with us, but hopefully, you’ll at least get a better feel for the direction the project is taking.

Today:
I believe things have changed, and I agree that OpenVAS can decide to ‘fork’ from the NASL to something else, the problem though in similar fashion to what Metasploit has, the dangers of sharing and running someone else’s ‘code’ can be problematic.

Metasploit has a smaller scale problem as there aren’t hundreds of exploits written for it every month, OpenVAS on the other hand, will eventually reach that point.

Some 2 cents.

Nmap has a great scanning engine, and with the the lua interpreter and nmap libraries it makes a devent development environment for general discovery scripts. It has replaced Nessus for me in my development.

W3af is growing into a decent web testing tool, though it definitely has its own problems and quirks and consumes too much memory. It’s written in python, and can be easily extended. Paros is more stable, uses less memory and works better for many tasks at the moment, but the architecture is an evolutionary dead end.

Metasploit is written in ruby and has the best general network packet manipulation libraries I’ve ever worked with, and is great for all manner of packet creation and discovery tasks.

Given the new BSD license, when I build any new security tools I will strongly consider either writing them for metasploit, or borrowing some of their libraries. They have done an excellent job of taking the best in class ruby libraries and extending them to be even more useful.