Distributed & real time digital forensics at the speed of the cloud
Перейти к файлу
Aaron Meihm d0e77beaf8 file: honor matchlimit, uses channels for result processing
The matchlimit option to the file module was not working correctly due
to a couple reasons.

First, it relied on the Totalhits value in the module statistics to
compare the number of hits to the match limit. This value was compiled
in buildResults, so was 0 throughout module execution. Because of this
matchlimit would never be exceeded.

Also, the comparison to Totalhits was only occuring on directory entry.
This means if the match limit was hit while scanning a single directory,
it would continue to scan files exceeding the match limit.

This modifies the way results are processed by Search types, so
individual checks submit matched files via a channel to the parent
Search entry. The Search entry can then maintain a list of matches, and
increment Totalhits as required while the processing is occuring instead
of in buildResults.

Closes #382
2017-08-21 16:58:33 -05:00
actions
client mig-cmd: printAndExit, don't treat NewClient errors as fatal 2017-07-26 15:13:42 -05:00
conf remove agent-intel-worker 2017-07-25 13:46:01 -05:00
database
doc <doc/rst: Fix a typo in link to file.go> 2017-07-19 00:54:47 +02:00
mig-agent Merge pull request #365 from tydavis/issue235 2017-07-12 14:59:52 -05:00
mig-api mig-api: commandsToComplianceItems, make Tags a map 2017-07-25 13:50:11 -05:00
mig-loader [minor] update comments for loader TAGS value 2017-07-06 16:10:16 -05:00
mig-runner
mig-scheduler
modules file: honor matchlimit, uses channels for result processing 2017-08-21 16:58:33 -05:00
pgp
runner-plugins runner-scribe: apply a v2bkey based on operator and team values 2017-07-27 13:13:17 -05:00
service
testutil
tools Merge pull request #345 from rezen/master 2017-07-06 15:57:00 -05:00
vendor vendor updates from gozdef 2017-07-26 16:58:03 -05:00
workers remove agent-intel-worker 2017-07-25 13:46:01 -05:00
.gitignore [minor] ignore custom built-in configs in gitignore 2017-07-10 13:57:43 -05:00
.travis.yml
AUTHORS
CONTRIBUTING.md update CONTRIBUTING.md, remove requirement to tag commits 2017-07-12 09:43:39 -05:00
Dockerfile
LICENSE
Makefile remove agent-intel-worker 2017-07-25 13:46:01 -05:00
README.md
acl.go
action.go [minor/bug] in SignAction, remove temporary file 2017-04-25 10:38:02 -05:00
agent.go in mig.Agent, declare Tags as a map for Agent type 2017-07-25 13:51:39 -05:00
command.go
constants.go
investigator.go
loader.go
logging_posix.go
logging_windows.go [medium/bug] on windows, close log file before rotate 2017-05-25 15:47:50 -05:00
manifest.go
misc.go
runner.go
version.go

README.md

MIG: Mozilla InvestiGator

Build Status

MIG is Mozilla's platform for investigative surgery of remote endpoints.

Quick Start w/ Docker

You can spin up a local-only MIG setup using docker. The container is not suitable for production use but lets you experiment with MIG quickly.

$ docker pull mozilla/mig
$ docker run -it mozilla/mig

Once inside the container, you can use the MIG tools to query a local agent, as such:

mig@5345268590c8:~$ mig file -t all -path /usr/bin -sha2 5c1956eba492b2c3fffd8d3e43324b5c477c22727385be226119f7ffc24aad3f
1 agents will be targeted. ctrl+c to cancel. launching in 5 4 3 2 1 GO
Following action ID 7978299359234.
 1 / 1 [=========================================================] 100.00% 0/s4s
100.0% done in 3.029105958s
1 sent, 1 done, 1 succeeded
ed11f485244a /usr/bin/wget [lastmodified:2016-07-05 15:32:42 +0000 UTC, mode:-rwxr-xr-x, size:419080] in search 's1'
1 agent has found results

To explore the capabilities of MIG, take a look at the CheatSheet.

What is this?

MIG is composed of agents installed on all systems of an infrastructure that are be queried in real-time to investigate the file-systems, network state, memory or configuration of endpoints.

Capability Linux MacOS Windows
file inspection check check check
network inspection check check (partial)
memory inspection check check check
vuln management check (planned) (planned)
log analysis (planned) (planned) (planned)
system auditing (planned) (planned) (planned)

Imagine it is 7am on a saturday morning, and someone just released a critical vulnerability for your favorite PHP application. The vuln is already exploited and security groups are releasing indicators of compromise (IOCs). Your weekend isn't starting great, and the thought of manually inspecting thousands of systems isn't making it any better.

MIG can help. The signature of the vulnerable PHP app (the md5 of a file, a regex, or just a filename) can be searched for across all your systems using the file module. Similarly, IOCs such as specific log entries, backdoor files with md5 and sha1/2/3 hashes, IP addresses from botnets or byte strings in processes memories can be investigated using MIG. Suddenly, your weekend is looking a lot better. And with just a few commands, thousands of systems will be remotely investigated to verify that you're not at risk.

MIG command line demo

MIG agents are designed to be lightweight, secure, and easy to deploy so you can ask your favorite sysadmins to add it to a base deployment without fear of breaking the entire production network. All parameters are built into the agent at compile time, including the list and ACLs of authorized investigators. Security is enforced using PGP keys, and even if MIG's servers are compromised, as long as our keys are safe on your investigator's laptop, no one will break into the agents.

MIG is designed to be fast, and asynchronous. It uses AMQP to distribute actions to endpoints, and relies on Go channels to prevent components from blocking. Running actions and commands are stored in a Postgresql database and on disk cache, such that the reliability of the platform doesn't depend on long-running processes.

Speed is a strong requirement. Most actions will only take a few hundreds milliseconds to run on agents. Larger ones, for example when looking for a hash in a big directory, should run in less than a minute or two. All in all, an investigation usually completes in between 10 and 300 seconds.

Privacy and security are paramount. Agents never send raw data back to the platform, but only reply to questions instead. All actions are signed by GPG keys that are not stored in the platform, thus preventing a compromise from taking over the entire infrastructure.

Technology

MIG is built in Go and uses a REST API that receives signed JSON messages distributed to agents via RabbitMQ and stored in a Postgres database.

It is:

  • Massively Distributed means Fast.
  • Simple to deploy and Cross-Platform.
  • Secured using OpenPGP.
  • Respectful of privacy by never retrieving raw data from endpoints.

Check out this 10 minutes video for a more general presentation and a demo of the console interface.

MIG youtube video

MIG was recently presented at the SANS DFIR Summit in Austin, Tx. You can watch the recording below:

MIG @ DFIR Summit 2015

Discussion

Join #mig on irc.mozilla.org (use a web client such as mibbit).

We also have a public mailing list at list@mig.ninja.

Documentation

All documentation is available in the 'doc' directory and on http://mig.mozilla.org .

Testing

Assuming you have a dedicated Ubuntu system (like a VM), you can use the standalone installation script to deploy a test environment rapidly.

$ sudo apt-get install golang git

# must be >= 1.5
$ go version
go version go1.6.1 linux/amd64

$ export GOPATH=$HOME/go

$ mkdir $GOPATH

$ go get mig.ninja/mig

$ cd $GOPATH/src/mig.ninja/mig

$ bash tools/standalone_install.sh

This script will install all of the components MIG needs for a localhost only installation. Follow instructions at the end of the script to convert it to a real infrastructure, or read Installation & Configuration.