High level¶

• Provide a platform for use by defenders to rapidly discover and respond to security incidents.
• Automate interfaces to other systems like MIG, flowspec, load balancers, etc
• Provide metrics for security events and incidents
• Facilitate real-time collaboration amongst incident handlers
• Facilitate repeatable, predictable processes for incident handling
• Go beyond traditional SIEM systems in automating incident handling, information sharing, workflow, metrics and response automation

Technical¶

• Replace a Security Information and Event Management (SIEM)
• Scalable, should be able to handle thousands of events per second, provide fast searching, alerting, correlation and handle interactions between teams of incident handlers.

MozDef aims to provide traditional SIEM functionality including:

• Accepting events/logs from a variety of systems
• Storing events/logs
• Facilitating searches
• Facilitating alerting
• Facilitating log management (archiving,restoration)

It is non-traditional in that it:

• Accepts only JSON input
• Provides you open access to your data
• Integrates with a variety of log shippers including heka, logstash, beaver, nxlog and any shipper that can send JSON to either rabbit-mq or an HTTP endpoint.
• Provides easy python plugins to manipulate your data in transit
• Provides realtime access to teams of incident responders to allow each other to see their work simultaneously

Frontend processing¶

Frontend processing for MozDef consists of receiving an event/log (in json) over HTTP(S) or AMQP(S), doing data transformation including normalization, adding metadata, etc. and pushing the data to elasticsearch.

Internally MozDef uses RabbitMQ to queue events that are still to be processed. The diagram below shows the interactions between the python scripts (controlled by uWSGI), the RabbitMQ exchanges and elasticsearch indices.

Event Management¶

From an event management point of view MozDef relies on Elastic Search for:

• event storage
• event archiving
• event indexing
• event searching

This means if you use MozDef for your log management you can use the features of Elastic Search to store millions of events, archive them to Amazon if needed, index the fields of your events, and search them using highly capable interfaces like Kibana.

MozDef differs from other log management solutions that use Elastic Search in that it does not allow your log shippers direct contact with Elastic Search itself. In order to provide advanced functionality like event correlation, aggregation and machine learning, MozDef inserts itself as a shim between your log shippers (rsyslog, syslog-ng, beaver, nxlog, heka, logstash) and Elastic Search. This means your log shippers interact with MozDef directly and MozDef handles translating their events as they make they’re way to Elastic Search.

Event Pipeline¶

The logical flow of events is:

                   +–––––––––––+              +––––––––––––––+
                   |    MozDef +––––––––––––––+              |
+––––––––––+       |    FrontEnd              | Elastic      |
| shipper  +–––––––+–––––––––––+              | Search       |
++++++++++++                                  | cluster      |
++++++++++++                                  |              |
| shipper  +–––––––+–––––––––––+              |              |
+––––––––––+       |    MozDef +-–––––––––––––+              |
                   |    FrontEnd              |              |
                   +–––––––––––+              |              |
                                              +––––––––––––––+

Choose a shipper (logstash, nxlog, beaver, heka, rsyslog, etc) that can send JSON over http(s). MozDef uses nginx to provide http(s) endpoints that accept JSON posted over http. Each front end contains a Rabbit-MQ message queue server that accepts the event and sends it for further processing.

You can have as many front ends, shippers and cluster members as you with in any geographic organization that makes sense for your topology. Each front end runs a series of python workers hosted by uwsgi that perform:

• event normalization (i.e. translating between shippers to a common taxonomy of event data types and fields)
• event enrichment
• simple regex-based alerting
• machine learning on the real-time event stream

Event Enrichment¶

To facilitate event correlation, MozDef allows you to write plugins to populate your event data with consistent meta-data customized for your environment. Through simple python plug-ins this allows you to accomplish a variety of event-related tasks like:

• further parse your events into more details
• geoIP tag your events
• correct fields not properly handled by log shippers
• tag all events involving key staff
• tag all events involving previous attackers or hits on a watchlist
• tap into your event stream for ancilary systems
• maintain ‘last-seen’ lists for assets, employees, attackers

Event Correlation/Alerting¶

Correlation/Alerting is currently handled as a series of queries run periodically against the Elastic Search engine. This allows MozDef to make full use of the lucene query engine to group events together into summary alerts and to correlate across any data source accessible to python.

Incident Handling¶

From an incident handling point of view MozDef offers the realtime responsiveness of Meteor in a web interface. This allows teams of incident responders the ability to see each others actions in realtime, no matter their physical location.

Dockerfile¶

After installing docker, use this to build a new image:

cd docker && sudo make build

Running the container:

sudo make run
(once inside as root)
/etc/init.d/supervisor start

You’re done! Now go to:

• http://localhost:3000 < meteor (main web interface)
• http://localhost:9090 < kibana
• http://localhost:9200 < elasticsearch
• http://localhost:8080 < loginput
• http://localhost:8081 < rest api

Get a terminal in the container¶

An common problem in Docker is that once you start a container, you cannot enter it as there is no ssh by default.

When you make the container, you will enter it as root by default, but if you would like to enter it manually use nsenter present in the util-linux > 2.23 package. Debian and Ubuntu currently provide the 2.20 version so you need to download and compile the source code:

cd /tmp
curl https://www.kernel.org/pub/linux/utils/util-linux/v2.24/util-linux-2.24.tar.gz | tar -zxf-
cd util-linux-2.24
./configure --without-ncurses
make nsenter
cp nsenter /usr/local/bin

Now we can create a script for docker (/usr/local/sbin/dkenter):

#!/bin/bash

CNAME=$1
CPID=$(docker inspect --format '{{ .State.Pid }}' $CNAME)
nsenter --target $CPID --mount --uts --ipc --net --pid

While your MozDef container is running:

docker ps # find the container ID, fc4917f00ead in this example
dkenter fc4917f00ead
root@fc4917f00ead:/# ...
root@fc4917f00ead:/# exit

Summary¶

If you don’t want to install MozDef with docker on your own machine because for example it doesn’t support docker or you fear you don’t have enough memory, AWS supports docker.

1. Create a t2.small instance (enough to test MozDef) with the following details:
   • AMI: Ubuntu LTS-14-04 HVM
   • In “Configure Instance Details”, expand the “Advanced Details” section. Under “User data”, select “As text”. Enter #include https://get.docker.io into the instance “User data”. It will bootstrap docker in your instance boot.
2. In this instance, clone our github repo
3. Follow our docker config install instructions
4. Configure your security group to open the ports you need. Keep in mind that it’s probably a bad idea to have a public facing elasticsearch.

Detailed Steps¶

Step by Step:

Sign into AWS
Choose EC2
Choose Images->AMIs
Find  Public Image ami-a7fdfee2 or a suitable Ubuntu 14.04 LTS(HVM) SSD 64bit server with HVM virtualization.
Choose Launch
Choose an instance type according to your budget. (at least a t2.small)
Choose next: configure instance details
Choose a network or create a VPC
Choose or create a new subnet
Choose to Assign a public IP
Under advanced details: user data choose 'as text' and enter #include https://get.docker.io
Choose next: add storage and add appropriate storage according to your budget
Choose next and add any tags you may want
Choose next and select any security group you may want to limit incoming traffic.
Choose launch and select an ssh key-pair or create a new one for ssh access to the instance.

For easy connect instructions, select your instance in the Ec2 dashboard->instances menu and choose connect for instructions.
ssh into your new instance according to the instructions ^^

clone the github repo to get the latest code:
from your home directory (/home/ubuntu if using the AMI instance from above)
    sudo apt-get update
    sudo apt-get install git
    git clone https://github.com/jeffbryner/MozDef.git

change the settings.js file to match your install:
vim /home/ubuntu/MozDef/docker/conf/settings.js
    <change rootURL,rootAPI, kibanaURL from localhost to the FQDN or ip address of your AMI instance: i.e. http://1.2.3.4 >

Inbound port notes:
You will need to allow the AWS/docker instance to talk to the FQDN or ip address you specify in settings.js
or the web ui will likely fail as it tries to contact internal services.
i.e. you may need to setup custom TCP rules in your AWS security group to allow the instance to talk to itself
if you use the public IP on the ports specified in settings.js. (usually 3000 for meteor, 8081 for rest api, 9090 for kibana and 9200 for kibana/ES)

build docker:
    cd MozDef/docker
    sudo apt-get install make
    sudo make build (this will take awhile)
        [ make build-no-cache     (if needed use to disable docker caching routines or rebuild)
        [ at the end you should see a message like: Successfully built e8e075e66d8d ]

starting docker:
    <build dkenter which will allow you to enter the docker container and control services, change settings, etc>
        sudo apt-get install gcc
        cd /tmp
        curl https://www.kernel.org/pub/linux/utils/util-linux/v2.24/util-linux-2.24.tar.gz | tar -zxf-
        cd util-linux-2.24
        ./configure --without-ncurses
        make nsenter
        sudo cp nsenter /usr/local/bin

        sudo vim /usr/local/bin/dkenter
            #!/bin/bash

            CNAME=$1
            CPID=$(docker inspect --format '{{ .State.Pid }}' $CNAME)
            nsenter --target $CPID --mount --uts --ipc --net --pid

        sudo chmod +x /usr/local/bin/dkenter

    cd && cd MozDef/docker/
    screen
    sudo make run
    (once inside the container)
    #/etc/init.d/supervisor start

    Browse to http://youripaddress:3000 for the MozDef UI

Build notes:
************
You can sign in using any Persona-enabled service (i.e. any yahoo or gmail account will work)
supervisor config that starts everything is in /etc/supervisor/conf.d/supervisor.conf
MozDef runs as root in /opt/MozDef
Logs are in /var/log/mozdef
MozDef will automatically start sending sample events to itself. To turn this off:
    0) get a new screen ( ctrl a c)
    1) sudo docker ps (to get the container id)
    2) sudo dkenter <containerid>
    3) supervisorctl
    4) stop realTimeEvents

ElasticSearch¶

Installation instructions are available on Elasticsearch website. You should prefer packages over archives if one is available for your distribution.

Marvel plugin¶

Marvel is a monitoring plugin developed by Elasticsearch (the company).

WARNING: this plugin is NOT open source. At the time of writing, Marvel is free for development but you have to get a license for production.

To install Marvel, on each of your elasticsearch node, from the Elasticsearch home directory:

sudo bin/plugin -i elasticsearch/marvel/latest
sudo service elasticsearch restart

You should now be able to access to Marvel at http://any-server-in-cluster:9200/_plugin/marvel

Python¶

Create a mozdef user:

adduser mozdef

We need to install a python2.7 virtualenv.

On Yum-based systems:

sudo yum install make zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel pcre-devel gcc gcc-c++ mysql-devel

On APT-based systems:

sudo apt-get install make zlib1g-dev libbz2-dev libssl-dev libncurses5-dev libsqlite3-dev libreadline-dev tk-dev libpcre3-dev libpcre++-dev build-essential g++ libmysqlclient-dev

Then:

su - mozdef
wget http://python.org/ftp/python/2.7.6/Python-2.7.6.tgz
tar xvzf Python-2.7.6.tgz
cd Python-2.7.6
./configure --prefix=/home/mozdef/python2.7 --enable-shared
make
make install

cd /home/mozdef

wget https://bootstrap.pypa.io/get-pip.py
export LD_LIBRARY_PATH=/home/mozdef/python2.7/lib/
./python2.7/bin/python get-pip.py
./python2.7/bin/pip install virtualenv
mkdir ~/envs
cd ~/envs
~/python2.7/bin/virtualenv mozdef
source mozdef/bin/activate
pip install -r MozDef/requirements.txt

At this point when you launch python, It should tell you that you’re using Python 2.7.6.

Whenever you launch a python script from now on, you should have your mozdef virtualenv actived and your LD_LIBRARY_PATH env variable should include /home/mozdef/python2.7/lib/

RabbitMQ¶

RabbitMQ is used on workers to have queues of events waiting to be inserted into the Elasticsearch cluster (storage).

To install it, first make sure you enabled EPEL repos. Then you need to install an Erlang environment. On Yum-based systems:

sudo yum install erlang

You can then install the rabbitmq server:

sudo rpm --import http://www.rabbitmq.com/rabbitmq-signing-key-public.asc
sudo yum install rabbitmq-server

To start rabbitmq at startup:

chkconfig rabbitmq-server on

On APT-based systems

sudo apt-get install rabbitmq-server
sudo invoke-rc.d rabbitmq-server start

Meteor¶

Meteor is a javascript framework used for the realtime aspect of the web interface.

We first need to install Mongodb since it’s the DB used by Meteor.

On Yum-based systems:

In /etc/yum.repo.d/mongo, add:

[mongodb]
name=MongoDB Repository
baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/
gpgcheck=0
enabled=1

Then you can install mongodb:

sudo yum install mongodb

On APT-based systems:

sudo apt-get install mongodb-server

For meteor, in a terminal:

curl https://install.meteor.com/ | sh

wget http://nodejs.org/dist/v0.10.26/node-v0.10.26.tar.gz
tar xvzf node-v0.10.26.tar.gz
cd node-v0.10.26
./configure
make
sudo make install

Make sure you have meteorite/mrt (run as root/admin):

npm install -g meteorite

Then from the meteor subdirectory of this git repository (/home/mozdef/MozDef/meteor) run:

mrt add iron-router
mrt add accounts-persona

You may want to edit the app/lib/settings.js file to properly point to your elastic search server:

elasticsearch={
  address:"http://servername:9200/",
  healthurl:"_cluster/health",
  docstatsurl:"_stats/docs"
}

Then start meteor with:

meteor

Node¶

Alternatively you can run the meteor UI in ‘deployment’ mode using a native node installation.

First install node:

yum install bzip2 gcc gcc-c++ sqlite sqlite-devel
wget http://nodejs.org/dist/v0.10.25/node-v0.10.25.tar.gz
tar xvfz node-v0.10.25.tar.gz
cd node-v0.10.25
python configure
make
make install

Then bundle the meteor portion of mozdef:

cd <your meteor mozdef directory>
meteor bundle mozdef.tgz

You can then deploy the meteor UI for mozdef as necessary:

scp mozdef.tgz to your target host
tar -xvzf mozdef.tgz

This will create a ‘bundle’ directory with the entire UI code below that directory.

You will need to update the settings.js file to match your servername/port:

vim bundle/programs/server/app/app/lib/settings.js

If your development OS is different than your production OS you will also need to update the fibers node module:

cd bundle/programs/server/node_modules
rm -rf fibers
sudo npm install fibers@1.0.1

Then run the mozdef UI via node:

export MONGO_URL=mongodb://mongoservername:3002/meteor
export ROOT_URL=http://meteorUIservername/
export PORT=443
node bundle/main.js

Nginx¶

We use nginx webserver.

You need to install nginx:

sudo yum install nginx

On apt-get based system:

sudo apt-get nginx

If you don’t have this package in your repos, before installing create /etc/yum.repos.d/nginx.repo with the following content:

[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/6/$basearch/
gpgcheck=0
enabled=1

UWSGI¶

We use uwsgi to interface python and nginx:

wget http://projects.unbit.it/downloads/uwsgi-2.0.2.tar.gz
tar zxvf uwsgi-2.0.2.tar.gz
cd uwsgi-2.0.2
~/python2.7/bin/python uwsgiconfig.py --build
~/python2.7/bin/python uwsgiconfig.py  --plugin plugins/python core
cp python_plugin.so ~/envs/mozdef/bin/
cp uwsgi ~/envs/mozdef/bin/

cp -r ~/MozDef/rest   ~/envs/mozdef/
cp -r ~/MozDef/loginput   ~/envs/mozdef/
mkdir ~/envs/mozdef/logs

cd ~/envs/mozdef/rest
# modify config file
vim index.conf
# modify uwsgi.ini
vim uwsgi.ini
uwsgi --ini uwsgi.ini

cd ../loginput
# modify uwsgi.ini
vim uwsgi.ini
uwsgi --ini uwsgi.ini

sudo cp nginx.conf /etc/nginx
# modify /etc/nginx/nginx.conf
sudo vim /etc/nginx/nginx.conf
sudo service nginx restart

Kibana¶

Kibana is a webapp to visualize and search your Elasticsearch cluster data:

wget https://download.elasticsearch.org/kibana/kibana/kibana-3.0.0milestone5.tar.gz
tar xvzf kibana-3.0.0milestone5.tar.gz
mv kibana-3.0.0milestone5 kibana
# configure /etc/nginx/nginx.conf to target this folder
sudo service nginx reload

To initialize elasticsearch indices and load some sample data:

cd examples/es-docs/
python inject.py

Start Services¶

Start the following services

cd ~/MozDef/mq ./esworker.py

cd ~/MozDef/alerts celery -A celeryconfig worker –loglevel=info –beat

cd ~/MozDef/examples/demo ./syncalerts.sh ./sampleevents.sh

Start Services¶

To start the following services you can place the init scripts under /etc/init.d/ and set them to executable. You can find the init scripts in the MozDef/initscripts directory. Or you can start them manually.

The initscripts included will match the following startup commands:

1. /etc/init.d/rabbitmq-server start or systemctl start rabbitmq-server

   $ invoke-rc.d rabbitmq-server start

2. /etc/init.d/elasticsearch start or systemctl start elasticsearch

   $ service elasticsearch start

3. /etc/init.d/nginx start or systemctl start nginx

   $ service nginx start

4. /etc/init.d/mozdefloginput start

   $ cd $MOZDEF_PATH/loginput && uwsgi –ini uwsgi.ini

5. /etc/init.d/mozdefrestapi start

   $ cd $MOZDEF_PATH/rest && uwsgi –ini uwsgi.ini

6. /etc/init.d/mozdefmq start

   $ cd $MOZDEF_PATH/mq && uwsgi –ini uwsgi.ini

7. /etc/init.d/mozdefalerts start

   $ cd $MOZDEF_PATH/bin && supervisord -c /home/mozdef/envs/mozdef/alerts/supervisord.alerts.conf

8. /etc/init.d/mozdefalertsplugin start

   $ cd $MOZDEF_PATH/alerts && uwsgi –ini uwsgi-alertsplugin.ini

9. /etc/init.d/mozdefweb start

   $ cd $MOZDEF_PATH/meteor && meteor run

Events visualizations¶

Since the backend of MozDef is Elastic Search, you get all the goodness of Kibana with little configuration. The MozDef UI is focused on incident handling and adding security-specific visualizations of SIEM data to help you weed through the noise.

Alerts¶

Alerts are implemented as Elastic Search searches. MozDef provides a plugin interface to allow open access to event data for enrichment, hooks into other systems, etc.

Incident handling¶

What should I log?¶

If your program doesn’t log anything it doesn’t exist. If it logs everything that happens it becomes like the proverbial boy who cried wolf. There is a fine line between logging too little and too much but here is some guidance on key events that should be logged and in what detail.

Background¶

Mozilla used CEF as a logging standard for compatibility with Arcsight and for standardization across systems. While CEF is an admirable standard, MozDef prefers JSON logging for the following reasons:

• Every development language can create a JSON structure
• JSON is easily parsed by computers/programs which are the primary consumer of logs
• CEF is primarily used by Arcsight and rarely seen outside that platform and doesn’t offer the extensibility of JSON
• A wide variety of log shippers (heka, logstash, fluentd, nxlog, beaver) are readily available to meet almost any need to transport logs as JSON.
• JSON is already the standard for cloud platforms like amazon’s cloudtrail logging

Description¶

As there is no common RFC-style standard for json logs, we prefer the following structure adapted from a combination of the graylog GELF and logstash specifications.

Note all fields are lowercase to avoid one program sending sourceIP, another sending sourceIp, another sending SourceIPAddress, etc. Since the backend for MozDef is elasticsearch and fields are case-sensitive this will allow for easy compatibility and reduce potential confusion for those attempting to use the data. MozDef will perform some translation of fields to a common schema but this is intended to allow the use of heka, nxlog, beaver and retain compatible logs.

Mandatory Fields¶

Details substructure (mandatory if such data is sent, otherwise optional)¶

Examples¶

{
    "timestamp": "2014-02-14T11:48:19.035762739-05:00",
    "hostname": "somemachine.in.your.company.com",
    "processname": "/path/to/your/program.exe",
    "processid": 3380,
    "severity": "INFO",
    "summary": "joe login failed",
    "category": "authentication",
    "source": "ldap",
    "tags": [
        "ldap",
        "adminAccess",
        "failure"
    ],
    "details": {
        "username": "joe",
        "task": "access to admin page /admin_secret_radioactiv",
        "result": "10 authentication failures in a row"
    }
}

Special Config Items¶

Here are some tips for some key settings:

[options]
esservers=http://server1:9200,http://server2:9200,http://server3:9200

is how you can specify servers in your elastic search cluster.

[options]
defaulttimezone=US/Pacific

is how you set the default timezone to something other than UTC

[options]
backup_indices = intelligence,kibana-int,alerts,events,complianceitems,.jsp,.marvel-kibana,vulnerabilities
backup_dobackup = 1,1,1,1,1,1,1,1
backup_rotation = none,none,monthly,daily,none,none,none,none
backup_pruning = 0,0,0,20,0,0,0,0

is how you would configure the backupSnapshot.py and pruneIndexes.py programs to backup selected elastic search indexes, rotate selected indexes and prune certain indexes at selected intervals. In the case above we are backing up all indexes mentioned, rotating alerts monthly, rotating events daily and pruning events indices after 20 days.

[options]
aggregations = category1,category2
aggregationthresholds = 200,120

is how you would configure eventStatsAlerts.py to alert you when you receive a 200% variance in events of category1 and a 120% variance in category2. All other categories will alert at a 100% variance by default.

[options]
autocategorize = True
categorymapping = [{"bruteforce":"bruteforcer"},{"nothing":"nothing"}]

is how you would configure collectAttackers.py to do autocategoization of attackers that it discovers and specify a list of mappings matching alert categories to attacker category.

Myo with TLS/SSL¶

MozDef supports the Myo armband to allow you to navigate the attackers scene using gestures. This works fine if meteor is hosted using http WITHOUT TLS/SSL as the browser will allow you to connect to the server and to the Myo connect which runs a local webserver at http://127.0.0.1:10138 by default. The browser makes a websocket connection to Myo connect and everyone is happy.

When hosting MozDef/Meteor on a TLS/SSL-enabled server things go south quickly. The browser doesn’t like (or permit) a https:// hosted page from accessing a plain text websocket resource such as ws://127.0.0.1:10138.

Luckily you can use nginx to work around this.

On you local workstation you can setup a nginx reverse proxy to allow the browser to do TLS/SSL connections, and use nginx to redirect that 127.0.0.1 traffic from TLS to plain text Myo. Here’s some configs:

First in mozdef you need to add a myoURL option to settings.js:

mozdef = {
  rootURL: "http://yourserver",
  port: "3000",
  rootAPI: "https://yourserver:8444/",
  enableBlockIP: true,
  kibanaURL: "http://yourkibanaserver:9090",
  myoURL: "wss://127.0.0.1:8444/myo/"
}

This tells MozDef to initialize Myo using a local TLS connection to port 8444.

Now install nginx and set a nginx.conf file like so:

http {
    include       mime.types;
    default_type  application/octet-stream;
    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_certificate /path/to/localhost.crt;
    ssl_certificate_key /path/to/localhost.key;

    sendfile        on;
    keepalive_timeout  65;

    proxy_headers_hash_max_size 51200;
    proxy_headers_hash_bucket_size 6400;
    ##ssl version of myo connect##
    server{
        listen  *:8444 ssl;
        #access_log /dev/null main;
         location /{
             proxy_pass http://127.0.0.1:10138;
             proxy_read_timeout 90;
             # WebSocket support (nginx 1.4)
             proxy_http_version 1.1;
             proxy_set_header Upgrade $http_upgrade;
             proxy_set_header Connection "upgrade";
             proxy_redirect     default;
         }
    }
}

You’ll need a SSL certificate that your browser trusts, you can issue a self-signed one and accept it by just browsing to https://127.0.0.1:8443 and accept the cert if necessary.

Start up MozDef, start up your Myo and enjoy!

insert_simple.js¶

insert_simple.js sends indexing requests with 1 log/request.

Usage: node ./insert_simple.js <processes> <totalInserts> <host1> [host2] [host3] [...]

• processes: Number of processes to spawn
• totalInserts: Number of inserts to perform, please note after a certain number node will slow down. You want to have a lower number if you are in this case.
• host1, host2, host3, etc: Elasticsearch hosts to which you want to send the HTTP requests

insert_bulk.js¶

insert_bulk.js sends bulk indexing requests (several logs/request).

Usage: node ./insert_bulk.js <processes> <insertsPerQuery> <totalInserts> <host1> [host2] [host3] [...]

• processes: Number of processes to spawn
• insertsPerQuery: Number of logs per request
• totalInserts: Number of inserts to perform, please note after a certain number node will slow down. You want to have a lower number if you are in this case.
• host1, host2, host3, etc: Elasticsearch hosts to which you want to send the HTTP requests

search_all_fulltext.js¶

search_all_fulltext.js performs search on all indices, all fields in fulltext. It’s very stupid.

Usage: node ./search_all_fulltext.js <processes> <totalSearches> <host1> [host2] [host3] [...]

• processes: Number of processes to spawn
• totalSearches: Number of search requests to perform, please note after a certain number node will slow down. You want to have a lower number if you are in this case.
• host1, host2, host3, etc: Elasticsearch hosts to which you want to send the HTTP requests