search

pry0cc / axiom

The dynamic infrastructure framework for everybody! Distribute the workload of many different scanning tools with ease, including nmap, ffuf, masscan, nuclei, meg and many more!
MIT License
4k stars 622 forks source link

[feature] handling case when input items are fewer than number of instances #448

Closed pdelteil closed 2 years ago

pdelteil commented 3 years ago

There's a border case when the amount of items in the input file are lower than the number of instances in a given fleet.

For example, we want to run a scan using all nuclei templates on 20 urls having a fleet with 40 machines. This situation will output the following error cat: input: No such file or directory because 20 instances are receiving empty input files.

Desired behavior

Warning about the number of item on the input file being lower than the amount of instances on a fleet. It would be useful for the user to know that (in this case) 20 instances are still available due to the small input.

easyrider commented 2 years ago

@0xtavian, what do you think about adjusting number of instances to input? I mean introducing needed_instances so the scan still works though not using fleet full capacity - works for me. I'm using this solution and will create a PR if this is a desired functionality.

0xtavian commented 2 years ago

Hey @easyrider, yea that’s not a bad idea. The way I originally thought I’d fix this issue is by creating a preflight check, which could be disabled by running —no-preflight or something. The idea was to ssh into each instance and use interlace to echo the hostname into a random path on the remote instance and then download the hostname from all instances and use that as selected.conf. This idea would auto fix itself if you had some down instances or instances not responding etc. basically try to dynamically create a new selected.conf prior to the scan to ensure every instance is live. Somewhere during the preflight check I had planned to reduce total number of instances if it was greater than the total number of targets. Either way, your fix would provide a little more granular control over the size of the fleet. Go ahead and push a PR and we’ll see if we need to make some tweaks. Thanks!

0xtavian commented 2 years ago

maybe we can name the option —instances or —fleet-size or something.

easyrider commented 2 years ago

@0xtavian, looks like my fix is much simpler and just fixes error when fleet is bigger than inputs - I hope the code is self explanatory.

Most naïve was to choose instances from the top to run jobs - I though about choosing random instances from the selected.conf list but this was it's easier to reason about what's being used at the moment.

My other 2 other biggest concerns about Axiom on Azure are:

  1. interlace - a memory hog on Azure when instances > 5 (freezes my VM)
  2. selected.conf being not updated properly - showing deleted instances, adding my master VM beside just worker instances
0xtavian commented 2 years ago

@easyrider just to circle back to this:

  1. What are the specs on the vm? Try for at 2 vcpu / 2-4 gb ram for a cloud based controller.
  2. selected.conf is updated via axiom-select. You should be able to exclude any instance you wish. It doesn’t automatically update when you delete instances. Ping us on discord to troubleshoot further https://github.com/pry0cc/axiom/wiki

thanks for the PR!

easyrider commented 2 years ago

@0xtavian, no, problem - thanks for the great tool!

  1. My spec is pretty poor: 1 vcpu, 1 GiB memory - I was thinking about optimizing it though as it is mostly CLI requests, I suppose interlace is the culprit here, have you considered other tools?
  2. Yea, that's what I've observed - wouldn't that be helpful it those are removed automatically? I think it's pretty simple to do - not a big problem though
0xtavian commented 2 years ago

@easyrider

  1. The machine you install axiom on, which we call the axiom controller, should have at least 2vcpu and 2gb ram. Anything less and you’ll experience issues like you described. For larger fleets you should consider an even stronger controller. Also, you can prevent axiom from re-generating the sshconfig (which is what the cli calls are for) by using the —cache option. This works for the core scripts scp,exec,scan etc.

Interlace is pretty awesome, as well as heavily relied upon in our code. I don’t think we’ll be considering alternatives anytime soon (although I’m a fan of GNU parallel and Rush).

  1. I think I want to avoid auto-updating selected.conf whenever possible. Doing it manually is also good opportunity to show users how axiom-select works imo. IIRC we are only auto-updating selected.conf for init and fleet. I’ll continue think about it more. Thanks. :)