Never Ending Security

It starts all here

Tag Archives: Moloch

Moloch – a open source large scale IPv4 full PCAP capturing, indexing and database system.


Moloch

Moloch is an open source, large scale IPv4 packet capturing (PCAP), indexing and database system. A simple web interface is provided for PCAP browsing, searching, and exporting. APIs are exposed that allow PCAP data and JSON-formatted session data to be downloaded directly. Simple security is implemented by using HTTPS and HTTP digest password support or by using apache in front. Moloch is not meant to replace IDS engines but instead work along side them to store and index all the network traffic in standard PCAP format, providing fast access. Moloch is built to be deployed across many systems and can scale to handle multiple gigabits/sec of traffic.

mol2

Impatient?

Run

./easybutton-singlehost.sh

in the Moloch source distribution to build a complete single-machine Moloch system. This is good for a demo and can also be used as a starting point for a real production deployment.

moloch documentation

The Moloch system is comprised of 3 components

  1. capture – A single-threaded C application that runs per network interface. It is possible to run multiple capture processes per machine if there are multiple interfaces to monitor.
  2. viewer – A node.js application that runs per capture machine and handles the web interface and transfer of PCAP files.
  3. elasticsearch – The search database technology powering Moloch.

Hardware Requirements

Moloch is built to run across many machines for large deployments. What follows are rough guidelines for folks capturing large amounts of data with high bit rates, obviously tailor for the situation. It is not recommended to run the capture and elasticsearch processes on the same machines for highly utilized GigE networks. For demo, small network, or home installations everything on a single machine is fine.

  1. Moloch capture/viewer systems
    • One dedicated management network interface and CPU for OS
    • For each network interface being monitored recommend ~10G of memory and another dedicated CPU
    • If running suricata or another IDS add an additional two (2) CPUs per interface, and an additional 5G memory (or more depending on IDS requirements)
    • Disk space to store the PCAP files: We recommend at least 10TB, xfs (with inode64 option set in fstab), RAID 5, at least 5 spindles)
    • Disable swap by removing it from fstab
    • If networks are highly utilized and running IDS then CPU affinity is required

  2. Moloch elasticsearch systems (some black magic here!)
    • 1/4 * Number_Highly_Utilized_Interfaces * Number_of_Days_of_History is a ROUGH guideline for number of elasticsearch instances (nodes) required. (Example: 1/4 * 8 interfaces * 7 days = 14 nodes)
    • Each elasticsearch node should have ~30G-40G memory (20G-30G [no more!] for the java process, at least 10G for the OS disk cache)
    • You can have multiple nodes per machine (Example 64G machine can have 2 ES nodes, 22G for the java process 10G saved for the disk cache)
    • Disable swap by removing it from fstab
    • Obviously the more nodes, the faster responses will be
    • You can always add more nodes, but it’s hard to remove nodes (more on this later)

Example Configuration

Here is an example system setup for monitoring 8x GigE highly-utilized networks, with an average of ~5 Gigabit/sec, with ~7 days of pcap storage.

  • capture/viewer machines
    • 8x PenguinComputing Relion 4724
    • 48GB of memory
    • 40TB of disk-
    • Running Moloch and Suricata

  • elasticsearch machines
    • 10x HP DL380-G7
    • 64GB of memory
    • 2TB of disk
    • Each system running 2 nodes

Ports Used:

  • tcp 8005 – Moloch web interface
  • tcp 9200-920x (configurable upper limit) – Elasticsearch service ports
  • tcp 9300-930x (configurable upper limit) – Elasticsearch mesh connections

mol

Important Considerations

  • Elasticsearch provides no security, so iptables should be used allowing only Moloch machines to talk to the elasticsearch machines (ports 9200-920x) and for them to mesh connect (ports 9300-930x).
  • Moloch machines should be locked down, however they need to talk to each other (port 8005), to the elasticsearch machines (ports 9200-920x), and the web interface needs to be open (port 8005).
  • Moloch viewer should be configured to use SSL.
    • It’s easiest to use a single certificate with multiple DNs.
    • Make sure you protect the cert on the filesystem with proper file permissions.
  • It is possible to set up a Moloch viewer on a machine that doesn’t capture any data that gateways all requests.
    • It is also possible to place apache in front of moloch, so it can handle the authentication and pass the username on to moloch
    • This is how we deploy it
  • A shared password stored in the Moloch configuration file is used to encrypt password hashes AND for inter-Moloch communication.
    • Make sure you protect the config file on the filesystem with proper file permissions.
    • Encrypted password hashes are used so a new password hash can not be inserted intoelasticsearch directly in case it hasn’t been secured.

More information can be found at: https://github.com/aol/moloch and at https://github.com/aol/moloch/wiki