[Feature-Request] Ability to choose root path for ax installation

[RogueSMG]

Hey there,

Since using axiom, though not directly related to ax itself, there's one issue I consistently ended up facing - My storage getting ramped up way too quickly!

There have been multiple instances where I lost my Controller VPS because I ran out of space mid Scans 🤡
Surely enough the main reason being me not able to realize both:

• the speed at which the distributed scans might run
• as well as the extent to which the data might be fetched/generated

I use Ax on a DigitalOcean VPS. With DO droplets, you get pretty limited storage even if you go with a costlier Droplet. I think it's the same for other providers but I'm not sure about that.

Comparatively, attaching a mounted Volume is significantly cheaper.

Hence, using mounted storage as the ax installation makes much more sense:

• More Storage, Cheaper
• Better FailSafe - Even if something fails/crashes or the storage gets filled up unexpectedly, the Droplet stays unaffected

So if I didn't miss it somehow, we don't have any option to choose an installation location for axiom as of now. I have installed it on my mounted storage but had to make changes to quite a lot of files and it's a bit of a hassle.

I think an option to choose the Installation Location by default would make ax much more reliable 😄

Kind Regards

[0xtavian]

Hey @RogueSMG!

Great question. Yes, heavy use of ax scan can require a lot of disk space for the controller (specifically logs files of previous scans).

While there isn’t an option to specify a custom installation directory for axiom directly, you do have a few options.

Option one: using one of the following ax scan flags to reduce the amount of logs ultimately saved (to the controller and the instances) at the end of the scan.

--rm-logs   delete remote and local logs after scan completes, except for the unmered output files in ~/.axiom/logs/$module+$timestamp/output
 
--no-logs   do not store any logs at all, do not tail terminal output. Delete all logs even the unmerged output files in ~/.axiom/logs/$module+$timestamp/output

Option two: create a new disk like you did using the cloud console and attach it to your controller and mount the disk to $HOME/.axiom.

If you don’t want to set up axiom from scratch after mounting the new disk, you probably need to copy your existing $HOME/.axiom to another directory, mount the additional disk to $HOME/.axiom and copy the contents back.

Everything should work fine after that! Let me know if you run into any issues!

Edit: will also add this guidance to our FAQ over the weekend! https://ax.attacksurge.com/overview/installation-guide#faq

[RogueSMG]

Hey @0xtavian

Ah, I missed --no-logs. Also mounting directly to $HOME/.axiom makes sense.

I think that should solve the problem, Thank You!

Kind Regards

[devdev-automation]

As an alternative to this, an option to specify the output directory of log files or an "archive" option to compress log files after parsing would be a pretty simple solution.

Could possibly even get really fancy by creating post scan modules that could be used to further modify/analyze scan results. That would be super useful doing some post processing of results and using logstash to push them off to an Elastic Stack.

[0xtavian]

Hey @devdev-automation! are you thinking something like --log-dir $local-path?

That could redirect both the working directory ($HOME/.axiom/tmp/$scan-uid) and final logs ($HOME/.axiom/logs/$scan-uid) to a user-defined path. I like that idea and can definitely add it!

We previously zipped results automatically after scans, but it became inconvenient constantly unzipping them. Making that an optional flag again could make sense.

Regarding post-scan modules, I agree that post-processing is powerful. The challenge is that Ax supports arbitrary tools with wildly different output formats. Because users control which tools they run and how those tools output data, they’re actually in a better position than Ax to normalize or transform results for their own workflows.

That’s why we generally recommend simple bash wrappers or post-processing scripts. Since users define their scan stack, they can implement whatever bespoke normalization, enrichment, or Logstash/Elastic ingestion logic makes sense for their environment.

[devdev-automation]

are you thinking something like --log-dir $local-path

Yea, I think that would be perfect. Might be worth creating two options in case users only care about the final log location and not the tmp dir.

--log-dir /mnt/share/ax-output
--tmp-dir /tmp/ax-temp

That’s why we generally recommend simple bash wrappers or post-processing scripts

Any chance you have some example scripts that you could point to for post processing? I'd be curious to see what others have done.