Go to Top

Performance gains with fingerprinting and multi-Instance scans

Hey folks,

I have some really impressive benchmarks to present, showing the performance difference between what was possible with v0.4.2 and what’s going to be possible with v0.4.3.

For the shown benchmarks, only audit modules were loaded to make the affect of the described changes clearer — since fingerprinting only affects audit modules. Also, all scans were performed against the same server.

Platform fingerprinting

The experimental branch just received a new merge to include the new platform fingerprinting functionality.

Platform fingerprinting allows Arachni to know what technologies are used on the server-side and then use that knowledge to provide a more efficient and tailor-made scan. Put simply, if the remote host is identified as Unix the OS command injection module will only send Unix payloads — same deal with programming languages, etc.

This only affects a handful of audit modules but it’s enough to make a non-negligible difference in the amount of HTTP requests and the overall scan time. All this goodness happens automatically (and is enabled by default) but should you (as a user) need more control or just want to disable this new feature you can of course do just that.

One of the more interesting options is specifying extra platforms and this can greatly assist with modules and payloads that deal with SQL injection vulnerabilities. There’s no way to know the DB platform used by a site (not until it’s not too late anyway) so if you want a very optimized scan you’ll have to provide that information yourself.

Alternatively, you can disable fingerprinting altogether and manually specify the platforms used by the website in case you have configured your webserver to impersonate a different system.

Here are some numbers:

HTTP requests Runtime
Without fingerprinting 353.567 00:14:03
With fingerprinting 254.567 00:11:31
— and user specified DB 180.567 00:08:38

Now, that’s a significant difference.

Multi-Instance scans

Up to now, operations utilizing more than one Instance to perform a single, high-performance scan were an experimental feature. Now, they have become stable enough (I’m sure there must be a bug somewhere but they’ve been looking stable for a while now) to be used in production environments and bring with them a significant performance boost.

I’ve been raving about this feature for some time now so I’ll skip the talking and give you the latest numbers, 4 Instances were used for the scans:

HTTP requests Runtime
Without fingerprinting 362.443 00:05:4
With fingerprinting 258.382 00:04:11
— and user specified DB 187.666 00:03:02

The difference

To drive this baby home, let me just present the old and new best-case performance scenarios:

HTTP requests Runtime
v0.4.2 (Single instance, no fingerprinting) 353.567 00:14:03
4 Instances, fingerprinting and user specified DB platform 187.666 00:03:02

That’s some cool stuff, am I right (or am I right)?

, , , ,

About Tasos Laskos

CEO of Sarosys LLC, founder and lead developer of Arachni.

One Response to "Performance gains with fingerprinting and multi-Instance scans"

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.