OnWorks Linux and Windows Online WorkStations

Logo

Free Hosting Online for WorkStations

< Previous | Contents | Next >

10.2.2. Executing Commands on Minions‌


As soon as minions are connected, you can execute commands on them from the master:


master# salt ’*’ test.ping

kali-scratch:

True kali-master:

True

master# salt ’*’ test.ping

kali-scratch:

True kali-master:

True


This command asks all minions (the ’*’ is a wildcard targeting all minions) to execute the ping function from the test execution module. This function returns a True value on success and is a simple way to ensure that the connection is working between the master and the various minions.

You can also target a specific minion by giving its identifier in the first parameter, or possibly a subset of minions by using a less-generic wildcard (such as ’*-scratch’ or ’kali-*’). Here is an example of how to execute an arbitrary shell command on the kali-scratch minion:


master# salt kali-scratch cmd.shell ’uptime; uname -a’

kali-scratch:

05:25:48 up 44 min, 2 users, load average: 0.00, 0.01, 0.05

Linux kali-scratch 4.5.0-kali1-amd64 #1 SMP Debian 4.5.3-2kali1 (2016-05-09) x86_64

GNU/Linux

master# salt kali-scratch cmd.shell ’uptime; uname -a’

kali-scratch:

05:25:48 up 44 min, 2 users, load average: 0.00, 0.01, 0.05

Linux kali-scratch 4.5.0-kali1-amd64 #1 SMP Debian 4.5.3-2kali1 (2016-05-09) x86_64

GNU/Linux


Salt Module Reference There are many execution modules available for all sorts of use cases. We won’t cover them all here, but the full list is available at https://docs.saltstack.com/ en/latest/ref/modules/all/index.html. You can also obtain a description of all the execution modules and their available functions on a given minion with the salt minion sys.doc command. Running this command returns a very long list of func- tions, but you can filter the list by passing the name of a function or module prefixed by its parent module as a parameter:

master# salt kali-scratch sys.doc disk.usage

disk.usage:


Return usage information for volumes mounted on this

minion


One of the most useful modules is pkg, which is a package manager abstraction relying on the appropriate package manager for the system (apt-get for Debian and its derivatives like Kali).

The pkg.refresh_db command updates the package list (that is, it performs apt-get update) while pkg.upgrade installs all the available updates (it performs apt-get upgrade or apt-get dist-upgrade, depending on the options received). The pkg.list_upgrades command lists the pending upgrade operations (that would be performed by the pkg.upgrade dist_upgrade=True command).

The service module is an abstraction of the service manager (systemd in the case of Kali), which lets you perform all the usual systemctl operations: service.enable, service.disable, service. start, service.stop, service.restart, and service.reload:


master# salt ’*’ service.enable ssh

kali-scratch:

True kali-master:

True

master# salt ’*’ service.start ssh

kali-master:

True

kali-scratch:

True

master# salt ’*’ pkg.refresh_db

kali-scratch:

----------

kali-master:

----------

master# salt ’*’ pkg.upgrade dist_upgrade=True

kali-scratch:

----------

changes:

----------

base-files:

----------

new:

1:2016.2.1

old:

1:2016.2.0

[...]

zaproxy:

----------

new:

2.5.0-0kali1 old:

2.4.3-0kali3

comment: result:

True

master# salt ’*’ service.enable ssh

kali-scratch:

True kali-master:

True

master# salt ’*’ service.start ssh

kali-master:

True

kali-scratch:

True

master# salt ’*’ pkg.refresh_db

kali-scratch:

----------

kali-master:

----------

master# salt ’*’ pkg.upgrade dist_upgrade=True

kali-scratch:

----------

changes:

----------

base-files:

----------

new:

1:2016.2.1

old:

1:2016.2.0

[...]

zaproxy:

----------

new:

2.5.0-0kali1 old:

2.4.3-0kali3

comment: result:

True

As a more concrete sample, you could easily set up a distributed Nmap scan with dnmap. After having installed the package on all the minions, you start the server in a first terminal:


server# salt ’*’ pkg.install dnmap

[...]

server# vim dnmap.txt

server# dnmap_server -f dnmap.txt

server# salt ’*’ pkg.install dnmap

[...]

server# vim dnmap.txt

server# dnmap_server -f dnmap.txt


Assuming that the server IP is 1.2.3.4, you can next tell all minions to start a client process that connects to the server:


server# salt ’*’ cmd.run_bg template=jinja ’dnmap_client -s 1.2.3.4 -a {{ grains.id }}’

kali-scratch:

----------

pid:

17137

[...]

server# salt ’*’ cmd.run_bg template=jinja ’dnmap_client -s 1.2.3.4 -a {{ grains.id }}’

kali-scratch:

----------

pid:

17137

[...]


Note that the example uses cmd.run_bg to run the dnmap_client command in the background. Don’t wait until it finishes, since it is a long-running process. Unfortunately, it doesn’t kill itself properly when you interrupt the server so you might have to clean it up:


server# salt ’*’ cmd.shell ’pkill -f dnmap_client’

server# salt ’*’ cmd.shell ’pkill -f dnmap_client’


Top OS Cloud Computing at OnWorks: