-
Notifications
You must be signed in to change notification settings - Fork 758
RPC server
Dispatchers are remote agents which provide you with scanner Instances, those Instances are the entities that actually perform the scans.
Setting up Dispatchers across multiple machines allows you to spread out the workload of many scans across multiple nodes.
Starting a Dispatcher can be as simple as running: arachni_rpcd
This will bind on localhost:7331
by default.
In order to connect the Dispatchers into a grid you'll need to:
- Specify an IP address or hostname on which the Dispatcher will be accessible by the rest of the Grid nodes (i.e. other Dispatchers).
- Specify a neighbouring Dispatcher when running a new one.
- Use different Pipe IDs -- these are used to identify independent bandwidth lines to the target in order to split the workload in a way that will aggregate the collective bandwidth.
After that, they will build and maintain their network themselves.
Running the first Dispatcher:
arachni_rpcd --pipe-id="Pipe 1" --nickname="My Dispatcher" --address=192.168.0.1
Adding more in order to form a Grid:
arachni_rpcd --pipe-id="Pipe 2" --nickname="My second Dispatcher" --address=192.168.0.2 --neighbour=192.168.0.1:7331
Lather, rinse, repeat:
arachni_rpcd --pipe-id="Pipe 3" --nickname="My third Dispatcher" --address=192.168.0.3 --neighbour=192.168.0.2:7331
arachni_rpcd --pipe-id="Pipe 4" --nickname="My forth Dispatcher" --address=192.168.0.4 --neighbour=192.168.0.3:7331
The above setup assumes that each Dispatcher is on a machine with independent bandwidth lines
(to the target website at least). If you want to, out of curiosity, start a few Dispatchers on
localhost
you will need to specify unique port numbers for them:
arachni_rpcd --pipe-id="Pipe 1" --nickname="My Dispatcher"
arachni_rpcd --pipe-id="Pipe 2" --nickname="My second Dispatcher" --port=1111 --neighbour=localhost:7331
arachni_rpcd --pipe-id="Pipe 3" --nickname="My third Dispatcher" --port=2222 --neighbour=localhost:1111
This is very important, you should read it thoroughly.
By default, all connections are performed over encrypted sockets using SSL. This takes care of encryption but not authN/authZ which is a very important issue when it comes to the Dispatcher.
The Dispatcher is a dispatch server, and as such, its focus is on maintaining a pool of running servers, ready to be used at a moment's notice. A major part of maintaining that pool is replenishing it once a dispatch call has been performed -- i.e. when a server if pop'ed from the pool, another one must be pushed.
When you take into account that server shutdown is delegated to the client the security issue becomes crystal clear. Clients can easily fork-bomb the machine on which a Dispatcher is running.
This makes it crucial to provide Dispatcher access to trusted clients only. Sufficient authN/authZ can be achieved by either:
- Configuring the relevant SSL options for both the clients and dispatch servers.
- Rolling your own network security scheme via a VPN or something similar.
The help output of the RPC server if fairly straightforward:
Arachni - Web Application Security Scanner Framework v1.0dev
Author: Tasos "Zapotek" Laskos <tasos.laskos@gmail.com>
(With the support of the community and the Arachni Team.)
Website: http://arachni-scanner.com
Documentation: http://arachni-scanner.com/wiki
Usage: arachni_rpcd [options]
Supported options:
-h
--help output this
--address=<host> specify address to bind to
(Default: localhost)
--port=<num> specify port to listen to
(Default: 7331)
--port-range=<beginning>-<end>
specify port range for the RPC instances
(Make sure to allow for a few hundred ports.)
(Default: 1025-65535)
--reroute-to-logfile reroute all output to a logfile under 'logs/'
--pool-size=<num> how many server workers/processes should be available
at any given moment (Default: 5)
--neighbour=<URL> URL of a neighbouring Dispatcher (used to build a grid)
--weight=<float> weight of the Dispatcher
--pipe-id=<string> bandwidth pipe identification
--nickname=<string> nickname of the Dispatcher
--debug
SSL --------------------------
(All SSL options will be honored by the dispatched RPC instances as well.)
(Do *not* use encrypted keys!)
--ssl-pkey <file> location of the server SSL private key (.pem)
(Used to verify the server to the clients.)
--ssl-cert <file> location of the server SSL certificate (.pem)
(Used to verify the server to the clients.)
--node-ssl-pkey <file> location of the client SSL private key (.pem)
(Used to verify this node to other servers.)
--node-ssl-cert <file> location of the client SSL certificate (.pem)
(Used to verify this node to other servers.)
--ssl-ca <file> location of the CA certificate (.pem)
If you are interested in providing webappsec scanning services you can write your own client using the RPC API.
Pages [all]
Can't find what you're looking for? Why not have a look at the support portal?