Config file

[bee-san]

Something that adapts to the user's host is an awesome idea! :)

It can also learn or allow a config file for default commands in the future, things like:

• Amount of parallel nmap processes (assuming we go through this route)
• Only TCP or UDP
• Saving these scans to a default location and so on.

Originally posted by @bernardoamc in #69 (comment)

[bee-san]

Specifically what I am looking for is something like this:

{ 192.168.0.1: [21, 22, 80, 443], 192.168.0.2: [8080, 9162]}

So a listing of IP addresses and their ports. We can use adaptive learning to insert previously found open ports too.

This way, over time, the organisation doesn't have to manually write their own open ports -- Rustscan will find them for them.

[bernardoamc]

I like this format a lot and this issue raised a few questions in my head.

1. What's the goal for aggregating this information?
2. Are we planning to use this file as input for RustScan? How so?

Maybe we are conflating two different things here. The first being a config file with things like scan preferences and another one being a log or recon file which gets updated after each recon is executed.

[inainazumakun]

I think the original idea for this was to create preset scans for commonly used flags and ranges, and possibly lists of scripts to execute as well.

The usage would probably be something similar to rustscan 10.5.12.156 --config vulnscan.config, and would be possibly a json containing flags for configuring the threads allocated, scripts used, and ports scanned. Or also be able to scan a set amount of IP ranges as possibly for a scheduled maintenance/check for a network

[bernardoamc]

We can agree on a minimum viable configuration file to get this idea out of the paper.

I would be happy starting with:

1. Ports to be scanned
2. Threads to be allocated
3. Flags to be passed to nmap
4. If the user specifies a field through the command line AND through the config file like number of threads, then the command line would have precedence.

What do you think?

[bee-san]

Sure! One thing to note is that if we place the config file in APPDIRS, and the argument for it -c for config does not have an argument, we can search APPDIRS for the config file. That way, the user doesn't have to specify a full path for it each time.

We could also create another flag -a for "appdirs" which lists the location where RustScan is expecting the config file to be :)

[bee-san]

#85 Is an issue which relates to this issue.

[idangur]

I think that adding the option to add to output/pipe results to a default file and specify the file format.

Something like:

output:
	file: /path/to/file.extension (json/xml/txt)
	type: append / write

so you can monitor the file for logs and send them to splunk/elk would be really nice to have as a qos feature

[inainazumakun]

(copied from #90 (comment))
Additionally, it would be a pretty cool/useful idea to make a .last_scan that converts the last performed scan into a RustScan .config that you can export into a new .config or repeat the last performed scan with.

[bee-san]

The way we do this in Ciphey is to load the config file (default config) as a dictionary (or hashmap, as we're in Rust) and then to load the user arguments as another dictionary (StructOpts already does this).

Then simply config.update(opts) which places priority on the command arguments while maintaining clean code.

[andy5995]

Ah, if you're looking to implement a config file, I just wrote a very small, simple library that will do that. Though the format of the config file it can parse is different than what you're planning. But perhaps that could be easily changed.

https://lib.rs/crates/configster

But I see from #136 that it's probably not necessary at this point. Good luck!

[bernardoamc]

Closing this one now that we have a config file. We can open following up issues with feature request or good first issue. :)